From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <guix-devel-bounces+larch=yhetil.org@gnu.org>
Received: from mp12.migadu.com ([2001:41d0:2:bcc0::])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits))
	by ms5.migadu.com with LMTPS
	id wJeJLSytS2OqPAAAbAwnHQ
	(envelope-from <guix-devel-bounces+larch=yhetil.org@gnu.org>)
	for <larch@yhetil.org>; Sun, 16 Oct 2022 09:05:16 +0200
Received: from aspmx1.migadu.com ([2001:41d0:2:bcc0::])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits))
	by mp12.migadu.com with LMTPS
	id AI57LSytS2NSEgAAauVa8A
	(envelope-from <guix-devel-bounces+larch=yhetil.org@gnu.org>)
	for <larch@yhetil.org>; Sun, 16 Oct 2022 09:05:16 +0200
Received: from lists.gnu.org (lists.gnu.org [209.51.188.17])
	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
	(No client certificate requested)
	by aspmx1.migadu.com (Postfix) with ESMTPS id 0A80F44FB3
	for <larch@yhetil.org>; Sun, 16 Oct 2022 09:05:16 +0200 (CEST)
Received: from localhost ([::1]:57336 helo=lists1p.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.90_1)
	(envelope-from <guix-devel-bounces+larch=yhetil.org@gnu.org>)
	id 1ojxhz-0006en-60
	for larch@yhetil.org; Sun, 16 Oct 2022 03:05:15 -0400
Received: from eggs.gnu.org ([2001:470:142:3::10]:35148)
 by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.90_1) (envelope-from <liliana.prikler@gmail.com>)
 id 1ojxhd-0006ef-OC
 for guix-devel@gnu.org; Sun, 16 Oct 2022 03:04:53 -0400
Received: from mail-ed1-x543.google.com ([2a00:1450:4864:20::543]:38882)
 by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128)
 (Exim 4.90_1) (envelope-from <liliana.prikler@gmail.com>)
 id 1ojxhb-0003If-Gv; Sun, 16 Oct 2022 03:04:53 -0400
Received: by mail-ed1-x543.google.com with SMTP id l22so12042612edj.5;
 Sun, 16 Oct 2022 00:04:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112;
 h=mime-version:user-agent:content-transfer-encoding:references
 :in-reply-to:date:cc:to:from:subject:message-id:from:to:cc:subject
 :date:message-id:reply-to;
 bh=W8gOdT4h8eOe+JFMME8BZPKbfyB5Wx3phEPliuNFb4c=;
 b=id9G/5Obe109QuJQ+4Na/looObvhCA/bfgZ4Ldd3fhSPTHq4fygW61CNOFCvUPJVOd
 tsIQpmS0gOQWpXvCfrU2knnYUDFdU5k4gsuG+Ggi7rMVFvv4Ur82o9DXehveCaOpgkPJ
 eCE+S6amteepUochKvPOVv1X4OP5gv7NPVa7GehaJWBT26ZY78xNHAkan3SM4Ujh98gq
 1PY+HDZ2ougccpIVDgCDqYnlABENEj9F1FRLBGH7d4sjXhYxfMP/B3v/qDVSyv133pRU
 Q/I9n2NLHDw1mGoepbWzSXN7ACyQEpTrMnXm9XX+VwZipvhri0CDQmyLoMR9M0WoZ5Aa
 fBGw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20210112;
 h=mime-version:user-agent:content-transfer-encoding:references
 :in-reply-to:date:cc:to:from:subject:message-id:x-gm-message-state
 :from:to:cc:subject:date:message-id:reply-to;
 bh=W8gOdT4h8eOe+JFMME8BZPKbfyB5Wx3phEPliuNFb4c=;
 b=FbbYOQ3JLF5uYPQ7lFhcfPixrYlmsf84360GOhLr9hjWjH4DzGispCLQPiUs5ApDCO
 ikMhDxwnKgo4IbMYQkGOJZa5GRfqL87cluA1FTYUq9iOGzM5XqDiBurMebgEHQF1TwC2
 G2uMujK4TcXk8YL2ku0vrm8GYxwAvfgM6ilw0loy9o7Axp0U6ViwN9AP31g94NbHb49p
 l0zxwDoJ34mvJJ2+xCIVNdqVkRXJIv6Q0MYRj7tTMY7eOCY+p55n07rB8+EK2W0L2YPe
 txBD+DkpFlhAImEl8apzq+FCJ9jrmpPFZAQc5NN4qBdU3zmOrAVoboFaIrrewxitUJxo
 UlBQ==
