From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp11.migadu.com ([2001:41d0:2:bcc0::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms0.migadu.com with LMTPS id hjzXEcSxz2HyUwAAgWs5BA (envelope-from ) for ; Sat, 01 Jan 2022 02:43:32 +0100 Received: from aspmx1.migadu.com ([2001:41d0:2:bcc0::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp11.migadu.com with LMTPS id 6OGBDsSxz2FHYQAA9RJhRA (envelope-from ) for ; Sat, 01 Jan 2022 02:43:32 +0100 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 C900916B2B for ; Sat, 1 Jan 2022 02:43:31 +0100 (CET) Received: from localhost ([::1]:55406 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1n3TQg-0000BF-DE for larch@yhetil.org; Fri, 31 Dec 2021 20:43:30 -0500 Received: from eggs.gnu.org ([209.51.188.92]:42404) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1n3TPn-0000AQ-Ou for guix-devel@gnu.org; Fri, 31 Dec 2021 20:42:36 -0500 Received: from world.peace.net ([64.112.178.59]:54576) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1n3TPl-0004Je-K4 for guix-devel@gnu.org; Fri, 31 Dec 2021 20:42:35 -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 1n3TPj-0005v3-5M; Fri, 31 Dec 2021 20:42:31 -0500 From: Mark H Weaver To: Liliana Marie Prikler , guix-devel@gnu.org Subject: Re: On raw strings in commit field In-Reply-To: References: <6e451a878b749d4afb6eede9b476e5faabb0d609.camel@gmail.com> <87k0fm7v3k.fsf@netris.org> Date: Fri, 31 Dec 2021 20:41:42 -0500 Message-ID: <871r1smdu6.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: 0 X-Spam_score: 0.0 X-Spam_bar: / X-Spam_report: (0.0 / 5.0 requ) SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=unavailable autolearn_force=no X-Spam_action: no action X-BeenThere: guix-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+larch=yhetil.org@gnu.org Sender: "Guix-devel" X-Migadu-Flow: FLOW_IN X-Migadu-Country: US ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1641001412; 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: in-reply-to:in-reply-to:references:references:list-id:list-help: list-unsubscribe:list-subscribe:list-post; bh=EuV4FNBQh2k8yMI/qUy2ky6LliAe6U277ywvyUHx4to=; b=n/Uotln2I2pBm8STx9p/QDYsspSO5btWdmDH6hz/7Z1vynIQWdqZFiFmtn1Dk8ve0ZQxT+ dHNeMIljyX1d64PMi/eFPYvSHAP4jzG0hTZj7nVoL+5c1QC+lV8JsNy4BvDtOMQLtgG9xl KwRO91wQirPaHI8nVrjkQIMPCFKT63+rgCkJKxs6T0s5k44mfroNkgcVJfMTy/rHAc2QIo AJRbuhKxrWvXE/fkWbBy+2l0lckHwgZaKmQ8GlgjnQMLqfWyDPYVQhgGoNVrYycuIjbvNx YKKTfrZXRU8YqGM5M0MiEa0uvk91Yen1yBrnXxc42dZWCreu4yMAgFB+0Raprg== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1641001412; a=rsa-sha256; cv=none; b=V0feP1PPBGbhb+xSgB4nYZZGvRfdcoseKIQbSgq4oCDz6CUmnnOyRnqZsRML/bDHCrsVSy msKzPAQiwsoS8Sn0q0WiPsaRi69/JPqLSb63rnh1a0akTp3uzFde3vDiL4nPkEkQgnJ/CJ XfOHzaRJdFEmTa8smL7QcmSl/ZPTfhg5DGki5+Vclv2wpO/washSwmvYQVWah+BsRCol83 bSaBK628uiq7jcChCjs4gF9mlpzTbdoYlzt02WxGH+rZHx24Gxa4jU7Tee5DB+XdG7x20P 6v85OkgZa4J1OXPOxAv9xYHpOe5dJ+IIn18PwjN6QfzTMk/t13DgkiNEqRMa8w== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=none; dmarc=none; spf=pass (aspmx1.migadu.com: domain of "guix-devel-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="guix-devel-bounces+larch=yhetil.org@gnu.org" X-Migadu-Spam-Score: -3.08 Authentication-Results: aspmx1.migadu.com; dkim=none; dmarc=none; spf=pass (aspmx1.migadu.com: domain of "guix-devel-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="guix-devel-bounces+larch=yhetil.org@gnu.org" X-Migadu-Queue-Id: C900916B2B X-Spam-Score: -3.08 X-Migadu-Scanner: scn0.migadu.com X-TUID: od7aBI0skPSr Hi Liliana, Liliana Marie Prikler writes: > Am Mittwoch, dem 29.12.2021 um 20:13 -0500 schrieb Mark H Weaver: [...] >> The simple fact is that the way Ricardo wrote the 'guile-aiscm' package >> is the right way to ensure that it can be reliably reproduced in the >> future. > And here I disagree. This reasoning presupposes that we have to ensure > that the package still points to the same commit if the tag changes, > which itself presupposes that the tag does change. I disagree with the last line above. What makes you think that I'm presupposing that the tag does change? There's a difference between "presupposing that the tag does change" and "not assuming that the tag will not change". Do you see the difference? > However, if we are > always talking about more than one possible "1.2.3" (with the included > future tag that we have yet to witness), we lose the basis by which we > currently assign "1.2.3" as the version=20 I see what you're getting at here, but still I disagree. Our basis for associating version "1.2.3" with commit XYZ is simply that upstream had indicated that version "1.2.3" was commit XYZ. That historical fact is immutable. If upstream later indicates that version "1.2.3" is now commit YYZ, I don't think that invalidates our basis for continuing to associate version "1.2.3" with commit XYZ. The aforementioned immutable historical fact still remains our basis and justification for making that association. Perhaps some people would prefer to use a distro where version "1.2.3" of package FOO could mean a different thing tomorrow than it means today. Personally, that's not what I want. If upstream changes their mind about the meaning of version "1.2.3", I want that to correspond to a different version number in Guix, perhaps "1.2.3a" or something, as Taylan suggested. Incidentally, I vaguely recall that we've done that in the past, but I don't know if we've done it consistently. > As pointed out elsewhere, SWH keeps a history of the tags that we could > look up until one matches, Only if SWH took a snapshot at the right time. I would guess that mutations of release tags usually happen within a few days after the release tag is first created. Relying on SWH to take a snapshot within that possibly quite small time interval doesn't sound very robust to me. > and there'd also be the option to keep a > secondary index ourselves (or have a third party do it). That's true, but then we'd be adding another piece of centralized infrastructure that users would need to rely upon in order to reliably reproduce their systems. That infrastructure would have to be maintained indefinitely. If we failed to keep up maintenance, then users could run into problems reproducing their older systems. It seems to me clearly better to avoid relying on a piece of centralized infrastructure if it can be easily avoided, no? >> On the other hand, if we refer to git _commit hashes_, then it *is* >> feasible for us to fetch the archived source from SWH, regardless of >> what upstream has done to its tags in the meantime. >>=20 >> For that reason alone, I think that the way Ricardo wrote the >> guile-aiscm package definition is clearly the right approach, given >> Guix's longstanding goals. > To me, it rather sounds like a workaround for longstanding bugs [1, 2]. [...] > [1] https://issues.guix.gnu.org/28659 > [2] https://issues.guix.gnu.org/39575 I don't understand how it's a workaround for those bugs. Even if those bugs were fixed, we'd still need a reliable way to find the git commit that matches the one expected by a git-fetch record, i.e. the one that will produce a source checkout with the expected SHA256 hash. Am I missing something? >> > On the note of fallbacks, we do also have the issue that Guix fails >> > on the first download that does not match the hash instead of e.g. >> > continuing to SWH to fetch an archive of the old tag (as well as >> > other fallback-related issues, also including the "Tricking Peer >> > Review" thread). >>=20 >> That's a bug that can, and should, be fixed.=C2=A0 The existence of that >> bug might temporarily prevent us from enjoying the benefits of >> Ricardo's approach, but that's not an argument for adopting practices >> that push us farther from our core goals. >>=20 >> What do you think? > Which bug are you talking about? "Tricking Peer Review" or the > fallback thing? I was talking about the fallback issue. > If it's the fallback thing, then that's an enabler for > Ricardo's approach, since as you pointed out the commit will still be > fetched correctly from SWH (if not from the main repo itself).=20 Right. > Now, "Tricking Peer Review" is a harder thing to circumvent. We would > need to issue a warning, preferably a big one if fallbacks do kick in > unintended, i.e. particularly outside of time-machine. Regarding "Tricking Peer Review": I think it would be ideal for package definitions to include both the git tag _and_ the git commit hash, and to teach our linter to raise an alarm when the expected tags are missing or fail to match the expected commit hash. For similar reasons, it would also be good to include the fingerprints of upstream PGP signing keys in our package definitions, and to teach our linter to check those signatures and that they match the SHA256 hashes in our recipes. What do you think? Regards, Mark --=20 Disinformation flourishes because many people care deeply about injustice but very few check the facts. Ask me about .