Hi, On Wed, 2024-06-19 at 09:47 +0100, Simon McVittie wrote: > On Wed, 19 Jun 2024 at 07:54:45 +0200, Ansgar 🙀 wrote: > > Just include a hash > > similar to [1] in the signed tag data > > Prior art: this is conceptually the same as git-evtag from > src:git-evtag. You can see real-world use of git-evtag in the upstream > tags (e.g. v0.9.0) of src:bubblewrap.
That requires the Git objects to be available? These are no longer available once tag2upload processed the repository. So I think the Golang example is a better real-world use of something like this. > > it might need minor changes if > > one cares about file permissions[2]. > > If this is something that will be used as a security mechanism, then > I think it probably needs to represent symbolic links as well. I think > git-evtag does (it checksums all git "blobs" and I believe that includes > symlinks), but it seems sumdb/dirhash behaves as though symlinks didn't > exist. The `find . -printf ...` part can include that. There is %y for the file type and %l for the target of symbolic links. (This is the reason I suggested that modification.) > git specifically *doesn't* care about file permissions, beyond a 1-bit > representation of whether it's executable or not, so anything like > tag2upload that is based on git-as-source will have to cope with mtimes > and detailed permissions possibly differing between what was obtained > from git and what's in the .dsc. When people have talked about code being > "treesame" elsewhere in this thread, I believe they mean "all facts that > git tracks in its tree are the same, facts that git does not track might > not be". As I said: just don't include what we don't care about in the hash. We might not want to care about timestamps or permissions beyond executable or not. That's fine. (AFAIU Golang doesn't care about file permissions at all, so it's fine for them to not include those at all.) Ansgar
