Am 11.02.22 um 22:27 schrieb Junio C Hamano: > René Scharfe <l.s.r@xxxxxx> writes: > >>> Or if people do not _exclude_ tracked files from the archive, then >>> the verifier who has a tarball and a Git tree object can consult the >>> tree object to see which ones are added untracked cruft. >> >> True, but if you have the tree objects then you probably also have the >> blobs and don't need the archive? Or is this some kind of sparse >> checkout scenario? > > My phrasing was too loose. This is a "how to verify a distro > tarball" (without having a copy of the project repository, but with > some common tools like "git") scenario. > > The verifier has a tarball. In addition, the verifier knows the > object name of the Git tree object the tarball was taken from, and > somehow trusts that the object name is genuine. We can do either > "untar + git-add . && git write-tree" or its equivalent to see how > the contents hashes to the expected tree (or not). > > How the verifier trusts the object name is out of scope (it may come > from a copy of a signed tag object and a copy of the commit object > that the tag points at and the contents of signed tag object, with > its known format, would allow you to write a stand alone tool to > verify the PGP signature). Right, but the tree hash does not directly allow to see which objects are tracked or not. This information is necessary to reconstruct the signed tree. (Having tracked files first, then the signature file and then untracked files in the archive would be an easy way to transmit it.) > Line-end normalization and smudge filter rules may get in the way, > if we truly did "untar" to the filesystem, but I thought "git > archive" didn't do smudge conversion and core.crlf handling when > creating the archive? git archive uses convert_to_working_tree() to archive the same file contents as tar or zip would. René
