[MIR] busybox package

[Utkarsh Gupta]

[Availability]
==============
src:busybox was introduced in Dapper (2006) and has been in main since then. src:busybox & bin:busybox-static are in main, to be more precise. And this request is to promote bin:busybox from src:busybox in main, too. It only depends on the libc6 package, which is in main already. The package builds on all the architectures; is Arch:any.

[Rationale]
===========
This package is to be included in our partner's cloud images, going back to Bionic. As cloud images are to ship only packages from main this request is to see that happen.

[Security]
==========
The binary doesn't install services / daemons (/etc/init.d/*, /etc/init/*, /lib/systemd/system/*). Just ships the "busybox" binary, its docs, and a man page.

[Dependencies]
==============
libc6, which is in main already.

[Maintenance]
=============
Server team.

[Background information]
========================
Tiny utilities for small and embedded systems.

---
Upstream: https://git.busybox.net/busybox/
Launchpad page: https://launchpad.net/ubuntu/+source/busybox
Ubuntu bugs: https://bugs.launchpad.net/ubuntu/+source/busybox
Debian Package Tracker: https://tracker.debian.org/pkg/busybox
Debian bugs: https://bugs.debian.org/cgi-bin/pkgreport.cgi?repeatmerged=no&src=busybox

[Utkarsh Gupta (utkarsh)]

Commenting here to be explicit:
We want to promote bin:busybox until Bionic. So I/H/G/F/B seed changes are expected.

[Didier Roche-Tolomelli (didrocks)]

Note: this is not a full review of the busybox package but rather a difference assessement between the busybox-static and busybox package (as part of this request).

The binary package "busybox" is quite similar to the static one and replaces it. It produces a binary with the same name, linked against libc6 only.
A man page (same than the busybox-static one) is provided and a simple trigger for update-initramfs is in place.
There is nothing special in the control or rules files.

I think this is thus +1 on the MIR-team side. However, as discussed, switching for some part from a statically linked, in a limited environment where busybox-static was running to a dynamically linked, opened one. As discussed during the MIR meeting, this would need a security assessment.

[Seth Arnold (seth-arnold)]

Just how bad are the consequences of not promoting this package to main?

The code is fairly gross. There's absolute gobs of writing outside array bounds, resource leaks, potential uses of uninitialized variables, etc.

I don't know if there's any security-relevant findings -- busybox is almost always restricted solely to a system administrator who is in trouble and needs tools and can't have the Good Tools for whatever reason, so a lot of the choices sort of make sense. However, there's just a lot of choices that may have made sense thirty years ago that just don't make sense today, and a lot of the choices make it much harder to use Coverity or similar tools to find the real bugs.

Actually bringing the entire codebase up to modern standards is not going to be cost-effective (and probably not within the goals of the project).

Thanks

[Christian Ehrhardt  (paelzer)]

Thank you, options are discussed.
I'll set the bug to incomplete to reflect this isn't blocked on security right now.

[Utkarsh Gupta (utkarsh)]

Hello,

Thank you for the review, comments, and suggestions, Seth. We'll investigate other options and see what can be worked out. Closing this until then. Thanks, again.