Re: git archive setting user and group

From: brian m. carlson <sandals@crustytoothpaste.net>
Date: Jan 23, 2021, 01:05 UTC
Message-ID: <YAt2PPM4HRcKva9a@camp.crustytoothpaste.net>
In-Reply-To: <20210122213954.7dlnnpngjoay3oia@chatter.i7.local>

On 2021-01-22 at 21:39:54, Konstantin Ryabitsev wrote:

Show 15 quoted lines

> On Fri, Jan 22, 2021 at 10:00:04PM +0100, René Scharfe wrote:
> > Adding support for using a custom user and group should be easy.  Is
> > this just a cosmetic thing?  Regular users would ignore the user info in
> > the archive, and root should not be used for extracting, and on systems
> > that don't have a logwatch user this wouldn't make a difference anyway,
> > right?
> 
> 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.

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.

> I would argue that adding user/group support to "git archive" operation is
> not really solving any problems other than "it's different from when I run it
> as a regular user" -- and can introduce potential compatibility problems if
> implemented.

I agree that this feature isn't really something we want. Git produces tar archives for software interchange, in which case producing an intentionally anonymous tarball is the desired behavior.

-- 
brian m. carlson (he/him or they/them)
Houston, Texas, US