© 2004
Canonical Ltd.
•
Terms of use
•
Data privacy
•
Contact Launchpad Support
•
Blog
•
Careers
•
System status
•
a60fb26
(Get the code!)
Review for Source Package: dracut
[Summary]
MIR team ACK under the complex constraints listed below.
This does need a security review, or not, well ....
It really depends on the scope - the current requested scope is just
'dracut-install' which would be fine if fully separated.
Otherwise (read if later anyone wants to use more of dracut) it would need
security review as outlined in the security section below.
List of specific binary packages to be promoted to main: (?dracut-install?)
Specific binary packages built, but NOT to be promoted to main: all others
Required TODOs:
#1 - I mentioned above this would need security review and much more if
staying as-is.
I'm really just looking for a good compromise for you, tell me if you
strongly dislike this :-)
And I'm afraid that even just functionally no one had time yet to deeply
test all the potential interactions with the many Ubuntu packages this
could interact and depends on.
I wanted to ask you what you would think of breaking out
/usr/
Make it a depends from dracut-cure to not break the former use-case in
universe.
With that in place I think we could agree on promoting just dracut-install
to main without the full security-review needed now.
To use more of dracut you can then take your time in further cycles.
Update:
- bdrung and I talked, we will separate dracut-install to pass for now.
- but we will enqueue it into security-review as well as having a look
at all the "later TODOs" plus evaluating dracut for Ubuntu in general.
- Overall that decouples the current urgent needs from the
good-
Recommended TODOs:
#2 - The package should get a team bug subscriber before being promoted
Later TODOs:
This MIR is a special case as I'm reviewing with urgency and a very reduced
use-case in mind. But passing along I've found a few things which should be
looked at once we'd wan't to use more of dracut.
Most of this is "recommended" todo, but should be looked at.
#3 - for now it makes the process and build easier to not use dracut-cpio
but since this is done for speed (which here we really talk about two
boot-time and initramfs update time) it might be worth to experiment and
look at the difference that this might give us.
https:/
https:/
This would be part of "we look at the whole thing" efforts as
we can't be sure yet if it really helps our case.
#4 - Since this generally and especially once introduced for more use case
than just dracut-install will surely hit some edge cases and break
I think this might be a case to have a look at translations.
#5 - resolve netplan interaction in bug 2019940
#6 - please demote pigz to a suggests (or even better consider to add it to main
as the rationale behind this is speed and this should make creation
a bit faster as well)
This is not needed for just dracut-install if split out.
[Duplication]
The only other package in main providing similar functionality is
initramfs-tools and this request is adding dracut aware and intentional
(thanks bdrung for outlining the rationale). We will keep all the mechanisms
in place of initramfs-tools, and only use one command from dracut-core (for now)
[Dependencies]
OK:
- no -dev/-debug/-doc packages that need exclusion
- No dependencies in main that are only superficially tested requiring
more tests now.
Problems:
- "pigz" is not in main, bdrung is aware of this and already mentioned it in
the initial report
[Embedded sources and static linking]
OK:
- 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
Problems: None
- embedded source present in the form of src/dracut-
But right now this isn't used as --enable-
[Security]
OK:
- does not run a daemon as root
- does not use webkit1,2
- does not use lib*v8 directly
- does not parse data formats 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
Problems:
- history of CVEs does not look concerning, but there have been a few cases
of real issues. Now you rightfully called most of them likely to be Suse/RH
specific, but that is a problem in this case.
So far no one has ever inspected this deeply with Ubuntu/Debian in mind, so
this really is worth a security review.
And what was mostly reported were permission and symlink attacks which might
quite likely to be easily missed, if you look at CVE-2015-0267 it wasn't
even in the source of dracut but an interaction with other packages.
And it installs a lot of them as dependencies. I'd not feel comfortable saying
that there surely isn't a bad interaction of this with any of Ubuntus
cpio kmod udev kpartx libkmod2 e2fsprogs cryptsetup dmsetup dmraid lvm2
mdadm console-setup binutils systemd pkg-config
Then OTOH - the "current" change pulling this in does not use any of the real
dracut architecture and I do not want/need to block on this.
- By controlling what is present at early boot it is also indirectly involved
with many important tasks like system authentication, security attestation
and cryptography.
[Common blockers]
OK:
- does not FTBFS currently
- does have a non-trivial test suite that runs as autopkgtest
- This does not need special HW for build or test
- no new python2 dependency
Problems:
- does not have a test suite that runs at build time (ok, as explained by
the reporter that would need permissions and resources the build system
is not meant to have)
[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.
- debian/watch is present and looks ok
- Upstream update history is sporadic (delay, then many) but ok
- Debian/Ubuntu update history is 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
(except a bunch known to bdrung and worked)
- 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 (mostly shell scripts)
- no use of sudo, gksu, pkexec, or LD_LIBRARY_PATH (only in tests)
- no use of user nobody
- no use of setuid / setgid
- no dependency on webkit, qtwebkit, seed or libgoa-*
- not part of the UI for extra checks
Problems:
- important open bugs (crashers, etc) in Debian or Ubuntu
IMHO bug 2019940 is critical if we would use more than dracut-install
- no translation present, but none needed as this is sysadmin level. Ok since
for now we only use the copy tool and nothing of the complexity that might
be worth to communicate well if used