From: Junio C Hamano Date: Tue, 07 Apr 2026 19:57:54 GMT Subject: Re: [RFC] archive: behavior of --prefix with absolute or parent path components Message-ID: In-Reply-To: <20260407192454.GA754735@coredump.intra.peff.net> Jeff King writes: >> In such cases, tar emits warnings like: >> "Removing leading '/' from member names" >> "Removing leading '../' from member names" > > Yes, but note that with "-P" tar will happily allow those paths. They > _can_ be useful, if you know what you are doing, but they aren't > necessarily safe when coming from untrusted sources. > > We can also generate zip files, but I think most unzip implementations > have similar restrictions (info-zip does, with "-:" to override). > > In theory we could support other formats, but after 20 years I don't > think anybody has bothered to do so. Cpio, anyone? :) > > Though speaking of cpio (the command, not the format), it will happily > list and extract the paths above from a tar input without any extra > option (it has an option to restrict, but unlike tar, it defaults to > off). > >> From a user perspective, I was wondering: >> - Is this behavior intentional (i.e., leaving validation to archive >> consumers)? >> - Would it be worth documenting this explicitly? >> - Or should there be any normalization or validation at the Git level? >> >> I understand that Git generally avoids enforcing policy decisions in >> such cases, but I wanted to confirm whether this behavior is intentional. > > I don't recall it ever being discussed. Of the three you mentioned, > "../" and leading "/" are potentially useful, so I don't think we'd want > to disallow them entirely. At least some tar implementations require > "-P" on the generating side to avoid mistakes, so we could follow that > path. It may be considered a regression by anybody who is using the > feature currently, though. Thanks. I was writing almost exactly the same message ;-) > The "////" is meaningless AFAICT, and could be replaced with a single > slash. But I think it's also mostly harmless, as the reading side (well, > the kernel) will equate "foo/////file" and "foo/file". I don't know if > there are systems where that would not be the case. > > So...yeah. I guess we can document it more explicitly. Since you seem to > be the first to ask about it, it does not seem like a common question. > But if we can clarify the behavior without making the current docs > harder to read, I don't see a problem in doing so. Yup, in other words, "Patches welcome".