> On Feb 7, 2022, at 2:46 PM, Konstantin Ryabitsev <konstantin@xxxxxxxxxxxxxxxxxxx> wrote: > > 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.” I agree this would be really nice. If the tarball (or whatever) created could also be signed, so that it could be trusted regardless of the particular server you fetch it from, it might work as a nice packaging format. Maybe you could have a signed header with the hash of the tarball that’s produced? You wouldn’t really need a signed tag in that case. Our use for this would be to host these signed git archives (.gar files?) on mirrors — which we may or may not trust. If I can get around the hostile tarball issue I’d be super excited about the idea. -Todd
