Since first switching from centralized VCS systems to a decentralized one—specifically git—I have properly understood that that git's commit ID's were hashes of the included objects and some meta data that served to disambiguate the commit from invalid data or any other commits by you or others. So far so good.
There is a much excerpted quote going around that Wikipedia attributes to Linus Torvalds about the design of git: (emphasis mine)
You can have people who try to be malicious. They won't succeed. [...] Nobody has been able to break SHA-1, but the point is the SHA-1, as far as Git is concerned, isn't even a security feature. It's purely a consistency check. The security parts are elsewhere, so a lot of people assume that since Git uses SHA-1 and SHA-1 is used for cryptographically secure stuff, they think that, OK, it's a huge security feature. It has nothing at all to do with security, it's just the best hash you can get.
I've seen this and other documentation and assumed I understood what this referenced. Of course if you really wanted security you could sign your commits using GPG. This would render a theoretical hash collision attack useless. Apparently I was wrong. I commented on a Github issue to this affect.
Of course SHA-1 has its weaknesses. But it's not supposed to do anything for which those weaknesses matter. Basically all the hash function does is provide a way to disambiguate commits in a history. If you really want to ensure code integrity the GPG signing functions are there for you.
I was corrected (apparently legitimately) to point out that the actual data itself never gets signed:
So, what does gpg actually sign? It signs the commit object, not the blob [...]. And since commit object, tree object and blob object are all connected via SHA-1, the only guarantee you have about the actual content of the repository being not tampered with is not the gpg signature but the SHA-1 hash.
However, in spite of seeming to be right in that detail, I feel like the rest of that rebuttal has a bit too much tin-foil-hat involved. The issues was later discussed on Reddit but to no real conclusion.
I would like to understand what the actual threat model is and how realistic an attack on this vector is. How bad a design flaw is signing the hash from a security standpoint? Realistically what would have to happen to attack this system as opposed to one that worked per my initial assumption that the entire glob was signed somehow? How feasible is such an attack? When Torvalds mentioned that "The security parts are elsewhere.", what parts might he have been referring to? Is there some other proper way to mitigate repositories against tampering other than signed commits?
Aucun commentaire:
Enregistrer un commentaire