From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp11.migadu.com ([2001:41d0:8:6d80::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms0.migadu.com with LMTPS id BcXVEtYa0mHfcgEAgWs5BA (envelope-from ) for ; Sun, 02 Jan 2022 22:36:22 +0100 Received: from aspmx1.migadu.com ([2001:41d0:8:6d80::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp11.migadu.com with LMTPS id kJaDD9Ya0mH5dQAA9RJhRA (envelope-from ) for ; Sun, 02 Jan 2022 22:36:22 +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 675E6FEAA for ; Sun, 2 Jan 2022 22:36:21 +0100 (CET) Received: from localhost ([::1]:40430 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1n48Wa-0003Uf-Db for larch@yhetil.org; Sun, 02 Jan 2022 16:36:20 -0500 Received: from eggs.gnu.org ([209.51.188.92]:32796) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1n48Vu-0003UK-O4 for guix-devel@gnu.org; Sun, 02 Jan 2022 16:35:40 -0500 Received: from [2a00:1450:4864:20::342] (port=39526 helo=mail-wm1-x342.google.com) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1n48Vs-0004PZ-TQ for guix-devel@gnu.org; Sun, 02 Jan 2022 16:35:38 -0500 Received: by mail-wm1-x342.google.com with SMTP id g7-20020a7bc4c7000000b00345c4bb365aso17521197wmk.4 for ; Sun, 02 Jan 2022 13:35:32 -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=ZWSLj5JfTu6kKAu9YbWt9ff82LBspYJ1b1zPpd3tT48=; b=IPoFF+e+1x/F1+b0y/I94AWpbolNPV+LVKVXFZ86mhx5ib8wUl5Xpq/Ph08d3o60wQ okLBdw0sHK11TQ5LKIQ9VrzF9WMQNVUDL8i64Bk+jg6kA0M5NZcwfTAwk1LdNLpVuvxD J1mLPzltSuqUAsmVZTp6C5pDYgkqbDAtQORC6MM4MkQf6QHfEIWWbeBoTuuL/WcBvzrw eVSaABl7+CXiqKOWBLjrHlKLdxK46wWsQUSjs7EpCRYk6oLD/M49VsD3f9o4hMucsuZr /SjPG6LhWhwo0S816Z4dB9RFWQ7CH9v5Va/FuHXroQmhL6a+A43fLhRG7MxulIvv9riV Y8KQ== 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=ZWSLj5JfTu6kKAu9YbWt9ff82LBspYJ1b1zPpd3tT48=; b=b0umwF1rs3Tu6c33JBu8QqQ2UeElDqT5s+tCvNRoAcSQlkKkVeBvfl//hHtLy3XSgT c08CBDsVLEpVhdLLf1JJeaQRbPas8r2vG1QdfbtfkTfHveuoEmREPwfsL6tj6UztJ1Wh wa5fTsV9h+G9/4oLsx2BGEGYQ+Buad1b3volXFDwFnhySXh8PqKfsxw63Ydft2TR/CnL 4Q4skVYrhLqR6Jdlf4QW1IRHXE2kHDZEoFAtuWU7GoAVQ+WQwWePAKUMR4fT4xRVzJ/J onBL+pvPU+IjTttfXfFURjBhU1cfX4726fdnplB9piO6mYwh/DXO8A5zwhnPUn4Bt6hV lfNA== X-Gm-Message-State: AOAM533iRMSP1nD+lEqWrbHc3Fn6vAWYAteXZlAfDEi+DaLwkxmXcHyU GDtD+9DL7qlyoThZbsEHoJI= X-Google-Smtp-Source: ABdhPJwVJpvo2hdDICnTZLmiQcYZ2hqI6J5u7PITj45MufBoHXfpkvjnIyf0IGYdxsT7Qj1iTcYqPg== X-Received: by 2002:a05:600c:4f46:: with SMTP id m6mr30439823wmq.19.1641159331184; Sun, 02 Jan 2022 13:35:31 -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 r62sm31708577wmr.35.2022.01.02.13.35.29 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 02 Jan 2022 13:35:30 -0800 (PST) Message-ID: <86bf0d941ff6095961670a41478e603fa961e498.camel@gmail.com> Subject: Re: On raw strings in commit field From: Liliana Marie Prikler To: zimoun , Mark H Weaver , guix-devel@gnu.org Date: Sun, 02 Jan 2022 22:35:29 +0100 In-Reply-To: <86bl0url52.fsf@gmail.com> References: <6e451a878b749d4afb6eede9b476e5faabb0d609.camel@gmail.com> <86y243kdoo.fsf@gmail.com> <899587fb6a76ddfa37d197d3d0fd23cdc7ad8592.camel@gmail.com> <867dbmi7pf.fsf@gmail.com> <3d448fe42f0c43574db96fa26aecd7da5fd5a95d.camel@gmail.com> <877dbkmjm9.fsf@netris.org> <762e9fb7116c442bf0f8f63221bf32fa2b77f2cf.camel@gmail.com> <87y240kq2i.fsf@netris.org> <9362c6fb7e34ded5d009c3f79cd18300d6cd539c.camel@gmail.com> <87r19rkx9h.fsf@netris.org> <86bl0url52.fsf@gmail.com> 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::342 (failed) Received-SPF: pass client-ip=2a00:1450:4864:20::342; envelope-from=liliana.prikler@gmail.com; helo=mail-wm1-x342.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=1641159382; 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=ZWSLj5JfTu6kKAu9YbWt9ff82LBspYJ1b1zPpd3tT48=; b=KB7/EYtsAWKWY3l6thuVaoNwr3UVz9atg8aU/wjxQfjvmXmWDfujA0EB7dfWklePbVOPgf EvklMHMiPA9aALwyctJBFW+2STRj5lrvGoHkkHACwGDaJ1/3r21eO4WcEmD451vT4CrGBf 7nX7LLTk0Gc80vXFTBqyvCY9m7lKrziVQqOhRSeZZWp7Md+Cy33i8SpH97V/4obymQ+6AB EZ+Huluo/vx0uwvqsNJvSsJ7mWczPa7+as19WqjTKs7EiOQvumN5HcQQ34ZeNjWUic315J 4vYEzZM5i8Tdf5KR2uQYpRADfE+RlfYXAbZonAOCXB1hsvWmv/EVDahZ/PCpKA== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1641159382; a=rsa-sha256; cv=none; b=axvqa9OSRm9FNrYpAog5hFaLYC0YPfbq0bhBJmyrz9V9VcMWykNpg9AVpWJeSIj+aHtzMh 0OE+XBzioQeZAGwAMUE6/3M0fTWXpU1Gx8lYuWSIgNnZO0ZRWl5qcQJ54SS95+U9xDZ+lV vLPfwsLy4vZP4TYVyiFp3zysxXS17OLQOvCM+j0uqfOL7V+3vW4uE7dCibd4Uuord1ykia ZZtD601heqLNO4J2GTLXuXVp2k5yL2q/fzlCg4e/VmU50kIcMz3XjaasZIu6AAxDYhcCx2 YdceTfYSuDHcG7tOy5qYpuS3YWWUE0VCZsEo9hK9eIntJWo9AqHhrDxXJJeMzA== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=IPoFF+e+; 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: -9.28 Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=IPoFF+e+; 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: 675E6FEAA X-Spam-Score: -9.28 X-Migadu-Scanner: scn0.migadu.com X-TUID: Yz0SCF7lhvto Hi Simon, Am Sonntag, dem 02.01.2022 um 20:30 +0100 schrieb zimoun: > Last on this point, using ’git-version’ and commit or tag to define > Guix version (the field ’version’) is not related to the issue of > referring by tag or commit in ’uri’ field.  That’s not the same > level. Look at the title, now back to me, now back to the title, now back to me. Sadly, that title is not about whether to use a commit in the , but whether to use a *raw* commit string and not indicating so in the version field of the . So while a preference of git-fetch over url-fetch, commit over tag (or the other way round) are perhaps adjacent, the use of this style rather than let- bound commits with git-versions is pretty damn relevant. > The statement still appears to me wrong because Git commit hash only > depends on the content itself. If you define content through the NAR hash used by Guix, I'm pretty sure vanity commits invalidate that statement. > If your point is that Git using SHA-1 is subject to chose-prefix > attack, yeah it is well-known since, > >     https://sha-mbles.github.io/ > > and it is even discussed in the long thread “Tricking peer review” > .  For instance, see > my email about SWH case < > https://yhetil.org/guix/86r1cgcb8r.fsf@gmail.com>. > > Even more, we discussed chosen-prefix attack and SHA-1 for channel > fallback starting here . > > Somehow, as always and even outside content-address system, you have > to distinguish between identifier and integrity.  Anyway. That might work against injecting evil content, but the attack surface for a denial of surface (which is what we need to consider in our robustness argument) is a little larger, don't you think? Heck, if I'm in control of the forge and I used a preimage attack to push a different commit under the same hash, Guix would not even bother using SWH and just error out (once substitutes have been garbage-collected, which again is a prerequisite for any robustness argument and may therefore be assumed). > In despite of being aware (before this discussion) of many flaws, I > am still thinking that intrinsic values is better than extrinsic > values for referencing source or paper or else.  And yes, intrinsic > values are not the perfect solution but it is really better than > extrinsic ones; and it is not because it is not perfect that it is > not worth or preferable. > Although not perfect, it is still better.  Where the impression of > all your lengthy answers provide is that intrinsic referencing has > some well-known issues so let find overcomplicated strategies to fix > extrinsic referencing which has even more issues. If intrinsic values are so good, why wouldn't you use them for versions then? :P Our issues here are not of technological nature, they are social issues. I don't care if we're using SemVer, CalVer, jiffies the start of the pandemic, BibleVerse or years since the birth of Kim Il Sŏng to version and url-fetch, svn-fetch, git-fetch, or butterfly-fetch to fetch software. I care about consistency, both internal and external, which for any given package means using (V(T), T) or (V(T, C), C) and not (V(T), C), though of course the choice of which might vary. > Well, I am confused by what you are trying to raise in all this now > lengthy thread – I have read it several times. :-) > > To me, the points for more intrinsic values and less extrinsic ones > in ’uri’ field are: > >  1. yes, upstream extrinsic addressing are handy >  2. but they add burden for lookup >  3. uri requires intrinsic addressing to ease long term >  4. it is not clear what intrinsic values pick and how to transition > > and for ’version’ field, we can do whatever we want as Guix > packagers. There are a few equivalent ways of formulating my core point here, so pick the one you're most comfortable with: 1. If you can't trust tag T to uniquely label version V(T), you cannot do so for the commit C it points to either. 2. If you can't trust tag T to always point to commit C, there is no basis on which you can claim V(T) is provided by C. 3. If you version a package V(T) and fetch it using commit C, but T points to C', that's an issue. Bonus claim as a length extender: 4. If you cannot trust commit C to remain for as long as you want it to stay... well, then you'd better not use git-fetch at all, don't you think? > Guix history is just one DAG we collectively agree on – I would not > say it is a social construct though, anyway. Oh, but it is, and it has been changed in the past. Now try finding out when. Bonus points if you do so in 10 years without referring to logs.guix.gnu.org. Jackpot if you do so after Guix switched its version control system because Git still uses SHA-1 in year N and it has been utterly broken at that point. All our versioning systems, whether "intrinsic" or extrinsic are socially constructed through our collective agreement to use the same software to assign meaning to a particular mapping.