On Sat, Jan 23, 2021 at 01:05:00AM +0000, brian m. carlson wrote: > > Right now, "git archive" operations are bit-for-bit identical across all > > versions going back at least 8+ years. In fact, we've been relying on this to > > support bundling tarball signatures with git tags themselves (via git notes). > > E.g. you can see this in action here: > > https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tag/?h=v5.10.9 > > > > If you click on "(sig)", you will download a signature that can be used to > > verify the tarball generated using "git archive". > > Please do not rely on this behavior. I want to state in the strongest > possible terms that this is not guaranteed behavior and it may change at > any time. We have explicitly said so on the list multiple times. If > you need reproducible archives, you need to add a tool to canonicalize > them in a suitable format and not rely on Git to never change things. It doesn't need to be perpetually the same. This is the reason the comments mention git version -- "to generate an archive that matches this signature, run this command (with this git version)." I know there is no guarantee that this won't ever change across versions, but I don't see why we can't expect git-archive to return the same bit-for-bit output when using the same version of git. Adding --owner and --group would potentially change that, especially if that's something settable via git-config. > If you are relying on this behavior right now, I urge you to change that > at your earliest possible convenience. I don't want to break > kernel.org's infrastructure again, but I'm also not going to tiptoe > around sending patches in fear of that, nor feel bad if it happens again > for this reason. It won't break, it will just inconvenience folks who are using this perk -- Greg KH will just have to use the same git version that we have on the server when he generates the signatures. This has happened before. -K
