Comment 2 for bug 1927004

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

[Summary]
There are only some minor concerns listed below, which shouldn't block
this, so this is ACK from MIR team. Please see Notes and TODOs below.

This does need a security review (though I considered skipping it,
but want to err on the side of safety), so I'll assign ubuntu-security

List of specific binary packages to be promoted to main:
- fence-agents-common
- fence-agents-supported

Just for clarification, list of binary packages to remain in universe:
- fence-agents

Notes:
1) The Ubuntu Server team isn't yet subscribed.
   This is allowed per the new MIR process, but please remember to
   subscribe before the package is promoted to main.
2) The bug description states CVE-2019-10153 was already fixed,
   but that doesn't appear correct per the Ubuntu CVE page:
   https://ubuntu.com/security/CVE-2019-10153
   I don't think this medium CVE needs to block MIR, however.
3) I'm concerned about the split of the binary packages which
   leaves one package in universe; I have no problem with leaving
   a package in universe, but I'm concerned about the naming.
   After this MIR, the packages 'fence-agents-supported' and
   'fence-agents-common' will be in main and fully supported,
   but the generically-named binary package 'fence-agents' will
   remain in universe. I feel like this is going to lead to
   confusion by users of fence agents in the unsupported
   'fence-agents' binary package.

Required TODOs:
1) Ubuntu Server Team must subscribe to the package before
   it's promoted to main.

Recommended TODOs:
1) It might be adding more obviousness than is really needed,
   but I suggest renaming the binary package 'fence-agents'
   to 'fence-agents-unsupported' to make it clear (to users)
   that the agents in the package aren't supported.

[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 open a port
- does not parse data formats
- 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
- does have a test suite that runs at build time
- test suite fails will fail the build upon error.
- does have a test suite that runs as autopkgtest
- no translation present, but none needed for this case
- not a python/go package, no extra constraints to consider in that regard

Problems:
- The package needs Ubuntu Server team to subscribe

[Packaging red flags]
OK:
- Ubuntu does carry a delta, but it is reasonable and maintenance under control
- symbols tracking not applicable for this kind of code.
- d/watch is present and looks ok
- Upstream update history is good
- Debian/Ubuntu update history is good
- the (almost) current release is packaged
- promoting this does not seem to cause issues for MOTUs that so far
  maintained the package
- no massive Lintian warnings
- d/rules is rather clean
- Does not have Built-Using
- not go package
- is not on the lto-disabled list

[Upstream red flags]
OK:
- no incautious use of malloc/sprintf (as far as I can check it)
- no use of user nobody
- no use of setuid
- no important open bugs (crashers, etc) in Debian or Ubuntu or Upstream
- no dependency on webkit, qtwebkit, seed or libgoa-*
- not part of the UI for extra checks

Problems:
- warning during the build, but appears harmless:
  "make[5]: warning: jobserver unavailable: using -j1. Add '+' to parent make rule."
- use of sudo, though usage appears reasonable and is optional