unofficial mirror of guix-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: zimoun <zimon.toutoune@gmail.com>
To: Liliana Marie Prikler <liliana.prikler@gmail.com>,
	Mark H Weaver <mhw@netris.org>,
	guix-devel@gnu.org
Subject: Re: On raw strings in <origin> commit field
Date: Mon, 03 Jan 2022 20:07:44 +0100	[thread overview]
Message-ID: <86tuektz7j.fsf@gmail.com> (raw)
In-Reply-To: <8fc6f95442ff8c5f0d5a317a84b7bdd180543cae.camel@gmail.com>

Hi Liliana,

On Mon, 03 Jan 2022 at 19:13, Liliana Marie Prikler <liliana.prikler@gmail.com> wrote:
> Am Montag, dem 03.01.2022 um 10:22 +0100 schrieb zimoun:
>> On Sun, 02 Jan 2022 at 22:35, Liliana Marie Prikler
>> <liliana.prikler@gmail.com> wrote:
>> 
>> > > 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.
>> 
>> I do not understand what it means – not to say I think your comment
>> does not make sense at all.  Well, I already took the time to explain
>> twice how it works.
>> 
>> <https://yhetil.org/guix/86y243kdoo.fsf@gmail.com>
>> <https://yhetil.org/guix/867dbmi7pf.fsf@gmail.com>
> Nothing agains Yhetil, but that page did break for me yesterday with a
> 502.  If you have anything important to say, (partially) quoting
> yourself would be much preferred while still adding said link for
> curious outsiders, because then I can use an intrinsic lookup mechanism
> using only my own mailbox rather than an extrinsic one.

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. :-)


> 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.


> I'm not trying to stoke fear, I'm arguing that "raw string in <git-
> 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 <git-reference>”.  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.


Cheers,
simon


  reply	other threads:[~2022-01-03 19:30 UTC|newest]

Thread overview: 63+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-12-28 20:55 On raw strings in <origin> commit field Liliana Marie Prikler
2021-12-29  8:39 ` zimoun
2021-12-29 20:25   ` Liliana Marie Prikler
2021-12-30 12:43     ` zimoun
2021-12-31  0:02       ` Liliana Marie Prikler
2021-12-31  1:23         ` zimoun
2021-12-31  3:27           ` Liliana Marie Prikler
2021-12-31  9:31             ` Ricardo Wurmus
2021-12-31 11:07               ` Liliana Marie Prikler
2021-12-31 12:31                 ` Ricardo Wurmus
2021-12-31 13:18                   ` Liliana Marie Prikler
2021-12-31 13:15               ` zimoun
2021-12-31 15:19                 ` Liliana Marie Prikler
2021-12-31 17:21                   ` zimoun
2021-12-31 20:52                     ` Liliana Marie Prikler
2021-12-31 23:36         ` Mark H Weaver
2022-01-01  1:33           ` Liliana Marie Prikler
2022-01-01  5:00             ` Mark H Weaver
2022-01-01 10:33               ` Liliana Marie Prikler
2022-01-01 20:37                 ` Mark H Weaver
2022-01-01 22:55                   ` Liliana Marie Prikler
2022-01-02 22:57                     ` Mark H Weaver
2022-01-03 21:25                       ` Liliana Marie Prikler
2022-01-03 23:14                         ` Mark H Weaver
2022-01-04 19:55                           ` Liliana Marie Prikler
2022-01-04 23:42                             ` Mark H Weaver
2022-01-05  9:28                               ` Mark H Weaver
2022-01-05 20:43                                 ` Liliana Marie Prikler
2022-01-06 10:38                                   ` Mark H Weaver
2022-01-06 11:25                                     ` Liliana Marie Prikler
2022-01-02 19:30                   ` zimoun
2022-01-02 21:35                     ` Liliana Marie Prikler
2022-01-03  9:22                       ` zimoun
2022-01-03 18:13                         ` Liliana Marie Prikler
2022-01-03 19:07                           ` zimoun [this message]
2022-01-03 20:19                             ` Liliana Marie Prikler
2022-01-03 23:00                               ` zimoun
2022-01-04  5:23                                 ` Liliana Marie Prikler
2022-01-04  8:51                                   ` zimoun
2022-01-04 13:15                                     ` zimoun
2022-01-04 19:45                                       ` Liliana Marie Prikler
2022-01-04 19:53                                         ` zimoun
2021-12-31 23:56         ` Mark H Weaver
2022-01-01  0:15           ` Liliana Marie Prikler
2021-12-30  1:13 ` Mark H Weaver
2021-12-30 12:56   ` zimoun
2021-12-31  3:15   ` Liliana Marie Prikler
2021-12-31  7:57     ` Taylan Kammer
2021-12-31 10:55       ` Liliana Marie Prikler
2022-01-01  1:41     ` Mark H Weaver
2022-01-01 11:12       ` Liliana Marie Prikler
2022-01-01 17:45         ` Timothy Sample
2022-01-01 19:52           ` Liliana Marie Prikler
2022-01-02 23:00             ` Timothy Sample
2022-01-03 15:46           ` Ludovic Courtès
2022-01-01 20:19         ` Mark H Weaver
2022-01-01 23:20           ` Liliana Marie Prikler
2022-01-02 12:25             ` Mark H Weaver
2022-01-02 14:09               ` Liliana Marie Prikler
2022-01-02  2:07         ` Bengt Richter
2021-12-31 17:56 ` Vagrant Cascadian
2022-01-03 15:51   ` Ludovic Courtès
2022-01-03 16:29     ` Vagrant Cascadian

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://guix.gnu.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=86tuektz7j.fsf@gmail.com \
    --to=zimon.toutoune@gmail.com \
    --cc=guix-devel@gnu.org \
    --cc=liliana.prikler@gmail.com \
    --cc=mhw@netris.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/guix.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).