Re: On raw strings in <origin> commit field

[Liliana Marie Prikler]

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 <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.
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 <git-reference>, 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