diff options
author | Lasse Collin <lasse.collin@tukaani.org> | 2016-03-13 20:21:49 +0200 |
---|---|---|
committer | Lasse Collin <lasse.collin@tukaani.org> | 2016-06-28 21:09:46 +0300 |
commit | 74f8dad9f912a2993768d93d108ea2b0b2c196e0 (patch) | |
tree | aac8ee8edb43e23c1f025bc9c8ce39bd312b5a7c /INSTALL | |
parent | Update THANKS. (diff) | |
download | xz-74f8dad9f912a2993768d93d108ea2b0b2c196e0.tar.xz |
liblzma: Disable external SHA-256 by default.
This is the sane thing to do. The conflict with OpenSSL
on some OSes and especially that the OS-provided versions
can be significantly slower makes it clear that it was
a mistake to have the external SHA-256 support enabled by
default.
Those who want it can now pass --enable-external-sha256 to
configure. INSTALL was updated with notes about OSes where
this can be a bad idea.
The SHA-256 detection code in configure.ac had some bugs that
could lead to a build failure in some situations. These were
fixed, although it doesn't matter that much now that the
external SHA-256 is disabled by default.
MINIX >= 3.2.0 uses NetBSD's libc and thus has SHA256_Init
in libc instead of libutil. Support for the libutil version
was removed.
Diffstat (limited to 'INSTALL')
-rw-r--r-- | INSTALL | 36 |
1 files changed, 36 insertions, 0 deletions
@@ -246,6 +246,42 @@ XZ Utils Installation the liblzma ABI, so this option should be used only when it is known to not cause problems. + --enable-external-sha256 + Try to use SHA-256 code from the operating system libc + or similar base system libraries. This doesn't try to + use OpenSSL or libgcrypt or such libraries. + + The reasons to use this option: + + - It makes liblzma slightly smaller. + + - It might improve SHA-256 speed if the implementation + in the operating is very good (but see below). + + External SHA-256 is disabled by default for two reasons: + + - On some operating systems the symbol names of the + SHA-256 functions conflict with OpenSSL's libcrypto. + This causes weird problems such as decompression + errors if an application is linked against both + liblzma and libcrypto. This problem affects at least + FreeBSD 10 and older and MINIX 3.3.0 and older, but + other OSes that provide a function "SHA256_Init" might + also be affected. FreeBSD 11 has the problem fixed. + NetBSD had the problem but it was fixed it in 2009 + already. OpenBSD uses "SHA256Init" and thus never had + a conflict with libcrypto. + + - The SHA-256 code in liblzma is faster than the SHA-256 + code provided by some operating systems. If you are + curious, build two copies of xz (internal and external + SHA-256) and compare the decompression (xz --test) + times: + + dd if=/dev/zero bs=1024k count=1024 \ + | xz -v -0 -Csha256 > foo.xz + time xz --test foo.xz + --disable-xz --disable-xzdec --disable-lzmadec |