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

[Jeff King <peff@peff.net>]

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

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

> 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