From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp12.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 +HRpJJpa02Hi/wAAgWs5BA (envelope-from ) for ; Mon, 03 Jan 2022 21:20:42 +0100 Received: from aspmx1.migadu.com ([2001:41d0:2:bcc0::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp12.migadu.com with LMTPS id OMT2IJpa02GRCAEAauVa8A (envelope-from ) for ; Mon, 03 Jan 2022 21:20: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 22B4843C65 for ; Mon, 3 Jan 2022 21:20:42 +0100 (CET) Received: from localhost ([::1]:50940 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1n4Tov-0000ty-8u for larch@yhetil.org; Mon, 03 Jan 2022 15:20:41 -0500 Received: from eggs.gnu.org ([209.51.188.92]:37462) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1n4Tno-0000H4-G5 for guix-devel@gnu.org; Mon, 03 Jan 2022 15:19:32 -0500 Received: from [2a00:1450:4864:20::444] (port=38706 helo=mail-wr1-x444.google.com) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1n4Tnm-0004ia-Sz for guix-devel@gnu.org; Mon, 03 Jan 2022 15:19:32 -0500 Received: by mail-wr1-x444.google.com with SMTP id e5so71910082wrc.5 for ; Mon, 03 Jan 2022 12:19:30 -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=CU44JRHdfwE785kZiwyQlyCLY1OIGNWJMxEgPtLiK2s=; b=YGrHlZHRUApKW3CiU9b4pz7JfqGTisqf3pJtcEJ9m6gH/dwtjRU7uK3L5dFBcwYMxm xzVKCybZa7UEmh7S7sJ8XeAjh7eRhPQunujoWh90+ity5veyy5fzLjXkdbvUShjQKeUJ CAinOCpKw1FOh7ky+Vx8AWQjLI8VkWAVrLfZnJ0OI3XX4pEmMSeuhkGU9xaQsF8YZnoi GRJK2Y8hEjpeU4rUznSm6/u5a5AANd9sRddYYcERIE9Ceh5jE/ZZKjgXF7xLAtBWdFLu JhdH/S4bllum0E0z0sZSMFh1yzhyW07b1ajRlaW+jQ1Xe1okPj8p3Koq/jOVWpoxgxjz qAzA== 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=CU44JRHdfwE785kZiwyQlyCLY1OIGNWJMxEgPtLiK2s=; b=NUPFLD6/f6LlB2MbivvcbZE8WKpR6Ujj/jY0hR1GfM2pyd+ytWqO6NHZrbw7pG3hBv vbXDN0X1ZQJ06OtMVgL6M0jcb3D96fSQ2EmDMMrc/LRGZLj1M9Bh6P2jsrtVpjrX3m1W xViUR/sm5QV9C/G6tkkYYh2xJor08KebasxKF6cN7K1AfeEzyYIPUyWVycXVf2ZhtpN9 9HJneGA0z71bSyINdzAMssar2KVayckPNplSOnZ7rLfXadHcQzP86oDKu8UZztOxs403 g+KZS+fVJXex7ylJdZbjf1lCD5Wc4MEFy9GwhvGvjVFye7geuIptlk5F2oLDfgbwgBDX li9g== X-Gm-Message-State: AOAM5309NNKtwhHd12kmWS4ce/OZPqQ2VRsKRfF35ayCxqXMd8kTZCKZ oPqbmOLP50399cMKTE/evIM= X-Google-Smtp-Source: ABdhPJxzXt4vQTVrnNktfKXkDzcFxunIB0nOUHd6hbmHQmxXepcN1IPQpXIexYc5z0mmFd3a30GoAw== X-Received: by 2002:adf:f741:: with SMTP id z1mr40415183wrp.54.1641241169359; Mon, 03 Jan 2022 12:19:29 -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 i12sm36173693wrp.96.2022.01.03.12.19.28 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 03 Jan 2022 12:19:28 -0800 (PST) Message-ID: <0fff4aa2b320a82905c4b6bd43f7cd3d6e7493c6.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: Mon, 03 Jan 2022 21:19:27 +0100 In-Reply-To: <86tuektz7j.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> <86bf0d941ff6095961670a41478e603fa961e498.camel@gmail.com> <864k6lw4vh.fsf@gmail.com> <8fc6f95442ff8c5f0d5a317a84b7bdd180543cae.camel@gmail.com> <86tuektz7j.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::444 (failed) Received-SPF: pass client-ip=2a00:1450:4864:20::444; envelope-from=liliana.prikler@gmail.com; helo=mail-wr1-x444.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=1641241242; 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=CU44JRHdfwE785kZiwyQlyCLY1OIGNWJMxEgPtLiK2s=; b=pwqqDgv4y06DFtD4Y1hmg97Kfw3x2VcExP0R02sDAEKyxmsjToidilAnlf5dknSuDGLhSR HbhsKVzN+g0J64Lz862pyZEFWhjiLtBGcdYKL0G6njC+CluBHRLOlh9OwDr98Py0NMfWVS 3MLUCq/GBsJqqraiL+Le5ED0M7jILs4K0OUa6nUlVWp4KmBmr1C5qj+nErmDBoKJeU4y4V HmfvSid5GQxGGiTjdv6aM/XmYauHAQ2oKm3BFcYlIOUavF0TlKCuP4fT3hVEeHJx+z/MWs h3gJEjKmDXKD+lQWz5mxTax7MRDbv02uyS7cBOM3zB/Erai1vtG4ZbtDzMBHdQ== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1641241242; a=rsa-sha256; cv=none; b=DUrz+2rdwBHmvNCgUXsf0GxHmCOa4wa/W+OPCYqcPasut2PPz9ch2AipCg/epVUPajyMA0 UFl1RC3JnwkGBltl2m4asA1TfIu/i/KtE/PHgpooBUUyDESyc7tP8KznVkwOonXHO3EBj8 nllO7bI6grVRH5An1aTw3FE1wGMrgnehKzgbj3W7ANZgvSZYm4OpDPzBEA3DRDIqJY2r1b 9LssXyZijx5U/8u2a6lLadXDUfgYfCA9KQ6e3VOxfLQVrhxQCj8y6I5OowL1R6wPrjt1t7 Y2xoL7U6wC24ZeGCiDXm1M2NPqotdnf5gsXCRFbAEq/MpxPVhzZ7TUY1dq7fhg== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=YGrHlZHR; 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.29 Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=YGrHlZHR; 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: 22B4843C65 X-Spam-Score: -4.29 X-Migadu-Scanner: scn1.migadu.com X-TUID: kF8MnW58PNmG Am Montag, dem 03.01.2022 um 20:07 +0100 schrieb zimoun: > This is somehow intrinsic* because public-inbox uses Message-ID as URL. > Therefore, using emacs-notmuch, you just have to search for > id:86y243kdoo.fsf@gmail.com for instance. > > *intrinsic: no it is not intrinsic but self-contained. :-) I am very happy with my mail reader not showing Message IDs for the most part, but fair enough, I'll extend that courtesy to you and make it do so. In any case, I am not sure what I'm missing from those messages here. We both agree, that Guix and Git use different (S, H, F) with S being the serializer, H a cryptographic hash function and F a formatter, for their fundamental operations. And that while Guix can produce git hashes "internally" (I'm pretty sure it just calls to libgit, but it's fine if it doesn't), it does not use them for anything meaningful in its own logic. In particular, Guix content addressing scheme is based on SHA-256 NAR hashes, which ought to be robust enough for anything that relies on content addressing. > > Anyway, the point here is a rather simple one that you can base on > > your own explanations.  Due to the different ways Guix and Git > > filter, serialize and hash content, you can have two objects O and > > O', such that Git hashes O and O' differently, but Guix does not, and > > similarly two objects O and O' such that Guix hashes them > > differently, but Git does not.  Finding particular values for O and > > O' would in some cases be computationally expensive, especially if > > you want to force a hash collision in SHA-256 instead of reusing the > > same files but attaching a different commit message, but > > theoretically possible, and if theoretic possibilities is something > > you want to base your policies on, that is a thing to consider. > > Collision with hashing functions does not mean that the hash does not > *only* depend on the content.  Collision means that 2 contents provides > the same hash.  The final hashes only depends on the content, whatever > the serializer is and as weak as the hashing function is. 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. > > > I'm not trying to stoke fear, I'm arguing that "raw string in > reference> for robustness" is a bad take for a multitude of > > reasons. > > 1) No one is advocating to replace tomorrow all by “Git SHA-1 commit > hash in ”.  Instead, people exposed what are the > motivations to do so, what it would fix, and so on. > > 2) I am still failing to understand your multitude bad reasons.  Yes > for sure, introducing more intrinsic values is not straightforward, > socially and about toolings, but I have not read multitude > fundamentally bad reasons.  Anyway. I think you're missing an important section of the exchange between messages 867dbmi7pf.fsf@gmail.com and 3d448fe42f0c43574db96fa26aecd7da5fd5a95d.camel@gmail.com concerning alternative styles, which you've since ignored. My issues with the proposed style are: 1. It is inconsistent, choosing both to trust and not trust a tag simultaneously. 2. It does not communicate anything about that choice to the reader. 3. It enables a particular class of "Tricking Peer Review" style problems. 4a. The issue it tries to address is mostly a social one. 4b. Even if content addressing solves it, SHA-1 is a poor hash and likely to introduce a similar robustness problem anyway. 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. Cheers