From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp10.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 sNnmJTs30GESagEAgWs5BA (envelope-from ) for ; Sat, 01 Jan 2022 12:12:59 +0100 Received: from aspmx1.migadu.com ([2001:41d0:2:bcc0::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp10.migadu.com with LMTPS id YAOrHjs30GFshQAAG6o9tA (envelope-from ) for ; Sat, 01 Jan 2022 12:12:59 +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 ED76F303F3 for ; Sat, 1 Jan 2022 12:12:58 +0100 (CET) Received: from localhost ([::1]:58622 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1n3cJm-000758-4r for larch@yhetil.org; Sat, 01 Jan 2022 06:12:58 -0500 Received: from eggs.gnu.org ([209.51.188.92]:48138) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1n3cJU-00074y-EW for guix-devel@gnu.org; Sat, 01 Jan 2022 06:12:40 -0500 Received: from [2a00:1450:4864:20::441] (port=43813 helo=mail-wr1-x441.google.com) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1n3cJS-0004AZ-DM for guix-devel@gnu.org; Sat, 01 Jan 2022 06:12:40 -0500 Received: by mail-wr1-x441.google.com with SMTP id o3so1938863wrh.10 for ; Sat, 01 Jan 2022 03:12:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=message-id:subject:from:to:date:in-reply-to:references:user-agent :mime-version:content-transfer-encoding; bh=EA+c+3GX5zCwthSNXHCfCbhyWsMcmRIkkIL8MSHBuUI=; b=cdZRtELfrhe8ao7BTmLy9Wt2l4oRtjXz/Vn76MsCJo00zfdaujMntcZC94+xZxEqAM 7A9KLiZFZEe2oXyFThb+5JUBdGQ4mGpa+HboeubA4x/Z4R80ZbT25Ro+zG9j1dkZpGZk jhirX6yLNx+x37DTp4B3Nfh7VjN14YX8UH2hXZpNancw8cgyJVUgoGBCuV0mpe1/6Q1R Td4AzD7shDpHfISsI7Gr6kNOLAVsw+gHv48bKVVureciOkk07MHnA6HBBkp4xQ7wgnqT yTaNe94ZnxqrhKgak/pMkRhsXFbNwOfBeo/ItRN8hX+LKcE04YBkj1aPS8UnoOick5F1 SrHg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:subject:from:to:date:in-reply-to :references:user-agent:mime-version:content-transfer-encoding; bh=EA+c+3GX5zCwthSNXHCfCbhyWsMcmRIkkIL8MSHBuUI=; b=nKSY6k4DaVO5/JEbAXxo4vbvQRYPWFUp4xOTmyr12hLQJPpD99+7FQ9VwltkLCrJHT cgv3f6kGW7CTJKJjHKGs2EmOd08aiWA5UbPoi5RuqKlYozeGN0WmsNgNy4EoLeX7/4fF oytRFicx6A8+wKGamaZuKrFvVZ1f0QmTzQkjPPrqEZich4P7RDjb2QD6gwkSjudzYX7Y QCMFJgqLyFN0brEE4kU5Kwx6ytOzKIOCEMVSkRWaWXfKLZu8L8OLQG0XorKJcB9IT68F 4EW2q8PBu1fOfyLPZA2rX5N4Dj0sbrIxwzzw0MM50mca4zZCeu3tnhgGe9h5UfdRKyTD DqAQ== X-Gm-Message-State: AOAM532zyxvI0o6yHo4pEDMCuI8ypcUjJ3MgNYYaEuJka8va3jNzt4EH 1Ga20D+D84OSxxd8T/e1HFtZExXzMkxGhQ== X-Google-Smtp-Source: ABdhPJxYZEPZK/H4cxGxA4Po0lYZtGnr80ORm1Bs+N4/UBhFzVK+x+NUWZxG1S8J3zB/YX+EQW1RAw== X-Received: by 2002:a05:6000:10d2:: with SMTP id b18mr31858928wrx.193.1641035555329; Sat, 01 Jan 2022 03:12:35 -0800 (PST) Received: from nijino.fritz.box (85-127-52-93.dsl.dynamic.surfer.at. [85.127.52.93]) by smtp.gmail.com with ESMTPSA id p22sm38501316wms.2.2022.01.01.03.12.34 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 01 Jan 2022 03:12:34 -0800 (PST) Message-ID: Subject: Re: On raw strings in commit field From: Liliana Marie Prikler To: Mark H Weaver , guix-devel@gnu.org Date: Sat, 01 Jan 2022 12:12:33 +0100 In-Reply-To: <871r1smdu6.fsf@netris.org> References: <6e451a878b749d4afb6eede9b476e5faabb0d609.camel@gmail.com> <87k0fm7v3k.fsf@netris.org> <871r1smdu6.fsf@netris.org> Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.42.1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Host-Lookup-Failed: Reverse DNS lookup failed for 2a00:1450:4864:20::441 (failed) Received-SPF: pass client-ip=2a00:1450:4864:20::441; envelope-from=liliana.prikler@gmail.com; helo=mail-wr1-x441.google.com X-Spam_score_int: 6 X-Spam_score: 0.6 X-Spam_bar: / X-Spam_report: (0.6 / 5.0 requ) DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RDNS_NONE=0.793, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=no 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=1641035579; 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:dkim-signature; bh=EA+c+3GX5zCwthSNXHCfCbhyWsMcmRIkkIL8MSHBuUI=; b=RfD2nRVQ/qspdVPU/UVzKNLgAZzADoSfQMsne9/xwj3bmKpezSKSQGOb+NH4MXOp/qFYOd YOVmWADEtnaGEoW6el8AyYT9W8G5sPbd/TzAgpP00x5XfvCDiyN3d7neQ69eSLrZ7dDCgN j4WrRzqjvsLhuyYyAwZRV3XH7IAB1qKNNql7aMAensKitQeo9shsJfq3ZqFbaISxsgdqcg aj4IXyYUD7u4rl1LdU8ZFxnmz8j2mry6ZVIIv0OJTTbddyG32T68bWBBS0dxLLEKdxbveU OaTHz1UnaXjE6CyQNnFSEvwTw86sb4viuh4aV4WIAyUdd2unqRQXqpIQKuX+lg== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1641035579; a=rsa-sha256; cv=none; b=SqnNyE4XxAiskO881LfGDEs4vFmeGFxTSKJKnj0IY7s6btS33BdB4/WW1xHai2tKpGc02g ygpt9oo6qNPjukGN1Qyk3HipAuwrVyEC7KEghadjtsyGgAa8QBHxZk9FJ/PPFQBfKwMoU2 B0tb+ghzmtysXV3hewHajkQDn8iAn4cwoa/BZlu1pfys1QUivlSdy44hSUx16zJf0PABEG xTyvaJtaKgx21uz4oAP1A6R0YIAU6Rnnkyn6UBfqxPh8H99hxWNdyRKpdbTBpo15v1ppV6 SoxXNlJ6tnNDtoasYEGJLkhzv1k0BYbxvI7qN2AbG1M7Bf7I2yavyc9Iw13m1w== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=cdZRtELf; dmarc=pass (policy=none) header.from=gmail.com; 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: -6.28 Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=cdZRtELf; dmarc=pass (policy=none) header.from=gmail.com; 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: ED76F303F3 X-Spam-Score: -6.28 X-Migadu-Scanner: scn0.migadu.com X-TUID: HOJ1V0AKoSAt Am Freitag, dem 31.12.2021 um 20:41 -0500 schrieb Mark H Weaver: > 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? I'm pretty sure ¬assume(¬X) = assume(¬¬X) in this concept. You have to start with some assumptions and while ideally we'd like to encode "I don't care", we do not have a system that allows us to do so. > > 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 > > 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. History is a social construct, it's not 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. I'm pretty sure it does, particularly to a future observer who may not have the luxury of a history to distinguish that record from one in which a malicious committer linked those versions and tag together and then no one bothered to check. > 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. The entire point here is to use git-version in combination with let- bound commit hashes, yes. > > 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. If the scenario is "a few days within release" vs "literally forever", there would for one only be a relatively short range of bad Guix versions having a broken reference (limiting impact) and for another, the majority of the audience would also associate the latter with said version. There's really no good argument from the robustness side to be had here. > > 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, the > 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? We can make that a key-value store for which you write a distributed MapReduce function in Erlang if it makes you happier. > > > 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. > > > > > > 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? We are working on the base assumption here, that we have an (array of) reachable fallbacks in any case, I don't think it's too big of a leap to assume that we can keep a mapping  (origin-file-name x origin-hash) → canonicalized-uri around either as part of said fallbacks or in parallel. > 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. That is among the solutions I've proposed here, so naturally I'd be fine with it. > 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? I think that is one of the main things we could import over from Guix for Racket users (previously Xiden, currently denxi). I.e. we could have (origin ... (sha256 some-hash) (sha512 some-other-hash) (pgp-signature sig) [other validation forms...] [patches and snippet]) We would have to break record ABI for that, but imo with field sanitizers that's something we could code up. If at some time in the future SHA-2 is broken, we can then still rely on the robustness that breaking all of these hashes would be difficult and perhaps not worth it for GNU Hello. Now obviously, there is a performance tradeoff here. You don't want to only check signatures all the time for a relatively minor build (particularly with Rust where the build phase is literally copy-paste for 90% of the packages). So we'd have to add a configuration option on the sliding scale between "only check the weakest" over "only check the strongest" over "check at least N at random or all of them" to "check everything always". Cheers