Am Montag, dem 03.01.2022 um 10:22 +0100 schrieb zimoun: > Hi Liliana, > > 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.
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. > Maybe you also deny the Git documentation saying «Git is a > content-addressable filesystem.» > > <https://git-scm.com/book/en/v2/Git-Internals-Git-Objects> I don't see why I ought to. At this point we're very far removed from my original claim. However, speaking about file systems, they do support a variety of operations and one of them which Git has goes by the familiar command "rm -rf /". (And even if Git didn't, Git over HTTPS certainly does particularly when only considering 'git clone', so that'd again be a moot point to argue). All file systems, content-addressable or otherwise will run out of names if the space to store them is finite while the number of files to store is not. Some allow the user to overwrite existing files even if that pool has not yet been exhausted. You might see that as a vulnerability. I don't really care. > I have the impression that you are trying to keep your statement by > stretching how it concretely works. Instead of just say: “My bad, I > was going too far with the chosen-prefix attack of SHA-1”. And > that’s fine because that’s a valid objection. (Even if I was already > aware, mentioning such issue helps for a sane collective discussion, > IMHO.) I'm not trying to sell you on Fossil, but even before SHA-mbles, SHAttered were the first to claim that Git was broken due to their attack [1]. Which doesn't necessarily mean their attack is practical against Git, for they haven't demonstrated it, but if you want to stoke fear, go ahead. (Speaking towards a general you, not you personally.) 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. No matter what scenarios you think up for other repos out there, the worst effect on Guix in the foreseeable future is that it's going to barf a hash mismatch at you if you try to `guix build -S'. Which if you want to weaken the robustness claim even more is going to happen for a dozen commits in a selection in the span of a few years. Depending on where you live, it's likelier you (again general you) got the rona within the last week than a package caught the hashies. [1] https://shattered.io/
