Re: [RFC] archive: behavior of --prefix with absolute or parent path components

From: Jeff King <peff@peff.net>
Date: Apr 7, 2026, 19:24 UTC
Message-ID: <20260407192454.GA754735@coredump.intra.peff.net>
In-Reply-To: <20260407162101.2285-1-pushkarkumarsingh1970@gmail.com>

On Tue, Apr 07, 2026 at 04:21:01PM +0000, Pushkar Singh wrote:

Show 14 quoted lines

> Currently, --prefix accepts values such as absolute paths or ones with ..,
> e.g.:
>     git archive --prefix=/ HEAD > out.tar
>     git archive --prefix=//// HEAD > out.tar
>     git archive --prefix=../../ HEAD > out.tar
> 
> Upon listing the archive contents (e.g., tar -tf), you get entries like:
>     /a.txt
>     ////a.txt
>     ../../a.txt
> 
> 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).

Show 8 quoted lines

> 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.

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.

-Peff