GNU bug report logs - #47614
[security] Chunked store references in .zo files in Racket 8

Please note: This is a static page, with minimal formatting, updated once a day.
Click here to see this page with the latest information and nicer formatting.

Package: guix; Reported by: Mark H Weaver <mhw@HIDDEN>; Keywords: security; dated Tue, 6 Apr 2021 11:09:01 UTC; Maintainer for guix is bug-guix@HIDDEN.

Message received at 47614 <at> debbugs.gnu.org:


Received: (at 47614) by debbugs.gnu.org; 16 Apr 2021 15:46:47 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Fri Apr 16 11:46:47 2021
Received: from localhost ([127.0.0.1]:41501 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1lXQgB-0004Qb-EV
	for submit <at> debbugs.gnu.org; Fri, 16 Apr 2021 11:46:47 -0400
Received: from eggs.gnu.org ([209.51.188.92]:51726)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <ludo@HIDDEN>) id 1lXQg9-0004LT-UA
 for 47614 <at> debbugs.gnu.org; Fri, 16 Apr 2021 11:46:46 -0400
Received: from fencepost.gnu.org ([2001:470:142:3::e]:42475)
 by eggs.gnu.org with esmtp (Exim 4.90_1)
 (envelope-from <ludo@HIDDEN>)
 id 1lXQg4-0007NK-GO; Fri, 16 Apr 2021 11:46:40 -0400
Received: from [2a01:e0a:1d:7270:af76:b9b:ca24:c465] (port=39294 helo=ribbon)
 by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256)
 (Exim 4.82) (envelope-from <ludo@HIDDEN>)
 id 1lXQg3-0007SL-Vb; Fri, 16 Apr 2021 11:46:40 -0400
From: =?utf-8?Q?Ludovic_Court=C3=A8s?= <ludo@HIDDEN>
To: Philip McGrath <philip@HIDDEN>
Subject: Re: bug#47614: [security] Chunked store references in .zo files in
 Racket 8
References: <7eaf8b95-5550-66e1-fda2-d691255b49d7@HIDDEN>
 <2abc59d0-905e-ab0c-ae25-bf572f34fcd5@HIDDEN>
Date: Fri, 16 Apr 2021 17:46:38 +0200
In-Reply-To: <2abc59d0-905e-ab0c-ae25-bf572f34fcd5@HIDDEN> (Philip
 McGrath's message of "Tue, 6 Apr 2021 21:48:34 -0400")
Message-ID: <87blae44gx.fsf_-_@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.2 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: -0.7 (/)
X-Debbugs-Envelope-To: 47614
Cc: Mark H Weaver <mhw@HIDDEN>, 47614 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.7 (-)

Hi Philip and all,

Philip McGrath <philip@HIDDEN> skribis:

> Indeed, I expect this is a more precise diagnosis of the same
> problem. My patch in https://issues.guix.gnu.org/47180 solves it by
> putting the store references (search paths for foreign libraries) in a
> configuration data file that isn't compiled, so they don't end up in
> .zo files in the first place.

IIUC, now that <https://issues.guix.gnu.org/47180> has been closed, this
bug is fixed.  Am I right?

Thanks,
Ludo=E2=80=99.




Information forwarded to bug-guix@HIDDEN:
bug#47614; Package guix. Full text available.

Message received at 47614 <at> debbugs.gnu.org:


Received: (at 47614) by debbugs.gnu.org; 13 Apr 2021 21:29:03 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Tue Apr 13 17:29:03 2021
Received: from localhost ([127.0.0.1]:32788 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1lWQak-00045Y-QA
	for submit <at> debbugs.gnu.org; Tue, 13 Apr 2021 17:29:03 -0400
Received: from world.peace.net ([64.112.178.59]:35854)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <mhw@HIDDEN>) id 1lWQai-000451-MQ
 for 47614 <at> debbugs.gnu.org; Tue, 13 Apr 2021 17:29:01 -0400
Received: from mhw by world.peace.net with esmtpsa
 (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92)
 (envelope-from <mhw@HIDDEN>)
 id 1lWQac-0001MN-09; Tue, 13 Apr 2021 17:28:54 -0400
From: Mark H Weaver <mhw@HIDDEN>
To: =?utf-8?Q?L=C3=A9o?= Le Bouter <lle-bout@HIDDEN>, 47614 <at> debbugs.gnu.org
Subject: Re: bug#47614: [security] Chunked store references in .zo files in
 Racket 8
In-Reply-To: <9b7e130d5b993a0376698e07f5f9346a5775604f.camel@HIDDEN>
References: <87k0pf7jti.fsf@HIDDEN>
 <e9234acf1e9dff8e5a0fc0ff078fc9e2f201e9a4.camel@HIDDEN>
 <87tuojqf0r.fsf@HIDDEN>
 <9b7e130d5b993a0376698e07f5f9346a5775604f.camel@HIDDEN>
Date: Tue, 13 Apr 2021 17:27:11 -0400
Message-ID: <87a6q1swmt.fsf@HIDDEN>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: 0.0 (/)
X-Debbugs-Envelope-To: 47614
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)

