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

[Patrick Schleizer]

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