[Summary] This is a small package which installs only only 2 perl scripts, which are called only from maintainer scripts. I don't see any security aspect of this package which would require a review by the security team. There is only one issue I see as potentially blocking MIR, that the two installed perl scripts are in /usr/lib. The FHS appears to prefer that binaries/scripts that are not intended for direct user use should be located in /usr/libexec instead of /usr/lib, though it does still allow use of /usr/lib. But it does state, both for /usr/lib and /usr/libexec, that the application should use a single subdirectory. While it does not explicitly state that applications must use a single subdirectory instead of placing files directly into /usr/lib, my reading of it infers that. https://refspecs.linuxfoundation.org/FHS_3.0/fhs/ch04s06.html https://refspecs.linuxfoundation.org/FHS_3.0/fhs/ch04s07.html However, this wouldn't be the first package in main that chose to drop scripts directly into /usr/lib (e.g. command-not-found). But it would be very rare. I think this should be changed, to place the files into a subdirectory of either /usr/lib or /usr/libexec, or at minimum provide a rationale for dropping the scripts directly into /usr/lib. List of specific binary packages to be promoted to main: - usrmerge Notes: There are a few other trivial issues that I don't believe need to block MIR; I will list them for completeness: 1. the test(s) are not run at build or via autopkgtest (this package is infrequently updated and the developer-run tests are likely sufficient) 2. the d/* maintainter scripts are not chmod +x (the build will set them +x so this is inconsequential) 3. the d/copyright is not in DEP5 format (nice to fix but also inconsequential) [Duplication] There is no other package in main providing the same functionality. [Dependencies] OK: - no other Dependencies to MIR due to this - no -dev/-debug/-doc packages that need exclusion [Embedded sources and static linking] OK: - no embedded source present - no static linking [Security] OK: - history of CVEs does not look concerning - does not run a daemon as root - does not use webkit1,2 - does not use lib*v8 directly - does not parse data formats - does not open a port - does not process arbitrary web content - does not use centralized online accounts - does not integrate arbitrary javascript into the desktop - does not deal with system authentication (eg, pam), etc) [Common blockers] OK: - does not FTBFS currently - The package has a team bug subscriber (foundations) - translation present - not a python/go package, no extra constraints to consider int hat regard Problems: - does not have a test suite that runs at build time - does not have a test suite that runs as autopkgtest [Packaging red flags] OK: - Ubuntu does not carry a delta - symbols tracking not applicable for this kind of code. - d/watch is not present, as this is native package - Upstream update history not applicable (native package) - Debian/Ubuntu update history is good but slowed in recent releases - the current release is packaged - promoting this does not seem to cause issues for MOTUs that so far maintained the package (no Ubuntu delta) - d/rules is rather clean - Does not have Built-Using - Not Go Package Problems: - lintian --pedantic warnings: 1. maintainer scripts are not +x 2. installed perl scripts are located in /usr/lib 3. d/copyright is not in DEP5 format [Upstream red flags] OK: - no Errors/warnings during the build - no incautious use of malloc/sprintf (as far as I can check it) - no use of sudo, gksu, pkexec, or LD_LIBRARY_PATH - no use of user nobody - no use of setuid - no important open bugs (crashers, etc) in Debian or Ubuntu - no dependency on webkit, qtwebkit, seed or libgoa-* - not part of the UI for extra checks