Hi L=C3=A9o,

L=C3=A9o Le Bouter <lle-bout@HIDDEN> writes:

> On Tue, 2021-04-06 at 17:27 -0400, Mark H Weaver wrote:
>>=20
>> L=C3=A9o Le Bouter <lle-bout@HIDDEN> writes:
>>=20
>> > I think that probably replacing arbitrary paths in built binaries
>> > is a risky and maybe unreliable engineering choice and that
>> > mechanisms inside kernels should be preferred to give processes a
>> > different view of the file system (retaining the path but changing
>> > the contents of the folder).
>>=20
>> I've had thoughts along these lines myself, but I don't think it can
>> work properly.  The fundamental problem is that in general, each
>> process includes shared objects from many different Guix packages.
>> There would need to be a mechanism to determine, when looking up a
>> file, which Guix package that file lookup was originating from (or
>> whether it was coming from a file name provided by the user), in
>> order to determine which "view of the file system" to use for
>> purposes of that lookup.  There's no way to determine this reliably.
>
> Is it really that big a deal if it's impossible to access the ungrafted
> /gnu/store item?=20

It's a fair question, and reasonable people may disagree, but I would
personally find it quite troubling to not be able to confidently and
straightforwardly examine files in /gnu/store without wondering if my
tools were showing me something else.

Anyway, this would be a very radical change in Guix, and I think this
bug report is not the best place to discuss it.  If you'd like to persue
this idea further, I suggest starting a thread on 'guix-devel'.

>> > OTOH, what would be wrong with replacing hashes directly without
>> > expecting them to be next to anything else?
>>=20
>> Personally, I would find that limitation acceptable, and that's
>> fairly close to what our grafter originally did (although my fast
>> grafting code always assumed that a "-" would follow the hash).
>> However, we've since become accustomed to being able to have
>> replacements with different version numbers.  That's a nice feature.
>
> Version numbers, agree, I didnt realize that replacing the program name
> and version was also required there. However I am thinking we could
> fake (or alias, with a symlink) the version in the store item name on
> purpose so that it remains the same while pointing to something with a
> newer version, it would actually be better that way because we wouldnt
> have to think about retaining identical version string length during
> grafts.

This idea is the subject of <https://bugs.gnu.org/43984>, and it's
certainly doable.  The main disadvantage I see is that file system
lookups in grafted store items would become less efficient, because more
symbolic links would need to be followed.  Anyway, if you'd like to
persue this idea further, let's discuss it in that other bug report.

>> Anyway, I doubt that imposing such a limitation would adequately
>> solve the problem here of chunked references in Racket 8, because I
>> suspect that Racket 8 could split store references at arbitrary
>> points in the string.  I doubt that we can safely assume that the
>> hash component of store references will be stored contiguously in
>> *.zo files.
>
> Indeed, is the format for the string references in .zo files documented
> anywhere? Is there hope you think we can recognize and automatically
> rewrite these strings?

According to Philip McGrath, "The .zo format is intentionally
undocumented and subject to breaking change, including from different
compilation options."  See <https://bugs.gnu.org/47614#19>.

     Thanks,
       Mark




Information forwarded to bug-guix@HIDDEN:
bug#47614; Package guix. Full text available.

Message received at 47614 <at> debbugs.gnu.org:


Received: (at 47614) by debbugs.gnu.org; 7 Apr 2021 01:48:44 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Tue Apr 06 21:48:44 2021
Received: from localhost ([127.0.0.1]:42645 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1lTxJE-0007se-GC
	for submit <at> debbugs.gnu.org; Tue, 06 Apr 2021 21:48:44 -0400
Received: from mail-qk1-f176.google.com ([209.85.222.176]:36466)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <philip@HIDDEN>) id 1lTxJC-0007sS-Bo
 for 47614 <at> debbugs.gnu.org; Tue, 06 Apr 2021 21:48:43 -0400
