Re: [PATCH] libssl: Hide library private symbols
On Fri, Jul 26, 2013 at 12:13:45PM +1000, Peter Waltenberg wrote: The compiler can't optimize if the symbols are called inter-module either. If it knows they're hidden, it can. And it clearly can optimize things if you mark them static so it knows they're not called inter-module. And seriously, do you REALLY think that any changes the compiler makes at that level will have measurable performance impacts ?. There are good reasons to hide parts of the API that you don't want used by external code - hiding symbols to improve performance is a big stretch. Even when just hiding it in the linker there is a difference. I can't seem to find the numbers anymore, so I can't say it's significant. But I would already be happy with just hiding it in the linker like I've been doing in Debian. It already resulted in people stopping using private symbols. Kurt __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
RE: [openssl.org #3073] [Patch] ALPN Implementation for OpenSSL
We believe our latest patch has addressed all feedback we have received so far. As far as we can tell this is ready for inclusion in the main trunk of the project. Naturally, if this is not the case and we still need to make changes we are happy to work with the community. Assuming no further changes are needed please let us know how we can ensure this gets applied to trunk - Parashuram __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
PEM_read_*_PrivateKey crashes under many threads and invalid key on Mac OSX and Cent 4.4
Hi, We're dealing with PEM_read_PrivateKey crashing intermittently when we use it in a multi-threaded environment. We have tried both PEM_read_PrivateKey and PEM_bio_read_PrivateKey. Two environments that are exhibiting the behavior are Mac OSX 10.7 and CentOs 4.4. Two environments that are NOT exhibiting the problem are Ubuntu 12.04 and CentOs 6.2. We compiled on CentOs 4.4 and moved the binary to CentOs 6.2 and the problem still happens. PEM_read_PrivateKey only crashes when we send it an invalid key. If the key is valid, it will not crash on these environments. We attached the source code we used to exhibit the problem here. Here are the libraries being linked in for the two different binaries: $ ldd ./crypto-broken linux-vdso.so.1 = (0x7fffcc461000) libpthread.so.0 = /lib64/libpthread.so.0 (0x0034e320) libc.so.6 = /lib64/libc.so.6 (0x0034e2e0) /lib64/ld-linux-x86-64.so.2 (0x0034e260) $ ldd ./crypto-works linux-vdso.so.1 = (0x7fff4d9df000) libpthread.so.0 = /lib64/libpthread.so.0 (0x0034e320) libcrypto.so.10 = /usr/lib64/libcrypto.so.10 (0x0034e4e0) libc.so.6 = /lib64/libc.so.6 (0x0034e2e0) /lib64/ld-linux-x86-64.so.2 (0x0034e260) libdl.so.2 = /lib64/libdl.so.2 (0x0034e2a0) libz.so.1 = /lib64/libz.so.1 (0x0034e3a0) On the Mac OSX 10.7 (doesn't work) dawilcox-MacBookPro1:we dawilcox$ otool -L crypto crypto: /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 169.3.0) /usr/lib/libcrypto.0.9.8.dylib (compatibility version 0.9.8, current version 47.0.0) Are we doing something off-hand wrong? Is there a place where we can file a bug? Thanks, David crypto_main.c Description: crypto_main.c
[openssl.org #3095] Incorrect result in HMAC functions when key is null
Hello, I've discovered a bug in OpenSSL HMAC handling -- when calling the HMAC() (http://www.openssl.org/docs/crypto/hmac.html) function, an incorrect result will be given if the `key` parameter is a NULL pointer, even when `key_len` is zero. Much easier to notice when you're not using null terminated strings/buffers. I would expect that the value of `key` would have no effect if `key_len` is 0 (CommonCrypto handles this fine). I have attached an example program demonstrating the problem. Please post the eventual bug tracker link on the mailing list if possible. Thanks, -- Jake Petroules Chief Technology Officer Petroules Corporation · www.petroules.com Email: jake.petrou...@petroules.com Hello,I've discovered a bug in OpenSSL HMAC handling -- when calling the HMAC()(http://www.openssl.org/docs/crypto/hmac.html) function, an incorrect result will be given if the `key` parameter is a NULL pointer, even when `key_len` is zero. Much easier to notice when you're not using null terminated strings/buffers. I would expect that the value of `key` would have no effect if `key_len` is 0 (CommonCrypto handles this fine). I have attached an example program demonstrating the problem.Please post the eventual bug tracker link on the mailing list if possible.Thanks, --Jake PetroulesChief Technology OfficerPetroules Corporation ·www.petroules.comEmail:jake.petrou...@petroules.com openssl-hmac-bug.c Description: Binary data
Re: PEM_read_*_PrivateKey crashes under many threads and invalid key on Mac OSX and Cent 4.4
On Thu, Jul 25, 2013, David Wilcox wrote: Hi, We're dealing with PEM_read_PrivateKey crashing intermittently when we use it in a multi-threaded environment. We have tried both PEM_read_PrivateKey and PEM_bio_read_PrivateKey. Two environments that are exhibiting the behavior are Mac OSX 10.7 and CentOs 4.4. Two environments that are NOT exhibiting the problem are Ubuntu 12.04 and CentOs 6.2. We compiled on CentOs 4.4 and moved the binary to CentOs 6.2 and the problem still happens. PEM_read_PrivateKey only crashes when we send it an invalid key. If the key is valid, it will not crash on these environments. We attached the source code we used to exhibit the problem here. Here are the libraries being linked in for the two different binaries: $ ldd ./crypto-broken linux-vdso.so.1 = (0x7fffcc461000) libpthread.so.0 = /lib64/libpthread.so.0 (0x0034e320) libc.so.6 = /lib64/libc.so.6 (0x0034e2e0) /lib64/ld-linux-x86-64.so.2 (0x0034e260) $ ldd ./crypto-works linux-vdso.so.1 = (0x7fff4d9df000) libpthread.so.0 = /lib64/libpthread.so.0 (0x0034e320) libcrypto.so.10 = /usr/lib64/libcrypto.so.10 (0x0034e4e0) libc.so.6 = /lib64/libc.so.6 (0x0034e2e0) /lib64/ld-linux-x86-64.so.2 (0x0034e260) libdl.so.2 = /lib64/libdl.so.2 (0x0034e2a0) libz.so.1 = /lib64/libz.so.1 (0x0034e3a0) On the Mac OSX 10.7 (doesn't work) dawilcox-MacBookPro1:we dawilcox$ otool -L crypto crypto: /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 169.3.0) /usr/lib/libcrypto.0.9.8.dylib (compatibility version 0.9.8, current version 47.0.0) Are we doing something off-hand wrong? Is there a place where we can file a bug? Well when the key is invalid an error is placed on the error queue. For multiple threads the locking callbacks must be set up correctly or it will cause problems. Did you set up the locking callbacks? Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
[openssl.org #3095] Incorrect result in HMAC functions when key is null
On Fri Jul 26 09:26:23 2013, jake.petrou...@petroules.com wrote: Hello, I've discovered a bug in OpenSSL HMAC handling -- when calling the HMAC() (http://www.openssl.org/docs/crypto/hmac.html) function, an incorrect result will be given if the `key` parameter is a NULL pointer, even when `key_len` is zero. Much easier to notice when you're not using null terminated strings/buffers. I would expect that the value of `key` would have no effect if `key_len` is 0 (CommonCrypto handles this fine). I have attached an example program demonstrating the problem. Passing NULL as the key has a special meaning to the OpenSSL APIs: it reuses the existing HMAC key for the context. If there is no HMAC key previously set the result is undefined. If you really want to use a zero length key set key_len to zero and key to non-NULL. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl.org #3095] Incorrect result in HMAC functions when key is null
After reviewing the documentation I see this behavior mentioned - easy to miss. However I'd argue that this behavior is wrong, given that there is no context to potentially re-use with the single shot function. Wouldn't it make more sense to simply treat a NULL pointer to key the same as passing a valid pointer, when key_len is 0, for the single-shot function? -- Jake Petroules Chief Technology Officer Petroules Corporation · www.petroules.com Email: jake.petrou...@petroules.com On Jul 26, 2013, at 8:46 AM, Stephen Henson via RT r...@openssl.org wrote: On Fri Jul 26 09:26:23 2013, jake.petrou...@petroules.com wrote: Hello, I've discovered a bug in OpenSSL HMAC handling -- when calling the HMAC() (http://www.openssl.org/docs/crypto/hmac.html) function, an incorrect result will be given if the `key` parameter is a NULL pointer, even when `key_len` is zero. Much easier to notice when you're not using null terminated strings/buffers. I would expect that the value of `key` would have no effect if `key_len` is 0 (CommonCrypto handles this fine). I have attached an example program demonstrating the problem. Passing NULL as the key has a special meaning to the OpenSSL APIs: it reuses the existing HMAC key for the context. If there is no HMAC key previously set the result is undefined. If you really want to use a zero length key set key_len to zero and key to non-NULL. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl.org #3095] Incorrect result in HMAC functions when key is null
After reviewing the documentation I see this behavior mentioned - easy to miss. However I'd argue that this behavior is wrong, given that there is no context to potentially re-use with the single shot function. Wouldn't it make more sense to simply treat a NULL pointer to key the same as passing a valid pointer, when key_len is 0, for the single-shot function? -- Jake Petroules Chief Technology Officer Petroules Corporation · www.petroules.com Email: jake.petrou...@petroules.com On Jul 26, 2013, at 8:46 AM, Stephen Henson via RT r...@openssl.org wrote: On Fri Jul 26 09:26:23 2013, jake.petrou...@petroules.com wrote: Hello, I've discovered a bug in OpenSSL HMAC handling -- when calling the HMAC() (http://www.openssl.org/docs/crypto/hmac.html) function, an incorrect result will be given if the `key` parameter is a NULL pointer, even when `key_len` is zero. Much easier to notice when you're not using null terminated strings/buffers. I would expect that the value of `key` would have no effect if `key_len` is 0 (CommonCrypto handles this fine). I have attached an example program demonstrating the problem. Passing NULL as the key has a special meaning to the OpenSSL APIs: it reuses the existing HMAC key for the context. If there is no HMAC key previously set the result is undefined. If you really want to use a zero length key set key_len to zero and key to non-NULL. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org
[openssl.org #3096] OpenSSL 1.0.1e: valgrind errors with -DPURIFY set
After upgrading from OpenSSL 1.0.0k to 1.0.1e (Linux, x86_64) we see valgrind errors of this kind although we always use -DPURIFY: ==11347== Conditional jump or move depends on uninitialised value(s) ==11347==at 0x5F5160: tls1_enc (t1_enc.c:832) ==11347==by 0x61AD11: ssl3_read_bytes (s3_pkt.c:402) ==11347==by 0x617A9F: ssl3_read (s3_lib.c:4207) ... Function tls1_enc() in file ssl/t1_enc.c has been changed from 1.0.0k to 1.0.1e, especially referenced line 832 is new. Maybe someone who knows the code (and the changes) immediately sees what valgrind is complaining about. Regards, Peter. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
