[arch-dev-public] [signoff] openssl-0.9.8g
Hi, I just uploaded a new release of openssl to testing. It fixes some security issues (see changelog below). So please sign-off. In addition to this I had to rebuilt ntp and fix its depends to openssl. Last but not least according to the changelog openssl does not provide any root-certs anymore. If there are any apps which rely on those, we should think about providing a separate root-certs package. Pierre Changes between 0.9.8g and 0.9.8h [28 May 2008] *) Fix flaw if 'Server Key exchange message' is omitted from a TLS handshake which could lead to a cilent crash as found using the Codenomicon TLS test suite (CVE-2008-1672) [Steve Henson, Mark Cox] *) Fix double free in TLS server name extensions which could lead to a remote crash found by Codenomicon TLS test suite (CVE-2008-0891) [Joe Orton] *) Clear error queue in SSL_CTX_use_certificate_chain_file() Clear the error queue to ensure that error entries left from older function calls do not interfere with the correct operation. [Lutz Jaenicke, Erik de Castro Lopo] *) Remove root CA certificates of commercial CAs: The OpenSSL project does not recommend any specific CA and does not have any policy with respect to including or excluding any CA. Therefore it does not make any sense to ship an arbitrary selection of root CA certificates with the OpenSSL software. [Lutz Jaenicke] *) RSA OAEP patches to fix two separate invalid memory reads. The first one involves inputs when 'lzero' is greater than 'SHA_DIGEST_LENGTH' (it would read about SHA_DIGEST_LENGTH bytes before the beginning of from). The second one involves inputs where the 'db' section contains nothing but zeroes (there is a one-byte invalid read after the end of 'db'). [Ivan Nestlerode <inestlerode@us.ibm.com>] *) Partial backport from 0.9.9-dev: Introduce bn_mul_mont (dedicated Montgomery multiplication procedure) as a candidate for BIGNUM assembler implementation. While 0.9.9-dev uses assembler for various architectures, only x86_64 is available by default here in the 0.9.8 branch, and 32-bit x86 is available through a compile-time setting. To try the 32-bit x86 assembler implementation, use Configure option "enable-montasm" (which exists only for this backport). As "enable-montasm" for 32-bit x86 disclaims code stability anyway, in this constellation we activate additional code backported from 0.9.9-dev for further performance improvements, namely BN_from_montgomery_word. (To enable this otherwise, e.g. x86_64, try "-DMONT_FROM_WORD___NON_DEFAULT_0_9_8_BUILD".) [Andy Polyakov (backport partially by Bodo Moeller)] *) Add TLS session ticket callback. This allows an application to set TLS ticket cipher and HMAC keys rather than relying on hardcoded fixed values. This is useful for key rollover for example where several key sets may exist with different names. [Steve Henson] *) Reverse ENGINE-internal logic for caching default ENGINE handles. This was broken until now in 0.9.8 releases, such that the only way a registered ENGINE could be used (assuming it initialises successfully on the host) was to explicitly set it as the default for the relevant algorithms. This is in contradiction with 0.9.7 behaviour and the documentation. With this fix, when an ENGINE is registered into a given algorithm's table of implementations, the 'uptodate' flag is reset so that auto-discovery will be used next time a new context for that algorithm attempts to select an implementation. [Ian Lister (tweaked by Geoff Thorpe)] *) Backport of CMS code to OpenSSL 0.9.8. This differs from the 0.9.9 implemention in the following ways: Lack of EVP_PKEY_ASN1_METHOD means algorithm parameters have to be hard coded. Lack of BER streaming support means one pass streaming processing is only supported if data is detached: setting the streaming flag is ignored for embedded content. CMS support is disabled by default and must be explicitly enabled with the enable-cms configuration option. [Steve Henson] *) Update the GMP engine glue to do direct copies between BIGNUM and mpz_t when openssl and GMP use the same limb size. Otherwise the existing "conversion via a text string export" trick is still used. [Paul Sheer <paulsheer@gmail.com>] *) Zlib compression BIO. This is a filter BIO which compressed and uncompresses any data passed through it. [Steve Henson] *) Add AES_wrap_key() and AES_unwrap_key() functions to implement RFC3394 compatible AES key wrapping. [Steve Henson] *) Add utility functions to handle ASN1 structures. ASN1_STRING_set0(): sets string data without copying. X509_ALGOR_set0() and X509_ALGOR_get0(): set and retrieve X509_ALGOR (AlgorithmIdentifier) data. Attribute function X509at_get0_data_by_OBJ(): retrieves data from an X509_ATTRIBUTE structure optionally checking it occurs only once. ASN1_TYPE_set1(): set and ASN1_TYPE structure copying supplied data. [Steve Henson] *) Fix BN flag handling in RSA_eay_mod_exp() and BN_MONT_CTX_set() to get the expected BN_FLG_CONSTTIME behavior. [Bodo Moeller (Google)] *) Netware support: - fixed wrong usage of ioctlsocket() when build for LIBC BSD sockets - fixed do_tests.pl to run the test suite with CLIB builds too (CLIB_OPT) - added some more tests to do_tests.pl - fixed RunningProcess usage so that it works with newer LIBC NDKs too - removed usage of BN_LLONG for CLIB builds to avoid runtime dependency - added new Configure targets netware-clib-bsdsock, netware-clib-gcc, netware-clib-bsdsock-gcc, netware-libc-bsdsock-gcc - various changes to netware.pl to enable gcc-cross builds on Win32 platform - changed crypto/bio/b_sock.c to work with macro functions (CLIB BSD) - various changes to fix missing prototype warnings - fixed x86nasm.pl to create correct asm files for NASM COFF output - added AES, WHIRLPOOL and CPUID assembler code to build files - added missing AES assembler make rules to mk1mf.pl - fixed order of includes in apps/ocsp.c so that e_os.h settings apply [Guenter Knauf <eflash@gmx.net>] *) Implement certificate status request TLS extension defined in RFC3546. A client can set the appropriate parameters and receive the encoded OCSP response via a callback. A server can query the supplied parameters and set the encoded OCSP response in the callback. Add simplified examples to s_client and s_server. [Steve Henson] -- archlinux.de
2008/5/28 Pierre Schmitz <pierre@archlinux.de>:
Hi,
I just uploaded a new release of openssl to testing. It fixes some security issues (see changelog below). So please sign-off.
In addition to this I had to rebuilt ntp and fix its depends to openssl.
Last but not least according to the changelog openssl does not provide any root-certs anymore. If there are any apps which rely on those, we should think about providing a separate root-certs package.
This reminds me a feature request about providing more root certificates in a separate package (more than in previous openssl package). -- Roman Kyrylych (Роман Кирилич)
On Wed, May 28, 2008 at 10:31:33PM +0300, Roman Kyrylych wrote:
This reminds me a feature request about providing more root certificates in a separate package (more than in previous openssl package).
You mean http://bugs.archlinux.org/task/7912 ? Discussion seems to focus on creating a seperate certificate package rather than including the certificates in openssl. Greg
2008/5/28 Grigorios Bouzakis <grbzks@gmail.com>:
On Wed, May 28, 2008 at 10:31:33PM +0300, Roman Kyrylych wrote:
This reminds me a feature request about providing more root certificates in a separate package (more than in previous openssl package).
You mean http://bugs.archlinux.org/task/7912 ?
Yep.
Discussion seems to focus on creating a seperate certificate package rather than including the certificates in openssl.
-- Roman Kyrylych (Роман Кирилич)
Am Mittwoch 28 Mai 2008 21:31:33 schrieb Roman Kyrylych:
This reminds me a feature request about providing more root certificates in a separate package (more than in previous openssl package).
I have just put such a package (ca-certificates) into testing. It includes all the certs Debian trusts, which should not be that bad. :-) They provide an update-script and the possibility to enable/disable some certs. Please give it a tr and tell me what you think. I plan to move it into extra and make it an optional package. Pierre -- archlinux.de
On Sun, Jun 1, 2008 at 7:13 PM, Pierre Schmitz <pierre@archlinux.de> wrote:
Am Mittwoch 28 Mai 2008 21:31:33 schrieb Roman Kyrylych:
This reminds me a feature request about providing more root certificates in a separate package (more than in previous openssl package).
I have just put such a package (ca-certificates) into testing. It includes all the certs Debian trusts, which should not be that bad. :-)
They provide an update-script and the possibility to enable/disable some certs.
Please give it a tr and tell me what you think. I plan to move it into extra and make it an optional package.
Nice work, thanks. It seemed to work here for msmtp certificate checks on a quick test. Is this maybe even core/support material? -Dan
Am Montag 02 Juni 2008 02:43:19 schrieb Dan McGee:
Is this maybe even core/support material?
I am still undecided how to handle this. We have several options: 1) Make ca-certificates a depend of openssl. This will restore the behaviour before the openssl project removed their own certs. Those packages using their own bundle (like curl) should be update to use this one instead. 2) Add this package as a dependency to browser and other appy which use openssl 3) Don't do anything and put it as an optional package into extra As I said I have no strong oppinion about this. Maybe option 1 would be the best because it does not change the current behaviour too much and browsers wouldn't complain about untrusted certs when the new openssl package is moved to core. Pierre -- archlinux.de
On Tue, 2008-06-03 at 22:09 +0200, Pierre Schmitz wrote:
Am Montag 02 Juni 2008 02:43:19 schrieb Dan McGee:
Is this maybe even core/support material?
I am still undecided how to handle this. We have several options:
1) Make ca-certificates a depend of openssl. This will restore the behaviour before the openssl project removed their own certs. Those packages using their own bundle (like curl) should be update to use this one instead. 2) Add this package as a dependency to browser and other appy which use openssl 3) Don't do anything and put it as an optional package into extra
As I said I have no strong oppinion about this. Maybe option 1 would be the best because it does not change the current behaviour too much and browsers wouldn't complain about untrusted certs when the new openssl package is moved to core.
Option 1 looks good to me. Note that browsers usually have their internal ca certificates included. Mozilla products store them in the nss library, kdelibs contains its own ca-bundle.crt in /opt/kde/share/apps/kssl/. Option 2 is required for anything that installs its own ca-bundle. Examples of these are curl, kdelibs, java-gcj-compat and nss. The last two of these require hooks in /etc/ca-certificates/update.d/ to regenerate their certificate database on any change/update to ca-certificates.
On Mon, 2008-06-02 at 02:13 +0200, Pierre Schmitz wrote:
Am Mittwoch 28 Mai 2008 21:31:33 schrieb Roman Kyrylych:
This reminds me a feature request about providing more root certificates in a separate package (more than in previous openssl package).
I have just put such a package (ca-certificates) into testing. It includes all the certs Debian trusts, which should not be that bad. :-)
They provide an update-script and the possibility to enable/disable some certs.
Please give it a tr and tell me what you think. I plan to move it into extra and make it an optional package.
Nice. I'll update java-gcj-compat to use these soon. At this moment the java-gcj-compat certificate db is created from a large certificate file we have in SVN. Does the ca-certificates update thing contain any support for hooks so the java-gcj-compat certdb can be rebuilt on update?
Am Montag 02 Juni 2008 08:53:21 schrieb Jan de Groot:
Nice. I'll update java-gcj-compat to use these soon. At this moment the java-gcj-compat certificate db is created from a large certificate file we have in SVN. Does the ca-certificates update thing contain any support for hooks so the java-gcj-compat certdb can be rebuilt on update?
Funny, that you ask for hooks. I removed that from the script because it uses run-parts which is only available on Debian based systems. But if we need it, I could add a package for run-parts. In addition to this we could think about to adjust other packages to use this certificates, too. ATM some packages come with their own bundle. From the man page it would do the following: \fBupdate-ca-certificates\fP invokes \fBrun-parts\fP on /etc/ca-certificates/update.d and calls each hook with a list of certificates: those added are prefixed with a +, those removed are prefixed with a -. -- archlinux.de
Am Montag 02 Juni 2008 09:03:38 schrieb Pierre Schmitz:
I could add a package for run-parts.
And done. This was the easiest and imho cleanest way to do it. I also added a man page for update-ca-certificates. And now I know what those hooks are good for. :-) -- archlinux.de
On Wednesday 28 May 2008 19:21:14 Pierre Schmitz wrote:
So please sign-off.
anyone? -- archlinux.de
On Sat, 31 May 2008, Pierre Schmitz wrote:
On Wednesday 28 May 2008 19:21:14 Pierre Schmitz wrote:
So please sign-off.
anyone?
The man pages are installed in /usr/man Apart from that I haven't noticed any problems. Fix the man pages and I'll signoff. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.
Am Samstag 31 Mai 2008 22:26:39 schrieb Eric Belanger:
The man pages are installed in /usr/man
fixed in openssl-0.9.8h-2 -- archlinux.de
On Sat, 31 May 2008, Pierre Schmitz wrote:
Am Samstag 31 Mai 2008 22:26:39 schrieb Eric Belanger:
The man pages are installed in /usr/man
fixed in openssl-0.9.8h-2
looks good. Signoff both arches. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.
participants (6)
-
Dan McGee
-
Eric Belanger
-
Grigorios Bouzakis
-
Jan de Groot
-
Pierre Schmitz
-
Roman Kyrylych