Received: by mail-qk1-f176.google.com with SMTP id c4so17215249qkg.3
 for <47614 <at> debbugs.gnu.org>; Tue, 06 Apr 2021 18:48:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=philipmcgrath.com; s=google;
 h=subject:references:to:from:message-id:date:user-agent:mime-version
 :in-reply-to:content-language:content-transfer-encoding;
 bh=TC9M1/7KxaFEkPgP1zYLPFVVOmqewfiUKZvJNvU5xk8=;
 b=KewtNXDXmmQOD1dLHvRCPgFM6Ruw/eHxHr48sWLHbosHCuey5hJQVvMCkd/w5BlkiY
 z4ZOKQwyHUhu+Q7kz23IwOEWUofVuJHmhKdVVuza8BJ40We0TvdzGVqq4pPu4qLZ8l/p
 n3e8RO+DBUZ1AzBUnIK7DaF49XMomAm73fd5ryoGC+j+h+IPeX4NdQIKaLWyRK5cW1y3
 0ERqQrUtRDfdhBuVhv+IKyggeixB/lsDKjMoppdoTq43Uq15eiivu6VrZeil+24/5ZA6
 fuDLiSfy2R79JAGnAvJFHC09PXIrzqXFSDgOSBVY3yn4D4RC9phW2xyjR0MbT0CAoQwu
 Sr+Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:subject:references:to:from:message-id:date
 :user-agent:mime-version:in-reply-to:content-language
 :content-transfer-encoding;
 bh=TC9M1/7KxaFEkPgP1zYLPFVVOmqewfiUKZvJNvU5xk8=;
 b=qSJ4SCd2sw7U7OM4Qh6YQFnsoCEZmnPpcfhK0Hsp4udG6Dj57jgVL8f90boPtFpGhT
 Xg+K5kZObJybpCRsu0pZVKNGKZBZSmgVAUGc1jyQOvg2L05z48Sz1q9n3vDR8KxNB9NA
 oBbpui0fnOQjt7FPuEXMYnag3Zc+XL8UPrmXLmuJRu285gRntVWwjPH8shAo8oYKs2i9
 1NR64qxDBK5i0at4M54xevuCbv5VYHCK6r0D9BYMbblr1rTsHo3VsqH6RDLC7SzVAF8q
 7nC3OFVn5uFCJhn1DdgIsL6VBDPPrWlEUzlynqhrhMX8ZCmR4aMB/lrVxBa3WsfKsfbx
 1yfA==
X-Gm-Message-State: AOAM5334ezcdhcbnSWLuqzsOZNDyzqnAYLsuYh/fHWnNAyr2c3IZ+VBU
 ySQqjJ/C+TVAoEa0XrdgXIuSOC3OLWZNEgt6PYg=
X-Google-Smtp-Source: ABdhPJxqTuvBXKFGDmMChF2k7KApDmwVWwUwQU/xtlaG7TBywYbe5KxmpcFZB1gCHANkoIxm2ljrRQ==
X-Received: by 2002:a37:a281:: with SMTP id l123mr904503qke.218.1617760116458; 
 Tue, 06 Apr 2021 18:48:36 -0700 (PDT)
Received: from Sapientia.local (c-73-125-89-242.hsd1.fl.comcast.net.
 [73.125.89.242])
 by smtp.gmail.com with ESMTPSA id g3sm15981128qth.66.2021.04.06.18.48.35
 for <47614 <at> debbugs.gnu.org>
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 06 Apr 2021 18:48:35 -0700 (PDT)
Subject: [security] Chunked store references in .zo files in Racket 8 #47614
References: <7eaf8b95-5550-66e1-fda2-d691255b49d7@HIDDEN>
To: 47614 <at> debbugs.gnu.org
From: Philip McGrath <philip@HIDDEN>
X-Forwarded-Message-Id: <7eaf8b95-5550-66e1-fda2-d691255b49d7@HIDDEN>
Message-ID: <2abc59d0-905e-ab0c-ae25-bf572f34fcd5@HIDDEN>
Date: Tue, 6 Apr 2021 21:48:34 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:78.0)
 Gecko/20100101 Thunderbird/78.9.0
MIME-Version: 1.0
In-Reply-To: <7eaf8b95-5550-66e1-fda2-d691255b49d7@HIDDEN>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-Spam-Score: 0.7 (/)
X-Debbugs-Envelope-To: 47614
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -0.3 (/)

Ah, I see the thread for https://issues.guix.gnu.org/47614 wasn't cc'ed 
here:


