Hi Am Montag, dem 26.09.2022 um 03:04 -0400 schrieb Philip McGrath: > I definitely advocate 'system*'-like functions in general. Still, > 'system'-like functions exist: I'm advocating that Guix should should > have a consistent answer for how such functions should behave. How is the current answer inconsistent?
> From a different perspective, this is part of why I've recently been > thinking we should find 'sh' dynamically: most programs/environments > don't, and shouldn't, need bash{-minimal,-static}, so it seems wrong > to make it a mandatory dependency of libc. Wrong in which sense? Technically, morally, philosophically? I don't think any of the values upheld by the GNU project, such as the four freedoms or the FSDG, nor our code of contract are violated by having bash-static in libc. > I think you're probably referring to the status quo, where "sh" is > looked up in the 'inputs' or a G-expression equivalent and an > absolute reference to that particular "sh" is embedded into the > package being built. (But, when cross-compiling, that "sh" would not > be in the$PATH in the build environment.) You still get an implicit bash-minimal in native-inputs. It's just not a regular input. > First, we have other POSIX-like shells packaged in Guix, such as > dash, zsh, and gash. Currently, to create an environment where one of > these shells is used to run 'system'-like functions (e.g. because > dash is supposed to be faster than bash), you would have to recompile > everything that depends on glibc. (Maybe you could craft a very ugly > graft.) The performance benefits of dash are irrelevant when you compare it to fork and exec. Thus I highly question the point you're trying to make. > Second, sometimes people may want to create environments, images, > etc. without an "sh" available. In some sense this is a special case > of using an alternate shell, but the consequences of the status quo > are especially notable. Currently, practically any environment or > image Guix creates will include bash-static, because glibc refers to > it. And yet, this bash-static will only be inside the container; with even its exact file name unknown and outside of PATH (and even _CS_PATH while we're at it). If your concern is that an attacker might break your containerized application and do arbitrary code execution in bash afterwards, I think you got your priorities mixed up; said attacker could probably side-load a static bash anyway. And I hardly doubt that any concern not related to security is critical either. > Programs in practice seem to look at "/bin/sh", and environments > configuring it by choosing what (possibly nothing) to put at > "/bin/sh" from the perspective of programs in that environment. I mean, both are valid solutions. You're not going to put an unreliable shell as /bin/sh or attempt to shadow sh in your $PATH. confstr and _CS_PATH are for paranoid people who believe you might (and even if you do use it, how sure are you that you're not just getting /bin/sh). > > > I think we should document the decision (for example, why > > > 'bash-static' vs. 'bash- minimal'?) > > > > Because cycles -- bash-minimal is linked to a (shared) glibc, which > > is a separate package from bash-minimal, so glibc cannot use > > bash-minimal, it uses bash-static instead which is linked to a > > (static) glibc (which might use a bootstrap bash (not 100% sure), > > but it's statically linked, so no reference to the bootstrap bash > > remains IIUC). > > > > Also, why? This is an implementation detail. Who would the target > > audience be for this documentation? > > > > I don't mean "document the decision" to necessarily imply something > elaborate or formal, but I think the next person packaging a language > with a function like 'system' in its standard library shouldn't have > to reevaluate these questions from scratch. Also, if we decided the > right thing were to advocate for upstreams to do something > differently for the sake of portability (e.g. trying to get people to > use _CS_PATH---which I'm not suggesting), it would help to have a > rationale to point to. > > Specifically with respect to bash-minimal vs. bash-static, I'm still > not clear on when I should use which. You're not going to need bash-static. For most intents and purposes, you can ignore its existence. In fact, if it bothers you that much, I suggest hiding it like gcc. > The package descriptions are identical, and I haven't found a clear > (to me, at least) explanation in the source code comments. For > example, if bash-static is needed to avoid a cycle as you say, what > is the benefit of also having bash-minimal? bash-minimal is to be used in shell wrappers, as they don't need a full-blown bash (with among others the ability to load extensions, which bash-minimal lacks). Unlike bash-static, bash-minimal can be grafted (both itself and its dependents), so fixing a safety-critical bug in any of those does not cause a world rebuild. Cheers