[Summary] MIR Team Ack for exactly the specified binaries, not more. List of specific binary packages to be promoted to main: debugedit, librpmio9
This does not need a security review, but we want an ack to promote the defined subset of binaries. Those binaries are rather safe, but e.g. the rpm package manager is part of the same src and had quite some CVEs over the years. So tracking CVEs on the source level will be flagged and then on triage rated as "no problem". We have done promotions of a subset of binaries before, but IIRC we always got an "ack we are ok to do so" from security. That is what I'd like to see here as well. Therefore I'm assigning ubuntu-security now. @Matthias - there are a few TODOs below you could look at until security replies Required TODOs: - Subscribe foundation-bugs to the package - librpm-dev needs an extra-exclude before promotion of src:rpm Recommended TODOs: - pick up upstream unit tests at build time test execution to cover debugedit [Special Case] I was reviewing this and it indeed seems to be a special case - thanks for bringing it up Matthias! It is special for multiple reasons: - in terms of the purpose the "debugedit" tool is not strictly tied to rpm usage, rpm* functionality or anything like it. It just happens to be part of that upstream source and was never split. => Yet we do MIR reviews on src-packages :-/ - The dependencies debugedit has to librpmio9 are all isolated to just one function "handle_build_id" and really just for a few basic things like the pgpHashAlgo types and rpmDigest* functions. This - again - isn't very RPM specific. => So it would pull in a lib for a small fraction of it's features that likely also could come from elsewhere - Strictly speaking, for the use case you are after, this is due build time dependency. These days those no more have to be in main. But since we have promoted the core dev tools into main, adding that dependency to debhelper would be a component mismatch still. => So it has to be promoted even thou it would only be used to build and not at runtime - librpmio9 has not much use outside of the rpm source package => so there is no further gain in promoting it That explains why you started directly listing alternative options which would eliminate some or all of the above problems, but at different levels of extra maintenance effort. But TBH - splitting the source or applying Delta just for the sake of the MIR process (but no other gain) is a bad thing. Depending on what alternative we pick we'd loose the help of upstream and/or Debian maintaining it on their end. So while I see the reason to be tempted I don't think we should do it. After all the process does not exist to make things hard, but to ensure a certain quality level and maintenance/security feasibility. A while ago we started to explicitly list the to-be-promoted binaries in such cases and explicitly mention the limited-ack. That would here likely be the best choice for Ubuntu as a whole (in regard to effort vs gain and for not adding complexity artificially). [Duplication] There is no other package in main providing the same functionality. [Dependencies] OK: - no other Dependencies to MIR due to this Problems: - librpm-dev exists and should not be promoted, this will need an entry to extra-excludes before promotion [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 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) Problems: - does parse data formats But the risk of that is low, it will run in build environments where more often than not the build process has root anyway. Not much to exploit further from there. - We will want an ack from security to promote only the subset of binaries. As the rpm package manager being part of the same source isn't as calm, there are some CVEs for that which we'd NOT be affected in main. [Common blockers] OK: - does not FTBFS currently - no translation present, but none needed for this case (user visible)? - not a python/go package, no extra constraints to consider int hat regard - no new python2 dependency Problems: - does not have a test suite that runs at build time Here I think we should improve, upstream ships a testsuite, but dh_auto_test runs make check which doesn't do much. ./test/rpmtests seems extensive, if that could be enabled that would help to ensure no stray update breaks things. - does not have a test suite that runs as autopkgtest There isn't much functionality out of libs or dependencies, so the build-time tests should be sufficient - but if (while implementing build time tests) it seems trivial one might add the same as autopkgtest as well to get rechecked on dependency updates. - The package has no team bug subscriber yet (Foundations is the one planned) [Packaging red flags] OK: - Ubuntu does not carry a delta - symbols tracking is in place - d/watch is present and looks ok - Upstream update history is slow, but ok (nothing bad on being stable) - Debian/Ubuntu update history is ok (a lot of NMUs, but ok) - the 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 [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 Note: for a tool not usually installed there is a high amount of "this pkg is in a broekn state" bugs, but reading through those I didn't find the package to be guilty. Even [1] is not having a lot for debugedit. - no dependency on webkit, qtwebkit, seed or libgoa-* - not part of the UI for extra checks [1]: https://github.com/rpm-software- management/rpm/issues?q=is%3Aissue+is%3Aopen+debugedit ** Changed in: rpm (Ubuntu) Assignee: Christian Ehrhardt (paelzer) => Ubuntu Security Team (ubuntu-security) ** Summary changed: - [MIR] debugedit (binary package built from rpm) + [MIR] debugedit + librpmio9 (binary packages built from src:rpm) -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1913871 Title: [MIR] debugedit + librpmio9 (binary packages built from src:rpm) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/rpm/+bug/1913871/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs