Re: How safe are signed git tags? Only as safe as SHA-1 or somehow safer?

> Dear git developers!
> 
> Jeff King wrote:
>> On Sun, Nov 16, 2014 at 03:31:10PM +0000, Patrick Schleizer wrote:
>>
>>> 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?
>>
>> Yes, it is only as "safe as SHA-1" in the sense that you have GPG-signed
>> only a SHA-1 hash. If somebody can find a collision with a hash you have
>> signed, they can substitute the colliding data for the data you signed.
>>
>> Of course, "safe as SHA-1" and "find a collision" are vague. If
>> pre-image attacks are feasible (i.e., given already-published SHA-1, I
>> can find a different input with the same SHA-1), then attacks are
>> trivial. But when people talk about attacks on SHA-1, they are usually
>> referring to finding a collision between two new pieces of data. You can
>> also use that in an attack, but it's much less straightforward
>> (basically, you need to get somebody to sign one of the colliding pieces
>> of data and then replace it with the other).
> 
> Sounds pretty sad. Isn't this a security issue that should be fixed?
> 
> Rather than discussing how feasible collisions in SHA-1 are... Attacks
> on SHA-1 are only getting worse, no? Since the Snowden revelations we
> know that powerful adversaries that are working on such things and would
> use such weaknesses to exploit users.
> 
> Dear git developers, could you please make a long story short? Change to
> some stronger hash algorithm? (sha256, sha512, or so?) Or provide an
> option for that?
> 
>> And of course there is the question of getting the colliding data to the
>> victim. Git does collision checks whenever a remote (e.g., from a "git
>> fetch") gives us data that we already have. So you could poison new
>> cloners with bad data, but you could not convince a repository with the
>> existing "good" half of the collision to fetch the "evil" half.
> 
> Poison git cloners with bad data is exactly my point here. Because
> sometimes I am a cloner of my own code - cloning it on a separate
> machine - then verify it using gpg - but don't check it any further. In
> such cases, I'd prefer if security wouldn't depend on SHA-1.
> 
> Cheers,
> Patrick
> 
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>