{"thread":{"id":"65451","subject":"[RFC] archive: behavior of --prefix with absolute or parent path components","startedAt":"2026-04-07T16:21:07Z","lastAt":"2026-04-08T17:40:45Z","messageCount":6,"participants":["Pushkar Singh","Jeff King","Junio C Hamano","brian m. carlson"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"541076","messageId":"20260407162101.2285-1-pushkarkumarsingh1970@gmail.com","threadId":"65451","inReplyTo":null,"subject":"[RFC] archive: behavior of --prefix with absolute or parent path components","fromName":"Pushkar Singh","fromEmail":"pushkarkumarsingh1970@gmail.com","sentAt":"2026-04-07T16:21:01Z","receivedAt":"2026-04-07T16:21:07Z","isPatch":false,"body":"Hi,\n\nWhile experimenting with \"git archive\", I noticed some behavior around\nthe --prefix option that might be worth clarifying.\n\nCurrently, --prefix accepts values such as absolute paths or ones with ..,\ne.g.:\n git archive --prefix=/ HEAD > out.tar\n git archive --prefix=//// HEAD > out.tar\n git archive --prefix=../../ HEAD > out.tar\n\nUpon listing the archive contents (e.g., tar -tf), you get entries like:\n /a.txt\n ////a.txt\n ../../a.txt\n\nIn such cases, tar emits warnings like:\n \"Removing leading '/' from member names\"\n \"Removing leading '../' from member names\"\n\nThis suggests that Git passes the prefix through as-is, relying on \ndownstream tools to sanitize potentially unsafe paths.\n\nFrom a user perspective, I was wondering:\n - Is this behavior intentional (i.e., leaving validation to archive\n consumers)?\n - Would it be worth documenting this explicitly?\n - Or should there be any normalization or validation at the Git level?\n\nI understand that Git generally avoids enforcing policy decisions in \nsuch cases, but I wanted to confirm whether this behavior is intentional.\n\nI’d appreciate any thoughts on this :-)\n\nThanks,\nPushkar"},{"id":"541088","messageId":"20260407192454.GA754735@coredump.intra.peff.net","threadId":"65451","inReplyTo":"20260407162101.2285-1-pushkarkumarsingh1970@gmail.com","subject":"Re: [RFC] archive: behavior of --prefix with absolute or parent path components","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2026-04-07T19:24:54Z","receivedAt":"2026-04-07T19:24:55Z","isPatch":false,"body":"On Tue, Apr 07, 2026 at 04:21:01PM +0000, Pushkar Singh wrote:\n\n> Currently, --prefix accepts values such as absolute paths or ones with ..,\n> e.g.:\n> git archive --prefix=/ HEAD > out.tar\n> git archive --prefix=//// HEAD > out.tar\n> git archive --prefix=../../ HEAD > out.tar\n> \n> Upon listing the archive contents (e.g., tar -tf), you get entries like:\n> /a.txt\n> ////a.txt\n> ../../a.txt\n> \n> In such cases, tar emits warnings like:\n> \"Removing leading '/' from member names\"\n> \"Removing leading '../' from member names\"\n\nYes, but note that with \"-P\" tar will happily allow those paths. They\n_can_ be useful, if you know what you are doing, but they aren't\nnecessarily safe when coming from untrusted sources.\n\nWe can also generate zip files, but I think most unzip implementations\nhave similar restrictions (info-zip does, with \"-:\" to override).\n\nIn theory we could support other formats, but after 20 years I don't\nthink anybody has bothered to do so. Cpio, anyone? :)\n\nThough speaking of cpio (the command, not the format), it will happily\nlist and extract the paths above from a tar input without any extra\noption (it has an option to restrict, but unlike tar, it defaults to\noff).\n\n> From a user perspective, I was wondering:\n> - Is this behavior intentional (i.e., leaving validation to archive\n> consumers)?\n> - Would it be worth documenting this explicitly?\n> - Or should there be any normalization or validation at the Git level?\n> \n> I understand that Git generally avoids enforcing policy decisions in \n> such cases, but I wanted to confirm whether this behavior is intentional.\n\nI don't recall it ever being discussed. Of the three you mentioned,\n\"../\" and leading \"/\" are potentially useful, so I don't think we'd want\nto disallow them entirely. At least some tar implementations require\n\"-P\" on the generating side to avoid mistakes, so we could follow that\npath. It may be considered a regression by anybody who is using the\nfeature currently, though.\n\nThe \"////\" is meaningless AFAICT, and could be replaced with a single\nslash. But I think it's also mostly harmless, as the reading side (well,\nthe kernel) will equate \"foo/////file\" and \"foo/file\". I don't know if\nthere are systems where that would not be the case.\n\nSo...yeah. I guess we can document it more explicitly. Since you seem to\nbe the first to ask about it, it does not seem like a common question.\nBut if we can clarify the behavior without making the current docs\nharder to read, I don't see a problem in doing so.\n\n-Peff\n"},{"id":"541090","messageId":"xmqq1pgq4k71.fsf@gitster.g","threadId":"65451","inReplyTo":"20260407192454.GA754735@coredump.intra.peff.net","subject":"Re: [RFC] archive: behavior of --prefix with absolute or parent path components","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2026-04-07T19:57:54Z","receivedAt":"2026-04-07T19:57:56Z","isPatch":false,"body":"Jeff King writes:\n\n>> In such cases, tar emits warnings like:\n>> \"Removing leading '/' from member names\"\n>> \"Removing leading '../' from member names\"\n>\n> Yes, but note that with \"-P\" tar will happily allow those paths. They\n> _can_ be useful, if you know what you are doing, but they aren't\n> necessarily safe when coming from untrusted sources.\n>\n> We can also generate zip files, but I think most unzip implementations\n> have similar restrictions (info-zip does, with \"-:\" to override).\n>\n> In theory we could support other formats, but after 20 years I don't\n> think anybody has bothered to do so. Cpio, anyone? :)\n>\n> Though speaking of cpio (the command, not the format), it will happily\n> list and extract the paths above from a tar input without any extra\n> option (it has an option to restrict, but unlike tar, it defaults to\n> off).\n>\n>> From a user perspective, I was wondering:\n>> - Is this behavior intentional (i.e., leaving validation to archive\n>> consumers)?\n>> - Would it be worth documenting this explicitly?\n>> - Or should there be any normalization or validation at the Git level?\n>> \n>> I understand that Git generally avoids enforcing policy decisions in \n>> such cases, but I wanted to confirm whether this behavior is intentional.\n>\n> I don't recall it ever being discussed. Of the three you mentioned,\n> \"../\" and leading \"/\" are potentially useful, so I don't think we'd want\n> to disallow them entirely. At least some tar implementations require\n> \"-P\" on the generating side to avoid mistakes, so we could follow that\n> path. It may be considered a regression by anybody who is using the\n> feature currently, though.\n\nThanks. I was writing almost exactly the same message ;-)\n\n> The \"////\" is meaningless AFAICT, and could be replaced with a single\n> slash. But I think it's also mostly harmless, as the reading side (well,\n> the kernel) will equate \"foo/////file\" and \"foo/file\". I don't know if\n> there are systems where that would not be the case.\n>\n> So...yeah. I guess we can document it more explicitly. Since you seem to\n> be the first to ask about it, it does not seem like a common question.\n> But if we can clarify the behavior without making the current docs\n> harder to read, I don't see a problem in doing so.\n\nYup, in other words, \"Patches welcome\".\n\n"},{"id":"541105","messageId":"adWEDmP7A5XzRcyP@fruit.crustytoothpaste.net","threadId":"65451","inReplyTo":"20260407192454.GA754735@coredump.intra.peff.net","subject":"Re: [RFC] archive: behavior of --prefix with absolute or parent path components","fromName":"brian m. carlson","fromEmail":"sandals@crustytoothpaste.net","sentAt":"2026-04-07T22:24:14Z","receivedAt":"2026-04-07T22:24:22Z","isPatch":false,"body":"On 2026-04-07 at 19:24:54, Jeff King wrote:\n> Yes, but note that with \"-P\" tar will happily allow those paths. They\n> _can_ be useful, if you know what you are doing, but they aren't\n> necessarily safe when coming from untrusted sources.\n> \n> We can also generate zip files, but I think most unzip implementations\n> have similar restrictions (info-zip does, with \"-:\" to override).\n\nI suspect there are people using this with `/` because they want to\ndeploy files to places like `/etc`. We've actually had requests for the\nability to have multiple roots in a repository so that people can do\nthis kind of thing, so I'm certain there are people finding _some_ way\nto do it, even if not with this exact approach.\n\nIn conjunction with a tool like mtree(1) to adjust ownership and\npermissions, this could be useful.\n\n> In theory we could support other formats, but after 20 years I don't\n> think anybody has bothered to do so. Cpio, anyone? :)\n\ncpio doesn't have the long filename support that our pax (tar) archives\nhave, so I wouldn't recommend adding it. The only place I still see\npeople use it is initramfs images for Linux.\n\n> I don't recall it ever being discussed. Of the three you mentioned,\n> \"../\" and leading \"/\" are potentially useful, so I don't think we'd want\n> to disallow them entirely. At least some tar implementations require\n> \"-P\" on the generating side to avoid mistakes, so we could follow that\n> path. It may be considered a regression by anybody who is using the\n> feature currently, though.\n> \n> The \"////\" is meaningless AFAICT, and could be replaced with a single\n> slash. But I think it's also mostly harmless, as the reading side (well,\n> the kernel) will equate \"foo/////file\" and \"foo/file\". I don't know if\n> there are systems where that would not be the case.\n\nTechnically, POSIX allows `//` to be different than `/`, I believe,\nalthough I'm not aware of anyone outside of Windows (and maybe Interix)\nwhere that has any special meaning. If you have such a system, it could\nbe useful to provide that as well as `/`.\n\nI agree that it's more likely a typo, though.\n-- \nbrian m. carlson (they/them)\nToronto, Ontario, CA\n"},{"id":"541143","messageId":"20260408160005.193621-2-pushkarkumarsingh1970@gmail.com","threadId":"65451","inReplyTo":"20260407162101.2285-1-pushkarkumarsingh1970@gmail.com","subject":"[PATCH] archive: document --prefix handling of absolute and parent paths","fromName":"Pushkar Singh","fromEmail":"pushkarkumarsingh1970@gmail.com","sentAt":"2026-04-08T16:00:06Z","receivedAt":"2026-04-08T16:01:23Z","isPatch":true,"body":"Clarify that --prefix is used as given and is not normalized,\nand may include leading slashes or parent directory components.\n\nSigned-off-by: Pushkar Singh \n---\n Documentation/git-archive.adoc | 5 +++++\n 1 file changed, 5 insertions(+)\n\ndiff --git a/Documentation/git-archive.adoc b/Documentation/git-archive.adoc\nindex a0e3fe7996..086bade6d8 100644\n--- a/Documentation/git-archive.adoc\n+++ b/Documentation/git-archive.adoc\n@@ -54,6 +54,11 @@ OPTIONS\n \tPrepend / to paths in the archive. Can be repeated; its\n \trightmost value is used for all tracked files. See below which\n \tvalue gets used by `--add-file`.\n++\n+The is used as given and is not normalized. It may\n+include leading slashes or parent directory components (e.g.,\n+`../`). Some archive consumers may treat such paths as\n+potentially unsafe and adjust or warn during extraction.\n \n -o ::\n --output=::\n-- \n2.53.0.582.gca1db8a0f7\n\n"},{"id":"541160","messageId":"20260408174043.GC2850002@coredump.intra.peff.net","threadId":"65451","inReplyTo":"20260408160005.193621-2-pushkarkumarsingh1970@gmail.com","subject":"Re: [PATCH] archive: document --prefix handling of absolute and parent paths","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2026-04-08T17:40:43Z","receivedAt":"2026-04-08T17:40:45Z","isPatch":true,"body":"On Wed, Apr 08, 2026 at 04:00:06PM +0000, Pushkar Singh wrote:\n\n> \tPrepend / to paths in the archive. Can be repeated; its\n> \trightmost value is used for all tracked files. See below which\n> \tvalue gets used by `--add-file`.\n> ++\n> +The is used as given and is not normalized. It may\n> +include leading slashes or parent directory components (e.g.,\n> +`../`). Some archive consumers may treat such paths as\n> +potentially unsafe and adjust or warn during extraction.\n\nThanks, this reads fine to me.\n\n-Peff\n"}]}