X-Gm-Message-State: ACrzQf1T3af/c7UtDN+7BZnPnxeMFg2yDE+rcw0Xkm+mdrZ3NSB7acnM
 3jzXXo1WowVzboZNySGtSJA=
X-Google-Smtp-Source: AMsMyM4ggCp0gJUUT2gnUn2Aer8s8ZhOR/Br0TIsBT7kL80e3Qar849jBe5npGSbyzmaoCr4dfjA9w==
X-Received: by 2002:a05:6402:254f:b0:45d:3044:d679 with SMTP id
 l15-20020a056402254f00b0045d3044d679mr5237231edb.137.1665903887869; 
 Sun, 16 Oct 2022 00:04:47 -0700 (PDT)
Received: from lumine.fritz.box (85-127-52-93.dsl.dynamic.surfer.at.
 [85.127.52.93]) by smtp.gmail.com with ESMTPSA id
 n14-20020a170906840e00b0078d44511979sm4143273ejx.138.2022.10.16.00.04.46
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Sun, 16 Oct 2022 00:04:47 -0700 (PDT)
Message-ID: <7d61f502c9907fd9564e4052c8100aabd4d2828c.camel@gmail.com>
Subject: Re: What 'sh' should 'system' use?
From: Liliana Marie Prikler <liliana.prikler@gmail.com>
To: Philip McGrath <philip@philipmcgrath.com>, Ludovic
 =?ISO-8859-1?Q?Court=E8s?= <ludo@gnu.org>
Cc: guix <guix-devel@gnu.org>, Maxime Devos <maximedevos@telenet.be>
Date: Sun, 16 Oct 2022 09:04:45 +0200
In-Reply-To: <4651725.rnE6jSC6OK@bastet>
References: <2284386.8hzESeGDPO@bastet> <87fsg7cwn0.fsf@gnu.org>
 <4651725.rnE6jSC6OK@bastet>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
User-Agent: Evolution 3.46.0 
MIME-Version: 1.0
Received-SPF: pass client-ip=2a00:1450:4864:20::543;
 envelope-from=liliana.prikler@gmail.com; helo=mail-ed1-x543.google.com
X-Spam_score_int: -20
X-Spam_score: -2.1
X-Spam_bar: --
X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1,
 DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001,
 RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001,
 SPF_PASS=-0.001 autolearn=ham autolearn_force=no
X-Spam_action: no action
X-BeenThere: guix-devel@gnu.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Development of GNU Guix and the GNU System distribution."
 <guix-devel.gnu.org>
List-Unsubscribe: <https://lists.gnu.org/mailman/options/guix-devel>,
 <mailto:guix-devel-request@gnu.org?subject=unsubscribe>
List-Archive: <https://lists.gnu.org/archive/html/guix-devel>
List-Post: <mailto:guix-devel@gnu.org>
List-Help: <mailto:guix-devel-request@gnu.org?subject=help>
List-Subscribe: <https://lists.gnu.org/mailman/listinfo/guix-devel>,
 <mailto:guix-devel-request@gnu.org?subject=subscribe>
Errors-To: guix-devel-bounces+larch=yhetil.org@gnu.org
Sender: "Guix-devel" <guix-devel-bounces+larch=yhetil.org@gnu.org>
X-Migadu-Flow: FLOW_IN
X-Migadu-Country: US
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org;
	s=key1; t=1665903916;
	h=from:from:sender:sender:reply-to:subject:subject:date:date:
	 message-id:message-id:to:to:cc:cc:mime-version:mime-version:
	 content-type:content-type:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references:list-id:list-help:
	 list-unsubscribe:list-subscribe:list-post:dkim-signature;
	bh=W8gOdT4h8eOe+JFMME8BZPKbfyB5Wx3phEPliuNFb4c=;
	b=TTjd/Y4TnXlERCc3XIbLOp+fsb8gn02j6CYOVG2LWa1MIbcQX+Y/vUY0RtsDmTBk4OGRC2
	9wKK0MusgkUtajX7lj5wHgRyg7E9qfR9wctN08VORbeQ/8e0wmj5YhFtKm9BHOwtR8jt/y
	xoN295pVEL8iUFxnc0EcWa/NaEeICJw+3njlFrWwNtWQdVoTnGjgyEPuowdjAU/XGlIXUo
	3hVyUvCRjOuAQATb3trIfbMjSyEveLBMMxMkuqZTwH/KQa32UAVeTJ4yf2DcF0cud4jCRH
	xfUG6/aCR4qc63KYGeXw/uU+dQO+sieksMFfExQYqd69iB5GK44kjPy2xLaw+w==
