Hi,
Philip McGrath skribis:
> 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
>
Am Sonntag, dem 16.10.2022 um 03:56 -0400 schrieb Philip McGrath:
> I don't think I understand this. Does it mean that, in the following,
> I am running a Bash that wouldn't have security bugs fixed? If so,
> that seems quite bad!
You would, but note that in order to exploit this, you would have
On Sunday, October 16, 2022 3:04:45 AM EDT Liliana Marie Prikler wrote:
> 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 skribis:
> > > > 1) If we want to continue
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 skribis:
> > > 1) If we want to continue to hard-code a specific shell into
> > > Glibc, I
> > > think we should document the
On Saturday, October 1, 2022 12:54:27 PM EDT Ludovic Courtès wrote:
> Hello!
>
> Philip McGrath 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
Hello!
Philip McGrath 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,
On 26-09-2022 09:04, Philip McGrath wrote:
[...]
(Very occasionally, a program really does want to invoke the shell, such
as when shell expansion is part of an existing API.)
From a different perspective, this is part of why I've recently been
thinking we should find 'sh' dynamically: most
Hi,
Am Montag, dem 26.09.2022 um 04:07 -0400 schrieb Philip McGrath:
> Hi,
>
> On 9/19/22 03:07, Liliana Marie Prikler wrote:
> > Am Sonntag, dem 18.09.2022 um 20:13 -0400 schrieb Philip McGrath:
> > > On the other hand, even Nix puts '/bin/sh' at its usual path: we
> > > are really quite an
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
Hi,
On 9/19/22 03:07, Liliana Marie Prikler wrote:
Am Sonntag, dem 18.09.2022 um 20:13 -0400 schrieb Philip McGrath:
On the other hand, even Nix puts '/bin/sh' at its usual path: we
are really quite an outlier in this respect. (IIUC, Nix also has
'/usr/bin/env', but no other utilities at FHS
Hi,
On 9/19/22 08:55, Maxime Devos wrote:
(4) Stop using 'system' in applications -- instead use whatever the
language's equivalent of Guile's system*, execl ... or Guix'
'invoke'. Why? Because 'system'-like functions requires quoting the
command line arguments whereas in 'system*'-like
On 19-09-2022 02:13, Philip McGrath wrote:
1) If we want to continue to hard-code a specific shell into Glibc,
We do, for reproducibility -- otherwise, the behaviour of the 'system'
function depends on whatever is the current /bin/sh, and sometimes
/bin/sh is updated (and on some foreign
Am Sonntag, dem 18.09.2022 um 20:13 -0400 schrieb Philip McGrath:
> On the other hand, even Nix puts '/bin/sh' at its usual path: we are
> really quite an outlier in this respect. (IIUC, Nix also has
> '/usr/bin/env', but no other utilities at FHS paths.)
We are not. We provide both /bin/sh and
Hi Guix,
The C standard library includes a function 'system' to run a string as a shell
command. Other languages provide similar functions, including Guile and many
other Schemes and the Standard ML Basis Library.[1][2] Even without a
dedicated library function, a program might want to run
14 matches
Mail list logo