From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp10.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms0.migadu.com with LMTPS id EC7ABg/+0WFj0QAAgWs5BA (envelope-from ) for ; Sun, 02 Jan 2022 20:33:35 +0100 Received: from aspmx1.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp10.migadu.com with LMTPS id eBwNOw7+0WGcIgEAG6o9tA (envelope-from ) for ; Sun, 02 Jan 2022 20:33:34 +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 4D8CD7ACB for ; Sun, 2 Jan 2022 20:33:34 +0100 (CET) Received: from localhost ([::1]:35212 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1n46bl-0008OG-Gf for larch@yhetil.org; Sun, 02 Jan 2022 14:33:33 -0500 Received: from eggs.gnu.org ([209.51.188.92]:42022) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1n46bN-0008O7-F7 for guix-devel@gnu.org; Sun, 02 Jan 2022 14:33:09 -0500 Received: from [2a00:1450:4864:20::42e] (port=45592 helo=mail-wr1-x42e.google.com) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1n46bL-0004Qq-Hg for guix-devel@gnu.org; Sun, 02 Jan 2022 14:33:09 -0500 Received: by mail-wr1-x42e.google.com with SMTP id v7so66057460wrv.12 for ; Sun, 02 Jan 2022 11:33:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=from:to:subject:in-reply-to:references:date:message-id:mime-version :content-transfer-encoding; bh=g7N3Z7trhRKavwIEOfEjz39L9MJ09JO+ss4aICGJpsM=; b=FgllqHNahr02HFtuGA7Z8jo3DBtVPIB/hBd5N9l3f/1pK4rjhbU+HGS1Da8ECkMxoO m2Uv7R3Noe+nsoTEPK548vXnIUuHDrbq+1OmimrgO693VreqeqeGNhegA1t+zLVTMlvp 9pjvWL52gfme8jXDx2Y4cg9lMf8iayAO6lZ56SPrq7ZAc9FGEcxHDpc+LhjHyICpY+Ky TokVxh91qmg3ahxYhSLDmGNujY6bbcLK/Sm60vpYoYfdE7zbT3pmwJJ1k5suKsMo5yOd p9LXwEv22EhpXtImi6MT8nJx6onKWpijyvU/n2+qeIX64A0OIxtuqzSIkuBUiKDRp1oN eOIw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:to:subject:in-reply-to:references:date :message-id:mime-version:content-transfer-encoding; bh=g7N3Z7trhRKavwIEOfEjz39L9MJ09JO+ss4aICGJpsM=; b=m1kuzIDLmPoa12R0uIVNHKrf7cAnzMF/D2kCN95UJyWLVgsRGTY+f71Dk3KMrCaKXh E/IZinmOaBuhrlJbS/Getz8gJdSPxYKXdJ89Z6xuo49fWWmW/OuZUD4bPsSUHiFxUG+s O1gqqKhL2k3KsfqkpnBk3qXrNVxXqaM5tTD/FZCE8VmCQfqzVC7GZyvkmR3yPGFKoZic KxqEZ5K3wyzke3ja43Rj5pGWpYo3GWU5CB/1wFVX8Ykg+LB4uaE+7z5GTZdorq77yhB6 d0nWGtzEDuBs6h4gHT5xfHP3Vlo4y+lXJ7QhVImicAKphTEJNO9TL7MbriZmBcNtDCjw gCsA== X-Gm-Message-State: AOAM533/ntVBvVAmLSjMIQmIe2SMIqPOR8e8a+avhbGbT7P9GmJ4A7oT y570OFBU/u9kHL0+q7HpKPHfrUVcLnr+Ow== X-Google-Smtp-Source: ABdhPJxVYd1rYFjXJoGHzVnOS0F2dp/PuTeUNU4XqO6jcVJSsVMxqbpVlbKhgEup/j9F0Sgb6haKxg== X-Received: by 2002:a5d:660e:: with SMTP id n14mr36219614wru.613.1641151984960; Sun, 02 Jan 2022 11:33:04 -0800 (PST) Received: from lili (2a01cb04061b8800e2568b9190e03e61.ipv6.abo.wanadoo.fr. [2a01:cb04:61b:8800:e256:8b91:90e0:3e61]) by smtp.gmail.com with ESMTPSA id w21sm27930721wmi.19.2022.01.02.11.33.04 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 02 Jan 2022 11:33:04 -0800 (PST) From: zimoun To: Mark H Weaver , Liliana Marie Prikler , guix-devel@gnu.org Subject: Re: On raw strings in commit field In-Reply-To: <87r19rkx9h.fsf@netris.org> 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> Date: Sun, 02 Jan 2022 20:30:01 +0100 Message-ID: <86bl0url52.fsf@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Host-Lookup-Failed: Reverse DNS lookup failed for 2a00:1450:4864:20::42e (failed) Received-SPF: pass client-ip=2a00:1450:4864:20::42e; envelope-from=zimon.toutoune@gmail.com; helo=mail-wr1-x42e.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=1641152014; 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=g7N3Z7trhRKavwIEOfEjz39L9MJ09JO+ss4aICGJpsM=; b=M/UqDg8r2MQhTxrwvwrVDyU7gl+kYl4V7R/423HBuq3kGgIn/vkmx5RivhS3ZlO2HKHlgU YBsm2latBBGS+50fCTztxnQFSCZlzBVGkO5RuOODb3Q0ovFJSuhNiQHcWLwgJwu8igFmFp lkLYEb0Gd18IrUygzgw94YIjjeLEVqdroJS5mKtijprBhPFwIA1JVvVGvODrHQwemWkqzw c7q8oN11r3CEZOIdjVJLeN7nNpOOKNO8ueiFMObvS6QDlbfYa/+Ag5WIRJNrHHIOnvGkdR yk6TuWTeMLCDr6w8jNgtqBi1ZOSyP8k/RiEtboEsY3eMAtfBq/8cczAur1vAJA== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1641152014; a=rsa-sha256; cv=none; b=MQNRmHBNWJFfRC3XoJ6kSGA5rS5ce7RLdBgdMLRRkWWtrm3eOnoaHYLKpq6tpD9L0+5BJi IPzeXlrJVTsSZElPOi8hjLQaFEanzk/DBWlcVcQjQX80A7jgSPTZGlDwGJvfAHNsi6yJ1V 2aVzRMiANpIiRusI6DlVyoxcJZDvSXnJYpF38p4jcyyeXHnl50TxUGCTiFQoVkhnsZKP82 mEPJiTicxhF1gR/wkkpa4WAlPWNJ97u9oa2RRbNyX4HFa78rkykeAVsdkhvUiFlJTb+YzK N+BDOYOHdfVqjhMEBH9nPOAsMLO5FzT5J97NSjD0Sy1pFy07FUx7AJ8uwmyKKQ== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=FgllqHNa; 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: -4.28 Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=FgllqHNa; 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: 4D8CD7ACB X-Spam-Score: -4.28 X-Migadu-Scanner: scn1.migadu.com X-TUID: RM4GeiknNCoZ Hi Mark, Liliana, all, On Sat, 01 Jan 2022 at 15:37, Mark H Weaver wrote: >>> Where is the Cantor-style diagonalization argument that you spoke of? >> >> You skipped over it, read again. The key point is that you're >> referencing the thing you think will be invalidated to create your >> scheme. > > I've carefully read your message at least 4 times, but I've been unable > to find anything resembling Cantor's diagonalization argument in there. > Does anyone else see it? Perhaps my powers of recognition are too weak. Mark, I do not see the diagonalization either. Liliana, please point explicitly what acts as diagonale in your reasoning. Or anyone else if I am missing the obvious. That=E2=80=99s said, I think the reasoning is doomed earlier. It reads, Okay, so let's write out the full argument. At a certain date, we package or update P to version V through reference to tag T (at commit C). Because we can't trust T to remain valid, we only keep (V, C) around for "robustness". Now notice, how version V is generated by referring to T. Without = loss of generality, assume that T is invalidated, otherwise nothing to prove. Since V is created through reference to T, it is also invalidated as being the canonical V, whichever it is. A similar argument can be made for C as well. So both (V, C) are invalidated= and the only thing we can claim is "yeah, upstream did tag that T at so= me point". And this statement =C2=ABWithout loss of generality, assume that T is invalidated, otherwise nothing to prove. Since V is created through reference to T, it is also invalidated as being the canonical V, whichever it is.=C2=BB is not enough precise. Because the pair (V,C) is fixed by Guix packagers; thus whatever T is becoming, then the pair (V,C) is not invalidated. What is invalidated is the match between what upstream calls version (what we can name upstream canonical) and what the Guix project considers as version (what the end-user expects similar to the upstream canonical one). Timothy provided an example of such mismatch. The reasoning requires 2 versions: the upstream canonical version V=E2=80=99 linked to T. And the Guix-related version noted V and used by the pair (V,C) in the package definition. It appears to me hard to infer logical arguments for the link between V and V=E2=80=99. Moreover, the pair (V,C) is stored inside the immutable Guix history. Yeah, maybe tomorrow we will all be crazy and rewrite all the Guix history, because yes Guix history is just one DAG we collectively agree on =E2=80=93 I would not say it is a social construct though, anyway. As I tried to explain , the Guix =E2=80=99versi= on=E2=80=99 field matches as much as possible upstream =E2=80=9Ccanonical=E2=80=9D vers= ion defined by tag, commit, url, revision, etc. but both are not the same thing. In addition, Git-tag and Git-commit are not the same philosophical ontology. Last on this point, using =E2=80=99git-version=E2=80=99 and commit or tag t= o define Guix version (the field =E2=80=99version=E2=80=99) is not related to the issue o= f referring by tag or commit in =E2=80=99uri=E2=80=99 field. That=E2=80=99s not the sa= me level. Moreover, Liliana you wrote: Git commit hashes do not just depend on the content. They also depend on how much effort you put into solving a proof of work challenge that won't ever earn you crypto coins [1]. pointing to . The statement =C2=ABGit commit hashes do not just depend on the content=C2=BB is wrong. Specifically, it is by adding more well-chosen content that the hash is tricked. Now, Liliana, you can define =E2=80=9Ccontent=E2=80=9C by useful = content opposed as meta-content, etc. Well, it is fine but the statement still appears to me wrong because Git commit hash only depends on the content itself. 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 =E2=80=9CTricking peer review= =E2=80=9D . For instance, see my email about SWH case . 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. 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. Well, I am confused by what you are trying to raise in all this now lengthy thread =E2=80=93 I have read it several times. :-) To me, the points for more intrinsic values and less extrinsic ones in =E2=80=99uri=E2=80=99 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 =E2=80=99version=E2=80=99 field, we can do whatever we want as Guix= packagers. Then, we can come up and question by overcomplicated philosophico-logics and metaphysics arguments the meaning of life, fore sure it is interesting =E2=80=93 at least I find it sometimes interesting :-) =E2=80= =93 but I am doubtful it helps in cooking the rice. ;-) Cheers, simon