Re: git & Debian packaging sprint report

[Ansgar Burchardt <ansgar@debian.org>]

Russ Allbery writes:
> Scott Kitterman <debian@kitterman.com> writes:
>> Except that we have different requirements than git.  Git isn't looking
>> for security properties from SHA-1, so it's highly likely it'll meet
>> their accident avoidance requirements long after it's no longer
>> appropriate for security related assertions.
>
>> I don't think adding more SHA-1 in a security sensitive context is a
>> good plan.
>
> I talked this over briefly in the security pod at work with some other
> security engineers who know more crypto than I do to sanity-check my
> initial opinion.
>
> The consensus among all of us was that if you have an opportunity to pick
> something other than SHA-1 when designing a new protocol, you should.

We have that opportunity here, so I guess we should then? :-)

There are also other useful properties the current implementation has:
for example the archive contains the artifact that was signed.  This can
be checked at a later time unlike a Git tag on salsa.d.o that may or may
not exist in the future.  It is always possible to go back to the key
that was used to introduce an artifact without having to trust any
system.

> But
> if it's not simple to pick a different hash, SHA-1 preimage resistance is
> reasonable and the other design properties of the system should dominate
> any concern about SHA-1 preimage attacks.

What about MD5's preimage resistance?  We don't really care about
collision attacks after all.

We have most infrastructure already using SHA-2 and there are
preparations to support newer hashes as well; it is a regression to
introduce a new system bound to SHA1 for the foreseeable future (and
given Git's use of SHA1 their need to require a strong hash is far
less).

Ansgar