Re: Gitorious should use CRC128 / 256 / 512 instead of SHA-1

From: Konstantin Ryabitsev <konstantin@linuxfoundation.org>
Date: Jan 13, 2023, 15:45 UTC
Message-ID: <20230113154516.jxm2cer4sogatayp@meerkat.local>
In-Reply-To: <8a8fbe42-7809-f3e7-b233-6bef790254e1@selasky.org>

On Fri, Jan 13, 2023 at 03:42:48PM +0100, Hans Petter Selasky wrote:

Show 12 quoted lines

> > I do not understand the goal of this request. If it is possible to forge
> > hashes, then nothing in a git repository can ever be trusted. Signed
> > content will no longer be verifiable. The whole Merkel Tree representing
> > the commit history becomes easily corruptible by hackers and no upstream
> > remote repository can ever be trusted - or someone's own if someone
> > targets a repo with malware that rewrites hashes. Imagine a scenario when
> > malware replaces a blob in a repo and then forges the hash to pretend that
> > the replacement never occurred. Using git as a supply chain audit trail
> > becomes impossible. This is a potential vector for ransomware invading the
> > git ecosystem. This seems like a really fatal path to take for the
> > product.
>

> If a hacker replaces a blob, everyone on the project will see it, because
> such changes typically generate a commit e-mail.

I don't think you have a very clear picture of how git works.

Show 5 quoted lines

> And then an action will be made to revoke the access of that hacker. Now a
> clever hacker wouldn't do that. A clever hacker would just flip one bit
> somewhere in a random blob, looking like a hardware fault, and then force
> the project to rewind to backups every day, because the repository can no
> longer be verified.

That's not how it works at all. If there is a corrupted object, the admins of the repository just put the correct object into place either from a backup or from another copy of the repository. There is no rewinding required.

> There is no advantage from protecting from hardware errors, unless you can
> recover from them! Cryptographic hash algorithms are not suitable to recover
> bits. They only tell data is OK or NOK, and if there is no backup, you loose
> it!

This is true about all digital media.

> It is no solution for big repositories to rewind to backups just because
> of bit-flips. Such problems should be fixed w/o the need to roll-back,
> because that stops the entire production!

No it doesn't.

> > it can be repaired by a push --force
> 
> Hobby projects can do that, but not big projects like FreeBSD and the Linux
> kernel.

Sure they can, but not due to missing objects (a corrupted object is just a missing object). If, for some reason, Linus ever needs to remove something from linux.git, he will do it and just give a heads-up why and for what reason.

I think you're misunderstanding some of the core principles of git.

-K