Re: git archive generates tar with malformed pax extended attribute

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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



[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux