37132 2004-01-03 12:05 0000 New tar fails to unpack certain archives properly 2004-01-19 21:25:28 0000 1 1 1 Unclassified Gentoo Linux Unspecified unspecified All All RESOLVED FIXED P2 critical --- 1 aliz@gentoo.org base-system@gentoo.org 043936y@acadiau.ca avenj@gentoo.org benoit.boissinot@ens-lyon.fr bla@af.gliwice.pl carpaski@gentoo.org chainsaw@gentoo.org chriskds25@yahoo.com derk@zapville.org ehmsen@gentoo.org gentoo@valli.org jochen.eisinger@gmx.de mallchin@blueyonder.co.uk mkennedy@gentoo.org president@sheergenius.com sgtphou@fire-eyes.org suka@gentoo.org tove@gentoo.org ykar@list.ru aliz@gentoo.org 2004-01-03 12:05:07 0000 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 chainsaw@gentoo.org 2004-01-03 12:10:47 0000 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) aliz@gentoo.org 2004-01-03 12:13:21 0000 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 chainsaw@gentoo.org 2004-01-03 12:21:00 0000 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. chainsaw@gentoo.org 2004-01-03 12:34:48 0000 Looks as if the "P" option to tar (--absolute-names) disables the check. Playing around with this. chainsaw@gentoo.org 2004-01-03 12:40:33 0000 Created an attachment (id=23085) 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. vapier@gentoo.org 2004-01-03 12:42:11 0000 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 chainsaw@gentoo.org 2004-01-03 12:45:56 0000 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. chainsaw@gentoo.org 2004-01-03 12:47:02 0000 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. chainsaw@gentoo.org 2004-01-03 13:14:27 0000 Created an attachment (id=23092) 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). chainsaw@gentoo.org 2004-01-03 13:15:20 0000 Created an attachment (id=23093) 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) vapier@gentoo.org 2004-01-03 13:50:55 0000 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; chainsaw@gentoo.org 2004-01-03 13:58:43 0000 Created an attachment (id=23099) 1.13.92-hardcode-absolute-names-to-on.diff Redoing things the hardcoded way, in tar.c, as asked. chainsaw@gentoo.org 2004-01-03 13:59:37 0000 Created an attachment (id=23100) 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? :) vapier@gentoo.org 2004-01-03 21:54:31 0000 *** Bug 37157 has been marked as a duplicate of this bug. *** aliz@gentoo.org 2004-01-04 02:52:35 0000 *** Bug 37170 has been marked as a duplicate of this bug. *** aliz@gentoo.org 2004-01-04 03:58:59 0000 *** Bug 36810 has been marked as a duplicate of this bug. *** aliz@gentoo.org 2004-01-04 04:00:03 0000 *** Bug 37103 has been marked as a duplicate of this bug. *** jochen.eisinger@gmx.de 2004-01-04 04:55:38 0000 *** Bug 37176 has been marked as a duplicate of this bug. *** kloeri@gentoo.org 2004-01-04 06:41:14 0000 *** Bug 37190 has been marked as a duplicate of this bug. *** tseng@gentoo.org 2004-01-04 08:06:09 0000 *** Bug 37195 has been marked as a duplicate of this bug. *** seemant@gentoo.org 2004-01-04 08:54:58 0000 thanks for the patch, Tony, added to portage and reporting this issue upstream seemant@gentoo.org 2004-01-04 09:16:32 0000 *** Bug 37202 has been marked as a duplicate of this bug. *** seemant@gentoo.org 2004-01-04 09:26:15 0000 *** Bug 37203 has been marked as a duplicate of this bug. *** seemant@gentoo.org 2004-01-05 04:29:03 0000 *** Bug 37287 has been marked as a duplicate of this bug. *** corporate_gadfly@hotmail.com 2004-01-05 11:05:11 0000 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. azarah@gentoo.org 2004-01-06 10:53:46 0000 I do not think this is the proper fix .. azarah@gentoo.org 2004-01-06 10:58:45 0000 Created an attachment (id=23245) 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? azarah@gentoo.org 2004-01-06 11:05:36 0000 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 ... lu_zero@gentoo.org 2004-01-06 11:25:16 0000 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. azarah@gentoo.org 2004-01-06 11:39:49 0000 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 ... azarah@gentoo.org 2004-01-06 14:04:12 0000 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. rjtupas@mac.com 2004-01-07 02:21:03 0000 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. vapier@gentoo.org 2004-01-07 22:17:51 0000 *** Bug 37352 has been marked as a duplicate of this bug. *** chainsaw@gentoo.org 2004-01-07 23:06:05 0000 (From update of attachment 23099) This workaround is no longer necessary now that the true cause is found. Obsoleting. vapier@gentoo.org 2004-01-08 17:17:27 0000 *** Bug 37610 has been marked as a duplicate of this bug. *** suka@gentoo.org 2004-01-10 04:47:41 0000 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 azarah@gentoo.org 2004-01-11 06:02:17 0000 Added -r2 with new patch - can we verify that it still works? azarah@gentoo.org 2004-01-11 08:12:14 0000 Ok, seems this also fixes the openoffice issues with -r1 (bug #37610). vapier@gentoo.org 2004-01-19 21:25:28 0000 *** Bug 38739 has been marked as a duplicate of this bug. *** 23085 2004-01-03 12:40 0000 ebuild.sh.diff ebuild.sh.diff text/plain LS0tIC91c3IvbGliL3BvcnRhZ2UvYmluL2VidWlsZC5zaC5vcmlnCTIwMDQtMDEtMDMgMjE6MzY6 MjUuMDMwOTU4NTQ0ICswMTAwCisrKyAvdXNyL2xpYi9wb3J0YWdlL2Jpbi9lYnVpbGQuc2gJMjAw NC0wMS0wMyAyMTozNzoyNS45MjA3MDE4OTYgKzAxMDAKQEAgLTI4MCw3ICsyODAsNyBAQAogCWlm IFsgIiRVU0VSTEFORCIgPT0gIkJTRCIgXTsgdGhlbgogCQl0YXJ2YXJzPSIiCiAJZWxzZQotCQl0 YXJ2YXJzPSItLW5vLXNhbWUtb3duZXIiCQorCQl0YXJ2YXJzPSItLW5vLXNhbWUtb3duZXIgLS1h YnNvbHV0ZS1uYW1lcyIJCiAJZmkJCiAKIAlmb3IgeCBpbiAiJEAiOyBkbwo= 23092 2004-01-03 13:14 0000 1.13.92-disable-dotslash-check.diff 1.13.92-disable-dotslash-check.diff text/plain LS0tIHNyYy9uYW1lcy5jLm9yaWcJMjAwNC0wMS0wMyAyMjowNDo1My44NTExNzgzODQgKzAxMDAK KysrIHNyYy9uYW1lcy5jCTIwMDQtMDEtMDMgMjI6MDY6MDEuNzcyODUyNzIwICswMTAwCkBAIC0x MDEwLDcgKzEwMTAsNyBAQAogewogICBjaGFyIGNvbnN0ICpwOwogCi0gIGlmIChhYnNvbHV0ZV9u YW1lc19vcHRpb24pCisgIGlmICgxKSAvKiBUaGlzIGRpc2FibGVzIGEgYnVnZ3kgY2hlY2sgb24g Li8gaW4gcGF0aG5hbWVzICovCiAgICAgcCA9IGZpbGVfbmFtZTsKICAgZWxzZQogICAgIHsK 23093 2004-01-03 13:15 0000 tar-1.13.92.ebuild.diff tar-1.13.92.ebuild.diff text/plain LS0tIC91c3IvcG9ydGFnZS9hcHAtYXJjaC90YXIvdGFyLTEuMTMuOTIuZWJ1aWxkCTIwMDMtMTIt MjkgMDU6MDI6MjYuMDAwMDAwMDAwICswMTAwCisrKyB0YXItMS4xMy45Mi5lYnVpbGQJMjAwNC0w MS0wMyAyMjowOTowMS40NDE4MDUxMzYgKzAxMDAKQEAgLTI2LDYgKzI2LDggQEAKIAkjIEZpeCBj b25maWd1cmUgc2NyaXB0cyB0byBzdXBwb3J0IGxpbnV4LW1pcHMgdGFyZ2V0cwogCWdudWNvbmZp Z191cGRhdGUKIAorCWVwYXRjaCAke0ZJTEVTRElSfS8ke1BWfS1kaXNhYmxlLWRvdHNsYXNoLWNo ZWNrLmRpZmYKKwogCWVjb25mIFwKIAkJLS1iaW5kaXI9L2JpbiBcCiAJCS0tbGliZXhlY2Rpcj0v dXNyL2xpYi9taXNjIFwK 23099 2004-01-03 13:58 0000 1.13.92-hardcode-absolute-names-to-on.diff 1.13.92-hardcode-absolute-names-to-on.diff text/plain LS0tIHNyYy90YXIuYy5vcmlnCTIwMDMtMTItMDEgMTU6MTE6MDUuMDAwMDAwMDAwICswMTAwCisr KyBzcmMvdGFyLmMJMjAwNC0wMS0wMyAyMjo1Mzo0Ny40MDMyMTA2ODggKzAxMDAKQEAgLTEyNDQs NiArMTI0NCwxMCBAQAogCX0KICAgICB9CiAKKyAgLyogSGFyZGNvZGUgYWJzb2x1dGVfbmFtZXNf b3B0aW9uIHRvIGVuYWJsZWQsIHRvIGF2b2lkIGdldHRpbmcgYml0dGVuCisgICAgIGJ5IGEgYnVn Z3kgY2hlY2sgdGhhdCByZW1vdmVzIHRvbyBtdWNoIHdoZW4gLi8gaXMgaW4gdGhlIHBhdGggKi8K KyAgYWJzb2x1dGVfbmFtZXNfb3B0aW9uID0gdHJ1ZTsKKwogICAvKiBIYW5kbGUgb3BlcmFuZHMg YWZ0ZXIgYW55ICItLSIgYXJndW1lbnQuICAqLwogICBmb3IgKDsgb3B0aW5kIDwgYXJnYzsgb3B0 aW5kKyspCiAgICAgewo= 23100 2004-01-03 13:59 0000 tar-1.13.92.ebuild.diff tar-1.13.92.ebuild.diff text/plain LS0tIC91c3IvcG9ydGFnZS9hcHAtYXJjaC90YXIvdGFyLTEuMTMuOTIuZWJ1aWxkCTIwMDMtMTIt MjkgMDU6MDI6MjYuMDAwMDAwMDAwICswMTAwCisrKyAvdXNyL2xvY2FsL3BvcnRhZ2UvYXBwLWFy Y2gvdGFyL3Rhci0xLjEzLjkyLmVidWlsZAkyMDA0LTAxLTAzIDIyOjU1OjIxLjY4MjE0NDM2MCAr MDEwMApAQCAtMjYsNiArMjYsOCBAQAogCSMgRml4IGNvbmZpZ3VyZSBzY3JpcHRzIHRvIHN1cHBv cnQgbGludXgtbWlwcyB0YXJnZXRzCiAJZ251Y29uZmlnX3VwZGF0ZQogCisJZXBhdGNoICR7RklM RVNESVJ9LyR7UFZ9LWhhcmRjb2RlLWFic29sdXRlLW5hbWVzLXRvLW9uLmRpZmYKKwogCWVjb25m IFwKIAkJLS1iaW5kaXI9L2JpbiBcCiAJCS0tbGliZXhlY2Rpcj0vdXNyL2xpYi9taXNjIFwK 23245 2004-01-06 10:58 0000 tar-1.13.92-fix-pathstrip.patch tar-1.13.92-fix-pathstrip.patch text/plain LS0tIHRhci0xLjEzLjkyL3NyYy9uYW1lcy5jLm9yaWcJMjAwNC0wMS0wNiAyMDo0NTo1NC4zMDYx MjAyMDAgKzAyMDAKKysrIHRhci0xLjEzLjkyL3NyYy9uYW1lcy5jCTIwMDQtMDEtMDYgMjA6NDY6 MDcuNjQxMDkyOTc2ICswMjAwCkBAIC0xMDI1LDggKzEwMjUsMTAgQEAKIAkgICAgewogCSAgICAg IGlmIChwWzFdID09ICcuJyAmJiAoSVNTTEFTSCAocFsyXSkgfHwgIXBbMl0pKQogCQlwcmVmaXhf bGVuID0gcCArIDIgLSBmaWxlX25hbWU7CisjaWYgMAogCSAgICAgIGVsc2UgaWYgKElTU0xBU0gg KHBbMV0pKQogCQlwcmVmaXhfbGVuID0gcCArIDEgLSBmaWxlX25hbWU7CisjZW5kaWYKIAkgICAg fQogCSAgCiAJICBkbwo=