> > The proposed patch splits the busybox package into two subpackages,
> > busybox-core and busybox-suid. The core package contains everything
> > that is currently included in the busybox package except for the
> > bbsuid binary. This will be shipped via the busybox-suid package. The
> > busybox package will be turned into a metapackage that pulls in
> > busybox-core and busybox-suid, so for most use cases nothing will
> > change except for those installations that desire it explicitly.
> I wonder if we somehow can solve this with totally 2 packages:
> busybox + busybox-suid
> instead of totally 3:
> busybox-core + busybox-suid + busybox.
I did not go for this option because it introduces a breaking change, but
it is certainly desirable in the long run. Since 3.3 is now in freeze, it
may be OK to possibly break dependencies here.
> We could for example add busybox-suid as a dependency to alpine-base,
> or assume that busybox-suid is needed if some other package like openrc
> is installed and have install_if="busybox=$pkgver openrc". I wonder
> what happens then, if you "apk add !busybox-suid" to opt out?
Having busybox-suid as a dependency to alpine-base is crucial, but I think
we need to take care of packages that really require it, eg. mkinitfs
without suid could lead to really interesting problems. Having a
metapackage for the transition would soften the blow.
I don't have the overview yet to really offer a qualified opinion here.
> I suppose the most critical thing we want avoid is someone end up
> locked out from remote box due to 'su' not working after an upgrade.
Let me know what you decide is the best way to proceed, I'll make the
necessary modifications to the patch.
Thanks for reviewing this.
Received on Thu Oct 22 2015 - 18:39:30 GMT