[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
