Re: git archive generates tar with malformed pax extended attribute

[Jeff King <peff@peff.net>]

On Sun, May 26, 2019 at 11:33:20PM +0200, René Scharfe wrote:

> Git archive writes link targets that are 100 characters long or less
> into the appropriate field in the plain tar header.  It copies
> everything, including NULs, but unlike a PAX extended header that field
> lacks a length indicator, so extractors basically have to treat it as
> NUL-terminated.
> 
> If we want to preserve NUL in short link targets as well, we'd have to
> put such names into an PAX extended header..

I can't say that I care much either way, since putting NULs in your
filenames is pretty crazy. But that would at least make things
consistent regardless of the length.

I also wondered if you could play any security tricks here (e.g., by
having one tool view a filename as "foo" and another as "foo\0bar"). I
doubt it, though.  Filenames themselves in Git are always
NUL-terminated, since that's dictated the tree format; so this is really
just about link destinations.

And even then, it's hard to imagine a case. I was wondering if you could
have an entry ".git\0foo" that ends up written to the filesystem as
".git". But these are tar archives we're talking about, so it's not like
you couldn't just put ".git" in a tar file in the first place.

But maybe somebody else can brainstorm something more evil. :)

-Peff