-------- Forwarded Message --------
Subject: Re: Racket 8 and store references (was [security] Chunked store 
references in .zo files in Racket 8 #47614)
Date: Tue, 6 Apr 2021 21:38:57 -0400
From: Philip McGrath <philip@HIDDEN>
To: Jack Hill <jackhill@HIDDEN>, Mark H Weaver <mhw@HIDDEN>
CC: guix-devel@HIDDEN

Indeed, I expect this is a more precise diagnosis of the same problem. 
My patch in https://issues.guix.gnu.org/47180 solves it by putting the 
store references (search paths for foreign libraries) in a configuration 
data file that isn't compiled, so they don't end up in .zo files in the 
first place.

The .zo format is intentionally undocumented and subject to breaking 
change, including from different compilation options. At a minimum, a 
change to the Racket version number signals a breaking change to 
compiled code (e.g. Git is now at 8.0.0.13, so 13 breaking changes since 
the release). Internally, I don't know all the details, but the normal 
8.0 .zo format has a Racket layer around the Chez Scheme object format, 
which seems to be very complex: it looks like it supports 
user-configurable compression at the granularity of the individual 
object within an object file. So it seems much better to avoid rewriting 
.zo files altogether.

-Philip

On 4/6/21 9:20 PM, Jack Hill wrote:
> On Tue, 6 Apr 2021, Mark H Weaver wrote:
> 
>> Anyway, I doubt that imposing such a limitation would adequately solve
>> the problem here of chunked references in Racket 8, because I suspect
>> that Racket 8 could split store references at arbitrary points in the
>> string.  I doubt that we can safely assume that the hash component of
>> store references will be stored contiguously in *.zo files.
> 
> Mark and everyone,
> 
> I wanted to spin off a subthread on guix-devel, to make you aware of 
> another problem that we've run into with reference in .zo getting 
> mangled: https://issues.guix.gnu.org/47180
> 
> Best,
> Jack
> 




Information forwarded to bug-guix@HIDDEN:
bug#47614; Package guix. Full text available.

Message received at 47614 <at> debbugs.gnu.org:


Received: (at 47614) by debbugs.gnu.org; 6 Apr 2021 22:18:49 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Tue Apr 06 18:18:48 2021
Received: from localhost ([127.0.0.1]:42146 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1lTu24-0000HK-LD
	for submit <at> debbugs.gnu.org; Tue, 06 Apr 2021 18:18:48 -0400
Received: from mail.zaclys.net ([178.33.93.72]:45111)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <lle-bout@HIDDEN>) id 1lTu22-0000H3-3O
 for 47614 <at> debbugs.gnu.org; Tue, 06 Apr 2021 18:18:47 -0400
Received: from [192.168.1.115] (lsl43-1_migr-78-195-19-20.fbx.proxad.net
 [78.195.19.20] (may be forged)) (authenticated bits=0)
 by mail.zaclys.net (8.14.7/8.14.7) with ESMTP id 136MIY3H006999
 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO);
 Wed, 7 Apr 2021 00:18:40 +0200
DMARC-Filter: OpenDMARC Filter v1.3.2 mail.zaclys.net 136MIY3H006999
Authentication-Results: mail.zaclys.net;
 dmarc=fail (p=reject dis=none) header.from=zaclys.net
Authentication-Results: mail.zaclys.net;
 spf=fail smtp.mailfrom=lle-bout@HIDDEN
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=zaclys.net;
 s=default; t=1617747520;
 bh=I+ZAY2U8nqFePFLKHyUD5c83cw2H8xXLgMAhBEvnTZg=;
 h=Subject:From:To:Date:In-Reply-To:References:From;
 b=P1E6RA1PpDmxs4byzvRkDM2mdz9UG3p8ktFDHJwuAycmhEwpIz+HBhYynKu12Bc4m
 e6akSkOdTA84YpkVXM1+n53GR9K8tHd5f8OVwQGLEb4QrmB7LkVcejzed3mzLijGXh
 +ntEdp5VRXrpRDFQCc4YXJSURimNPNUTeA0930MQ=
Message-ID: <9b7e130d5b993a0376698e07f5f9346a5775604f.camel@HIDDEN>
Subject: Re: bug#47614: [security] Chunked store references in .zo files in
 Racket 8
From: =?ISO-8859-1?Q?L=E9o?= Le Bouter <lle-bout@HIDDEN>
To: Mark H Weaver <mhw@HIDDEN>, 47614 <at> debbugs.gnu.org
Date: Wed, 07 Apr 2021 00:18:29 +0200
In-Reply-To: <87tuojqf0r.fsf@HIDDEN>
References: <87k0pf7jti.fsf@HIDDEN>
 <e9234acf1e9dff8e5a0fc0ff078fc9e2f201e9a4.camel@HIDDEN>
 <87tuojqf0r.fsf@HIDDEN>
Content-Type: multipart/signed; micalg="pgp-sha512";
 protocol="application/pgp-signature"; boundary="=-YWjOopJBmmdqQ/Jdmgc3"
User-Agent: Evolution 3.34.2 
MIME-Version: 1.0
X-Spam-Score: 0.0 (/)
X-Debbugs-Envelope-To: 47614
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)


--=-YWjOopJBmmdqQ/Jdmgc3
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Tue, 2021-04-06 at 17:27 -0400, Mark H Weaver wrote:
> Hi L=C3=A9o,
>=20
> L=C3=A9o Le Bouter <lle-bout@HIDDEN> writes:
>=20
> > I think that probably replacing arbitrary paths in built binaries
> > is a
> > risky and maybe unreliable engineering choice and that mechanisms
> > inside kernels should be preferred to give processes a different
> > view
> > of the file system (retaining the path but changing the contents of
> > the
> > folder).
>=20
> I've had thoughts along these lines myself, but I don't think it can
> work properly.  The fundamental problem is that in general, each
> process
> includes shared objects from many different Guix packages.  There
> would
> need to be a mechanism to determine, when looking up a file, which
> Guix
> package that file lookup was originating from (or whether it was
> coming
> from a file name provided by the user), in order to determine which
> "view of the file system" to use for purposes of that
> lookup.  There's
> no way to determine this reliably.

