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/lib/dracut/dracut-install into a 'dracut-install' binary package.
     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-but-ok-to-happen-later elements


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://github.com/dracutdevs/dracut/commit/51d21c6b37
     https://github.com/dracutdevs/dracut/commit/afe4a6dbb7
     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-cpio/third_party/
  But right now this isn't used as --enable-dracut-cpio

[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