[Whonix-devel] [qubes-devel] How safe are signed git tags? Only as safe as SHA-1 or somehow safer?

[Alex Dubois]

Sent from my iPhone

> On 3 Nov 2014, at 09:08, Patrick Schleizer <patrick-mailinglists at whonix.org> wrote:
> 
> Hi!
> 
> How safe are signed git tags? Especially because git uses SHA-1. There
> is contradictory information around.
> 
> So if one verifies a git tag (`git tag -v tagname`), then `checksout`s
> the tag, and checks that `git status` reports no untracked/modified
> files, without further manually auditing the code, how secure is this
> actually? Is it only as safe as SHA-1?
> 
> Let's assume an adversary, that is capable of producing SHA-1 collisions.
> 
> Linus Torvalds said: [1]
> 
>> Git uses SHA-1 not for security
> 
> And goes on.
> 
>> The security parts are elsewhere
> 
> Could you please elaborate on this? Where are the security parts? Can
> you please briefly explain how these work? Where can I read more about this?
> 
> Wikipedia says. [2]
> 
>> Nonetheless, without second preimage resistance [3] of SHA-1 signed
> commits and tags would no longer secure the state of the repository as
> they only sign the root of a Merkle tree [4].
> 
> Which contradicts what Linus Torvalds said. What does that mean for
> security? Which statement is true?
> 
>> "The source control management system Git uses SHA-1 not for security
> but for ensuring that the data has not changed due to accidental
> corruption. Linus Torvalds has said, "If you have disk corruption, if
> you have DRAM corruption, if you have any kind of problems at all, Git
> will notice them. It's not a question of if, it's a guarantee. 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
> guarantee you, if you put your data in Git, you can trust the fact that
> five years later, after it was converted from your hard disk to DVD to
> whatever new technology and you copied it along, five years later you
> can verify that the data you get back out is the exact same data you put
> in. [...] One of the reasons I care is for the kernel, we had a break in
> on one of the BitKeeper sites where people tried to corrupt the kernel
> source code repositories." [6]
> 
> If (!) I understand Mike Gerwitz ([...] GNU [...]) 's opinion, his
> opinion is, that for best security each and every commit should be
> signed for best possible git verification security.

It also help for accountability (who committed what) particularly for small projects where real identity is verified. 

> 
> See also:
> 
> - Mike Gerwitz's "A Git Horror Story: Repository Integrity With Signed
> Commits" [7]
> 
> - Verbose reply by Mike Gerwitz to my question. [8]
> 
> - Similar question on security stackexchange. [9] Quote: "Nevertheless,
> If somebody managed to find a way how to find SHA1 collisions easily,
> then git would have much bigger problem."
> 
> Cheers,
> Patrick
> 
> [1] https://www.youtube.com/watch?v=4XpnKHJAok8&t=56m20s
> [2] https://en.wikipedia.org/wiki/SHA-1#Data_integrity
> [3] https://en.wikipedia.org/wiki/Second_preimage_resistance
> [4] https://en.wikipedia.org/wiki/Merkle_tree
> [5] https://www.youtube.com/watch?v=4XpnKHJAok8&t=56m20s
> [6] https://en.wikipedia.org/wiki/SHA-1#Data_integrity
> [7] http://mikegerwitz.com/papers/git-horror-story
> [8] https://www.whonix.org/forum/index.php/topic,538.msg4278.html#msg4278
> [9]
> https://security.stackexchange.com/questions/67920/how-safe-are-signed-git-tags-only-as-safe-as-sha-1-or-somehow-safer
> 
> -- 
> You received this message because you are subscribed to the Google Groups "qubes-devel" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to qubes-devel+unsubscribe at googlegroups.com.
> To post to this group, send email to qubes-devel at googlegroups.com.
> Visit this group at http://groups.google.com/group/qubes-devel.
> For more options, visit https://groups.google.com/d/optout.