Am Samstag, dem 15.10.2022 um 19:23 -0400 schrieb Philip McGrath: > On Saturday, October 1, 2022 12:54:27 PM EDT Ludovic Courtès wrote: > > Hello! > > > > Philip McGrath <phi...@philipmcgrath.com> skribis: > > > 1) If we want to continue to hard-code a specific shell into > > > Glibc, I > > > think we should document the decision (for example, why 'bash- > > > static' vs. > > > 'bash- minimal'?) […] > > > > The choice of ‘bash-static’ rather than ‘bash-minimal’ is motivated > > by > > the fact that, in (gnu packages commencement), we want to make sure > > ‘glibc-final’ does not retain references to its build-time > > environment. > > See #:allowed-references in ‘glibc-final’. > > > > This makes sense as far as using 'bash-static' in Glibc. The aspects > I'm unsure of are: > > 1. If I'm packaging software that implements a function like > 'system' (e.g. Racket, SML/NJ, Chez Scheme, etc.), should I use > 'bash-minimal' or 'bash-static'? > > 2. Do we really need 'bash-minimal' at all? Why not just replace it > with 'bash-static'? We already explained those two to you. Racket, SML/NJ, Chez Scheme et al. are not bootstrap-relevant, thus they can use bash-minimal. Unlike bash-static, bash-minimal can be grafted, i.e. a security bug in bash(- minimal) that necessitates a version bump or similar does not cause a world rebuild. A security bug in bash-static does.
> In particular, AFAICT, 'bash-minimal' currently has a reference to > 'bash-static' via Glibc: > > --8<---------------cut here---------------start------------->8--- > $ guix size bash-minimal > store item > total self > /gnu/store/5h2w4qi9hk1qzzgi1w83220ydslinr4s-glibc-2.33 > 38.3 36.6 50.4% > /gnu/store/094bbaq6glba86h1d4cj16xhdi6fk2jl-gcc-10.3.0-lib > 71.7 33.4 45.9% > /gnu/store/720rj90bch716isd8z7lcwrnvz28ap4y-bash-static-5.1.8 > 1.7 1.7 2.3% > /gnu/store/chfwin3a4qp1znnpsjbmydr2jbzk0d6y-bash-minimal-5.1.8 > 72.7 1.0 1.4% > total: 72.7 MiB > --8<---------------cut here---------------end--------------->8--- Everything has a reference to bash-static. That doesn't mean the static bash is ever invoked. > > > 2) If we want to make 'sh' a weak/dynamic reference, I think we > > > should strongly consider arranging to make it available at > > > '/bin/sh' when present. I expect this option would require less > > > patching of other packages *by far* than any other approach. > > > > This is not a viable option because build containers lack /bin/sh. > > > > Right, this option would depend on making /bin/sh exist in the build > environment. > > I'd hoped this might be possible without having to change the daemon, > but the ways I've tried so far haven't worked. I tried `(mkdir-p > "/bin")`, but the build user apparently doesn't have sufficient > permissions. Then I tried creating a nested container using `call- > with-container` in which I could bind-mound the directory from 'bash- > static' at '/bin', but I hit permissions errors that way, too. I also > thought there might be a way to pass the options like 'build-chroot- > dirs' to have it set up /bin/sh before it > drops privileges, but I couldn't figure out how to do that. > > > Overall, I think the current situation is a reasonable tradeoff. > > It forces us to do some patching, indeed, but I think that’s > > acceptable: we’re talking about a handful of packages. > > > > WDYT? > > > > Ludo’. > > The patching itself isn't so bad, and, as you say, it's limited to at > least a relatively small number of packages. However, the fact that > Glibc retains a reference to 'bash-static' affects nearly every > package. It doesn't affect them very much, to be sure! But I think it > does prevent using `guix shell --container` to create containers > without a shell, and it likewise seems difficult to experiment with > different shells. Or maybe it's really just that it disturbs my sense > of aesthetics. Functionality beats aesthetics. Cheers
