macro expanding error
Hi all, I'm compiling openssl-0.9.8p on Windows and find a strange thing in crypto/err/err_all.c , for example , the original declaration in crypto/store/store.h(line 390) is ... X509_NAME *STORE_ATTR_INFO_get0_dn(STORE_ATTR_INFO *attrs, STORE_ATTR_TYPES code); .. after preprocessing of crypto/err/err_all.c it becomes this : ... ((LPCSTR) 7) *STORE_ATTR_INFO_get0_dn(STORE_ATTR_INFO *attrs, STORE_ATTR_TYPES code); ... compiler complain this as C2059 , could someone help me with this , many thanks ! __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl.org #2765] openssl negotiates ECC ciphersuites in SSL 3.0
On Sun, Mar 18, 2012 at 12:49:35AM +0100, Kurt Roeckx via RT wrote: > I can confirm that removing the "no-ssl2" part gets me a TLS > instead of SSLv3 connection. The problem seems to be this code in s_client.c: #if !defined(OPENSSL_NO_SSL2) && !defined(OPENSSL_NO_SSL3) meth=SSLv23_client_method(); #elif !defined(OPENSSL_NO_SSL3) meth=SSLv3_client_method(); #elif !defined(OPENSSL_NO_SSL2) meth=SSLv2_client_method(); #endif SSLv23_client_method still exist when OPENSSL_NO_SSL2 is defined. There is no reason to use SSLv3_client_method() there. Using SSLv23_client_method when build using no-ssl2 does seem to work as expected. Kurt __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl.org #2765] openssl negotiates ECC ciphersuites in SSL 3.0
On Sun, Mar 18, 2012 at 12:20:48AM +0100, Kurt Roeckx via RT wrote: > On Sat, Mar 17, 2012 at 09:13:51PM +0100, Nikos Mavrogiannopoulos via RT > wrote: > > On 03/17/2012 09:03 PM, Stephen Henson via RT wrote: > > > > >> [n...@gnutls.org - Sat Mar 17 16:08:24 2012]: > > >> > > >> > > >> I captured the handshake (attached), and it seems the client > > >> advertises TLS 1.2. Could it be that the fallback is on the lowest > > >> supported version rather than the next available? > > >> > > > > > > That's strange. I tried OpenSSL 1.0.0h server (which supports up to > > > TLS 1.0) against OpenSSL 1.0.1 client (which also supports TLS 1.1 > > > and 1.2) and it ends up negotiating TLS v1.0 which is what I'd > > > expect. I'll see what that handshake capture reveals. > > > > > > Indeed interesting. I downloaded 1.0.0h from source I saw the behavior > > you describe. The issue is triggered on the version 1.0.0h as > > distributed by debian. > > The only think I can think of why it would behave different is > that we configured it with no-ssl2. > > The full options we call Configure with is: > no-idea no-mdc2 no-rc5 zlib enable-tlsext no-ssl2 I can confirm that removing the "no-ssl2" part gets me a TLS instead of SSLv3 connection. Kurt __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl.org #2282] AutoReply: [PATCH] Add PVK to usage of rsa and dsa commands
ping? this should be trivial. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl.org #2765] openssl negotiates ECC ciphersuites in SSL 3.0
On Sat, Mar 17, 2012 at 09:13:51PM +0100, Nikos Mavrogiannopoulos via RT wrote: > On 03/17/2012 09:03 PM, Stephen Henson via RT wrote: > > >> [n...@gnutls.org - Sat Mar 17 16:08:24 2012]: > >> > >> > >> I captured the handshake (attached), and it seems the client > >> advertises TLS 1.2. Could it be that the fallback is on the lowest > >> supported version rather than the next available? > >> > > > > That's strange. I tried OpenSSL 1.0.0h server (which supports up to > > TLS 1.0) against OpenSSL 1.0.1 client (which also supports TLS 1.1 > > and 1.2) and it ends up negotiating TLS v1.0 which is what I'd > > expect. I'll see what that handshake capture reveals. > > > Indeed interesting. I downloaded 1.0.0h from source I saw the behavior > you describe. The issue is triggered on the version 1.0.0h as > distributed by debian. The only think I can think of why it would behave different is that we configured it with no-ssl2. The full options we call Configure with is: no-idea no-mdc2 no-rc5 zlib enable-tlsext no-ssl2 I think the zlib option might also cause some behaviour changes. Kurt __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: FINGERPRINT_premain not called?
Understood. I asked in part because I want to minimize the number/scope of modifications so that the change letter validation is viable and straightforward; and, I asked out of curiosity. Kevin On Sat, Mar 17, 2012 at 12:26 PM, Andy Polyakov wrote: >> Is incore part of the validation, or is it like fipsld - allowed to be >> modified as needed without invalidating FIPS certification? > > It shouldn't void certification, no. But why is it concern for you? You > have to aim for change letter and therefore there is window for > including even this modification. > __ > OpenSSL Project http://www.openssl.org > Development Mailing List openssl-dev@openssl.org > Automated List Manager majord...@openssl.org __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl.org #2765] openssl negotiates ECC ciphersuites in SSL 3.0
On 03/17/2012 09:03 PM, Stephen Henson via RT wrote: >> [n...@gnutls.org - Sat Mar 17 16:08:24 2012]: >> >> >> I captured the handshake (attached), and it seems the client >> advertises TLS 1.2. Could it be that the fallback is on the lowest >> supported version rather than the next available? >> > > That's strange. I tried OpenSSL 1.0.0h server (which supports up to > TLS 1.0) against OpenSSL 1.0.1 client (which also supports TLS 1.1 > and 1.2) and it ends up negotiating TLS v1.0 which is what I'd > expect. I'll see what that handshake capture reveals. Indeed interesting. I downloaded 1.0.0h from source I saw the behavior you describe. The issue is triggered on the version 1.0.0h as distributed by debian. regards, Nikos __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
[openssl.org #2765] openssl negotiates ECC ciphersuites in SSL 3.0
> [n...@gnutls.org - Sat Mar 17 16:08:24 2012]: > > > I captured the handshake (attached), and it seems the client advertises > TLS 1.2. Could it be that the fallback is on the lowest supported > version rather than the next available? > That's strange. I tried OpenSSL 1.0.0h server (which supports up to TLS 1.0) against OpenSSL 1.0.1 client (which also supports TLS 1.1 and 1.2) and it ends up negotiating TLS v1.0 which is what I'd expect. I'll see what that handshake capture reveals. 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 #2765] openssl negotiates ECC ciphersuites in SSL 3.0
On 03/17/2012 03:53 PM, Stephen Henson via RT wrote: > The EC codes does need a bit of revising, that is one of its many quirks. > I'm trying to work out though how that client ends up producing that > condition. The only way I can think s_server with those command line > options could end up using SSL v3.0 is if the client sent a v3.0 client > hello. That would mean that it was sending a list of supported ciphers > including some it wasn't willing to support... not something you'd > expect to see in practice. I captured the handshake (attached), and it seems the client advertises TLS 1.2. Could it be that the fallback is on the lowest supported version rather than the next available? regards, Nikos handshake.cap Description: application/vnd.tcpdump.pcap
Re: [openssl.org #2764] modexp512-x86_64.pl generates incomplete file
On Sat, Mar 17, 2012 at 05:21:47PM +0100, Andy Polyakov via RT wrote:
> > modexp512-x86_64.s ends here:
> > | #
> > | # X2 = Xh * M2 + Xl
> > | # do first part (X2 = Xh * M2)
> > | addq$80,%rdi# rdi -> pXh ; 128 bits, 2 qwords
> > | #Xh is actually { [rdi+8*1], rbp }
> > | addq$64,%rsi# rsi -> M2
> > | leaq296(%rsp),%rcx# rcx -> pX2 ; 641 bits, 11 qwords
>
> I can't reproduce this, i.e. I can't confirm that modexp512-x86_64.s
> comes out truncated.
>
> > When generating the file perl also throws this error:
> > Can't locate object method "size" via package "expr" at
> > ./crypto/bn/asm/../../perlasm/x86_64-xlate.pl line 831, <> line 436.
>
> "expr" does not have "size" method and shouldn't have... Double-check
> that your copy of modexp512-x86_64.pl and x86_64-xlate.pl are pristine.
Ok,
So the problem is that I had this patch:
--- openssl-1.0.1.orig/crypto/perlasm/x86_64-xlate.pl
+++ openssl-1.0.1/crypto/perlasm/x86_64-xlate.pl
@@ -786,7 +786,7 @@
chomp($line);
-$line =~ s|[#!].*$||; # get rid of asm-style comments...
+#$line =~ s|[#!].*$||; # get rid of asm-style comments...
$line =~ s|/\*.*\*/||; # ... and C-style comments...
$line =~ s|^\s+||; # ... and skip white spaces in beginning
If I remember right, this was needed to be able to use preprocessor
commands in the .S files. (The file was also renamed from .s to
.S)
But I don't need that anymore, so I removed that patch, and you
can close this.
Kurt
__
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager majord...@openssl.org
Re: [openssl.org #2764] modexp512-x86_64.pl generates incomplete file
On Sat, Mar 17, 2012 at 05:21:47PM +0100, Andy Polyakov via RT wrote:
> > modexp512-x86_64.s ends here:
> > | #
> > | # X2 = Xh * M2 + Xl
> > | # do first part (X2 = Xh * M2)
> > | addq$80,%rdi# rdi -> pXh ; 128 bits, 2 qwords
> > | #Xh is actually { [rdi+8*1], rbp }
> > | addq$64,%rsi# rsi -> M2
> > | leaq296(%rsp),%rcx# rcx -> pX2 ; 641 bits, 11 qwords
>
> I can't reproduce this, i.e. I can't confirm that modexp512-x86_64.s
> comes out truncated.
>
> > When generating the file perl also throws this error:
> > Can't locate object method "size" via package "expr" at
> > ./crypto/bn/asm/../../perlasm/x86_64-xlate.pl line 831, <> line 436.
>
> "expr" does not have "size" method and shouldn't have... Double-check
> that your copy of modexp512-x86_64.pl and x86_64-xlate.pl are pristine.
Ok,
So the problem is that I had this patch:
--- openssl-1.0.1.orig/crypto/perlasm/x86_64-xlate.pl
+++ openssl-1.0.1/crypto/perlasm/x86_64-xlate.pl
@@ -786,7 +786,7 @@
chomp($line);
-$line =~ s|[#!].*$||; # get rid of asm-style comments...
+#$line =~ s|[#!].*$||; # get rid of asm-style comments...
$line =~ s|/\*.*\*/||; # ... and C-style comments...
$line =~ s|^\s+||; # ... and skip white spaces in beginning
If I remember right, this was needed to be able to use preprocessor
commands in the .S files. (The file was also renamed from .s to
.S)
But I don't need that anymore, so I removed that patch, and you
can close this.
Kurt
__
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager majord...@openssl.org
Re: [openssl.org #2765] openssl negotiates ECC ciphersuites in SSL 3.0
On Sat, Mar 17, 2012 at 3:53 PM, Stephen Henson via RT wrote: > > My reading of RFC4492 is that the ECC ciphersuites apply only to TLS > > 1.0 or later. According to it: "This document describes additions to TLS > > to support ECC, applicable both to TLS Version 1.0 [2] and to TLS > > Version 1.1 [3]. In particular, it defines...". > Well, SSL 3.0 was never passed as an IETF spefication, so if SSL 3.0 is the common protocol version, everything's an ad hoc interpretation of the RFCs (or, worse, you're really following draft-freier-ssl-version3-01.txt by the letter). SSL 3.0 behavior is just out of the scope of the RFCs; there's not good reason not to use the ECC ciphersuites in SSL 3.0 (apart from the various good reasons to entirely avoid SSL 3.0). > $ ./gnutls-cli localhost -p 5556 --x509cafile > ../doc/credentials/x509/ca.pem -d 99 > ... > |<3>| HSK[0x1d0bdc0]: Server's version: 3.0 Does this indicate that the server was actually configured to to only support SSL 3.0, not TLS? Bodo
Re: FINGERPRINT_premain not called?
> Is incore part of the validation, or is it like fipsld - allowed to be > modified as needed without invalidating FIPS certification? It shouldn't void certification, no. But why is it concern for you? You have to aim for change letter and therefore there is window for including even this modification. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl.org #2764] modexp512-x86_64.pl generates incomplete file
> modexp512-x86_64.s ends here:
> | #
> | # X2 = Xh * M2 + Xl
> | # do first part (X2 = Xh * M2)
> | addq$80,%rdi# rdi -> pXh ; 128 bits, 2 qwords
> | #Xh is actually { [rdi+8*1], rbp }
> | addq$64,%rsi# rsi -> M2
> | leaq296(%rsp),%rcx# rcx -> pX2 ; 641 bits, 11 qwords
I can't reproduce this, i.e. I can't confirm that modexp512-x86_64.s
comes out truncated.
> When generating the file perl also throws this error:
> Can't locate object method "size" via package "expr" at
> ./crypto/bn/asm/../../perlasm/x86_64-xlate.pl line 831, <> line 436.
"expr" does not have "size" method and shouldn't have... Double-check
that your copy of modexp512-x86_64.pl and x86_64-xlate.pl are pristine.
__
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager majord...@openssl.org
Re: [openssl.org #2762] OpenSSL 1.0.1 bug report
> Building with darwin-x86_64-cc. > > Error is: > > paes-x86_64.s:203:32-bit absolute addressing is not supported for x86-64 Sounds like bug in assembler, as it's not absolute address there. What does 'as -v' print on your system? I can't reproduce the problem with "Apple Inc version cctools-822, GNU assembler version 1.38". > I have attached my diff which fixes it. "Crocodile should be beheaded!" "Isn't it too harsh? Maybe cutting the tail is sufficient to teach him lesson?" "All right! Tail it is, but up to the neck!" Verify http://cvs.openssl.org/chngview?cn=22279. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl.org #2765] openssl negotiates ECC ciphersuites in SSL 3.0
On 03/17/2012 03:53 PM, Stephen Henson via RT wrote: > The EC codes does need a bit of revising, that is one of its many quirks. > I'm trying to work out though how that client ends up producing that > condition. The only way I can think s_server with those command line > options could end up using SSL v3.0 is if the client sent a v3.0 client > hello. That would mean that it was sending a list of supported ciphers > including some it wasn't willing to support... not something you'd > expect to see in practice. I captured the handshake (attached), and it seems the client advertises TLS 1.2. Could it be that the fallback is on the lowest supported version rather than the next available? regards, Nikos handshake.cap Description: application/vnd.tcpdump.pcap
[openssl.org #2760] possible bug report: DSA_verify() doesn't correctly account for len
The documentation doesn't reflect current behaviour. The "type" parameter to DSA_sign and DSA_verify is currently ignored, it should arguably check the length is consistent with the passed digest type. The actual algorithm implementation is OK though. The supplied digest will be truncated if it exceeds the size of the q parameter as mentioned in FIPS 186-3 for example. 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 #2763] Possible bug - TLS 1.2 compliance
> [fol...@cisco.com - Sat Mar 17 14:55:45 2012]: > > Using "openssl s_server" as the application with libcrypto 1.0.1, it > appears the TLS 1.2 behavior may not be compliant with RFC 5246. Page > 49 of RFC 5246 states: > > If the client provided a "signature_algorithms" extension, then all >certificates provided by the server MUST be signed by a >hash/signature algorithm pair that appears in that extension. > > Using the certificate attached to this email, which is signed using > RSA/SHA-512, s_server continues to establish the TLS session even though > the client has not offered RSA/SHA-512 in the ClientHello signature > algorithms extension. Maybe I'm misinterpreting the specification, but > shouldn't the sever fail this handshake since the client has indicated > it doesn't support RSA/SHA-512? > > Yes OpenSSL currently doesn't obey that restriction in common with many other implementations. There has been a discussion about this in the tls mailing lists. This will be fixed at some point but full support requires some non-trivial revision of certificate handling. Currently OpenSSL supports one chain per EE key type and fully supporting that would potentially need support for many different chains for each key type. Very few existing applications would support that (possibly none...). 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 #2765] openssl negotiates ECC ciphersuites in SSL 3.0
> [n...@gnutls.org - Sat Mar 17 14:57:31 2012]: > > Hello, > My reading of RFC4492 is that the ECC ciphersuites apply only to TLS > 1.0 or later. According to it: "This document describes additions to TLS > to support ECC, applicable both to TLS Version 1.0 [2] and to TLS > Version 1.1 [3]. In particular, it defines...". > > So it seems that SSL 3.0 shouldn't be negotiated with these > ciphersuites. However it seems that openssl s_server negotiates > ECC ciphersuites even under SSL 3.0. > > For example: > $ openssl version > OpenSSL 1.0.0h 12 Mar 2012 > > $ openssl s_server -cert x509/cert-rsa.pem -key x509/key-rsa.pem -port 5556 > Using default temp DH parameters > Using default temp ECDH parameters > ACCEPT > > $ ./gnutls-cli localhost -p 5556 --x509cafile > ../doc/credentials/x509/ca.pem -d 99 > ... > |<3>| HSK[0x1d0bdc0]: Server's version: 3.0 > ... > |<2>| unsupported cipher suite C0.13 > ... > *** Handshake has failed > GnuTLS error: Could not negotiate a supported cipher suite. > > So it seems that gnutls rejected the connection because the ciphersuite > isn't valid for this TLS version. > > [*] The credentials are just an RSA CA certificate and an RSA server > certificate. > The EC codes does need a bit of revising, that is one of its many quirks. I'm trying to work out though how that client ends up producing that condition. The only way I can think s_server with those command line options could end up using SSL v3.0 is if the client sent a v3.0 client hello. That would mean that it was sending a list of supported ciphers including some it wasn't willing to support... not something you'd expect to see in practice. 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 #2765] openssl negotiates ECC ciphersuites in SSL 3.0
Hello, My reading of RFC4492 is that the ECC ciphersuites apply only to TLS 1.0 or later. According to it: "This document describes additions to TLS to support ECC, applicable both to TLS Version 1.0 [2] and to TLS Version 1.1 [3]. In particular, it defines...". So it seems that SSL 3.0 shouldn't be negotiated with these ciphersuites. However it seems that openssl s_server negotiates ECC ciphersuites even under SSL 3.0. For example: $ openssl version OpenSSL 1.0.0h 12 Mar 2012 $ openssl s_server -cert x509/cert-rsa.pem -key x509/key-rsa.pem -port 5556 Using default temp DH parameters Using default temp ECDH parameters ACCEPT $ ./gnutls-cli localhost -p 5556 --x509cafile ../doc/credentials/x509/ca.pem -d 99 ... |<3>| HSK[0x1d0bdc0]: Server's version: 3.0 ... |<2>| unsupported cipher suite C0.13 ... *** Handshake has failed GnuTLS error: Could not negotiate a supported cipher suite. So it seems that gnutls rejected the connection because the ciphersuite isn't valid for this TLS version. [*] The credentials are just an RSA CA certificate and an RSA server certificate. regards, Nikos __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
[openssl.org #2764] modexp512-x86_64.pl generates incomplete file
Hi,
modexp512-x86_64.s ends here:
| #
| # X2 = Xh * M2 + Xl
| # do first part (X2 = Xh * M2)
| addq$80,%rdi# rdi -> pXh ; 128 bits, 2 qwords
| #Xh is actually { [rdi+8*1], rbp }
| addq$64,%rsi# rsi -> M2
| leaq296(%rsp),%rcx# rcx -> pX2 ; 641 bits, 11 qwords
When generating the file perl also throws this error:
Can't locate object method "size" via package "expr" at
./crypto/bn/asm/../../perlasm/x86_64-xlate.pl line 831, <> line 436.
With warnings on I get this instead:
"my" variable $pDst masks earlier declaration in same scope at
./crypto/bn/asm/modexp512-x86_64.pl line 627.
"my" variable $pDst_o masks earlier declaration in same scope at
./crypto/bn/asm/modexp512-x86_64.pl line 627.
"my" variable $pDst masks earlier declaration in same scope at
./crypto/bn/asm/modexp512-x86_64.pl line 711.
"my" variable $pDst_o masks earlier declaration in same scope at
./crypto/bn/asm/modexp512-x86_64.pl line 711.
Use of uninitialized value $flavour in pattern match (m//) at
./crypto/bn/asm/modexp512-x86_64.pl line 62.
Use of uninitialized value $flavour in pattern match (m//) at
./crypto/bn/asm/modexp512-x86_64.pl line 64.
Use of uninitialized value $output in pattern match (m//) at
./crypto/bn/asm/modexp512-x86_64.pl line 64.
Use of uninitialized value $flavour in concatenation (.) or string at
./crypto/bn/asm/modexp512-x86_64.pl line 71.
Use of uninitialized value $output in concatenation (.) or string at
./crypto/bn/asm/modexp512-x86_64.pl line 71.
Can't locate object method "size" via package "expr" at
./crypto/bn/asm/../../perlasm/x86_64-xlate.pl line 831, <> line 436.
Kurt
__
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager majord...@openssl.org
[openssl.org #2762] OpenSSL 1.0.1 bug report
Building with darwin-x86_64-cc. Error is: paes-x86_64.s:203:32-bit absolute addressing is not supported for x86-64 I have attached my diff which fixes it. Please let me know if you need further information. Regards, Jeremiah Rothschild Systems Administrator Franz Inc. diff -r -u openssl-1.0.1.stock/Configure openssl-1.0.1.working/Configure --- openssl-1.0.1.stock/Configure 2012-03-03 05:18:06.0 -0800 +++ openssl-1.0.1.working/Configure 2012-03-15 16:12:55.0 -0700 @@ -128,7 +128,7 @@ my $x86_elf_asm="$x86_asm:elf"; -my $x86_64_asm="x86_64cpuid.o:x86_64-gcc.o x86_64-mont.o x86_64-mont5.o x86_64-gf2m.o modexp512-x86_64.o::aes-x86_64.o vpaes-x86_64.o bsaes-x86_64.o aesni-x86_64.o aesni-sha1-x86_64.o::md5-x86_64.o:sha1-x86_64.o sha256-x86_64.o sha512-x86_64.o::rc4-x86_64.o rc4-md5-x86_64.o:::wp-x86_64.o:cmll-x86_64.o cmll_misc.o:ghash-x86_64.o:"; +my $x86_64_asm="x86_64cpuid.o:x86_64-gcc.o x86_64-mont.o x86_64-mont5.o x86_64-gf2m.o modexp512-x86_64.o::aes-x86_64.o bsaes-x86_64.o aesni-x86_64.o aesni-sha1-x86_64.o::md5-x86_64.o:sha1-x86_64.o sha256-x86_64.o sha512-x86_64.o::rc4-x86_64.o rc4-md5-x86_64.o:::wp-x86_64.o:cmll-x86_64.o cmll_misc.o:ghash-x86_64.o:"; my $ia64_asm="ia64cpuid.o:bn-ia64.o ia64-mont.o::aes_core.o aes_cbc.o aes-ia64.o::md5-ia64.o:sha1-ia64.o sha256-ia64.o sha512-ia64.o::rc4-ia64.o rc4_skey.o:ghash-ia64.o::void"; my $sparcv9_asm="sparcv9cap.o sparccpuid.o:bn-sparcv9.o sparcv9-mont.o sparcv9a-mont.o:des_enc-sparc.o fcrypt_b.o:aes_core.o aes_cbc.o aes-sparcv9.o:::sha1-sparcv9.o sha256-sparcv9.o sha512-sparcv9.o:::ghash-sparcv9.o::void"; my $sparcv8_asm=":sparcv8.o:des_enc-sparc.o fcrypt_b.o:void"; diff -r -u openssl-1.0.1.stock/crypto/evp/e_aes.c openssl-1.0.1.working/crypto/evp/e_aes.c --- openssl-1.0.1.stock/crypto/evp/e_aes.c 2011-11-15 04:19:56.0 -0800 +++ openssl-1.0.1.working/crypto/evp/e_aes.c2012-03-15 16:16:05.0 -0700 @@ -166,7 +166,7 @@ #define VPAES_CAPABLE (OPENSSL_ia32cap_P[1]&(1<<(41-32))) #endif #ifdef BSAES_ASM -#define BSAES_CAPABLE VPAES_CAPABLE +#define BSAES_CAPABLE (OPENSSL_ia32cap_P[1]&(1<<(41-32))) #endif /* * AES-NI section
