> 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.
It would be really interesting if it were possible to create an incrementally verifiable file format for this — commit messages have sizes embedded so it seems possible to string a bunch of commits/trees/blobs together in a file and to make that work. I’m just not sure if the format could be compressed and also trusted. I don’t know enough details of git’s own storage to say whether, e.g., pack files could help.
-Todd
> On Feb 7, 2022, at 1:34 PM, Konstantin Ryabitsev <konstantin@xxxxxxxxxxxxxxxxxxx> wrote:
>
> On Mon, Feb 07, 2022 at 12:57:55PM -0800, Junio C Hamano wrote:
>> You are solving a different problem: "I have this tar archive; what
>> git tree object would I get if I extract this archive to an empty
>> directory and said 'git add . && git write-tree'?".
>>
>> I agree that one is computable.
>
> So, I was brainstorming about this today, and I'm curious if you think this
> would be a useful feature to have, maybe even natively?
>
> E.g. here's a scenario:
>
> "git archive -S <signed-object>" creates an additional file that is added to
> the generated tar/zip archive -- for example, a ${prefix}.GIT_ARCHIVE_SIG. That
> file contains the raw contents of the signed tag and/or the signed commit.
>
> "git verify-archive" would look for a toplevel .GIT_ARCHIVE_SIG file. If it's
> present, it would verify the signature on these "detached" signed objects to
> get a trusted tree hash. Then it would compute the tree hash of the tar
> archive (minus the .GIT_ARCHIVE_SIG file) to see if it matches.
>
> In my mind, that would provide the following benefits over the current
> practice of detached .sig files:
>
> 1. environments like github/git.kernel.org would be able to create verifiable
> snapshot archives using an existing set of signed objects
> 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)
> 3. this would automatically support all git-native signature mechanisms like
> openssh and whatever else gets added in the future
>
> Does this idea have any merit, or is it too fragile/crazy to bother?
>
>> Of course, even that reverse problem will break once we consider the
>> release tarball generation procedure where we _add_ some generated
>> files that are not in the Git tree, for builder's convenience.
>
> Yes, but it's increasingly rare and many build instructions now specifically
> allow for things like "first, run autoconf if you don't already have a
> configure file", etc.
>
> -K
