[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: On raw strings in <origin> commit field
From: |
zimoun |
Subject: |
Re: On raw strings in <origin> commit field |
Date: |
Mon, 03 Jan 2022 20:07:44 +0100 |
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
- Re: On raw strings in <origin> commit field, (continued)
- Re: On raw strings in <origin> commit field, Liliana Marie Prikler, 2022/01/04
- Re: On raw strings in <origin> commit field, Mark H Weaver, 2022/01/04
- Re: On raw strings in <origin> commit field, Mark H Weaver, 2022/01/05
- Re: On raw strings in <origin> commit field, Liliana Marie Prikler, 2022/01/05
- Re: On raw strings in <origin> commit field, Mark H Weaver, 2022/01/06
- Re: On raw strings in <origin> commit field, Liliana Marie Prikler, 2022/01/06
- Re: On raw strings in <origin> commit field, zimoun, 2022/01/02
- Re: On raw strings in <origin> commit field, Liliana Marie Prikler, 2022/01/02
- Re: On raw strings in <origin> commit field, zimoun, 2022/01/03
- Re: On raw strings in <origin> commit field, Liliana Marie Prikler, 2022/01/03
- Re: On raw strings in <origin> commit field,
zimoun <=
- Re: On raw strings in <origin> commit field, Liliana Marie Prikler, 2022/01/03
- Re: On raw strings in <origin> commit field, zimoun, 2022/01/03
- Re: On raw strings in <origin> commit field, Liliana Marie Prikler, 2022/01/04
- Re: On raw strings in <origin> commit field, zimoun, 2022/01/04
- Re: On raw strings in <origin> commit field, zimoun, 2022/01/04
- Re: On raw strings in <origin> commit field, Liliana Marie Prikler, 2022/01/04
- Re: On raw strings in <origin> commit field, zimoun, 2022/01/04
Re: On raw strings in <origin> commit field, Liliana Marie Prikler, 2022/01/01