[arch-dev-public] [signoff] bzip2 1.0.5-1

older
[arch-dev-public] [signoff] lvm2...

Tom K

14 Apr 2008 14 Apr '08

11:04 p.m.

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.

Show replies by date

Dan McGee

14 Apr 14 Apr

11:43 p.m.

On Mon, Apr 14, 2008 at 4:04 PM, Tom K 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

dpmcgee＠gmail.com

15 Apr 15 Apr

1:59 a.m.

On 4/14/08, Dan McGee wrote:

...

On Mon, Apr 14, 2008 at 4:04 PM, Tom K 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

Aaron Griffin

6:48 p.m.

On Mon, Apr 14, 2008 at 6:59 PM, wrote:

...

On 4/14/08, Dan McGee wrote:

...
On Mon, Apr 14, 2008 at 4:04 PM, Tom K 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?

Dan McGee

8:09 p.m.

On Tue, Apr 15, 2008 at 11:48 AM, Aaron Griffin wrote:

...

On Mon, Apr 14, 2008 at 6:59 PM, wrote:

...
On 4/14/08, Dan McGee wrote:

...
On Mon, Apr 14, 2008 at 4:04 PM, Tom K 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: ./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 $ 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

Tom K

16 Apr 16 Apr

12:54 a.m.

Dan McGee wrote:

...

gnupg: ./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 $ 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.

Aaron Griffin

12:57 a.m.

On Tue, Apr 15, 2008 at 5:54 PM, Tom K 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!

Dan McGee

1:58 a.m.

On Tue, Apr 15, 2008 at 5:54 PM, Tom K wrote:

...

Dan McGee wrote:

...
gnupg: ./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 $ 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

5865

Age (days ago)

5866

Last active (days ago)

List overview

Download

7 comments

4 participants

participants (4)

Aaron Griffin
Dan McGee
dpmcgee＠gmail.com
Tom K