Re: On raw strings in <origin> commit field

[zimoun <zimon.toutoune@gmail.com>]

Hi Liliana,

On Mon, 03 Jan 2022 at 21:19, Liliana Marie Prikler <liliana.prikler@gmail.com> 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 «Git commit hashes do not just depend on the
        content» is wrong.  Specifically, it is by adding more
        well-chosen content that the hash is tricked.  Now, Liliana, you
        can define “content“ 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.

        <https://yhetil.org/guix/86bl0url52.fsf@gmail.com>

Sorry, I used meta-content instead of “content content”. :-) 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].

        <https://yhetil.org/guix/3d448fe42f0c43574db96fa26aecd7da5fd5a95d.camel@gmail.com>

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

        <https://yhetil.org/guix/86y243kdoo.fsf@gmail.com>

where there is no “content content” (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,

    <https://git-scm.com/book/en/v2/Git-Internals-Git-Objects>

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 – well there is no concrete
outcomes.  Your last paragraph,

        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.

is an acceptable ending. :-) Therefore, from my side, I consider it as a
final word.

Cheers,
simon