[arch-dev-public] [signoff] bzip2 1.0.5-1
Upstream vulnerability fix, our ref FS#10121, additional info here: https://www.cert.fi/haavoittuvuudet/joint-advisory-archive-formats.html Also, man path amended. In testing now for both arches. Thanks T.
On Mon, Apr 14, 2008 at 4:04 PM, Tom K <tom@archlinux.org> wrote:
Upstream vulnerability fix, our ref FS#10121, additional info here: https://www.cert.fi/haavoittuvuudet/joint-advisory-archive-formats.html Also, man path amended.
In testing now for both arches.
Looks good on i686. -Dan
On 4/14/08, Dan McGee <dpmcgee@gmail.com> wrote:
On Mon, Apr 14, 2008 at 4:04 PM, Tom K <tom@archlinux.org> wrote:
Upstream vulnerability fix, our ref FS#10121, additional info here: https://www.cert.fi/haavoittuvuudet/joint-advisory-archive-formats.html Also, man path amended.
In testing now for both arches.
Looks good on i686.
Maybe I spoke too soon. The program itself works fine, but linking against it is doing some really weird things. It seems that things are getting statically included now or something? I'm not completely sure what is going on, but my binaries for my pacman-git build went from 14K to 140K, and the strings output on the old vs. the new is showing a lot of BZ2 crud, which I've attached below (I sorted it so before/after would be as similar as possible). -Dan $ diff -u strings.old strings.new --- strings.old 2008-04-14 18:57:02.000000000 -0500 +++ strings.new 2008-04-14 18:57:29.000000000 -0500 @@ -1,3 +1,29 @@ + %d pointers, %d sorted, %d scanned + bucket sorting ... + depth %6d has + main sort initialise ... + qsort [0x%x, 0x%x] done %d this %d + reconstructing block ... + %d in block, %d after MTF & 1-2 coding, %d+2 syms in use + %d work, %d block, ratio %5.2f + bytes: mapping %d, + initial group %d, [%d .. %d], has %d syms (%4.1f%%) + pass %d: size is %d, grp uses are + [%d: huff+mtf + block %d: crc = 0x%08x, combined CRC = 0x%08x, size = %d + combined CRCs: stored = 0x%08x, computed = 0x%08x + final combined CRC = 0x%08x + too repetitive; using fallback sorting algorithm + (www.memtest86.com). At the time of writing it is free (GPLd). + Memtest86 tests memory much more thorougly than your BIOSs + Try a memory-test program. I have used Memtest86 + bzip2, and I would very much like to hear about it. Please + let me know, and, ideally, save a copy of the file causing the + points in compression, you may have a flaky memory system. + power-on test, and may find failures that the BIOS doesn't. + problem -- without which I will be unable to investigate it. + {0x%08x, 0x%08x} +%6d unresolved strings %s conflicts with %s %s/%s/depends %s/%s/desc @@ -6,18 +32,113 @@ %s: dependency file is missing %s: description file is missing %s: file list is missing +* If the error can be repeatably reproduced, this is a bug in +* If the error cannot be reproduced, and/or happens at different +*** A special note about internal error number 1007 *** /lib/ld-linux.so.2 /var/lib/pacman/ +1.0.5, 10-Dec-2007 +1G<1 +;GT| +<[^_] +<[^_] +BZ2_blockSort +BZ2_bsInitWrite +BZ2_bzBuffToBuffCompress +BZ2_bzBuffToBuffDecompress +BZ2_bzCompress +BZ2_bzCompressEnd +BZ2_bzCompressInit +BZ2_bzDecompress +BZ2_bzDecompressEnd +BZ2_bzDecompressInit +BZ2_bzRead +BZ2_bzReadClose +BZ2_bzReadGetUnused +BZ2_bzReadOpen +BZ2_bzWrite +BZ2_bzWriteClose +BZ2_bzWriteClose64 +BZ2_bzWriteOpen +BZ2_bz__AssertH__fail +BZ2_bzclose +BZ2_bzdopen +BZ2_bzerror +BZ2_bzflush +BZ2_bzlibVersion +BZ2_bzopen +BZ2_bzread +BZ2_bzwrite +BZ2_compressBlock +BZ2_crc32Table +BZ2_decompress +BZ2_hbAssignCodes +BZ2_hbCreateDecodeTables +BZ2_hbMakeCodeLengths +BZ2_indexIntoF +BZ2_rNums +CONFIG_ERROR +DATA_ERROR +DATA_ERROR_MAGIC +Experience suggests that a common cause of i.e. 1007 +FD;FH +FP;FL +FP;FL +FP;FL| +G 9E +G 9E +G 9E +G,u? +G8u$ +G8u$ +G8u' +G8u' +G8u' +G8u' +G<u' GLIBC_2.0 +GLIBC_2.1 +GLIBC_2.3 +I suggest the following: try compressing the file again, +IO_ERROR LIBSSP_1.0 -PTRh` -QVh0 +MEM_ERROR +ND;NH +NP;NL +O8iE +O8iE +O8iE +OUTBUFF_FULL +PARAM_ERROR +PTRh m +Please report it to me at: jseward@bzip.org. If this happened +QVh` +SEQUENCE_ERROR +This is a bug in bzip2/libbzip2, %s. +UNEXPECTED_EOF +US]CQ +VUUU +VUUU +W8iE +W8iE +W8iE WVSQ Y[^_] [^_] +[^_] +[^_] +[^_] +[^_] +[^_] +[^_] +[^_] +[^_] +[^_] +^(BM _IO_stdin_used _Jv_RegisterClasses __bss_start +__ctype_b_loc __errno_location __gmon_start__ __libc_start_main @@ -43,31 +164,60 @@ alpm_option_set_logcb alpm_release alpm_strerrorlast +bzip2/libbzip2: internal error number %d. cannot initialize alpm: %s +code lengths %d, +codes %d +component, you should also report this bug to the author(s) error : %s : %s error releasing alpm: %s error: error: could not register 'local' database (%s) exit +fclose +fdopen +ferror +fflush +fgetc +fopen64 +fputc +fread free +fwrite +is unreliable memory or other hardware. The 1007 assertion +just happens to cross-check the results of huge numbers of +kZ;& libacl.so.1 libalpm.so.2 libarchive.so.2 libattr.so.1 -libbz2.so.1.0 libc.so.6 libdownload.so libssp.so.0 libz.so.1 +malloc +memory reads/writes, and so acts (unintendedly) as a stress missing dependency for %s : %s +of that program. Please make an effort to report this bug; opendir +possibly monitoring progress in detail with the -vv flag. +quality software. Thanks. Julian Seward, 10 December 2007. readdir +rt+rld +selectors %d, snprintf stderr +stdin stdout +strcat strcmp strerror +strlen +test of your memory system. testdb +timely and accurate bug reports eventually lead to higher +ungetc usage: %s -b <pacman db> vfprintf warning: +when you were using some program which uses libbzip2 as a
On Mon, Apr 14, 2008 at 6:59 PM, <dpmcgee@gmail.com> wrote:
On 4/14/08, Dan McGee <dpmcgee@gmail.com> wrote:
On Mon, Apr 14, 2008 at 4:04 PM, Tom K <tom@archlinux.org> wrote:
Upstream vulnerability fix, our ref FS#10121, additional info here: https://www.cert.fi/haavoittuvuudet/joint-advisory-archive-formats.html Also, man path amended.
In testing now for both arches.
Looks good on i686.
Maybe I spoke too soon. The program itself works fine, but linking against it is doing some really weird things. It seems that things are getting statically included now or something? I'm not completely sure what is going on, but my binaries for my pacman-git build went from 14K to 140K, and the strings output on the old vs. the new is showing a lot of BZ2 crud, which I've attached below (I sorted it so before/after would be as similar as possible).
I don't see how this could relate, really, unless it has pkgconfig files that suddenly have "-static" added to the CFLAGS. As far as I'm aware, a library can't control how things link to it. Would you mind comparing to something else that makes use of bzip2?
On Tue, Apr 15, 2008 at 11:48 AM, Aaron Griffin <aaronmgriffin@gmail.com> wrote:
On Mon, Apr 14, 2008 at 6:59 PM, <dpmcgee@gmail.com> wrote:
On 4/14/08, Dan McGee <dpmcgee@gmail.com> wrote:
On Mon, Apr 14, 2008 at 4:04 PM, Tom K <tom@archlinux.org> wrote:
Upstream vulnerability fix, our ref FS#10121, additional info here: https://www.cert.fi/haavoittuvuudet/joint-advisory-archive-formats.html Also, man path amended.
In testing now for both arches.
Looks good on i686.
Maybe I spoke too soon. The program itself works fine, but linking against it is doing some really weird things. It seems that things are getting statically included now or something? I'm not completely sure what is going on, but my binaries for my pacman-git build went from 14K to 140K, and the strings output on the old vs. the new is showing a lot of BZ2 crud, which I've attached below (I sorted it so before/after would be as similar as possible).
I don't see how this could relate, really, unless it has pkgconfig files that suddenly have "-static" added to the CFLAGS. As far as I'm aware, a library can't control how things link to it.
Would you mind comparing to something else that makes use of bzip2?
I mean, what else do you want me to compare? WIthout touching CFLAGS, if i compile pacman from source with bzip2-1.0.4-3 installed, the binary is 156KB and does not have the BZ2 symbols in it. If I compile it from source with bzip2-1.0.5-1 installed, the binary is 290K and has BZ2 symbols included. Between steps I did a 'make clean all' - no reconfigure (but I have done a reconfigure and that does nothing either). gnupg: <bzip2 1.0.5-1 is installed here> ./configure --disable-keyserver-helpers --disable-card-support --disable-photo-viewers $ make $ ll g10/gpg -rwxr-xr-x 1 dmcgee users 2.3M 2008-04-15 13:02 g10/gpg $ strings g10/gpg | grep BZ2 BZ2_crc32Table BZ2_rNums $ ll tools/gpgsplit -rwxr-xr-x 1 dmcgee users 249K 2008-04-15 13:01 tools/gpgsplit $ strings tools/gpgsplit | grep BZ2 BZ2_crc32Table BZ2_rNums $ make clean <installed bzip2 1.0.4-3 here> $ make $ ll g10/gpg -rwxr-xr-x 1 dmcgee users 2.2M 2008-04-15 13:07 g10/gpg $ strings g10/gpg | grep BZ2 BZ2_bzCompressInit BZ2_bzDecompressEnd BZ2_bzDecompress BZ2_bzCompress BZ2_bzCompressEnd BZ2_bzDecompressInit $ ll tools/gpgsplit -rwxr-xr-x 1 dmcgee users 115K 2008-04-15 13:06 tools/gpgsplit $ strings tools/gpgsplit | grep BZ2 BZ2_bzDecompressEnd BZ2_bzDecompress BZ2_bzDecompressInit I didn't see how it could relate either, and I'm not using pkgconfig with pacman, I know that for sure. But something weird is going on here. -Dan
Dan McGee wrote:
gnupg: <bzip2 1.0.5-1 is installed here> ./configure --disable-keyserver-helpers --disable-card-support --disable-photo-viewers $ make $ ll g10/gpg -rwxr-xr-x 1 dmcgee users 2.3M 2008-04-15 13:02 g10/gpg $ strings g10/gpg | grep BZ2 BZ2_crc32Table BZ2_rNums $ ll tools/gpgsplit -rwxr-xr-x 1 dmcgee users 249K 2008-04-15 13:01 tools/gpgsplit $ strings tools/gpgsplit | grep BZ2 BZ2_crc32Table BZ2_rNums $ make clean <installed bzip2 1.0.4-3 here> $ make $ ll g10/gpg -rwxr-xr-x 1 dmcgee users 2.2M 2008-04-15 13:07 g10/gpg $ strings g10/gpg | grep BZ2 BZ2_bzCompressInit BZ2_bzDecompressEnd BZ2_bzDecompress BZ2_bzCompress BZ2_bzCompressEnd BZ2_bzDecompressInit $ ll tools/gpgsplit -rwxr-xr-x 1 dmcgee users 115K 2008-04-15 13:06 tools/gpgsplit $ strings tools/gpgsplit | grep BZ2 BZ2_bzDecompressEnd BZ2_bzDecompress BZ2_bzDecompressInit
I didn't see how it could relate either, and I'm not using pkgconfig with pacman, I know that for sure. But something weird is going on here.
-Dan
Found it. Our PKGBUILD links /lib/libbz2.so to /lib/libbz2.so.$pkgver, but the dev has not bumped the so number - I suppose because this release is only for the vuln fix in bzlib.c. So we're linking to nothing, which means building against bzip2 uses static. -2 on the way. T.
On Tue, Apr 15, 2008 at 5:54 PM, Tom K <tom@archlinux.org> wrote:
Found it. Our PKGBUILD links /lib/libbz2.so to /lib/libbz2.so.$pkgver, but the dev has not bumped the so number - I suppose because this release is only for the vuln fix in bzlib.c. So we're linking to nothing, which means building against bzip2 uses static.
Awesome, thanks a million!
On Tue, Apr 15, 2008 at 5:54 PM, Tom K <tom@archlinux.org> wrote:
Dan McGee wrote:
gnupg: <bzip2 1.0.5-1 is installed here> ./configure --disable-keyserver-helpers --disable-card-support --disable-photo-viewers $ make $ ll g10/gpg -rwxr-xr-x 1 dmcgee users 2.3M 2008-04-15 13:02 g10/gpg $ strings g10/gpg | grep BZ2 BZ2_crc32Table BZ2_rNums $ ll tools/gpgsplit -rwxr-xr-x 1 dmcgee users 249K 2008-04-15 13:01 tools/gpgsplit $ strings tools/gpgsplit | grep BZ2 BZ2_crc32Table BZ2_rNums $ make clean <installed bzip2 1.0.4-3 here> $ make $ ll g10/gpg -rwxr-xr-x 1 dmcgee users 2.2M 2008-04-15 13:07 g10/gpg $ strings g10/gpg | grep BZ2 BZ2_bzCompressInit BZ2_bzDecompressEnd BZ2_bzDecompress BZ2_bzCompress BZ2_bzCompressEnd BZ2_bzDecompressInit $ ll tools/gpgsplit -rwxr-xr-x 1 dmcgee users 115K 2008-04-15 13:06 tools/gpgsplit $ strings tools/gpgsplit | grep BZ2 BZ2_bzDecompressEnd BZ2_bzDecompress BZ2_bzDecompressInit
I didn't see how it could relate either, and I'm not using pkgconfig with pacman, I know that for sure. But something weird is going on here.
-Dan
Found it. Our PKGBUILD links /lib/libbz2.so to /lib/libbz2.so.$pkgver, but the dev has not bumped the so number - I suppose because this release is only for the vuln fix in bzlib.c. So we're linking to nothing, which means building against bzip2 uses static.
-2 on the way. T.
Thanks Tom- great find. I'll let you know how -2 works out. :) -Dan
participants (4)
-
Aaron Griffin
-
Dan McGee
-
dpmcgee＠gmail.com
-
Tom K