Re: [openssl.org #3165] tru64-alpha-cc compatibility fixes

2013-11-11 Thread Daniel Richard G. via RT
On Sun, 2013 Nov 10 23:01+0100, Andy Polyakov via RT wrote:

 If 'perl | cc -E -  a.s' was used, then consequent 'cc -c a.s' was
 observing truncated file, as if buffer was not flushed in time.

Ah, strange. Maybe a bug in their early implementation of support for
preprocessing stdin.

(I think it should work if it used a temporary file instead of a
pipe/stdin...)

 :-( indeed, worked for me. It's sometimes disadvantageous to
 have newest gear, huh? Changing .FRame to .frame should work, please
 verify that there are no other problems.

Old systems make for good corner cases! New systems just try to be like
Linux+GCC.

Yes, s/.FRame/.frame/ on the generated .s file allows it to assemble
correctly, and the full test suite then passes without error nor
Unaligned access messages.

(This is with git d0f1d924 plus my patch.)


--Daniel


-- 
Daniel Richard G. || sk...@iskunk.org
My ASCII-art .sig got a bad case of Times New Roman.


__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org


Re: [openssl.org #3165] tru64-alpha-cc compatibility fixes

2013-11-11 Thread Daniel Richard G.
On Sun, 2013 Nov 10 23:01+0100, Andy Polyakov via RT wrote:

 If 'perl | cc -E -  a.s' was used, then consequent 'cc -c a.s' was
 observing truncated file, as if buffer was not flushed in time.

Ah, strange. Maybe a bug in their early implementation of support for
preprocessing stdin.

(I think it should work if it used a temporary file instead of a
pipe/stdin...)

 :-( indeed, worked for me. It's sometimes disadvantageous to
 have newest gear, huh? Changing .FRame to .frame should work, please
 verify that there are no other problems.

Old systems make for good corner cases! New systems just try to be like
Linux+GCC.

Yes, s/.FRame/.frame/ on the generated .s file allows it to assemble
correctly, and the full test suite then passes without error nor
Unaligned access messages.

(This is with git d0f1d924 plus my patch.)


--Daniel


-- 
Daniel Richard G. || sk...@iskunk.org
My ASCII-art .sig got a bad case of Times New Roman.
__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org


[openssl.org #3169] [PATCH] Additional chain_cert functions for 1.0.2-dev

2013-11-11 Thread Rob Stradling via RT
This patch, which currently applies successfully against master and 
1_0_2, adds the following functions:

SSL_[CTX_]select_current_cert() - set the current certificate without 
disturbing the existing structure.

SSL_[CTX_]get0_chain_certs() - get the current certificate's chain.

SSL_[CTX_]clear_chain_certs() - clear the current certificate's chain.

The patch also adds these functions to, and fixes some existing errors 
in, SSL_CTX_add1_chain_cert.pod.

-- 
Rob Stradling
Senior Research  Development Scientist
COMODO - Creating Trust Online


diff --git a/doc/ssl/SSL_CTX_add1_chain_cert.pod b/doc/ssl/SSL_CTX_add1_chain_cert.pod
index 04f7526..2d2161a 100644
--- a/doc/ssl/SSL_CTX_add1_chain_cert.pod
+++ b/doc/ssl/SSL_CTX_add1_chain_cert.pod
@@ -3,9 +3,11 @@
 =head1 NAME
 
 SSL_CTX_set0_chain, SSL_CTX_set1_chain, SSL_CTX_add0_chain_cert,
-SSL_CTX_add1_chain_cert, SSL_set0_chain, SSL_set1_chain,
-SSL_add0_chain_cert, SSL_add1_chain_cert, SSL_CTX_build_cert_chain,
-SSL_build_cert_chain - extra chain certificate processing
+SSL_CTX_add1_chain_cert, SSL_CTX_get0_chain_certs, SSL_CTX_clear_chain_certs,
+SSL_set0_chain, SSL_set1_chain, SSL_add0_chain_cert, SSL_add1_chain_cert,
+SSL_get0_chain_certs, SSL_clear_chain_certs, SSL_CTX_build_cert_chain,
+SSL_build_cert_chain, SSL_CTX_select_current_cert,
+SSL_select_current_cert - extra chain certificate processing
 
 =head1 SYNOPSIS
 
@@ -13,36 +15,58 @@ SSL_build_cert_chain - extra chain certificate processing
 
  int SSL_CTX_set0_chain(SSL_CTX *ctx, STACK_OF(X509) *sk);
  int SSL_CTX_set1_chain(SSL_CTX *ctx, STACK_OF(X509) *sk);
- int SSL_CTX_add0_chain_cert(SSL_CTX *ctx, STACK_OF(X509) *x509);
+ int SSL_CTX_add0_chain_cert(SSL_CTX *ctx, X509 *x509);
  int SSL_CTX_add1_chain_cert(SSL_CTX *ctx, X509 *x509);
+ int SSL_CTX_get0_chain_certs(SSL_CTX *ctx, STACK_OF(X509) **sk);
+ int SSL_CTX_clear_chain_certs(SSL_CTX *ctx);
 
  int SSL_set0_chain(SSL *ssl, STACK_OF(X509) *sk);
  int SSL_set1_chain(SSL *ssl, STACK_OF(X509) *sk);
- int SSL_add0_chain_cert(SSL *ssl, STACK_OF(X509) *x509);
+ int SSL_add0_chain_cert(SSL *ssl, X509 *x509);
  int SSL_add1_chain_cert(SSL *ssl, X509 *x509);
+ int SSL_get0_chain_certs(SSL *ssl, STACK_OF(X509) **sk);
+ int SSL_clear_chain_certs(SSL *ssl);
 
  int SSL_CTX_build_cert_chain(SSL_CTX *ctx, flags);
- int SSL_build_cert_chain(SSL_CTX *ctx, flags);
+ int SSL_build_cert_chain(SSL *ssl, flags);
+
+ int SSL_CTX_select_current_cert(SSL_CTX *ctx, X509 *x509);
+ int SSL_select_current_cert(SSL *ssl, X509 *x509);
 
 =head1 DESCRIPTION
 
 SSL_CTX_set0_chain() and SSL_CTX_set1_chain() set the certificate chain
-associated with the current certificate of Bctx to Bsk. If Bsk is set
-to BNULL any existing chain is cleared.
+associated with the current certificate of Bctx to Bsk.
 
 SSL_CTX_add0_chain_cert() and SSL_CTX_add1_chain_cert() append the single
 certificate Bx509 to the chain associated with the current certificate of
 Bctx.
 
+SSL_CTX_get0_chain_certs() retrieves the chain associated with the current
+certificate of Bctx.
+
+SSL_CTX_clear_chain_certs() clears any existing chain associated with the
+current certificate of Bctx.  (This is implemented by calling
+SSL_CTX_set0_chain() with Bsk set to BNULL).
+
 SSL_CTX_build_cert_chain() builds the certificate chain for Bctx using the
 chain store. Any existing chain certificates are used as untrusted CAs.
 If the function is successful the built chain will replace any existing chain.
 The Bflags parameter can be set to BSSL_BUILD_CHAIN_FLAG_NO_ROOT to omit
 the root CA from the built chain.
 
-SSL_set0_chain(), SSL_set1_chain(), SSL_add0_chain_cert(), SSL_add0_chain_cert()
-and SSL_build_cert_chain() are similar except they apply to SSL structure
-Bssl.
+Each of these functions operates on the Icurrent end entity
+(i.e. server or client) certificate. This is the last certificate loaded or
+selected on the corresponding Bctx structure.
+
+SSL_CTX_select_current_cert() selects Bx509 as the current end entity
+certificate, but only if Bx509 has already been loaded into Bctx using a
+function such as SSL_CTX_use_certificate().
+
+SSL_set0_chain(), SSL_set1_chain(), SSL_add0_chain_cert(),
+SSL_add1_chain_cert(), SSL_get0_chain_certs(), SSL_clear_chain_certs(),
+SSL_build_cert_chain() and SSL_select_current_cert() are similar except they
+apply to SSL structure Bssl.
 
 All these functions are implemented as macros. Those containing a B1
 increment the reference count of the supplied certificate or chain so it must
@@ -56,10 +80,6 @@ The chains associate with an SSL_CTX structure are copied to any SSL
 structures when SSL_new() is called. SSL structures will not be affected
 by any chains subsequently changed in the parent SSL_CTX.
 
-Each of these functions operates on the Icurrent end entity
-(i.e. server or client) certificate. This is the last certificate set
-on the corresponding Bctx or Bssl structure.
-
 One chain can be set for each key type supported by a server. So, for example,
 an RSA 

PIC code on Sparc Solaris

2013-11-11 Thread Tom Kacvinsky
The short story is that I want to make static libraries of Open SSL so that
I can make Python modules (_ssl) that link against Open SSL statically,
thereby reducing the amount of run time dependencies we have.  But when I
link these libraries in statically, I get relocation errors form the linker
due to some of the code not being PIC.

I don't know if the development is the appropriate forum for this, but I
think it might since it has to do with how Open SSL builds on Solaris.

Here is my set up: gcc 4.7.4 with GNU assembler and Solaris linker (gcc was
configured with --with-gnu-as, but not with --with-gnu-ld).  I ran

./config --prefix=/home/tjk/openssl no-shared -fPIC

The configured build is for 32 bit Sparc Solaris running on a sparcv9
processor.

The C code compiles into PIC objects just fine, but the GNU assembler does
not produce PIC code for sparccpuid.S.  I worked around this by first
preprocessing the file using gcc:

gcc -I... -D... -E sparcpuid.S  sparcpuid.s

and then assembled it using

as -V -Qy -s -xarch=v8plusa -K PIC -xcode=pic32 sparcpuid.s

(I first ran gcc -v to see what gcc was going to pass to the assembler,
then took that output and modified it so that the right options would be
used for the Solaris assembler).  I found that the crucial option is
-xcode=pic32.

I do not really ant to do this as I plan on scripting builds of Open SSL
and this requires manual intervention.  Do you know of a way to get the GNU
assemble to produce PIC code?

Thanks,

Tom


Re: PIC code on Sparc Solaris

2013-11-11 Thread Tom Kacvinsky
It helps if I tell you I am using opnessl-1.0.1e



On Mon, Nov 11, 2013 at 1:06 PM, Tom Kacvinsky tom.kacvin...@vectorcast.com
 wrote:

 The short story is that I want to make static libraries of Open SSL so
 that I can make Python modules (_ssl) that link against Open SSL
 statically, thereby reducing the amount of run time dependencies we have.
 But when I link these libraries in statically, I get relocation errors form
 the linker due to some of the code not being PIC.

 I don't know if the development is the appropriate forum for this, but I
 think it might since it has to do with how Open SSL builds on Solaris.

 Here is my set up: gcc 4.7.4 with GNU assembler and Solaris linker (gcc
 was configured with --with-gnu-as, but not with --with-gnu-ld).  I ran

 ./config --prefix=/home/tjk/openssl no-shared -fPIC

 The configured build is for 32 bit Sparc Solaris running on a sparcv9
 processor.

 The C code compiles into PIC objects just fine, but the GNU assembler does
 not produce PIC code for sparccpuid.S.  I worked around this by first
 preprocessing the file using gcc:

 gcc -I... -D... -E sparcpuid.S  sparcpuid.s

 and then assembled it using

 as -V -Qy -s -xarch=v8plusa -K PIC -xcode=pic32 sparcpuid.s

 (I first ran gcc -v to see what gcc was going to pass to the assembler,
 then took that output and modified it so that the right options would be
 used for the Solaris assembler).  I found that the crucial option is
 -xcode=pic32.

 I do not really ant to do this as I plan on scripting builds of Open SSL
 and this requires manual intervention.  Do you know of a way to get the GNU
 assemble to produce PIC code?

 Thanks,

 Tom





openssl-1.0.2-stable-SNAP-20131111

2013-11-11 Thread The Doctor
This might have cropped into all the SSL snapshots.

/usr/bin/ranlib ../libssl.a || echo Never mind.
if [ -n libcrypto.so.1.0.0 libssl.so.1.0.0 ]; then  (cd ..; make 
libssl.so.1.0.0);  fi
[ -z  ] || gcc3 -fPIC -DOPENSSL_PIC -DZLIB_SHARED -DZLIB -DOPENSSL_THREADS 
-pthread -D_THREAD_SAFE -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -DKRB5_MIT 
-DPERL5 -DL_ENDIAN -DTERMIOS -fomit-frame-pointer -O2 -Wall -g 
-DOPENSSL_EXPERIMENTAL_DANE -DOPENSSL_EXPERIMENTAL_JPAKE 
-DOPENSSL_EXPERIMENTAL_STORE -DOPENSSL_BN_ASM_PART_WORDS -DOPENSSL_BN_ASM_MONT 
-DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM 
-DRMD160_ASM -DAES_ASM -DGHASH_ASM -Iinclude  -DFINGERPRINT_PREMAIN_DSO_LOAD -o 
fips_premain_dso   fips_premain.c fipscanister.o  libcrypto.a -lgmp -ldl -lm -lc
/bin/sh: 1: Syntax error: ( unexpected (expecting fi)
*** Error code 2

Stop.
*** Error code 1

Stop.
*** Error code 1

Stop.
*** Error code 1

Stop.
*** Error code 1

Stop.

openssl-1.0.2-stable-SNAP-20131110 did not have the above problem.

Please fix.

-- 
Member - Liberal International  This is doc...@nl2k.ab.ca Ici doc...@nl2k.ab.ca
God,Queen and country!Never Satan President Republic!Beware AntiChrist rising! 
http://www.fullyfollow.me/rootnl2k  Look at Psalms 14 and 53 on Atheism
23 Nov 2013 a Big day indeed
__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org


Re: [PATCH 0/4] ppc64 port to little-endian

2013-11-11 Thread Marcelo Cerri
On Fri, Nov 08, 2013 at 09:59:11PM +0100, Andy Polyakov wrote:
 Andy, do you think the changes in the config scripts can already be
 committed?
 
 Sure. Basically, explicit confirmation that everything works would
 have sufficed. Only one remaining thing. As for config patch, I
 don't quite understand. From what was discussed I've got impression
 that LE system can only execute LE binaries. But then why would
 config suggest to run ./Configure linux-ppc64le manually? Output for
 'uname -a' would suffice.

Hi Andy,

Everything works.

Regarding the config patch. I did the simplest change in order to
use -DL_ENDIAN instead of -DB_ENDIAN. Currently is there a way that
already is used in the config scripts to do that automatically?

Regards,
Marcelo Cerri
 

__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org


How to tweak openSSL vulnerabilities CVE-2013-0169

2013-11-11 Thread Alok Sharma
One of the openSSL vulnerabilities  is:

CVE-2013-0169:

  The TLS protocol 1.1 and 1.2 and the DTLS protocol 1.0 and 1.2, as used
in OpenSSL, , do not properly consider timing side-channel attacks on a MAC
check requirement during the processing of malformed CBC padding, which
allows remote attackers to conduct distinguishing attacks and
plaintext-recovery attacks via statistical analysis of timing data for
crafted packets, aka the Lucky Thirteen issue.

  All versions of OpenSSL are affected including 1.0.1c, 1.0.0j and 0.9.8x

  Affected users should upgrade to OpenSSL 1.0.1d, 1.0.0k or 0.9.8y



we use DTLS 1.0 protocol.

Does anyone know of any setting in openssl configuration that can be
tweaked to mitigate this vulnerability? E.g. a setting to not allow use of
algorithms with CBC etc.?

Regards,

Alok


Fwd: How to tweak openSSL vulnerabilities CVE-2013-0169

2013-11-11 Thread Alok Sharma
One of the openSSL vulnerabilities  is:

CVE-2013-0169:

  The TLS protocol 1.1 and 1.2 and the DTLS protocol 1.0 and 1.2, as used
in OpenSSL, , do not properly consider timing side-channel attacks on a MAC
check requirement during the processing of malformed CBC padding, which
allows remote attackers to conduct distinguishing attacks and
plaintext-recovery attacks via statistical analysis of timing data for
crafted packets, aka the Lucky Thirteen issue.

  All versions of OpenSSL are affected including 1.0.1c, 1.0.0j and 0.9.8x

  Affected users should upgrade to OpenSSL 1.0.1d, 1.0.0k or 0.9.8y



we use DTLS 1.0 protocol.

Does anyone know of any setting in openssl configuration that can be
tweaked to mitigate this vulnerability? E.g. a setting to not allow use of
algorithms with CBC etc.?

Regards,

Alok