From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp12.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 mH14Os6A02FEWQAAgWs5BA (envelope-from ) for ; Tue, 04 Jan 2022 00:03:42 +0100 Received: from aspmx1.migadu.com ([2001:41d0:8:6d80::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp12.migadu.com with LMTPS id wNsYN86A02HkcwEAauVa8A (envelope-from ) for ; Tue, 04 Jan 2022 00:03:42 +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 5FDE43DD91 for ; Tue, 4 Jan 2022 00:03:42 +0100 (CET) Received: from localhost ([::1]:34210 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1n4WMf-0000e1-I8 for larch@yhetil.org; Mon, 03 Jan 2022 18:03:41 -0500 Received: from eggs.gnu.org ([209.51.188.92]:50998) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1n4WMO-0000Nw-2l for guix-devel@gnu.org; Mon, 03 Jan 2022 18:03:24 -0500 Received: from [2a00:1450:4864:20::32a] (port=37576 helo=mail-wm1-x32a.google.com) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1n4WMM-0003vq-0M for guix-devel@gnu.org; Mon, 03 Jan 2022 18:03:23 -0500 Received: by mail-wm1-x32a.google.com with SMTP id a203-20020a1c7fd4000000b003457874263aso21791250wmd.2 for ; Mon, 03 Jan 2022 15:03:21 -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=K+c2iVqxBTxCmpR3WHHzCSa5omzxgt8snq9HlbVLQ6w=; b=PNeLYGdLt6+xrxTWue0fjGltvgMXu/WCfAt7SIiP2hY50fNFpgV+LTpGsIlZkLkVoN MYEWbUnYvXWvYuDasWsDYKgNbZC49V8cFZVuLR3FVzberBawBDr5vidMPkxGdAQdmEC6 Owpn0MN7qS+1+JkiXD1LZBo1+6KfMyyngbgsB3qUaMq1RJo7Q7Mx57wNxgnLTOdY0aZV dwe/A91e+McksMreinhZ3n0+oX4SID+eN8oevHM3msQmO2KgyIzQOOVCmoFOWaMKYOmD ntvG3xS6SvV3wPf8OCE9pcYmOnywm+m4PzW66Z+WndtH9mB7T61pVbioAkI1UWTYG89A W8Bw== 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=K+c2iVqxBTxCmpR3WHHzCSa5omzxgt8snq9HlbVLQ6w=; b=8BSAO5zf7hrEm8xAKoEyQs0Qj/B9yYHAiU8lTnyyjDCEazfvLFafEQmwTgLnn8nICg GL+YMBMYNXOKEPrjcLTTBlrd5R7AnemI4veaH9W2PGMrEIZSRnm3iVPjHvB00ZOfKuZ6 RSXo/wmTlp6iCe5vYbR+1Pwocm9hRRyeUiSWDgxb94bxabLlcwo1Gulmo9tlnv/QzLz/ fy7Wm931H8cJQW0WTVhFo29u4rtsMcpM4QXjoOq7sDxAflfJhJfJZKdzP4s3JA8Sipmi YECbH1bNTQcrcm+l5lsweeAfjs0ecBKZiupHbpQM4ESne0s/4lsWmrwrEIvxpYiCqw4t XiAQ== X-Gm-Message-State: AOAM530emsFNp7Rl6mgaBepAFP2NZntJvrsscGxUDKARqU38U49YCJ/A 1V2bwep71GjqIaakSBvog7GGBKOtwkY= X-Google-Smtp-Source: ABdhPJzohfPjYkqX+lHq+SMFxdHLpiQPh7AzBxfI7egPgSjOQpfRB9xjyz0J3hCCBDstK5954Dw6rg== X-Received: by 2002:a1c:740c:: with SMTP id p12mr39899659wmc.140.1641251000541; Mon, 03 Jan 2022 15:03:20 -0800 (PST) Received: from lili ([2a01:e0a:59b:9120:65d2:2476:f637:db1e]) by smtp.gmail.com with ESMTPSA id p18sm48955736wmq.0.2022.01.03.15.03.19 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 03 Jan 2022 15:03:20 -0800 (PST) From: zimoun To: Liliana Marie Prikler , Mark H Weaver , guix-devel@gnu.org Subject: Re: On raw strings in commit field In-Reply-To: <0fff4aa2b320a82905c4b6bd43f7cd3d6e7493c6.camel@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> <86bf0d941ff6095961670a41478e603fa961e498.camel@gmail.com> <864k6lw4vh.fsf@gmail.com> <8fc6f95442ff8c5f0d5a317a84b7bdd180543cae.camel@gmail.com> <86tuektz7j.fsf@gmail.com> <0fff4aa2b320a82905c4b6bd43f7cd3d6e7493c6.camel@gmail.com> Date: Tue, 04 Jan 2022 00:00:05 +0100 Message-ID: <864k6ke87e.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::32a (failed) Received-SPF: pass client-ip=2a00:1450:4864:20::32a; envelope-from=zimon.toutoune@gmail.com; helo=mail-wm1-x32a.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=1641251022; 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=K+c2iVqxBTxCmpR3WHHzCSa5omzxgt8snq9HlbVLQ6w=; b=A2zA4n9n5+FtUoMu3US9t9hu8RU3QBxzLwjXUjprcazRKYIeWqdA+qtTKEoM2JgrCc7G2E 5jQiJrfAcUnJ1QaHi4YstAjYewiK3CPMIRohkn/veY6ayXsCKR9o5+Oz4oabobYq1bkYq8 CzudW9c3J3+IdAPHT89dwVJhZQR7hPk3cxp2DUujyqKLZhVv7ZrxgEXwk/ny9Ei7N5rCzd bsxCzwOryvVzGeUJLR7IUFy2K+lxgTkfKCSBa+P05hpEcQ52af5SRf7w8Z9XgEmEJbFNUI Pn8+EyFgBKexogrU894kTExBPLNNXlW629I46qtqY6SivWatGbP2V7j+gq+1PQ== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1641251022; a=rsa-sha256; cv=none; b=nqRG0NOjCIObQP2U0+qnsqxbXYoten6lvB4qlNziOQ5jU4rCy3QxIU+9qQHQu2kC41xsj7 VSKdrxCSsBZNutWJugrR9M6xKms75IdyQ0OlvO9Rmi3sGB6jmkNOAFgk4Fl9gQ97J1UEBJ Vh8hOEndjqiRslpy6wcLyni3u++C/cW22sQ9bwLtnwtWjNkPWuKUb9Ml9x7x0Qx3jA6PTG FzBbsafr16wGqqZ0QuCesJGOdowqZ01t5hNOMkynVFUBQLMM3kiiuROpNTW78LkLRs3yVg Lfb28o1WM9c4AwqO3IqOBe54oZLEZo8ZblpxILmtRuftkXY5Ijcaq+H73Hxqeg== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=PNeLYGdL; 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: -8.89 Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=PNeLYGdL; 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: 5FDE43DD91 X-Spam-Score: -8.89 X-Migadu-Scanner: scn0.migadu.com X-TUID: ZXVpu5nk+AtX Hi Liliana, On Mon, 03 Jan 2022 at 21:19, Liliana Marie Prikler wrote: > That's not the case I'm making here. The case I'm making is that Git > considers some content content, which Guix does not consider content. > If I push the same file to two branches, once with the commit message > "Hello Mark" and once with "Hello Simon", they're the same file to > Guix, but different files to Git. You are saying what I predicted you will say :-) ; here I quote myself: 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 m= eta-content, etc. Well, it is fine but the statement still appears to me wrong because Git commit hash only depends on the content itself. Sorry, I used meta-content instead of =E2=80=9Ccontent content=E2=80=9D. :-= ) In all cases, that is part of the content that is hashed. Well, maybe I appears picky but I feel there is a fundamental misunderstanding somewhere. :-) Just let recap. :-) You wrote, full quotation: 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]. And the statement is incorrect, especially in the light of your last comment. If you read my first email, I took the example: $ cat /tmp/foo.txt | git hash-object --stdin 557db03de997c86a4a028e1ebd3a1ceb225be238 where there is no =E2=80=9Ccontent content=E2=80=9D (using your own word). = Git is a serializer, NAR is another. The content that you serialize does not matter, $ echo hello > hello.txt $ cat hello.txt | git hash-object --stdin ce013625030ba8dba906f756967f9e9ca394464a $ guix hash -S git -H sha1 -f hex hello.txt ce013625030ba8dba906f756967f9e9ca394464a Or using the default format and hash function, comparing Git and Nar serializers: $ guix hash -S nar hello.txt 04zwf782yjwnh3q6hz5izfd6jyip8kgw6g6yj43fiqhbyhdd0dqw $ guix hash -S git hello.txt 1d7bp5nmgpi5j1ikglw3l7ry7dzczlhp8wl79arl75g2kqyxiy1c The content can be one file, some files, folders, etc. or Git objects as Git commit object or Git tree object or whatever. Therefore, Git commit hash only depends on the content itself, i.e., Git commit object; as explained by the pointer provided earlier in the thread, On the other hand, we could build our own Guix-DVCS using NAR+SHA-256+Nix-base32 instead of Git Git+SHA-1+Hex. ;-) Last, identifier is different from integrity checksum. Especially, if a collision is possible, then it invalidates the integrity checksum. A collision for an identifier does not matter so much security-wise, because it just implies that the lookup is not unique or that one content is unreachable. Well, collision is for sure an issue and can break the content-address system, even can lead to security troubles for extreme cases, but also for sure, it does not change the relation between Git commit hash and content. For the rest, it does not matter if we agree or not because this discussion is far to cook the rice =E2=80=93 well there is no concrete outcomes. Your last paragraph, Once again, there are tangible benefits to using a (let-bound) commit inside a , particularly if you have a strong reason to believe that an upstream might be unreliable. However, virtually all of these go down the drain if you do not do so in tandem with git- version. is an acceptable ending. :-) Therefore, from my side, I consider it as a final word. Cheers, simon