Re: Sources for 3.18-rc1 not uploaded

["René Scharfe" <l.s.r@web.de>]

Am 23.10.2014 um 03:09 schrieb brian m. carlson:
> On Wed, Oct 22, 2014 at 11:42:48AM +0200, Michael J Gruber wrote:
>> Junio C Hamano schrieb am 21.10.2014 um 20:14:
>>> Michael J Gruber <git@drmicha.warpmail.net> writes:
>>>
>>>> Unfortunately, the git archive doc clearly says that the umask is
>>>> applied to all archive entries.
>>>
>>> Is an extended pax header "an archive entry"?  I doubt it, and the
>>> above is not relevant.  The mode bits for the archive entry that it
>>> applies to does not come from there.
>>
>> The problem seem to be old tar versions which mis-take the extensions
>> for archive entries, aren't they?
>
> Yes.  POSIX isn't clear on how unknown entries are to be handled.  I've
> seen some Windows tar implementations extract GNU longlink extensions as
> files, which leads to a lot of pain.

That's by design -- extended headers are meant to be extracted as plain 
files by implementations that do not understand them.

http://pubs.opengroup.org/onlinepubs/009695399/utilities/pax.html says: 
"If a particular implementation does not recognize the type, or the user 
does not have appropriate privilege to create that type, the file shall 
be extracted as if it were a regular file if the file type is defined to 
have a meaning for the size field that could cause data logical records 
to be written on the medium [...]."

>> My question to Brian still stands which existing users he was trying to
>> cater for with his patch. If there indeed are no existing affected users
>> besides the KUP users (as you seem to assume) it's a clear case. Pun
>> intended ;)
>
> The pax format is an extension of the tar format.  All of the pax
> implementations I've seen on Linux (OpenBSD's and MirBSD's) don't
> actually understand the pax headers and emit them as files.  7zip does
> as well.  I expect there are other Unix systems where tar itself doesn't
> understand pax headers, although I don't have access to anything other
> than Linux and FreeBSD.

NetBSD's tar does as well.

It's surprising and sad to see *pax* implementations not supporting pax 
extended headers in 2014, though.  It seems long file names etc. are not 
common enough.  Or perhaps pax is simply not used that much.

> Since it's very common to extract tar archives in /tmp, I didn't want to
> leave world-writable files in /tmp (or anywhere else someone might get
> to them).  While the contents probably aren't sensitive, a malicious
> user might fill someone's quota by "helpfully" appending /dev/zero to
> the file.  And yes, users do these things.

The extracted files are only world-writable if umask & 2 == 0 or if -p 
(preserve permissions) has been used, no?

René