From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp0 ([2001:41d0:2:bcc0::]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) by ms0.migadu.com with LMTPS id 8EJHDWUNdmAZrQAAgWs5BA (envelope-from ) for ; Tue, 13 Apr 2021 23:30:13 +0200 Received: from aspmx1.migadu.com ([2001:41d0:2:bcc0::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp0 with LMTPS id 8FY+B2UNdmDKEAAA1q6Kng (envelope-from ) for ; Tue, 13 Apr 2021 21:30:13 +0000 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 7BE5A1BA6F for ; Tue, 13 Apr 2021 23:30:11 +0200 (CEST) Received: from localhost ([::1]:51410 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lWQbp-0001DF-TO for larch@yhetil.org; Tue, 13 Apr 2021 17:30:09 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:55892) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lWQbj-0001D7-00 for bug-guix@gnu.org; Tue, 13 Apr 2021 17:30:03 -0400 Received: from debbugs.gnu.org ([209.51.188.43]:49475) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1lWQbi-0000Rv-NS for bug-guix@gnu.org; Tue, 13 Apr 2021 17:30:02 -0400 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1lWQbi-000475-HU for bug-guix@gnu.org; Tue, 13 Apr 2021 17:30:02 -0400 X-Loop: help-debbugs@gnu.org Subject: bug#47614: [security] Chunked store references in .zo files in Racket 8 Resent-From: Mark H Weaver Original-Sender: "Debbugs-submit" Resent-CC: bug-guix@gnu.org Resent-Date: Tue, 13 Apr 2021 21:30:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 47614 X-GNU-PR-Package: guix X-GNU-PR-Keywords: security To: =?UTF-8?Q?L=C3=A9o?= Le Bouter , 47614@debbugs.gnu.org Received: via spool by 47614-submit@debbugs.gnu.org id=B47614.161834934315724 (code B ref 47614); Tue, 13 Apr 2021 21:30:02 +0000 Received: (at 47614) by debbugs.gnu.org; 13 Apr 2021 21:29:03 +0000 Received: from localhost ([127.0.0.1]:32788 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lWQak-00045Y-QA for submit@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 ) id 1lWQai-000451-MQ for 47614@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 ) id 1lWQac-0001MN-09; Tue, 13 Apr 2021 17:28:54 -0400 From: Mark H Weaver In-Reply-To: <9b7e130d5b993a0376698e07f5f9346a5775604f.camel@zaclys.net> References: <87k0pf7jti.fsf@netris.org> <87tuojqf0r.fsf@netris.org> <9b7e130d5b993a0376698e07f5f9346a5775604f.camel@zaclys.net> Date: Tue, 13 Apr 2021 17:27:11 -0400 Message-ID: <87a6q1swmt.fsf@netris.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-guix@gnu.org List-Id: Bug reports for GNU Guix List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-guix-bounces+larch=yhetil.org@gnu.org Sender: "bug-Guix" X-Migadu-Flow: FLOW_IN ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1618349412; h=from:from:sender:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding:resent-cc: resent-from:resent-sender:resent-message-id:in-reply-to:in-reply-to: references:references:list-id:list-help:list-unsubscribe: list-subscribe:list-post; bh=UAKLUfaSIxWp7SjmaeMXe99fYSP6gUdSfYK+z5YSXSI=; b=RxuKcGVAXplqWF4MEB+EKkQENLwo4seEatknB4zR7TRGIXtiPsooOfQEWTpPrjFZX0keM4 LPjir9LBkN8JoiXW9BzKpoGAWeCZO+YtRwsxQ/jx/c5sN2fVwDW7dxiomalpDLbjYx/Wac 4xVyGhURDxwttQ/IYRp/3RvhM8DVrwoFvOFekcDd5d/xXCyyshZxESTlTnig+5ag0hyz5r SFpu0jePmOfZgPjN/+WpnyKBo8L1MuxVHUniwGWzpYlpvYId8HdWKSlP0BWj/tk1AKyJ0q YZu4EQbBiKlXShIJYFUqt3OSTbrWRxXZWcUjjiCnEpolX99uxCrr12AYHemIQQ== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1618349412; a=rsa-sha256; cv=none; b=OlOO/v+wnLSHnxyMR0mFvqmDoq4Fvi+CCEYwpDqB6UQJf5O6l2LTKGT3Cxd3xVo4OaEK0Q odCPtAsKQzm/NuaNNCFiU5mrXYQEEbI15yqVeq0gFeAGpPbf7ZjEXDfJZAG5BrunBd873T YIzbxTzm+xxEymsyhT09649L7JzfBwaZwdCxeXrd8bWScIOveEK8tdbD6b1GoZBVw2ABYU WL6dlhxVs4r0DaRefZjnPcEItHxDbALAx7Y//l31LyYNkIIe57pyghBW30sZEmUPzOFecK DgsHkEt5TIz8AtMRu8Mn1RCZj5Ed/jIxy7Q6cFuWgtOL6X/yyIrSKhmc4MMQkA== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=none; dmarc=none; spf=pass (aspmx1.migadu.com: domain of bug-guix-bounces@gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=bug-guix-bounces@gnu.org X-Migadu-Spam-Score: -0.94 Authentication-Results: aspmx1.migadu.com; dkim=none; dmarc=none; spf=pass (aspmx1.migadu.com: domain of bug-guix-bounces@gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=bug-guix-bounces@gnu.org X-Migadu-Queue-Id: 7BE5A1BA6F X-Spam-Score: -0.94 X-Migadu-Scanner: scn0.migadu.com X-TUID: 5VC+ESwuVoAW Hi L=C3=A9o, L=C3=A9o Le Bouter writes: > On Tue, 2021-04-06 at 17:27 -0400, Mark H Weaver wrote: >>=20 >> L=C3=A9o Le Bouter 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 , 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 . Thanks, Mark