Re: On raw strings in <origin> commit field

[Liliana Marie Prikler <liliana.prikler@gmail.com>]

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.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.

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/