Is it really that big a deal if it's impossible to access the ungrafted
/gnu/store item? If really required we could document a way to disable
it temporarily maybe? Do we need a specific view for each and every
package? I am thinking that overriding the view to the store item
that's a result of a package with a replacement field globally would be
sufficient.

> > OTOH, what would be wrong with replacing hashes directly without
> > expecting them to be next to anything else?
>=20
> Personally, I would find that limitation acceptable, and that's
> fairly
> close to what our grafter originally did (although my fast grafting
> code
> always assumed that a "-" would follow the hash).  However, we've
> since
> become accustomed to being able to have replacements with different
> version numbers.  That's a nice feature.
>=20

Version numbers, agree, I didnt realize that replacing the program name
and version was also required there. However I am thinking we could
fake (or alias, with a symlink) the version in the store item name on
purpose so that it remains the same while pointing to something with a
newer version, it would actually be better that way because we wouldnt
have to think about retaining identical version string length during
grafts.

> Anyway, I doubt that imposing such a limitation would adequately
> solve
> the problem here of chunked references in Racket 8, because I suspect
> that Racket 8 could split store references at arbitrary points in the
> string.  I doubt that we can safely assume that the hash component of
> store references will be stored contiguously in *.zo files.

Indeed, is the format for the string references in .zo files documented
anywhere? Is there hope you think we can recognize and automatically
rewrite these strings?

Thanks,
L=C3=A9o

--=-YWjOopJBmmdqQ/Jdmgc3
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEEFIvLi9gL+xax3g6RRaix6GvNEKYFAmBs3jUACgkQRaix6GvN
EKZahA//XEDSzqC2DXejbNOrKOnf7mqTm57Btvfr7F0PkCu/4PXBa+jAlORbJxgO
tyMEgL6vOK9RRgugUVtThHsKP7+FUIKABB6wSJLSf9AOGo+a0A4lrUdNLBkip71m
8Ol4nZ3UQM7ZwlMFM3SePYpzYrOWbU1Q++NCb1DeCcsUvCD+3gHYhp0p69UVgn46
HWk8Ue2D6Q3K7zQtlxP6so27R5rc+zv2zzKWm4wi/HSRzR9kWD9GK0bvYRAsQPFU
JQc08xJzNil/FeJTeQUKQHwKImiqSWZC26z74aMGpxIIavwk7sXz5565UvL0KZXr
SxcOxALEJsre6t9SqE90C9F/7Tkhu11FaPd75okFPNPTKiBQUB98Ywsmzg3sioGA
OgIfVTYpz31tPBKxphV+UkMoIUxjJCG7Jc0JOI5waNz86a0D5lCFkekGq7Szieh7
QTddZCYYJrn2ApTgMFvNf2HchJYA/KISjXx6RuJArXgc3JjkXJvfm2MOZ+bYfwnW
D51GDzgjIInJXgn6tG0Pm6siL+AHNGmaLzBg8pDsdtZ3leh95zSq6U6J/qG1FBef
bHNSaon0aO3b7pD1w7PpExi/+mqGxNziEKeYeY3njwssZzckbAVKr2qi/kmLfiyz
ZbueI8ERJBdZpyodFAwGR26NieJlgjVUHXhYQOvOxmtPjZjsgvE=
=/wmS
-----END PGP SIGNATURE-----

--=-YWjOopJBmmdqQ/Jdmgc3--





Information forwarded to bug-guix@HIDDEN:
bug#47614; Package guix. Full text available.

Message received at 47614 <at> debbugs.gnu.org:


Received: (at 47614) by debbugs.gnu.org; 6 Apr 2021 21:29:43 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Tue Apr 06 17:29:43 2021
Received: from localhost ([127.0.0.1]:41938 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1lTtGZ-0007Kc-6H
	for submit <at> debbugs.gnu.org; Tue, 06 Apr 2021 17:29:43 -0400
Received: from world.peace.net ([64.112.178.59]:46582)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <mhw@HIDDEN>) id 1lTtGX-0007KO-9o
 for 47614 <at> debbugs.gnu.org; Tue, 06 Apr 2021 17:29:41 -0400
Received: from mhw by world.peace.net with esmtpsa
 (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92)
 (envelope-from <mhw@HIDDEN>)
 id 1lTtGQ-00078F-KH; Tue, 06 Apr 2021 17:29:34 -0400
From: Mark H Weaver <mhw@HIDDEN>
To: =?utf-8?Q?L=C3=A9o?= Le Bouter <lle-bout@HIDDEN>, 47614 <at> debbugs.gnu.org
Subject: Re: bug#47614: [security] Chunked store references in .zo files in
 Racket 8
