Re: git & Debian packaging sprint report
Russ Allbery writes:
> Ansgar Burchardt writes:
>> Russ Allbery writes:
>>> If so, I think that security model is roughly equivalent to the
>>> automatic signing of binary packages by buildds, so probably doesn't
>>> introduce a new vulnerability,
>
>> It doesn't rely on strong cryptographic hashes to guarantee integrity.
>> To quote Wikipedia:
>
>> +---
>> | Revision control systems such as Git, Mercurial, and Monotone use
>> | SHA-1 not for security but to identify revisions and to ensure that
>> | the data has not changed due to accidental corruption.
>> +---[ https://en.wikipedia.org/wiki/SHA-1#Data_integrity ]
>
>> But developers could instead just sign artifacts using a strong
>> cryptographic hash that will be included in the source package; for
>> example the .orig.tar and .debian.tar which can be made reproducible
>> (git-archive is supposed to be reproducible; compression might not be so
>> just sign the uncompressed version).
>
>> We shouldn't go back to trusting SHA-1.
>
> I'm dubious that we really care that much about a preimage attack on
> SHA-1, but sure, if there's some easy way to use something different, that
> would be more future-proof.
SHA-1 isn't going to get stronger in the future. The TLS world has
already moved on, OpenPGP is still in the slow process to move on,
Release/Packages stopped using it[1], there is no reason to continue
using it.
There is another advantage to developers signing the artifacts: one
would need much less trust in the service building the source files as
it could only manipulate the .dsc, .changes and compression used.
It also has one downside: `git tag` alone won't be enough to generate
the required information, but then a special-purpose tool was proposed
here already.
The client tool could possibly also just create the .dsc and .changes,
except for hashes of the compressed files, and the web service just
recreate the tarball and compress them. That would require near zero
trust in the web service, but still allow developers to no longer upload
source packages which might be large. (A bit similar to not having to
trust buildds by making packages reproducible.)
Ansgar
[1] Though we still have MD5sum for some suites for jigdo...
Reply to: