Summary: | New tar fails to unpack certain archives properly | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Daniel Ahlberg (RETIRED) <aliz> |
Component: | [OLD] Unspecified | Assignee: | Gentoo's Team for Core System packages <base-system> |
Status: | RESOLVED FIXED | ||
Severity: | critical | CC: | 043936y, avenj, benoit.boissinot, bla, carpaski, chainsaw, chriskds25, derk.tebokkel, dev, ehmsen, gentoo, jochen.eisinger, mallchin, mkennedy, president, sgtphou, suka, tove |
Priority: | High | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | All | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: |
ebuild.sh.diff
1.13.92-disable-dotslash-check.diff tar-1.13.92.ebuild.diff 1.13.92-hardcode-absolute-names-to-on.diff tar-1.13.92.ebuild.diff tar-1.13.92-fix-pathstrip.patch |
Description
Daniel Ahlberg (RETIRED)
2004-01-03 12:05:07 UTC
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 attachment 23085 [details, diff]
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 attachment 23092 [details, diff]
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 attachment 23093 [details, diff]
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 attachment 23099 [details, diff]
1.13.92-hardcode-absolute-names-to-on.diff
Redoing things the hardcoded way, in tar.c, as asked.
Created attachment 23100 [details, diff]
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 attachment 23245 [details, diff]
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. *** Comment on attachment 23099 [details, diff]
1.13.92-hardcode-absolute-names-to-on.diff
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. *** |