{"thread":{"id":"55032","subject":"RE: git archive setting user and group","startedAt":"2021-01-22T20:42:00Z","lastAt":"2021-01-23T05:17:38Z","messageCount":12,"participants":["Jason Pyeron","René Scharfe","Konstantin Ryabitsev","Junio C Hamano","Ævar Arnfjörð Bjarmason","brian m. carlson","Jeff King"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"414994","messageId":"043f01d6f0fe$d6ad7660$84086320$@pdinc.us","threadId":"55032","inReplyTo":null,"subject":"RE: git archive setting user and group","fromName":"Jason Pyeron","fromEmail":"jpyeron@pdinc.us","sentAt":"2021-01-22T20:40:36Z","receivedAt":"2021-01-22T20:42:00Z","isPatch":false,"sender":{"key":"jpyeron@pdinc.us","avatar":"https://gravatar.com/avatar/c2e53452caa53d940768a1ffc9cf76196d851b9b534b7a39cd39852a70a0508f?d=mp&s=160"},"body":"> From: Jason Pyeron <jpyeron@pdinc.us>\n> Sent: Friday, January 22, 2021 3:09 PM\n> \n> I am about to make a release for logwatch tonight. Historically the files are owned by logwatch in the\n> tgz file. When I use git archive it is owned by uid 0, is there an option to set the uid/uname,\n> gid/gname owner of the files?\n\nAnswer: not at this time, as it is hard coded in the source.\n\narchive-tar.c:\nstatic void prepare_header(struct archiver_args *args,\n                           struct ustar_header *header,\n                           unsigned int mode, unsigned long size)\n{\n        xsnprintf(header->mode, sizeof(header->mode), \"%07o\", mode & 07777);\n        xsnprintf(header->size, sizeof(header->size), \"%011\"PRIoMAX , S_ISREG(mode) ? (uintmax_t)size : (uintmax_t)0);\n        xsnprintf(header->mtime, sizeof(header->mtime), \"%011lo\", (unsigned long) args->time);\n\n        xsnprintf(header->uid, sizeof(header->uid), \"%07o\", 0);\n        xsnprintf(header->gid, sizeof(header->gid), \"%07o\", 0);\n        strlcpy(header->uname, \"root\", sizeof(header->uname));\n        strlcpy(header->gname, \"root\", sizeof(header->gname));\n\n\nmeh.\n\n"},{"id":"414996","messageId":"cef51cd3-c6b5-ed24-f695-83be3a6743b4@web.de","threadId":"55032","inReplyTo":"043f01d6f0fe$d6ad7660$84086320$@pdinc.us","subject":"Re: git archive setting user and group","fromName":"René Scharfe","fromEmail":"l.s.r@web.de","sentAt":"2021-01-22T21:00:04Z","receivedAt":"2021-01-22T21:04:51Z","isPatch":false,"sender":{"key":"l.s.r@web.de","avatar":"https://avatars.githubusercontent.com/u/26122331?v=4"},"body":"Am 22.01.21 um 21:40 schrieb Jason Pyeron:\n>> From: Jason Pyeron <jpyeron@pdinc.us>\n>> Sent: Friday, January 22, 2021 3:09 PM\n>>\n>> I am about to make a release for logwatch tonight. Historically the files are owned by logwatch in the\n>> tgz file. When I use git archive it is owned by uid 0, is there an option to set the uid/uname,\n>> gid/gname owner of the files?\n>\n> Answer: not at this time, as it is hard coded in the source.\n>\n> archive-tar.c:\n> static void prepare_header(struct archiver_args *args,\n>                            struct ustar_header *header,\n>                            unsigned int mode, unsigned long size)\n> {\n>         xsnprintf(header->mode, sizeof(header->mode), \"%07o\", mode & 07777);\n>         xsnprintf(header->size, sizeof(header->size), \"%011\"PRIoMAX , S_ISREG(mode) ? (uintmax_t)size : (uintmax_t)0);\n>         xsnprintf(header->mtime, sizeof(header->mtime), \"%011lo\", (unsigned long) args->time);\n>\n>         xsnprintf(header->uid, sizeof(header->uid), \"%07o\", 0);\n>         xsnprintf(header->gid, sizeof(header->gid), \"%07o\", 0);\n>         strlcpy(header->uname, \"root\", sizeof(header->uname));\n>         strlcpy(header->gname, \"root\", sizeof(header->gname));\n>\n>\n> meh.\n>\n\nAdding support for using a custom user and group should be easy.  Is\nthis just a cosmetic thing?  Regular users would ignore the user info in\nthe archive, and root should not be used for extracting, and on systems\nthat don't have a logwatch user this wouldn't make a difference anyway,\nright?\n\nRené\n"},{"id":"414999","messageId":"045801d6f103$664852a0$32d8f7e0$@pdinc.us","threadId":"55032","inReplyTo":"cef51cd3-c6b5-ed24-f695-83be3a6743b4@web.de","subject":"RE: git archive setting user and group","fromName":"Jason Pyeron","fromEmail":"jpyeron@pdinc.us","sentAt":"2021-01-22T21:13:15Z","receivedAt":"2021-01-22T21:15:17Z","isPatch":false,"sender":{"key":"jpyeron@pdinc.us","avatar":"https://gravatar.com/avatar/c2e53452caa53d940768a1ffc9cf76196d851b9b534b7a39cd39852a70a0508f?d=mp&s=160"},"body":"> From: René Scharfe \n> Sent: Friday, January 22, 2021 4:00 PM\n> \n> Am 22.01.21 um 21:40 schrieb Jason Pyeron:\n> >> From: Jason Pyeron\n> >> Sent: Friday, January 22, 2021 3:09 PM\n> >>\n> >> I am about to make a release for logwatch tonight. Historically the files are owned by logwatch in\n> the\n> >> tgz file. When I use git archive it is owned by uid 0, is there an option to set the uid/uname,\n> >> gid/gname owner of the files?\n> >\n> > Answer: not at this time, as it is hard coded in the source.\n> >\n> > archive-tar.c:\n> > static void prepare_header(struct archiver_args *args,\n> >                            struct ustar_header *header,\n> >                            unsigned int mode, unsigned long size)\n> > {\n> >         xsnprintf(header->mode, sizeof(header->mode), \"%07o\", mode & 07777);\n> >         xsnprintf(header->size, sizeof(header->size), \"%011\"PRIoMAX , S_ISREG(mode) ?\n> (uintmax_t)size : (uintmax_t)0);\n> >         xsnprintf(header->mtime, sizeof(header->mtime), \"%011lo\", (unsigned long) args->time);\n> >\n> >         xsnprintf(header->uid, sizeof(header->uid), \"%07o\", 0);\n> >         xsnprintf(header->gid, sizeof(header->gid), \"%07o\", 0);\n> >         strlcpy(header->uname, \"root\", sizeof(header->uname));\n> >         strlcpy(header->gname, \"root\", sizeof(header->gname));\n> >\n> >\n> > meh.\n> >\n> \n> Adding support for using a custom user and group should be easy.  Is\n> this just a cosmetic thing?  Regular users would ignore the user info in\n\nIn this case, likely a cosmetic thing. \n\n> the archive, and root should not be used for extracting, and on systems\n\nBut I can think of situations, where it would matter - and I do not agree that \"root should not be used for extraction\".\n\n> that don't have a logwatch user this wouldn't make a difference anyway,\n> right?\n\nI updated the hard coded values to match what was needed, did a make and presto all was happy.\n\nThe backend should take:\n\n--group=NAME\n--group-id=GID\n--owner=NAME\n--owner-id=UID\n\nPatch wanted?\n\n"},{"id":"415003","messageId":"20210122213954.7dlnnpngjoay3oia@chatter.i7.local","threadId":"55032","inReplyTo":"cef51cd3-c6b5-ed24-f695-83be3a6743b4@web.de","subject":"Re: git archive setting user and group","fromName":"Konstantin Ryabitsev","fromEmail":"konstantin@linuxfoundation.org","sentAt":"2021-01-22T21:39:54Z","receivedAt":"2021-01-22T21:41:03Z","isPatch":false,"sender":{"key":"konstantin@linuxfoundation.org","avatar":"https://gravatar.com/avatar/7cb8827c6de56e1bd2dea16508c6708aa43feed3bf3813bcdacecdf96ceadd79?d=mp&s=160"},"body":"On Fri, Jan 22, 2021 at 10:00:04PM +0100, René Scharfe wrote:\n> Adding support for using a custom user and group should be easy.  Is\n> this just a cosmetic thing?  Regular users would ignore the user info in\n> the archive, and root should not be used for extracting, and on systems\n> that don't have a logwatch user this wouldn't make a difference anyway,\n> right?\n\nRight now, \"git archive\" operations are bit-for-bit identical across all\nversions going back at least 8+ years. In fact, we've been relying on this to\nsupport bundling tarball signatures with git tags themselves (via git notes).\nE.g. you can see this in action here:\nhttps://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tag/?h=v5.10.9\n\nIf you click on \"(sig)\", you will download a signature that can be used to\nverify the tarball generated using \"git archive\".\n\nI would argue that adding user/group support to \"git archive\" operation is\nnot really solving any problems other than \"it's different from when I run it\nas a regular user\" -- and can introduce potential compatibility problems if\nimplemented.\n\nSo, I would selfishly vote not to implement this.\n\n-K\n"},{"id":"415008","messageId":"048e01d6f10a$4d4da730$e7e8f590$@pdinc.us","threadId":"55032","inReplyTo":"20210122213954.7dlnnpngjoay3oia@chatter.i7.local","subject":"RE: git archive setting user and group","fromName":"Jason Pyeron","fromEmail":"jpyeron@pdinc.us","sentAt":"2021-01-22T22:02:39Z","receivedAt":"2021-01-22T22:15:27Z","isPatch":false,"sender":{"key":"jpyeron@pdinc.us","avatar":"https://gravatar.com/avatar/c2e53452caa53d940768a1ffc9cf76196d851b9b534b7a39cd39852a70a0508f?d=mp&s=160"},"body":"> From: Konstantin Ryabitsev\n> Sent: Friday, January 22, 2021 4:40 PM\n> Subject: Re: git archive setting user and group\n> \n> On Fri, Jan 22, 2021 at 10:00:04PM +0100, René Scharfe wrote:\n> > Adding support for using a custom user and group should be easy.  Is\n> > this just a cosmetic thing?  Regular users would ignore the user info in\n> > the archive, and root should not be used for extracting, and on systems\n> > that don't have a logwatch user this wouldn't make a difference anyway,\n> > right?\n> \n> Right now, \"git archive\" operations are bit-for-bit identical across all\n> versions going back at least 8+ years. In fact, we've been relying on this to\n> support bundling tarball signatures with git tags themselves (via git notes).\n> E.g. you can see this in action here:\n> https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tag/?h=v5.10.9\n> \n> If you click on \"(sig)\", you will download a signature that can be used to\n> verify the tarball generated using \"git archive\".\n> \n> I would argue that adding user/group support to \"git archive\" operation is\n> not really solving any problems other than \"it's different from when I run it\n> as a regular user\" -- and can introduce potential compatibility problems if\n\nBeing pedantic here, it is different than when I run it as any user - including root.\n\nDon’t confuse tar x with tar c.\n\ntar c captures the current owner of the files, or allows override with a single user / map file.\n\n> implemented.\n> \n> So, I would selfishly vote not to implement this.\n> \n> -K\n\n"},{"id":"415013","messageId":"xmqqsg6s61x2.fsf@gitster.c.googlers.com","threadId":"55032","inReplyTo":"cef51cd3-c6b5-ed24-f695-83be3a6743b4@web.de","subject":"Re: git archive setting user and group","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2021-01-22T22:29:29Z","receivedAt":"2021-01-22T22:30:59Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"René Scharfe <l.s.r@web.de> writes:\n\n> Am 22.01.21 um 21:40 schrieb Jason Pyeron:\n> ...\n>>         xsnprintf(header->uid, sizeof(header->uid), \"%07o\", 0);\n>>         xsnprintf(header->gid, sizeof(header->gid), \"%07o\", 0);\n>>         strlcpy(header->uname, \"root\", sizeof(header->uname));\n>>         strlcpy(header->gname, \"root\", sizeof(header->gname));\n>\n> Adding support for using a custom user and group should be easy.  Is\n> this just a cosmetic thing?  Regular users would ignore the user info in\n> the archive, and root should not be used for extracting, and on systems\n> that don't have a logwatch user this wouldn't make a difference anyway,\n> right?\n\nI am not particularly interested in cosmetics, but it probably is OK\nto make uname/gname overridable.  I do not see any point in uid/gid\nnumeric values overridable, though.  Just like user names and group\nnames do not name the same user and group on every machine, uid/gid\nare even less so.\n\n\n"},{"id":"415014","messageId":"87v9bo7gik.fsf@evledraar.gmail.com","threadId":"55032","inReplyTo":"20210122213954.7dlnnpngjoay3oia@chatter.i7.local","subject":"Re: git archive setting user and group","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2021-01-22T22:28:51Z","receivedAt":"2021-01-22T22:31:49Z","isPatch":false,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"\nOn Fri, Jan 22 2021, Konstantin Ryabitsev wrote:\n\n> On Fri, Jan 22, 2021 at 10:00:04PM +0100, René Scharfe wrote:\n>> Adding support for using a custom user and group should be easy.  Is\n>> this just a cosmetic thing?  Regular users would ignore the user info in\n>> the archive, and root should not be used for extracting, and on systems\n>> that don't have a logwatch user this wouldn't make a difference anyway,\n>> right?\n>\n> Right now, \"git archive\" operations are bit-for-bit identical across all\n> versions going back at least 8+ years. In fact, we've been relying on this to\n> support bundling tarball signatures with git tags themselves (via git notes).\n> E.g. you can see this in action here:\n> https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tag/?h=v5.10.9\n>\n> If you click on \"(sig)\", you will download a signature that can be used to\n> verify the tarball generated using \"git archive\".\n>\n> I would argue that adding user/group support to \"git archive\" operation is\n> not really solving any problems other than \"it's different from when I run it\n> as a regular user\" -- and can introduce potential compatibility problems if\n> implemented.\n>\n> So, I would selfishly vote not to implement this.\n\nIt seems \"logwatch\" has the same situation, except their backwards\ncompatibility is with non-\"git archive\" tool that used user != root.\n\nIf it solves a problem for some users and someone comes up with a patch\nI don't see why it shouldn't be implemented, but I think it's important\nthat \"root\" is the default unless configured or the relevant option is\ninvoked.\n\nOr do you mean that the kernel.org use-case is that users are expected\nto run \"git archive\" on their own machines and upload the result to\nkernel.org, and that kernel.org relies on two such files bit-for-bit\nidentical?\n"},{"id":"415020","messageId":"078701d6f111$14d304c0$3e790e40$@pdinc.us","threadId":"55032","inReplyTo":"xmqqsg6s61x2.fsf@gitster.c.googlers.com","subject":"RE: git archive setting user and group","fromName":"Jason Pyeron","fromEmail":"jpyeron@pdinc.us","sentAt":"2021-01-22T22:51:11Z","receivedAt":"2021-01-22T22:53:09Z","isPatch":false,"sender":{"key":"jpyeron@pdinc.us","avatar":"https://gravatar.com/avatar/c2e53452caa53d940768a1ffc9cf76196d851b9b534b7a39cd39852a70a0508f?d=mp&s=160"},"body":"> From: Junio C Hamano\n> Sent: Friday, January 22, 2021 5:29 PM\n> \n> René Scharfe <l.s.r@web.de> writes:\n> \n> > Am 22.01.21 um 21:40 schrieb Jason Pyeron:\n> > ...\n> >>         xsnprintf(header->uid, sizeof(header->uid), \"%07o\", 0);\n> >>         xsnprintf(header->gid, sizeof(header->gid), \"%07o\", 0);\n> >>         strlcpy(header->uname, \"root\", sizeof(header->uname));\n> >>         strlcpy(header->gname, \"root\", sizeof(header->gname));\n> >\n> > Adding support for using a custom user and group should be easy.  Is\n> > this just a cosmetic thing?  Regular users would ignore the user info in\n> > the archive, and root should not be used for extracting, and on systems\n> > that don't have a logwatch user this wouldn't make a difference anyway,\n> > right?\n> \n> I am not particularly interested in cosmetics, but it probably is OK\n> to make uname/gname overridable.  I do not see any point in uid/gid\n> numeric values overridable, though.  Just like user names and group\n\nInteresting. So logwatch(0) vs logwatch(1100) ? I guess it is as good as any value, but tar never uses 0.\n\nOn a system without the logwatch user/group tar behaves as follows:\n\n$ tar czf /tmp/logwatch.tgz --owner=logwatch --group=logwatch .\n\n$ tar tvzf /tmp/logwatch.tgz | head -n 1\ndrwxrwxr-x logwatch/logwatch 0 2020-03-14 15:01 ./\n\n$ tar tvzf /tmp/logwatch.tgz --numeric-owner | head -n 1\ndrwxrwxr-x 1049681/1049088   0 2020-03-14 15:01 ./\n\n$ id\nuid=1049681(myuser) gid=1049088(mygroup) groups=no one cares...\n\nbut when the user / group is known...\n\n$ tar czf /tmp/logwatch.tgz --owner=Guest --group=Users .\n\n$ tar tvzf /tmp/logwatch.tgz | head -n 1\ndrwxrwxr-x Guest/Users       0 2020-03-14 15:01 ./\n\n$ tar tvzf /tmp/logwatch.tgz --numeric-owner | head -n 1\ndrwxrwxr-x 1049077/545       0 2020-03-14 15:01 ./\n\n$ getent passwd Guest | cut -f 3 -d :\n1049077\n\n$ getent group Users | cut -f 3 -d :\n545\n\n\n> names do not name the same user and group on every machine, uid/gid\n> are even less so.\n> \n> \n\n\n"},{"id":"415029","messageId":"YAt2PPM4HRcKva9a@camp.crustytoothpaste.net","threadId":"55032","inReplyTo":"20210122213954.7dlnnpngjoay3oia@chatter.i7.local","subject":"Re: git archive setting user and group","fromName":"brian m. carlson","fromEmail":"sandals@crustytoothpaste.net","sentAt":"2021-01-23T01:05:00Z","receivedAt":"2021-01-23T01:06:12Z","isPatch":false,"sender":{"key":"sandals@crustytoothpaste.net","avatar":"https://avatars.githubusercontent.com/u/497054?v=4"},"body":"On 2021-01-22 at 21:39:54, Konstantin Ryabitsev wrote:\n> On Fri, Jan 22, 2021 at 10:00:04PM +0100, René Scharfe wrote:\n> > Adding support for using a custom user and group should be easy.  Is\n> > this just a cosmetic thing?  Regular users would ignore the user info in\n> > the archive, and root should not be used for extracting, and on systems\n> > that don't have a logwatch user this wouldn't make a difference anyway,\n> > right?\n> \n> Right now, \"git archive\" operations are bit-for-bit identical across all\n> versions going back at least 8+ years. In fact, we've been relying on this to\n> support bundling tarball signatures with git tags themselves (via git notes).\n> E.g. you can see this in action here:\n> https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tag/?h=v5.10.9\n> \n> If you click on \"(sig)\", you will download a signature that can be used to\n> verify the tarball generated using \"git archive\".\n\nPlease do not rely on this behavior.  I want to state in the strongest\npossible terms that this is not guaranteed behavior and it may change at\nany time.  We have explicitly said so on the list multiple times.  If\nyou need reproducible archives, you need to add a tool to canonicalize\nthem in a suitable format and not rely on Git to never change things.\n\nIf you are relying on this behavior right now, I urge you to change that\nat your earliest possible convenience.  I don't want to break\nkernel.org's infrastructure again, but I'm also not going to tiptoe\naround sending patches in fear of that, nor feel bad if it happens again\nfor this reason.\n\n> I would argue that adding user/group support to \"git archive\" operation is\n> not really solving any problems other than \"it's different from when I run it\n> as a regular user\" -- and can introduce potential compatibility problems if\n> implemented.\n\nI agree that this feature isn't really something we want.  Git produces\ntar archives for software interchange, in which case producing an\nintentionally anonymous tarball is the desired behavior.\n-- \nbrian m. carlson (he/him or they/them)\nHouston, Texas, US\n"},{"id":"415033","messageId":"YAus63jWBP1fIAhf@coredump.intra.peff.net","threadId":"55032","inReplyTo":"YAt2PPM4HRcKva9a@camp.crustytoothpaste.net","subject":"Re: git archive setting user and group","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2021-01-23T04:58:19Z","receivedAt":"2021-01-23T04:59:07Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Sat, Jan 23, 2021 at 01:05:00AM +0000, brian m. carlson wrote:\n\n> > Right now, \"git archive\" operations are bit-for-bit identical across all\n> > versions going back at least 8+ years. In fact, we've been relying on this to\n> > support bundling tarball signatures with git tags themselves (via git notes).\n> > E.g. you can see this in action here:\n> > https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tag/?h=v5.10.9\n> > \n> > If you click on \"(sig)\", you will download a signature that can be used to\n> > verify the tarball generated using \"git archive\".\n> \n> Please do not rely on this behavior.  I want to state in the strongest\n> possible terms that this is not guaranteed behavior and it may change at\n> any time.  We have explicitly said so on the list multiple times.  If\n> you need reproducible archives, you need to add a tool to canonicalize\n> them in a suitable format and not rely on Git to never change things.\n\nI strongly second this. :)\n\nIt's also not quite true that things have remained bit-for-bit identical\nfor all that time. We have fixed bugs in that time, although they do not\nalways cause a change in every output tarball (they often depend on\ncorner cases like having long pathnames). Two off the top of my head\n(that have indeed caused people to complain about changing checksums):\n\n  - 22f0dcd963 (archive-tar: split long paths more carefully,\n    2013-01-05)\n\n  - 82a46af13e (archive-tar: fix pax extended header length calculation,\n    2019-08-17)\n\nWe also rely on system gzip. That's pretty stable, but I have heard tell\nthat even `gzip -n` may differ on platforms.\n\nAnother fun one I saw recently: using export-subst with $Format:%h$ will\nproduce different results depending on how many objects are present in\nthe repository running git-archive.\n\n-Peff\n"},{"id":"415034","messageId":"20210123051149.vkeskbuod2twq4xu@chatter.i7.local","threadId":"55032","inReplyTo":"YAt2PPM4HRcKva9a@camp.crustytoothpaste.net","subject":"Re: git archive setting user and group","fromName":"Konstantin Ryabitsev","fromEmail":"konstantin@linuxfoundation.org","sentAt":"2021-01-23T05:11:49Z","receivedAt":"2021-01-23T05:13:46Z","isPatch":false,"sender":{"key":"konstantin@linuxfoundation.org","avatar":"https://gravatar.com/avatar/7cb8827c6de56e1bd2dea16508c6708aa43feed3bf3813bcdacecdf96ceadd79?d=mp&s=160"},"body":"On Sat, Jan 23, 2021 at 01:05:00AM +0000, brian m. carlson wrote:\n> > Right now, \"git archive\" operations are bit-for-bit identical across all\n> > versions going back at least 8+ years. In fact, we've been relying on this to\n> > support bundling tarball signatures with git tags themselves (via git notes).\n> > E.g. you can see this in action here:\n> > https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tag/?h=v5.10.9\n> > \n> > If you click on \"(sig)\", you will download a signature that can be used to\n> > verify the tarball generated using \"git archive\".\n> \n> Please do not rely on this behavior.  I want to state in the strongest\n> possible terms that this is not guaranteed behavior and it may change at\n> any time.  We have explicitly said so on the list multiple times.  If\n> you need reproducible archives, you need to add a tool to canonicalize\n> them in a suitable format and not rely on Git to never change things.\n\nIt doesn't need to be perpetually the same. This is the reason the comments\nmention git version -- \"to generate an archive that matches this signature,\nrun this command (with this git version).\" I know there is no guarantee that\nthis won't ever change across versions, but I don't see why we can't expect\ngit-archive to return the same bit-for-bit output when using the same version\nof git. Adding --owner and --group would potentially change that, especially\nif that's something settable via git-config.\n\n> If you are relying on this behavior right now, I urge you to change that\n> at your earliest possible convenience.  I don't want to break\n> kernel.org's infrastructure again, but I'm also not going to tiptoe\n> around sending patches in fear of that, nor feel bad if it happens again\n> for this reason.\n\nIt won't break, it will just inconvenience folks who are using this perk --\nGreg KH will just have to use the same git version that we have on the server\nwhen he generates the signatures. This has happened before.\n\n-K\n"},{"id":"415035","messageId":"20210123051626.7hubdcda74gq3oxo@chatter.i7.local","threadId":"55032","inReplyTo":"YAus63jWBP1fIAhf@coredump.intra.peff.net","subject":"Re: git archive setting user and group","fromName":"Konstantin Ryabitsev","fromEmail":"konstantin@linuxfoundation.org","sentAt":"2021-01-23T05:16:26Z","receivedAt":"2021-01-23T05:17:38Z","isPatch":false,"sender":{"key":"konstantin@linuxfoundation.org","avatar":"https://gravatar.com/avatar/7cb8827c6de56e1bd2dea16508c6708aa43feed3bf3813bcdacecdf96ceadd79?d=mp&s=160"},"body":"On Fri, Jan 22, 2021 at 11:58:19PM -0500, Jeff King wrote:\n> We also rely on system gzip. That's pretty stable, but I have heard tell\n> that even `gzip -n` may differ on platforms.\n\nThe signatures are made against uncompressed .tar output, so this is not a\nconsideration.\n\n> Another fun one I saw recently: using export-subst with $Format:%h$ will\n> produce different results depending on how many objects are present in\n> the repository running git-archive.\n\nAs long as the output is the same with thhe flags we specified in the\ncomment, we're still okay. E.g.:\n\n    -----BEGIN PGP SIGNATURE-----\n    Comment: This signature is for the .tar version of the archive\n    Comment: git archive --format tar --prefix=linux-5.10.9/ v5.10.9\n    Comment: git version 2.30.0\n\nIf running \"git archive --format tar --prefix=linux-5.10.9/ v5.10.9\" becomes\nnon-deterministic within the same version of git, *then* I'm in trouble. It's\nbeen remarkably stable within the past 8 years, so I don't expect there's a\ndramatic reason why \"--format tar\" output would need to change -- it's not\nlike the tar spec is much of a moving target.\n\n-K\n"}]}