Review for Source Package: coreutils-from
[Summary]
Thanks for reaching out, this could as well have been a part of coreutils
and we'd never have seen it - appreciated.
MIR team ACK
This does not need a security review
List of specific binary packages to be promoted to main:
- coreutils
- coreutils-from-gnu
Specific binary packages built, but NOT to be promoted to main:
- coreutils-from-uutils
- coreutils-from-toybox
- coreutils-from-busybox
These are ok to follow as their dependencies are resolved in individual MIRs.
Functionally this already provides all users need to experiment with either of
them, but would not yet change what is supported.
Recommended TODOs:
#1 - autopkg tests would be perfect here to check if all continues to work
no matter which of the coreutils implementers get updated. I agree that the
actual function is and should stay in the respective packages. But I'd
recommend to consider adding a test for the switching between different
sets of redirection. That has functionality in itself (are all tools
reachable and functional after switching, avoid dangling symlinks, ...)
and is the place that cares about conisstency between them (are all
behaving comparable enough).
[Rationale, Duplication and Ownership]
There is no other package in main providing the same functionality.
In some way it is an enabler to allow different packages that have the same,
but in a constructive way going forward, nothing that the MIR rules are about.
A team is committed to own long term maintenance of this package.
The rationale given in the report seems valid and useful for Ubuntu
[Dependencies]
OK:
- no other Dependencies to MIR due to this (and everyone is aware about the
further deps once we add more)
- no -dev/-debug/-doc packages that need exclusion
- No dependencies in main that are only superficially tested requiring
more tests now.
Problems: None
[Embedded sources and static linking]
OK:
- no embedded source present
- no static linking
- does not have unexpected Built-Using entries
- not a go package, no extra constraints to consider in that regard
- not a rust package, no extra constraints to consider in that regard
To be fair it doesn't have source at all :-)
Problems: None
[Security]
OK:
- history of CVEs does not look concerning (it is new, but given the
function I doubt it would be very bad)
- does not run a daemon as root
- does not use webkit1,2
- does not use lib*v8 directly
- does not parse data formats (files [images, video, audio,
xml, json, asn.1], network packets, structures, ...) from
an untrusted source.
- does not expose any external endpoint (port/socket/... or similar)
- 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)
- does not deal with security attestation (secure boot, tpm, signatures)
- does not deal with cryptography (en-/decryption, certificates,
signing, ...)
- this makes appropriate use of established risk mitigation features (none
as it is not acting, but only redirecting)
Being a coreutils mapper it indirectly deals with some very central system
functions, but all the actual code is in the related packges depended on by
coreutils-from.
Problems: None
[Common blockers]
OK:
- does not FTBFS currently
- This does not need special HW for build or test
- no new python2 dependency
- Python package, but using dh_python
- Go package, but using dh-golang
Problems:
- does not have a test suite that runs at build time
- does not have a non-trivial test suite that runs as autopkgtest
Given what the package does this isn't a requirement. But let me be honest
switching between those is a quite complex thing that can go wrong. I'm tempted
to suggest that adding a test here would be the perfect spot to ensure that
switching between the alternative works smoothly and behaves similar enough.
It isn't gating IMHO, but I'll add it as recommended task.
[Packaging red flags]
OK:
- Ubuntu does not carry a delta (it is native in ubuntu)
- symbols tracking not applicable for this kind of code.
- debian/watch is not present but also not needed (native)
- Upstream/Ubuntu update history is non-existing (new and therefore ok)
- the current release is packaged (could that ever be different for ubuntu
native?)
- promoting this does not seem to cause issues for MOTUs that so far
maintained the package
- no massive Lintian warnings
- debian/rules is rather clean
- It is not on the lto-disabled list
Problems: None
[Upstream red flags]
OK:
- no Errors/warnings during the build
- no incautious use of malloc/sprintf (for once I'm rather sure :-) )
- no use of sudo, gksu, pkexec, or LD_LIBRARY_PATH
- no use of user nobody
- no use of setuid / setgid
- no important open bugs (crashers, etc) in Debian or Ubuntu
- no dependency on webkit, qtwebkit or libseed
- not part of the UI for extra checks
- no translation present, but none needed for this case
Problems: None
** Changed in: coreutils-from (Ubuntu)
Status: New => In Progress
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/2110879
Title:
[MIR] coreutils-from
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/coreutils-from/+bug/2110879/+subscriptions
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
