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
