[PATCH] ec/ec_pmeth.c: fix unsigned char issue
From: Marcelo Cerri mhce...@linux.vnet.ibm.com
In some platforms, such as POWER, char is defined as unsigned. This
patch fix a problem when comparing a char to -1.
Signed-off-by: Marcelo Cerri mhce...@linux.vnet.ibm.com
---
crypto/ec/ec_pmeth.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/crypto/ec/ec_pmeth.c b/crypto/ec/ec_pmeth.c
index e477418..933bf43 100644
--- a/crypto/ec/ec_pmeth.c
+++ b/crypto/ec/ec_pmeth.c
@@ -319,7 +319,7 @@ static int pkey_ec_ctrl(EVP_PKEY_CTX *ctx, int type, int
p1, void *p2)
case EVP_PKEY_CTRL_EC_ECDH_COFACTOR:
if (p1 == -2)
{
- if (dctx-cofactor_mode != -1)
+ if (dctx-cofactor_mode != ((char) -1))
return dctx-cofactor_mode;
else
{
--
1.8.4.rc3
__
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager majord...@openssl.org
[PATCH 1/4] ppc64: add little-endian platform to Configure
This patch includes a new platform for little-endian ppc64. It uses the
same flags as big-endian ppc64 but it differs in the endianess flag and
uses a specific `flavour` value that is passed to the assembly generator
perl scripts.
Signed-off-by: Marcelo Cerri mhce...@linux.vnet.ibm.com
---
Configure | 1 +
config| 5 +++--
2 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/Configure b/Configure
index 8d8cb51..f4855fd 100755
--- a/Configure
+++ b/Configure
@@ -365,6 +365,7 @@ my %table=(
linux-generic64,gcc:-DTERMIO -O3
-Wall::-D_REENTRANT::-ldl:SIXTY_FOUR_BIT_LONG RC4_CHAR RC4_CHUNK DES_INT
DES_UNROLL
BF_PTR:${no_asm}:dlfcn:linux-shared:-fPIC::.so.\$(SHLIB_MAJOR).\$(SHLIB_MINOR),
linux-ppc64, gcc:-m64 -DB_ENDIAN -DTERMIO -O3
-Wall::-D_REENTRANT::-ldl:SIXTY_FOUR_BIT_LONG RC4_CHAR RC4_CHUNK DES_RISC1
DES_UNROLL:${ppc64_asm}:linux64:dlfcn:linux-shared:-fPIC:-m64:.so.\$(SHLIB_MAJOR).\$(SHLIB_MINOR):::64,
+linux-ppc64le, gcc:-m64 -DL_ENDIAN -DTERMIO -O3
-Wall::-D_REENTRANT::-ldl:SIXTY_FOUR_BIT_LONG RC4_CHAR RC4_CHUNK DES_RISC1
DES_UNROLL:${ppc64_asm}:linux64le:dlfcn:linux-shared:-fPIC:-m64:.so.\$(SHLIB_MAJOR).\$(SHLIB_MINOR):::64,
linux-ia64, gcc:-DL_ENDIAN -DTERMIO -O3
-Wall::-D_REENTRANT::-ldl:SIXTY_FOUR_BIT_LONG RC4_CHUNK DES_UNROLL
DES_INT:${ia64_asm}:dlfcn:linux-shared:-fPIC::.so.\$(SHLIB_MAJOR).\$(SHLIB_MINOR),
linux-ia64-icc,icc:-DL_ENDIAN -DTERMIO -O2 -Wall::-D_REENTRANT::-ldl
-no_cpprt:SIXTY_FOUR_BIT_LONG RC4_CHUNK DES_RISC1
DES_INT:${ia64_asm}:dlfcn:linux-shared:-fPIC::.so.\$(SHLIB_MAJOR).\$(SHLIB_MINOR),
linux-x86_64,gcc:-m64 -DL_ENDIAN -DTERMIO -O3
-Wall::-D_REENTRANT::-ldl:SIXTY_FOUR_BIT_LONG RC4_CHUNK DES_INT
DES_UNROLL:${x86_64_asm}:elf:dlfcn:linux-shared:-fPIC:-m64:.so.\$(SHLIB_MAJOR).\$(SHLIB_MINOR):::64,
diff --git a/config b/config
index b432f62..9b56d9f 100755
--- a/config
+++ b/config
@@ -586,10 +586,11 @@ case $GUESSOS in
esac
fi
;;
- ppc64-*-linux2)
+ ppc64*-linux2)
if [ -z $KERNEL_BITS ]; then
echo WARNING! If you wish to build 64-bit library, then you have
to
- echo invoke './Configure linux-ppc64' *manually*.
+ echo invoke './Configure linux-ppc64' or
+ echo './Configure linux-ppc64le' *manually*.
if [ $TEST = false -a -t 1 ]; then
echo You have about 5 seconds to press Ctrl-C to
abort.
(trap stty `stty -g` 2 0; stty -icanon min 0 time 50; read
waste) 1
--
1.7.12
__
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager majord...@openssl.org
[openssl.org #3154] [PATCH] Document argument-handling of SSL_CTX_add_extra_chain_cert
See on-list discussion starting with 20131029180341.ga31...@openssl.org --- doc/ssl/SSL_CTX_add_extra_chain_cert.pod | 4 1 file changed, 4 insertions(+) diff --git a/doc/ssl/SSL_CTX_add_extra_chain_cert.pod b/doc/ssl/SSL_CTX_add_extra_chain_cert.pod index 11b3b4b..7782623 100644 --- a/doc/ssl/SSL_CTX_add_extra_chain_cert.pod +++ b/doc/ssl/SSL_CTX_add_extra_chain_cert.pod @@ -24,6 +24,10 @@ the library will try to complete the chain from the available CA certificates in the trusted CA storage, see LSSL_CTX_load_verify_locations(3)|SSL_CTX_load_verify_locations(3). +Callers should avoid reuse or freeing of the object pointed to by x509 +after passing it to this function. It will be freed when ctx is +freed. + =head1 RESTRICTIONS Only one set of extra chain certificates can be specified per SSL_CTX -- 1.8.4.rc3 __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: Self-initialization of locking/threadid callbacks and auto-detection of features
On Oct 29 21:58, Andy Polyakov wrote: I feel like saying few words. One should recognize that by the time multi-threading support was taking shape there was a whole variety of threading implementations and callbacks were the only way to convey the specifics. Nowadays we're pretty much talking only about pthreads and Windows, and one can indeed argue why wouldn't OpenSSL simply default to either of the two when appropriate. While it's more than appropriate on Windows as it is, on pthreads-powered Unices it's not as obvious. [...] Ideally libcrypto should *detect* if *hosting* application is linked with libpthread and only *then* adjust accordingly. Is there way to detect if application is linked with libpthread at run-time? There is DSO_global_lookup. Please, before any change is made in terms of threading, let me point out that Cygwin is NOT Windows, even if it runs on Windows. Cygwin provides its own pthreads implementation which is always available, even without explicit linking against -lpthread. So, for Cygwin, please use pthreads, not Windows threading, otherwise applications linked against libcrypto might be broken in subtil ways. Thanks for considering, Corinna -- Corinna Vinschen Cygwin Maintainer Red Hat pgpKeAfpitjTD.pgp Description: PGP signature
Re: Self-initialization of locking/threadid callbacks and auto-detection of features
On Wed, Oct 30, 2013 at 11:15:27AM +0100, Corinna Vinschen wrote: Please, before any change is made in terms of threading, let me point out that Cygwin is NOT Windows, even if it runs on Windows. Cygwin provides its own pthreads implementation which is always available, even without explicit linking against -lpthread. So, for Cygwin, please use pthreads, not Windows threading, otherwise applications linked against libcrypto might be broken in subtil ways. Of course. But surely OpenSSL needs to be built separately (and differently) for native Windows and Cygwin. I.e., an OpenSSL DLL built against the Windows CRT can't be used from a Cygwin app. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: Self-initialization of locking/threadid callbacks and auto-detection of features
On Oct 30 11:39, Nico Williams wrote: On Wed, Oct 30, 2013 at 11:15:27AM +0100, Corinna Vinschen wrote: Please, before any change is made in terms of threading, let me point out that Cygwin is NOT Windows, even if it runs on Windows. Cygwin provides its own pthreads implementation which is always available, even without explicit linking against -lpthread. So, for Cygwin, please use pthreads, not Windows threading, otherwise applications linked against libcrypto might be broken in subtil ways. Of course. But surely OpenSSL needs to be built separately (and differently) for native Windows and Cygwin. I.e., an OpenSSL DLL built against the Windows CRT can't be used from a Cygwin app. Right. I'm just trying to raise awareness before Cygwin gets sorted into the runs on Windows so use Windows functions drawer, accidentally, as happened too often in the past in various projects. Corinna -- Corinna Vinschen Cygwin Maintainer Red Hat pgpV35LME50WJ.pgp Description: PGP signature
SSL_VERIFY_NONE not working
Hi, I want the client side don't try to verify the server certificate. The verify_mode in SSL_ctx_st is set to SSL_VERIFY_NONE. But connection always terminated after calling x509_verify_cert(). Do you know what happens? The doc says this mode set in client side will disable verification of server certificate. Is there any where else should be set too? Regards Jason
Re: Self-initialization of locking/threadid callbacks and auto-detection of features
On Wed, Oct 30, 2013 at 06:12:08PM +0100, Corinna Vinschen wrote: Right. I'm just trying to raise awareness before Cygwin gets sorted into the runs on Windows so use Windows functions drawer, accidentally, as happened too often in the past in various projects. I won't. I'll basically be adding new targets for every existing target that has a standard (POSIX or Win32) threading library. I probably won't change what target ./config picks -- I think core OpenSSL developers must make that decision. Nico -- __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: Self-initialization of locking/threadid callbacks and auto-detection of features
On Tue, Oct 29, 2013 at 09:58:25PM +0100, Andy Polyakov wrote: Another thing: run-time selection from among multiple pthreads implementations can only safely be managed by the RTLD, and dependencies on pthreads must still be declared via the linker-editor. Libraries should be able to refer to pthread_* symbols and still use the run-time-selected pthread implementation *even* if the library was linked with -lpthread (and therefore a specific libpthread.so compilation symlink). If an OS delivers two (or more) pthreads implementations then: - if the ABIs of those pthreads implementations all match then the RTLD should be able to substitute any of them regardless of which libpthread any one object in the process was linked with; (e.g., via LD_PRELOAD, different library search paths, ..., but all the libpthreads would have to have the same SONAMEs and symbol version numbers) - but if their ABIs are not compatible then no run-time substitution is safe, no matter what the mechanism. (unless compatibility shims are involved, but then we *really* must leave it all to the RTLD and we can't be using dlsym() or weak symbols) I don't think libraries should be failing to declare their dependencies and then use dlsym(RTLD_DEFAULT) and dlopen()+dlsym() as a way to run-time link-edit-load their undeclared dependencies. Doing so is fundamentally racy and so would have to be done in .init sections, and results (which pthread gets used) would be unpredictable (since that would depend on object load and .init firing order). Plus we'd lose observability via ldd(1). I can't see any way to justify this without having examples of OSes where this is the documented way to handle dynamic linking against libpthread. But maybe I'm missing something? Nico -- __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Enhancing eng_cryptodev.c
The cryptodev engine is working great for me, but eng_cryptodev.c does not make available many of the ciphers that the cryptodev module (linux-cryptodev) uses. Mainly, I'd like to add AES in ECB, CTR, and GCM modes. I'm attaching a patch, for review purposes only, just to see if I'm on the right track and/or missing something. I'll submit a proper patch once I've added the rest of the ciphers. However, initial testing seems like everything is in order. I've pasted output of AES-128-ECB with this patch running on BeagleBone Black (TI AM335x using linux-cryptodev). Does anybody see any issues with my approach? Josh debian@arm:~/debian-packages$ time openssl speed -evp aes-128-ecb -engine cryptodev engine cryptodev set. Doing aes-128-ecb for 3s on 16 size blocks: 10749 aes-128-ecb's in 0.01s Doing aes-128-ecb for 3s on 64 size blocks: 21660 aes-128-ecb's in 0.02s Doing aes-128-ecb for 3s on 256 size blocks: 8 aes-128-ecb's in 0.01s Doing aes-128-ecb for 3s on 1024 size blocks: 8 aes-128-ecb's in 0.00s Doing aes-128-ecb for 3s on 8192 size blocks: 8 aes-128-ecb's in 0.01s OpenSSL 1.0.1e 11 Feb 2013 built on: Mon Oct 28 00:28:43 UTC 2013 options:bn(64,32) rc4(ptr,char) des(idx,cisc,16,long) aes(partial) idea(int) blowfish(ptr) compiler: gcc -fPIC -DOPENSSL_PIC -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -DHAVE_CRYPTODEV -DUSE_CRYPTDEV_DIGESTS -march=armv7-a -Wa,--noexecstack -DTERMIO -O3 -Wall -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DAES_ASM -DGHASH_ASM The 'numbers' are in 1000s of bytes per second processed. type 16 bytes 64 bytes256 bytes 1024 bytes 8192 bytes aes-128-ecb 17198.40k69312.00k 204.80k infk 6553.60k real 0m15.698s user 0m0.057s sys 0m2.746s cryptodev.patch Description: Binary data
Re: Self-initialization of locking/threadid callbacks and auto-detection of features
It's getting closer, see: https://github.com/nicowilliams/openssl/compare/thread_safety I spoke to a Linux expert and was told that the correct thing to do in the shared build of OpenSSL is to always link with -lpthread. I assert that this is also the correct thing to do on Solaris. It's been so for a long time now. I.e., OpenSSL should default to using native threads on all POSIX-like and Win32/64 systems (others will have to contribute similar support for other environments). My patches nonetheless will allow apps to provide alternate threading callbacks, just as today, except that the callbacks now may not be changed once set, and they are set to native implementations where possible if they are needed before they are set. Nico -- __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
