Comment 1 for bug 1906671

Revision history for this message
Dan Streetman (ddstreet) wrote :

[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