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 /fKYGwvTbGAFigAAgWs5BA (envelope-from ) for ; Tue, 06 Apr 2021 23:30:51 +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 MLaMFAvTbGBWVwAA1q6Kng (envelope-from ) for ; Tue, 06 Apr 2021 21:30:51 +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 AF05F27C7A for ; Tue, 6 Apr 2021 23:30:50 +0200 (CEST) Received: from localhost ([::1]:49116 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lTtHc-0006Kq-II for larch@yhetil.org; Tue, 06 Apr 2021 17:30:48 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:44754) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lTtGz-0006KC-Bl for bug-guix@gnu.org; Tue, 06 Apr 2021 17:30:09 -0400 Received: from debbugs.gnu.org ([209.51.188.43]:58625) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1lTtGs-0004YU-N4 for bug-guix@gnu.org; Tue, 06 Apr 2021 17:30:07 -0400 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1lTtGs-0007LZ-Jm for bug-guix@gnu.org; Tue, 06 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, 06 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.161774458328191 (code B ref 47614); Tue, 06 Apr 2021 21:30:02 +0000 Received: (at 47614) by debbugs.gnu.org; 6 Apr 2021 21:29:43 +0000 Received: from localhost ([127.0.0.1]:41938 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lTtGZ-0007Kc-6H for submit@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 ) id 1lTtGX-0007KO-9o for 47614@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 ) id 1lTtGQ-00078F-KH; Tue, 06 Apr 2021 17:29:34 -0400 From: Mark H Weaver In-Reply-To: References: <87k0pf7jti.fsf@netris.org> Date: Tue, 06 Apr 2021 17:27:53 -0400 Message-ID: <87tuojqf0r.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=1617744651; 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=XoSbegkK+eZU7oxElKCLI0T8uNbLpnhYFht8WZnjf50=; b=o5ak5zamD0soHfLeqjRxQzBOZzK/jG9O3rRV8iZfm/PveDH9eU6MExewwi+P/sQNLszhRY pZsMaC3yA0JLSTWcevt73tqmotjH+T4hJabbvn6sutXTsO+r/DtrSJXzrCnPdTXNA35xWT VNDvQ9A2HC1mMNc7OnTyS5Y8pDoC6psFGDaUFHRI/XqPEUr1o4i4gTkyv2gHWO40byrS2h Ik1V2n5Cie912cfQVMgykibb2BjJXbeO6kiORPacL/kwyBUbh0LSiP6rU79lT3fjwODfUm nX/dAkuOTLyG6v4Vgemk6T92x6lOslbli4md95jU/PCWdQCAgst8TQL1gp7XGg== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1617744651; a=rsa-sha256; cv=none; b=gcwICSpiQOAXxEBFgqRgt516sC+Pdsp2rTwwNODOPVsCsbnO3G/GasRlcZzJWX9aaAtGEU VdIZcIhKUe3oKD66kuB2t7X5/GfL8QSpI6jlANrckEB8IDfBgVWYEbVhr1xzGQv4iJylk+ Sc5r2fgJACKQPuR7jhHreUMqcNNBWrc/7YPZcnvr0L/Zzk8vcYTgD9PTIbQZPCn/jqQfC0 doi11ZeZtq7xdrO+kBloucyXdKIxFaVu+i+miH8PQteIyRSoVKEM8bDU7DpguxDQmPg9qH Jz/8xFS5yCTwPkLvRNFC4EwBb+WeSKmZ5wQMjwOAGRcH/SNdX9hluVNUNuxdNg== 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: -2.44 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: AF05F27C7A X-Spam-Score: -2.44 X-Migadu-Scanner: scn0.migadu.com X-TUID: xl77M/Node4j Hi L=C3=A9o, L=C3=A9o Le Bouter 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