ARC-Seal: i=1; s=key1; d=yhetil.org; t=1665903916; a=rsa-sha256; cv=none;
	b=UsNnQj2m7kePDvoz/s+qC0cpZ7yqTvSd8EKrcas3qhHxu2hF1sHn5YwaTC8kNzWfok3QTz
	7n2KyraFk9o7I+ZwbNvUjiCtN6SNWNisZjmRuykB4sGCKyvrryGWH3RFQh6ZyTsLYfSE5Y
	X0SwMmHc4ejBihyqhvuZ9bGpbubv3+7Rb8Hf17n2iZThij4IV88ZHYaMTuDuq/BOd2qyZG
	y6f2DuAwg3J1wKMBY+tqXNVbKndJXJZZcC3P/bxU890hHH/neqF3liFf4Xb5JTpgeU6xbp
	+78D/DalGsyRL5nEBUCnk91DKvGZLYLe/Qra3xfzIN6MkIIfGg6iJcs56qBQvw==
ARC-Authentication-Results: i=1;
	aspmx1.migadu.com;
	dkim=pass header.d=gmail.com header.s=20210112 header.b="id9G/5Ob";
	dmarc=pass (policy=none) header.from=gmail.com;
	spf=pass (aspmx1.migadu.com: domain of "guix-devel-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="guix-devel-bounces+larch=yhetil.org@gnu.org"
X-Migadu-Spam-Score: -1.40
Authentication-Results: aspmx1.migadu.com;
	dkim=pass header.d=gmail.com header.s=20210112 header.b="id9G/5Ob";
	dmarc=pass (policy=none) header.from=gmail.com;
	spf=pass (aspmx1.migadu.com: domain of "guix-devel-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="guix-devel-bounces+larch=yhetil.org@gnu.org"
X-Migadu-Queue-Id: 0A80F44FB3
X-Spam-Score: -1.40
X-Migadu-Scanner: scn1.migadu.com
X-TUID: q7n9f0hZPFMm

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=C3=A8s wrote:
> > Hello!
> >=20
> > Philip McGrath <philip@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'?) [=E2=80=A6]
> >=20
> > The choice of =E2=80=98bash-static=E2=80=99 rather than =E2=80=98bash-m=
inimal=E2=80=99 is motivated
> > by
> > the fact that, in (gnu packages commencement), we want to make sure
> > =E2=80=98glibc-final=E2=80=99 does not retain references to its build-t=
ime
> > environment.
> > See #:allowed-references in =E2=80=98glibc-final=E2=80=99.
> >=20
>=20
> This makes sense as far as using 'bash-static' in Glibc. The aspects
> I'm unsure of are:
>=20
> =C2=A01. 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'?
>=20
> =C2=A02. 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:
>=20
> --8<---------------cut here---------------start------------->8---
> $ guix size bash-minimal=20
> store item=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0
> total=C2=A0=C2=A0=C2=A0 self
> /gnu/store/5h2w4qi9hk1qzzgi1w83220ydslinr4s-glibc-2.33=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0
> 38.3=C2=A0=C2=A0=C2=A0 36.6=C2=A0 50.4%
> /gnu/store/094bbaq6glba86h1d4cj16xhdi6fk2jl-gcc-10.3.0-lib=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0
> 71.7=C2=A0=C2=A0=C2=A0 33.4=C2=A0 45.9%
> /gnu/store/720rj90bch716isd8z7lcwrnvz28ap4y-bash-static-5.1.8=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0
> 1.7=C2=A0=C2=A0=C2=A0=C2=A0 1.7=C2=A0=C2=A0 2.3%
> /gnu/store/chfwin3a4qp1znnpsjbmydr2jbzk0d6y-bash-minimal-5.1.8=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0
> 72.7=C2=A0=C2=A0=C2=A0=C2=A0 1.0=C2=A0=C2=A0 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.
> >=20
> > This is not a viable option because build containers lack /bin/sh.
> >=20
>=20
> Right, this option would depend on making /bin/sh exist in the build
> environment.
>=20
> 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.
>=20
> > Overall, I think the current situation is a reasonable tradeoff.=C2=A0
> > It forces us to do some patching, indeed, but I think that=E2=80=99s
> > acceptable: we=E2=80=99re talking about a handful of packages.
> >=20
> > WDYT?
> >=20
> > Ludo=E2=80=99.
>=20
> 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