Hi Liliana, On Mon, 03 Jan 2022 at 19:13, Liliana Marie Prikler <liliana.prik...@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.prik...@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....@gmail.com> >> <https://yhetil.org/guix/867dbmi7pf....@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....@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
