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

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