From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp2 ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms11 with LMTPS id GN7CClTF11/cAgAA0tVLHw (envelope-from ) for ; Mon, 14 Dec 2020 20:04:36 +0000 Received: from aspmx1.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp2 with LMTPS id mPyMBlTF118wGwAAB5/wlQ (envelope-from ) for ; Mon, 14 Dec 2020 20:04:36 +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 B358C940253 for ; Mon, 14 Dec 2020 20:04:35 +0000 (UTC) Received: from localhost ([::1]:44648 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kou5C-0000F6-OA for larch@yhetil.org; Mon, 14 Dec 2020 15:04:34 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:39794) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kou50-0000Ek-4Q for guix-devel@gnu.org; Mon, 14 Dec 2020 15:04:22 -0500 Received: from world.peace.net ([64.112.178.59]:54278) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kou4y-0003px-2l for guix-devel@gnu.org; Mon, 14 Dec 2020 15:04:21 -0500 Received: from mhw by world.peace.net with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1kou4l-0000dJ-FK; Mon, 14 Dec 2020 15:04:07 -0500 From: Mark H Weaver To: Leo Famulari , zimoun Subject: Re: New =?utf-8?B?4oCcdW5ncmFmdGluZ+KAnQ==?= branch In-Reply-To: References: <87v9dcv8mt.fsf@gnu.org> <86sg88oeze.fsf@gmail.com> Date: Mon, 14 Dec 2020 15:03:16 -0500 Message-ID: <87v9d4rw80.fsf@netris.org> 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@netris.org; 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-BeenThere: guix-devel@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Guix-devel Errors-To: guix-devel-bounces+larch=yhetil.org@gnu.org Sender: "Guix-devel" X-Migadu-Flow: FLOW_IN X-Migadu-Spam-Score: -2.31 Authentication-Results: aspmx1.migadu.com; dkim=none; dmarc=none; spf=pass (aspmx1.migadu.com: domain of guix-devel-bounces@gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=guix-devel-bounces@gnu.org X-Migadu-Queue-Id: B358C940253 X-Spam-Score: -2.31 X-Migadu-Scanner: scn0.migadu.com X-TUID: LtRgGhimGRnU Hi Leo, Leo Famulari writes: > When we added the recursive grafting feature, we intended to use it to > deploy urgent security updates quickly, but we also intended to > "ungraft" quickly, maybe in a week or two. We never planned to keep > packages grafted for several months as we do now =E2=80=94 grafts were > considered a necessary but unfortunate violation of the functional > packaging model. I disagree that grafts are a violation of the functional packaging model. The only violations of the functional package model that I'm aware of are cases where packages fail to build deterministically. In other words, if a set of packages build deterministically, i.e. if the process to build them is a mathematical function, then it will still be a mathematical function when grafts are added. However, one potential issue with grafting is that packages are _built_ against the original (buggy) packages, and then store references to those buggy packages are later replaced (via copying, not mutation) with references to their replacements. In some cases, that might not have the same result as building against the replacements to begin with. So, it's still a mathematical function (assuming all packages build deterministically), but not necessarily the same function as if normal upgrades had been done instead of grafts. That's the main issue with grafts that I'm aware of. One particular case where there's a difference is if there are any references to grafted packages in build outputs that the reference scanner is unable to find, e.g. references within compressed files, or references encoded in UTF-16. Even without grafts, these hidden references can be a problem, because if *all* references to a dependency are invisible to the reference scanner, then the dependency could be deleted by the garbage collector, leaving those references dangling. With grafts, the problem of these hidden references becomes far more severe, because the hidden references will not be rewritten by the grafting process, and thus references to packages with security flaws could remain and be used at run time. This is not a violation of the functional packaging model, though. Does that make sense? Regards, Mark