Bugzilla Bug 37132

Some tar archives has paths like these in them: ..././...
when trying to unpack these archives with tar 1.13.92 it gives the following warning: tar: Removing leading ...

Confirmed tarballs that suffers from this are: libpcap-0.8.1, tcpdump-3.8.1 and iptables-1.2.9

The tar problem manifests itself like this:

>>> md5 src_uri ;-) tcpdump-3.8.1.tar.gz
>>> Unpacking source...
>>> Unpacking tcpdump-3.8.1.tar.gz to /var/tmp/portage/tcpdump-3.8.1/work
tar: Removing leading `tcpdump-3.8.1/./' from member names
>>> Source unpacked.

!!! ERROR: net-analyzer/tcpdump-3.8.1 failed.
!!! Function econf, Line 341, Exitcode 1
!!! no configure script found

And those weird paths are actually in the mentioned tar's:
tcpdump-3.8.1/./
tcpdump-3.8.1/./lbl/
tcpdump-3.8.1/./lbl/os-osf4.h
(truncated)

The result is that tar strips out the subdir in the tarball unpacking it
directly to $PORTAGE_TMDIR/work and not $PORTAGE_TMPDIR/work/libpcap-0.8.1

A fragment from tar-1.13.92/ChangeLog
One entry seems relevant, marked with <!>

003-11-14  Sergey Poznyakoff  <gray@Mirddin.farlep.net>

        * src/tar.h (archive_format): USTAR_FORMAT: New type.
        * src/create.c: Added POSIX.1-1988 support.
    <!>* src/names.c (safer_name_suffix): Skip leading ./
        * src/tar.c: New option --format=ustar forces
        POSIX.1-1988 archive format.
        * tests/delete03.sh: Updated.
        * tests/extrac04.sh: Updated.
        * tests/multiv01.sh: Updated.

Looks as if the "P" option to tar (--absolute-names) disables the check.
Playing around with this.

Created an attachment (id=23085) [details]
ebuild.sh.diff

This adds --absolute-names to the unpack command in ebuild.sh and allows me to
install libpcap.
Please perform a sanity check on this and treat it with care until I've tested
more thoroughly.

i dont really think the way to go is patching ebuild.sh

it's obvious it's a bug in tar, fix tar and we dont have to screw around with releasing another portage

Tested with:  libpcap-0.8.1, tcpdump-3.8.1 and iptables-1.2.9
These weren't willing to install earlier and work now.

Tested with: kdegames-3.2.0_beta2, tar-1.13.92 and portage-2.0.49-r20
These worked before, and still work now.

I'm not a C coder though.

Could mask the tar version, file a bug upstream or have someone else hack on names.c, I guess.

Anyway, should anyone be willing to take this route, it will work.

Created an attachment (id=23092) [details]
1.13.92-disable-dotslash-check.diff

This hardcodes the (apparently buggy) check to disabled in the tar sources.
Basically, this is the same solution as provided earlier, but then in a way
that doesn't require a portage upgrade (which would be tedious indeed, SpanKY,
agreed).

Created an attachment (id=23093) [details]
tar-1.13.92.ebuild.diff

And ofcourse the diff to the tar ebuild to apply this diff.

How's this? (Tested again, same 6 packages)

absolute_names_option is referenced in both src/extract.c and src/names.c, so
perhaps the better way of doing it is to patch src/tar.c around line 1246 with
absolute_names_option = true;

Created an attachment (id=23099) [details]
1.13.92-hardcode-absolute-names-to-on.diff

Redoing things the hardcoded way, in tar.c, as asked.

Created an attachment (id=23100) [details]
tar-1.13.92.ebuild.diff

And the ebuild change to have the patch applied.

Bugfixes to order, anyone else that would like a change? :)

*** Bug 37157 has been marked as a duplicate of this bug. ***

*** Bug 37170 has been marked as a duplicate of this bug. ***

*** Bug 36810 has been marked as a duplicate of this bug. ***

*** Bug 37103 has been marked as a duplicate of this bug. ***

*** Bug 37176 has been marked as a duplicate of this bug. ***

*** Bug 37190 has been marked as a duplicate of this bug. ***

*** Bug 37195 has been marked as a duplicate of this bug. ***

thanks for the patch, Tony, added to portage and reporting this issue upstream

*** Bug 37202 has been marked as a duplicate of this bug. ***

*** Bug 37203 has been marked as a duplicate of this bug. ***

*** Bug 37287 has been marked as a duplicate of this bug. ***

For the slow people among us (who need everything spelled out), the fix is to:
a) emerge tar, and then
b) emerge libpcap.
tar version app-arch/tar-1.13.92-r1 seems to address the problem mentioned here.

I do not think this is the proper fix ..

Created an attachment (id=23245) [details]
tar-1.13.92-fix-pathstrip.patch

The problem is the strip code also strip './', and not just '../'.  I do not
see why the code also strip './', as it refers to the current dir (or the
proper file if you append the path given to -C arg), and as we all know, RH
etc starts to ship tarballs that have pathnames start with './' for security
reasons - same reason why unzip add './' to all paths.

Anyhow, attached is patch that fixes the code not to stip './'.

Comments?

On another matter - if you look at the following code:

--
          if (p[0] == '.')
            {
              if (p[1] == '.' && (ISSLASH (p[2]) || !p[2]))
                prefix_len = p + 2 - file_name;
              else if (ISSLASH (p[1]))
                prefix_len = p + 1 - file_name;
            }
--

from src/names.c ('safer_name_suffix' function), is it safe?  I see no
test to see if the lenght of the input filename is >= 3 chars, but still
the code checks p[0], p[1] and p[2] without checking if its valid (sure,
there is the '!p[2]' check, but that follows 'ISSLASH (p[2])').  My C
is a bit rustic, so I might see something where there is none ...

if the string is 0 terminated should not be a problem:

if p[1] == 0 it exits and won't check the other conditions.

Maybe I forgot something, from a quick look at the rest of the code it should not cause any harm.

If p[2] is out of bounds, the 'ISSLASH (p[2])' will touch it.  The p==0 test
is only after, and this is not part of that while loop ...

Ok, here is the proper fix:

http://savannah.gnu.org/cgi-bin/viewcvs/tar/tar/src/names.c.diff?r1=1.36&r2=1.37&diff_format=u

I missed a change it seems :)  I'll commit tonight if somebody do not get there
before me.

I suffered from the exact same problem. After upgrading app-arch/tar-1.13.92 to
1.13.92-r1, I was able to successfully upgrade libpcap and iptables.

*** Bug 37352 has been marked as a duplicate of this bug. ***

(From update of attachment 23099 [details])
This workaround is no longer necessary now that the true cause is found.
Obsoleting.

*** Bug 37610 has been marked as a duplicate of this bug. ***

http://bugs.gentoo.org/show_bug.cgi?id=37728

Seems to be a duplicate of this one too, openoffice and openoffice-ximian both break with the current unstable app-arch/tar-1.13.92-r1

Added -r2 with new patch - can we verify that it still works?

Ok, seems this also fixes the openoffice issues with -r1 (bug #37610).

*** Bug 38739 has been marked as a duplicate of this bug. ***