In-Reply-To: <e9234acf1e9dff8e5a0fc0ff078fc9e2f201e9a4.camel@HIDDEN>
References: <87k0pf7jti.fsf@HIDDEN>
 <e9234acf1e9dff8e5a0fc0ff078fc9e2f201e9a4.camel@HIDDEN>
Date: Tue, 06 Apr 2021 17:27:53 -0400
Message-ID: <87tuojqf0r.fsf@HIDDEN>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: 0.0 (/)
X-Debbugs-Envelope-To: 47614
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)

Hi L=C3=A9o,

L=C3=A9o Le Bouter <lle-bout@HIDDEN> writes:

> I think that probably replacing arbitrary paths in built binaries is a
> risky and maybe unreliable engineering choice and that mechanisms
> inside kernels should be preferred to give processes a different view
> of the file system (retaining the path but changing the contents of the
> folder).

I've had thoughts along these lines myself, but I don't think it can
work properly.  The fundamental problem is that in general, each process
includes shared objects from many different Guix packages.  There would
need to be a mechanism to determine, when looking up a file, which Guix
package that file lookup was originating from (or whether it was coming
from a file name provided by the user), in order to determine which
"view of the file system" to use for purposes of that lookup.  There's
no way to determine this reliably.

For example, when Emacs stats a file, there's no way to automatically
determine which view of the file system to use for that file lookup.  If
the file being stat'd is a file that the user asked to look at, it
should use the user's view of the file system.  If Emacs is trying to
load one of its own dependent libraries, it should see the file system
view associated with the dependencies of Emacs.  If some code in
GnuTLS's shared library (loaded by Emacs) performs a file lookup, it
should see the GnuTLS file system view.  See the problem?

I've come to think that the Guix approach is the most "correct"
approach, given the APIs that our existing body of software was written
for.  (If we rewrote our software from scratch with different APIs, we
would have more options here, but that would be crazy :)

> OTOH, what would be wrong with replacing hashes directly without
> expecting them to be next to anything else?

Personally, I would find that limitation acceptable, and that's fairly
close to what our grafter originally did (although my fast grafting code
always assumed that a "-" would follow the hash).  However, we've since
become accustomed to being able to have replacements with different
version numbers.  That's a nice feature.

Anyway, I doubt that imposing such a limitation would adequately solve
the problem here of chunked references in Racket 8, because I suspect
that Racket 8 could split store references at arbitrary points in the
string.  I doubt that we can safely assume that the hash component of
store references will be stored contiguously in *.zo files.

What do you think?

      Thanks,
        Mark




Information forwarded to bug-guix@HIDDEN:
bug#47614; Package guix. Full text available.

Message received at 47614 <at> debbugs.gnu.org:


Received: (at 47614) by debbugs.gnu.org; 6 Apr 2021 17:39:52 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Tue Apr 06 13:39:52 2021
Received: from localhost ([127.0.0.1]:41677 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1lTpg8-0007yr-0x
	for submit <at> debbugs.gnu.org; Tue, 06 Apr 2021 13:39:52 -0400
Received: from mail.zaclys.net ([178.33.93.72]:44725)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <lle-bout@HIDDEN>) id 1lTpg5-0007yb-Vn
 for 47614 <at> debbugs.gnu.org; Tue, 06 Apr 2021 13:39:50 -0400
Received: from guix-xps.local (lsl43-1_migr-78-195-19-20.fbx.proxad.net
 [78.195.19.20] (may be forged)) (authenticated bits=0)
 by mail.zaclys.net (8.14.7/8.14.7) with ESMTP id 136HdguZ031880
 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO);
 Tue, 6 Apr 2021 19:39:43 +0200
DMARC-Filter: OpenDMARC Filter v1.3.2 mail.zaclys.net 136HdguZ031880
Authentication-Results: mail.zaclys.net;
 dmarc=fail (p=reject dis=none) header.from=zaclys.net
Authentication-Results: mail.zaclys.net;
 spf=fail smtp.mailfrom=lle-bout@HIDDEN
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=zaclys.net;
 s=default; t=1617730783;
 bh=4z9uqK/sXGcvK7Cc6ezWLezf6TgEi7mNRnQbZ/6Oq7Q=;
 h=Subject:From:To:Date:In-Reply-To:References:From;
 b=KvRzIaNcekgpsKA802I5h6L4SZVRn7sx1J+pIheaEqvQU6xXfRkfno3+wVsqbD5g+
 2Cbh2yj7MeIIHpL5xYczOZaYLdQH2CwICksxTTCjuZFzEjXgGIfSC8QPNlyUvN1tHP
 R4EPVneNDvn+NqyhkOmIrrc9f0uEBCkSNrKOv5N4=
