Re: Commit SHA1 == SHA1 checksum?

[Konstantin Ryabitsev <konstantin@linuxfoundation.org>]

On Mon, Feb 07, 2022 at 10:29:37PM +0000, Gamblin, Todd wrote:
> > 2. packagers would be able to perform cryptographic verification without
> >   needing to track any extra sources like corresponding .sig files; they
> >   would just need to add a build-time dependency on git (plus whatever it
> >   calls for cryptographic verification, such as gnupg or openssh)
> 
> This is a cool idea, but tar/gzip/etc. are vulnerable to input attacks (or
> at least there have been CVEs in the past), so this does not eliminate the
> need to verify a downloaded .tar or .tar.gz file independently.  You can
> verify the contents of the tar, but to do that you have to expand it, and to
> do that you’re still passing untrusted input to tar.

That's not really different from what git does when it clones a remote
repository to run "git verify-tag". It still accepts untrusted input from the
remote server, performs a lot of compression/decompression operations, etc, so
this is not introducing anything that git isn't already required to do.

I know there's a lot to be said about the simplicity of just computing a
signature over file bytes, but there are features you end up sacrificing, such
as ability to provide a single signature for multiple compression types,
adding a better compression algorithm in the future, or simply recompressing
with better flags in a long background process.

My goal is to improve the current situation where we're actually doing pretty
good for signed in-git objects, but none of that is carried over to packaging
systems. The only effort I know in that area is sigstore, but it requires
quite a bit of work to properly use on the part of the project maintainer,
whereas it would be great to be able to say "just do git tag -s and the
packaging systems will be able to use that."

-K