Review for Package: dhcpcd5

[Summary]

MIR team ACK under the constraint to resolve the below listed
required TODOs and as much as possible having a look at the
recommended TODOs.
And let me be clear, while I have a few small requests here and there
it looks much better than the isc-dhcp-client it is replacing.
So please do not consider this a set-back, but a motivational list of todos :-)

This does need a security review, so I'll assign ubuntu-security

List of specific binary packages to be promoted to main: dhcpcd-base
Specific binary packages built, but NOT to be promoted to main: dhcpcd, dhcpcd5

Recommended TODOs:
- #1 please clarify if you even want/need the binary package dhcpcd, AFAICS
  none of the use cases you listed to replace in FO092 are needing a service
  to run on all interfaces. Maybe I'm wrong - it would be helpful to know what
  to expect - will a future system have dhcpcd and run this on all interfaces
  or just dhcpcd-base to call the client as needed on specific interfaces.
- #2 The package should get a team bug subscriber before being promoted


Required TODOs:
- #3 While I understand that the majority of todays test blockers are due to
  package dependencies you'll need to get them running and working. The plan is
  to get this into main in 23.10 and only do the replacement in 24.04. That
  means there should be some way to get this testable (like not uninstalling
  ubuntu-minimal) in 23.10 as well.
   You already started the needed changes in the linked Debian bug discussions
- #4 please fix d/watch to use github tags from
  https://github.com/NetworkConfiguration/dhcpcd/tags
  (it is broken right now)
- #5 please update the packge to something more recent. For now Debian was
  in a freeze which explains it to some extent. But we should start and stay
  recent. (There is also nothing recent in experimental so far.)

[Duplication]
There is an obvious package in main providing the same functionality being
isc-dhcpi-client, but the whole reason to do this is to supersede that.
So this aspect is fine.

[Dependencies]
OK:
- no other Dependencies to MIR due to this
- 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

Problems: None

[Security]
OK:
- does not use webkit1,2
- does not use lib*v8 directly
- does not open a port/socket
- 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, ...)

Problems:
- history of CVEs does look concerning, but given that this is a commonly
  attacked code also not too much to block it (other dhcp implementations
  are similar). We can be happy they are handled ok so far.
- does run a daemon as root
  But that is not true if we only need dhcpcd-base and not dhcpcd as suggested
  above, furthermore the service is at least well hardened.
- does parse data formats (dhcp replies) from an untrusted source - anyone could
  reply to the broadcasts.


[Common blockers]
OK:
- does not FTBFS currently
- does have a test suite that runs at build time
  - test suite fails will fail the build upon error.
- This does not need special HW for build or test
- no new python2 dependency

Problems:
- does have a non-trivial test suite that runs as autopkgtest, but it is
  currently failing. There are great tests, actually a lot on ntp<->dhcp
  and you might think of others to be sure. But the actual problem right now
  is that this test can not work due to the conflicts it has. So right now
  this fails by "badpkg".
  To have it in main we would want those to work well.
  You might need to trick this a bit for now to be able to pre-test it in
  a PPA. Then on the actual change to get it into main it should be ready
  to be regularly auto-tested.
  => https://autopkgtest.ubuntu.com/packages/dhcpcd5

[Packaging red flags]
OK:
- Ubuntu does not carry a delta
- symbols tracking not applicable for this kind of code (no lib).
- Upstream update history is good
- Debian/Ubuntu update history is good
- promoting this does not seem to cause issues for MOTUs that so far
  maintained the package. There has been one update by Julien Lavergne
  6 years ago (Lubuntu), but nothing regular since then that this would
  inhibit.
- no massive Lintian warnings
- debian/rules is rather clean
- It is not on the lto-disabled list

Problems:
- debian/watch is present, but broken
- the current release is not packaged, I understand that Debian was frozen for
  a while, but 9.4.1 is 7 months old. Please get to 10.0.1 or whatever is
  recent then before promoting.

[Upstream red flags]
OK:
- no Errors/warnings during the build
- no incautious use of malloc/sprintf (as far as we can check it)
- no use of sudo, gksu, pkexec, or LD_LIBRARY_PATH (usage is OK inside
  tests)
- no use of user nobody
- no use of setuid
- no important open bugs (crashers, etc) in Debian or Ubuntu
- no dependency on webkit, qtwebkit, seed or libgoa-*
- not part of the UI for extra checks
- no translation present, but none needed for this case (admin/sytsem tool)

Problems: None