Message-ID: <e9234acf1e9dff8e5a0fc0ff078fc9e2f201e9a4.camel@HIDDEN>
Subject: Re: bug#47614: [security] Chunked store references in .zo files in
 Racket 8
From: =?ISO-8859-1?Q?L=E9o?= Le Bouter <lle-bout@HIDDEN>
To: Mark H Weaver <mhw@HIDDEN>, 47614 <at> debbugs.gnu.org
Date: Tue, 06 Apr 2021 19:39:42 +0200
In-Reply-To: <87k0pf7jti.fsf@HIDDEN>
References: <87k0pf7jti.fsf@HIDDEN>
Content-Type: multipart/signed; micalg="pgp-sha512";
 protocol="application/pgp-signature"; boundary="=-Cesk0LIKqiJGfD8yDHBD"
User-Agent: Evolution 3.34.2 
MIME-Version: 1.0
X-Spam-Score: 0.0 (/)
X-Debbugs-Envelope-To: 47614
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)


--=-Cesk0LIKqiJGfD8yDHBD
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

I think that probably replacing arbitrary paths in built binaries is a
risky and maybe unreliable engineering choice and that mechanisms
inside kernels should be preferred to give processes a different view
of the file system (retaining the path but changing the contents of the
folder).

OTOH, what would be wrong with replacing hashes directly without
expecting them to be next to anything else?

L=C3=A9o

--=-Cesk0LIKqiJGfD8yDHBD
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEEFIvLi9gL+xax3g6RRaix6GvNEKYFAmBsnN4ACgkQRaix6GvN
EKYdyQ//ZM1NkwAVwlz9jvAGlquG4PZtpNVMo9nKwCtDFNkdH24qcw0C4B9vDcz5
eSQl1zdd/Umo4brKd7namErlRBUS6C5HtsT763R8XbT8oY6qQhPYbl7fy445H3DK
D/vXRDZBMPAkmeX5W6bn9h+ZOULy1PB4iQXZ+/rleq+SvE7PGVbN2FKt7I2/mEn0
ft11Xf8XcDbD7IlKRgPcudYBJ7Eb8ibRjO4n9iluILxoZ6ST/rZHsn5XFFl4SuT/
O/a0NqoaFs5rd8aQcx2S3oTyRlpSDeR7o7IpKLGgZgjxCijzW0X6hEoo/d0QPd7Y
87srlKLNzj1KTP3UoOy5yYEEuw0lIplB+Jmzri93ncBEEDthWiHgpAfpDn26lbFz
DIFsLB07vL10QxrDgsGsGEpgFnmA/L0jeJCD+2PlrPNMovhYi9lypsdpBpDcoSOZ
aaPQXIdkwOo9iPybXkWI+eGRV+vMGwG1vli/v4YvoJXBh+eJwwi2d/mKfQzgt+EZ
dON/KbrVgVgtiyhic5ADKVn1t6xJQboqz075EAVwB7unH/XHpLY+TXRY4kogWfUi
XQLkSzG5MjOuNAI0WgUTz9IfXsQuFeHx4E1iYdSIwmZl+vos6YGkVykMsKHdIRn5
9Zuwt9Kl6hF8viKb4Plmhf/biCdKq3S/bxBybRrd7Tbd3OlopPo=
=CakI
-----END PGP SIGNATURE-----

--=-Cesk0LIKqiJGfD8yDHBD--





Information forwarded to bug-guix@HIDDEN:
bug#47614; Package guix. Full text available.
Added tag(s) security. Request was from Léo Le Bouter <lle-bout@HIDDEN> to control <at> debbugs.gnu.org. Full text available.

Message received at submit <at> debbugs.gnu.org:


Received: (at submit) by debbugs.gnu.org; 6 Apr 2021 11:08:44 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Tue Apr 06 07:08:44 2021
Received: from localhost ([127.0.0.1]:39362 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1lTjZb-0007z8-Nm
	for submit <at> debbugs.gnu.org; Tue, 06 Apr 2021 07:08:43 -0400
Received: from lists.gnu.org ([209.51.188.17]:44558)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <mhw@HIDDEN>) id 1lTjZX-0007yx-NC
 for submit <at> debbugs.gnu.org; Tue, 06 Apr 2021 07:08:42 -0400
Received: from eggs.gnu.org ([2001:470:142:3::10]:46854)
 by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.90_1) (envelope-from <mhw@HIDDEN>) id 1lTjZX-0008Da-J1
 for bug-guix@HIDDEN; Tue, 06 Apr 2021 07:08:39 -0400
Received: from world.peace.net ([64.112.178.59]:55740)
 by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.90_1) (envelope-from <mhw@HIDDEN>) id 1lTjZV-0002Af-FU
 for bug-guix@HIDDEN; Tue, 06 Apr 2021 07:08:39 -0400
