On Fri, Jan 13, 2023 at 03:42:48PM +0100, Hans Petter Selasky wrote: > > 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. > 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
