From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp0 ([2001:41d0:2:4a6f::]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) by ms0.migadu.com with LMTPS id cIYkK1/ebGD2nAAAgWs5BA (envelope-from ) for ; Wed, 07 Apr 2021 00:19:11 +0200 Received: from aspmx1.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp0 with LMTPS id kOMBJl/ebGCeeQAA1q6Kng (envelope-from ) for ; Tue, 06 Apr 2021 22:19:11 +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 05CE827B02 for ; Wed, 7 Apr 2021 00:19:11 +0200 (CEST) Received: from localhost ([::1]:45050 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lTu2Q-0002Rz-3m for larch@yhetil.org; Tue, 06 Apr 2021 18:19:10 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:54262) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lTu2I-0002Rp-3G for bug-guix@gnu.org; Tue, 06 Apr 2021 18:19:02 -0400 Received: from debbugs.gnu.org ([209.51.188.43]:58833) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1lTu2H-0002Nh-SY for bug-guix@gnu.org; Tue, 06 Apr 2021 18:19:01 -0400 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1lTu2H-0000Hm-Os for bug-guix@gnu.org; Tue, 06 Apr 2021 18:19:01 -0400 X-Loop: help-debbugs@gnu.org Subject: bug#47614: [security] Chunked store references in .zo files in Racket 8 Resent-From: =?UTF-8?Q?L=C3=A9o?= Le Bouter Original-Sender: "Debbugs-submit" Resent-CC: bug-guix@gnu.org Resent-Date: Tue, 06 Apr 2021 22:19:01 +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: Mark H Weaver , 47614@debbugs.gnu.org Received: via spool by 47614-submit@debbugs.gnu.org id=B47614.16177475291078 (code B ref 47614); Tue, 06 Apr 2021 22:19:01 +0000 Received: (at 47614) by debbugs.gnu.org; 6 Apr 2021 22:18:49 +0000 Received: from localhost ([127.0.0.1]:42146 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lTu24-0000HK-LD for submit@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 ) id 1lTu22-0000H3-3O for 47614@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; spf=fail smtp.mailfrom=lle-bout@zaclys.net 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@zaclys.net> Date: Wed, 07 Apr 2021 00:18:29 +0200 In-Reply-To: <87tuojqf0r.fsf@netris.org> References: <87k0pf7jti.fsf@netris.org> <87tuojqf0r.fsf@netris.org> 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-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" Reply-to: =?UTF-8?Q?L=C3=A9o?= Le Bouter From: =?UTF-8?Q?L=C3=A9o?= Le Bouter via Bug reports for GNU Guix X-Migadu-Flow: FLOW_IN ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1617747551; h=from:from:sender:sender:reply-to:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:mime-version:mime-version: content-type:content-type: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: dkim-signature; bh=I+ZAY2U8nqFePFLKHyUD5c83cw2H8xXLgMAhBEvnTZg=; b=r+EJetwup6Uo8ihFaVM9q9tu7oTKyHCAIFyT6nO1cZ78N0fYjlZD1H0Hv2y5nF/gMUjbos hYCFQ06Mdn77B2OJ6Jtfc0HnYxMEy57Z/nC6gH+nKcFZSJeTVjDCZ3V+3iWnosHOIugvQp 13lUbqdaWpMEcIDB6Gwdqa/7Gwjr+cPzZyAl9igweqcBoc1c3pM7KlEtE7qZ+f2f3Sfa+F 99Ps8huACFXAvkmi0jXoYuIjncON5N/A2yb9O7itYNt0uwA7v+vAypblfynIFOr8fBSSKs wZsSh026dQQgVEvmKqwAcwFMmkuHKkF5brSCoRi6iKhN3L2lxlcjma7eltFwJA== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1617747551; a=rsa-sha256; cv=none; b=VErFiNKrISwqASeDbYM0A4IOYX+pW2ZqfHf+9fgJfuDmT1Yw2l365LKCyiHTdCJfablIzS +5bMqNCLi6IzaNPGA1xSOEmhlSnVS1EiJ0BBvZ+HDOmK6C1Hm7zQutpkLn5r4u0mgLuvdk 2+FzRvDvc73PlUJtFqnjzkqrsp6VniZcUJgBQVpNVEus3nlnBDXt/4aW370InXJ3ncT8gg MRcalasUmWF/dflDh+Vp8Ns4LY0zxMfBuu2VTlYe0AjDOdPSWRNEh46jRhX/4MvzYEpn7z 4xKBfiWjJxVeN5O6pMPNu3EOTZHt+FkBZquo7x6FGrCjE/pmDWZaxa2y9vE1tw== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=fail ("headers rsa verify failed") header.d=zaclys.net header.s=default header.b=P1E6RA1P; dmarc=pass (policy=none) header.from=gnu.org; 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: -5.04 Authentication-Results: aspmx1.migadu.com; dkim=fail ("headers rsa verify failed") header.d=zaclys.net header.s=default header.b=P1E6RA1P; dmarc=pass (policy=none) header.from=gnu.org; 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: 05CE827B02 X-Spam-Score: -5.04 X-Migadu-Scanner: scn0.migadu.com X-TUID: BJ4VV4uS4HfV --=-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 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--