Received: from mhw by world.peace.net with esmtpsa
 (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92)
 (envelope-from <mhw@HIDDEN>)
 id 1lTjZS-0005gW-Te; Tue, 06 Apr 2021 07:08:35 -0400
From: Mark H Weaver <mhw@HIDDEN>
To: bug-guix@HIDDEN
Subject: [security] Chunked store references in .zo files in Racket 8
Date: Tue, 06 Apr 2021 07:06:54 -0400
Message-ID: <87k0pf7jti.fsf@HIDDEN>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Received-SPF: pass client-ip=64.112.178.59; envelope-from=mhw@HIDDEN;
 helo=world.peace.net
X-Spam_score_int: -18
X-Spam_score: -1.9
X-Spam_bar: -
X-Spam_report: (-1.9 / 5.0 requ) BAYES_00=-1.9, SPF_HELO_NONE=0.001,
 SPF_PASS=-0.001 autolearn=ham autolearn_force=no
X-Spam_action: no action
X-Spam-Score: -1.3 (-)
X-Debbugs-Envelope-To: submit
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -2.3 (--)

On my system, Racket 8.0 contains a *.zo file that contains a *chunked*
store reference.  As a result, it retains a reference to the ungrafted
Gtk+, and therefore to the ungrafted glib, cairo, and libx11.

The file is:

  /gnu/store/=E2=80=A6-racket-8.0/share/racket/pkgs/gui-lib/mred/private/wx=
/gtk/compiled/gtk3_rkt.zo,

and here's the relevant excerpt:

--8<---------------cut here---------------start------------->8---
mhw@jojen ~$ hexdump -C /gnu/store/=E2=80=A6-racket-8.0/share/racket/pkgs/g=
ui-lib/mred/private/wx/gtk/compiled/gtk3_rkt.zo | grep -B2 -A6 /gnu/
00000cf0  c0 06 23 00 06 36 02 31  c7 c6 46 25 02 61 7f 0b  |..#..6.1..F%.a=
..|
00000d00  48 c7 c5 06 a3 01 28 67  03 32 01 08 0c 00 f0 23  |H.....(g.2....=
.#|
00000d10  05 00 58 11 1e 26 48 2f  67 6e 75 2f 73 74 6f 72  |..X..&H/gnu/st=
or|
00000d20  65 2f 6e 32 63 6e 70 32  66 69 76 78 71 31 30 6b  |e/n2cnp2fivxq1=
0k|
00000d30  78 71 61 6c 63 76 32 71  34 31 77 7a 73 79 6a 39  |xqalcv2q41wzsy=
j9|
00000d40  79 64 62 01 d0 2b 2d 33  2e 32 34 2e 32 34 2f 6c  |ydb..+-3.24.24=
/l|
00000d50  69 62 04 00 f0 1f 67 74  6b 2d 33 2e 73 6f 00 0e  |ib....gtk-3.so=
..|
00000d60  11 1f 07 02 12 23 12 24  0c 26 00 15 06 41 0b 40  |.....#.$.&...A=
.@|
00000d70  00 1d 11 20 26 1e 5b 2e  2e 2e 61 74 65 2f 77 78  |... &.[...ate/=
wx|
--8<---------------cut here---------------end--------------->8---

The referenced store item is this:

  /gnu/store/n2cnp2fivxq10kxqalcv2q41wzsyj9yd-gtk+-3.24.24

Notice that in the .zo file, there are three additional bytes inserted
before the dash ("-").

This store reference is seen by the Guix scanner, because the nix hash
is stored contiguously.  However, it is *not* seen by the grafter.

Note that the grafter assumes that the entire store item name will be
stored contiguously.  The current implementation only finds hashes that
are immediately followed by a dash ("-"), and moreover assumes that nix
hashes will never occur except within the corresponding store item name.

In this case, the reference was simply ignored, because the dash was
separated from the hash.  If the extra junk had been inserted *after*
the dash, the grafter would have made a mess of things.  It would have
(incorrectly) assumed that the rest of the expected store item name
followed the dash, and inappropriately written the replacement string
over the unexpected bytes.

With this case in mind, I think we can no longer safely assume that the
bytes following a nix hash will be as we expect.  As a general
principle, I think that *every* byte that the grafter modifies should
first be checked against its expected value.  That should allow us to
catch problems like this early, and avoid non-obvious breakage cropping
up.

What do you think?

      Mark




Acknowledgement sent to Mark H Weaver <mhw@HIDDEN>:
New bug report received and forwarded. Copy sent to bug-guix@HIDDEN. Full text available.
Report forwarded to bug-guix@HIDDEN:
bug#47614; Package guix. Full text available.
Please note: This is a static page, with minimal formatting, updated once a day.
Click here to see this page with the latest information and nicer formatting.
Last modified: Fri, 16 Apr 2021 16:00:02 UTC

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997 nCipher Corporation Ltd, 1994-97 Ian Jackson.