[openssl-dev] Patch for iOS compilation failure on Xcode 9 / iOS 11 SDK

[Chris Ballinger via openssl-dev]

"-fomit-frame-pointer" is no longer allowed for armv7 targets, so I removed
it from the iphoneos-cross configure target. I noticed this
on openssl-1.0.2l.
--- Configure.orig  2017-05-25 05:54:38.0 -0700
+++ Configure   2017-09-29 12:09:45.0 -0700
@@ -652,7 +652,7 @@
 "debug-darwin64-x86_64-cc","cc:-arch x86_64 -ggdb -g2 -O0 -DL_ENDIAN 
-Wall::-D_REENTRANT:MACOSX:-Wl,-search_paths_first%:SIXTY_FOUR_BIT_LONG 
RC4_CHUNK DES_INT DES_UNROLL:".eval{my 
$asm=$x86_64_asm;$asm=~s/rc4\-[^:]+//;$asm}.":macosx:dlfcn:darwin-shared:-fPIC 
-fno-common:-arch x86_64 -dynamiclib:.\$(SHLIB_MAJOR).\$(SHLIB_MINOR).dylib",
 "debug-darwin-ppc-cc","cc:-DBN_DEBUG -DREF_CHECK -DCONF_DEBUG -DCRYPTO_MDEBUG 
-DB_ENDIAN -g -Wall -O::-D_REENTRANT:MACOSX::BN_LLONG RC4_CHAR RC4_CHUNK 
DES_UNROLL 
BF_PTR:${ppc32_asm}:osx32:dlfcn:darwin-shared:-fPIC:-dynamiclib:.\$(SHLIB_MAJOR).\$(SHLIB_MINOR).dylib",
 # iPhoneOS/iOS
-"iphoneos-cross","llvm-gcc:-O3 -isysroot \$(CROSS_TOP)/SDKs/\$(CROSS_SDK) 
-fomit-frame-pointer 
-fno-common::-D_REENTRANT:iOS:-Wl,-search_paths_first%:BN_LLONG RC4_CHAR 
RC4_CHUNK DES_UNROLL BF_PTR:${no_asm}:dlfcn:darwin-shared:-fPIC 
-fno-common:-dynamiclib:.\$(SHLIB_MAJOR).\$(SHLIB_MINOR).dylib",
+"iphoneos-cross","llvm-gcc:-O3 -isysroot \$(CROSS_TOP)/SDKs/\$(CROSS_SDK) 
-fno-common::-D_REENTRANT:iOS:-Wl,-search_paths_first%:BN_LLONG RC4_CHAR 
RC4_CHUNK DES_UNROLL BF_PTR:${no_asm}:dlfcn:darwin-shared:-fPIC 
-fno-common:-dynamiclib:.\$(SHLIB_MAJOR).\$(SHLIB_MINOR).dylib",
 
 # A/UX
 "aux3-gcc","gcc:-O2 -DTERMIO::(unknown):AUX:-lbsd:RC4_CHAR RC4_CHUNK 
DES_UNROLL BF_PTR:::",
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] shlibloadtest failure on non-Linux

[Matt Caswell]

On 09/05/17 18:12, Nick Reilly wrote:
> 
> 
> On 2017-05-09 10:08 AM, Matt Caswell wrote:
>>
>> I'm not sure why this makes a difference. The return value of dlclose()
>> tells you whether there has been an error or not. Not whether the
>> library has actually been removed from address space. Or am I missing
>> your point?
> 
> dlclose() is returning an error and dlerror() reports that the library
> cannot be closed as it is still in use (from the leaked reference).

Hmmm. Arguably that is broken dlclose() behaviour. dlclose() is just
supposed to inform the system that a handle previously returned by
dlopen() is no longer required by the application. AFAIK there is no
requirement for all other handles returned from other dlopen() open
calls for the same shared library to be closed first (how would that
work anyway...unless there was a strict requirement for the handle
returned from the first call to dlopen() to always be the last one to be
used in a call to dlclose()?).

This is not a problem on other non-linux Unix based systems that we have
tried it on, so it looks to be something peculiar to QNX.

Does QNX have a "-znodelete" equivalent? That would be the most
preferable fix.

Another option might be something like this:

diff --git a/test/shlibloadtest.c b/test/shlibloadtest.c
index 6f220ba530..bc701b4333 100644
--- a/test/shlibloadtest.c
+++ b/test/shlibloadtest.c
@@ -65,8 +65,16 @@ static int shlib_sym(SHLIB lib, const char *symname,
SHLIB_SYM *sym)

 static int shlib_close(SHLIB lib)
 {
+#ifdefined OPENSSL_SYS_QNX
+/*
+ * Ignore errors from dlclose() on QNX to avoid spurious complaints
about
+ * being unable to close it due to it still being in use.
+ */
+dlclose(lib);
+#else
 if (dlclose(lib) != 0)
 return 0;
+#endif

 return 1;
 }

Matt

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] shlibloadtest failure on non-Linux

[Salz, Rich via openssl-dev]

> Sense of OPENSSL_USE_NODELETE has been reversed i.e. you want #ifdef
> and not #ifndef

Argh, you're right.
 
> Also I think its still fair game to try a dlclose() just that the
> dlclose() may return an error if OPENSSL_USE_NODELETE is not defined.

I'll just leave it as-is.  Thanks for looking at this!
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] shlibloadtest failure on non-Linux

[Nick Reilly]

On 2017-05-09 10:03 AM, Salz, Rich via openssl-dev wrote:

doesn't test for whether this is set. I think the shlibloadtest should only test
the dlclose() return value on if OPENSSL_USE_NODELETE is set.


Please see https://github.com/openssl/openssl/pull/3399



Sense of OPENSSL_USE_NODELETE has been reversed i.e. you want #ifdef and 
not #ifndef


Also I think its still fair game to try a dlclose() just that the 
dlclose() may return an error if OPENSSL_USE_NODELETE is not defined.


Regards,
Nick.
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] shlibloadtest failure on non-Linux

[Nick Reilly]

On 2017-05-09 10:08 AM, Matt Caswell wrote:


I'm not sure why this makes a difference. The return value of dlclose()
tells you whether there has been an error or not. Not whether the
library has actually been removed from address space. Or am I missing
your point?


dlclose() is returning an error and dlerror() reports that the library 
cannot be closed as it is still in use (from the leaked reference).



No. The whole point of OPENSSL_USE_NODELETE is to indicate that the
library won't be unloaded until process exit because we've ensured that
through some other mechanism (e.g. because we built it using
"-znodelete" on Linux). We do not rely on the linux specific behaviour.
If your platform doesn't have some other mechanism then you need to use
the default "deliberate leak" approach.


Ok, misunderstood the intention of OPENSSL_USE_NODELETE, didn't realise 
it meant -znodelete.


Thanks,
Nick.
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] shlibloadtest failure on non-Linux

[Matt Caswell]

On 09/05/17 15:03, Salz, Rich via openssl-dev wrote:
>> doesn't test for whether this is set. I think the shlibloadtest should only 
>> test
>> the dlclose() return value on if OPENSSL_USE_NODELETE is set.
> 
> Please see https://github.com/openssl/openssl/pull/3399
>  
>> 2) crypto/init.c at line 77 does "atexit(OPENSSL_cleanup)". If I try defining
>> OPENSSL_USE_NODELETE then this atexit() handler is meant to cleanup on
>> unload of the shared library, but this meaning of atexit() is Linux 
>> specific. It is
>> not required in POSIX and the Linux manpage lists this usage under the
>> "Linux notes" section.
> 
> Does changing the guard to this work?
> #if !defined(OPENSSL_SYS_UEFI) &&  !defined(OPENSSL_SYS_QNX)
> 

That presumably would mean that the library would not clean up at all on
QNX, which is probably undesirable.

Matt
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] shlibloadtest failure on non-Linux

[Salz, Rich via openssl-dev]

> doesn't test for whether this is set. I think the shlibloadtest should only 
> test
> the dlclose() return value on if OPENSSL_USE_NODELETE is set.

Please see https://github.com/openssl/openssl/pull/3399
 
> 2) crypto/init.c at line 77 does "atexit(OPENSSL_cleanup)". If I try defining
> OPENSSL_USE_NODELETE then this atexit() handler is meant to cleanup on
> unload of the shared library, but this meaning of atexit() is Linux specific. 
> It is
> not required in POSIX and the Linux manpage lists this usage under the
> "Linux notes" section.

Does changing the guard to this work?
#if !defined(OPENSSL_SYS_UEFI) &&  !defined(OPENSSL_SYS_QNX)

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] shlibloadtest failure on non-Linux

[Nick Reilly]

Hi,
I just ported OpenSSL 1.1.0e to QNX and ran in to an issue on 
shlibloadtest and it trying to unload the shared libraries in 
conjunction with the code in crypto/init.c


1) crypto/init.c at line 106 deliberately leaks a reference to prevent 
the library from unloading unless OPENSSL_USE_NODELETE is defined, yet 
shlibloadtest doesn't test for whether this is set. I think the 
shlibloadtest should only test the dlclose() return value on if 
OPENSSL_USE_NODELETE is set.


2) crypto/init.c at line 77 does "atexit(OPENSSL_cleanup)". If I try 
defining OPENSSL_USE_NODELETE then this atexit() handler is meant to 
cleanup on unload of the shared library, but this meaning of atexit() is 
Linux specific. It is not required in POSIX and the Linux manpage lists 
this usage under the "Linux notes" section. In QNX there must be no 
atexit() handlers registered if the library is being unloaded, otherwise 
there is a forced abort() called from the dynamic linker. I think that 
rather than using the atexit() mechanism some other mechanism e.g. 
function attribute of destructor on gcc should be used.


Regards,
Nick.
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] In ssl3_write_bytes, some checks related to hanlding write failure are missing

[Raja ashok]

Hi Matt,

I created a Pull request for the second change on master, 1.0.2 and 1.1.0. I am 
creating PR in github for the first time, so if anything else I missed please 
update me.

https://github.com/openssl/openssl/pull/3124
https://github.com/openssl/openssl/pull/3123
https://github.com/openssl/openssl/pull/3122

Regards,
Ashok



Raja Ashok V K
Huawei Technologies
Bangalore, India
http://www.huawei.com 

本邮件及其附件含有华为公司的保密信息，仅限于发送给上面地址中列出的个人或群组。禁
止任何其他人以任何形式使用（包括但不限于全部或部分地泄露、复制、或散发）本邮件中
的信息。如果您错收了本邮件，请您立即电话或邮件通知发件人并删除本邮件！
This e-mail and its attachments contain confidential information from HUAWEI, 
which 
is intended only for the person or entity whose address is listed above. Any 
use of the 
information contained herein in any way (including, but not limited to, total 
or partial 
disclosure, reproduction, or dissemination) by persons other than the intended 
recipient(s) is prohibited. If you receive this e-mail in error, please notify 
the sender by 
phone or email immediately and delete it!


-Original Message-
From: openssl-dev [mailto:openssl-dev-boun...@openssl.org] On Behalf Of Matt 
Caswell
Sent: 03 April 2017 14:40
To: openssl-dev@openssl.org
Subject: Re: [openssl-dev] In ssl3_write_bytes, some checks related to hanlding 
write failure are missing

On 31/03/17 18:54, Raja ashok wrote:
> Hi All,
>
>
>
> In ssl3_write_bytes, if (len < tot) we are returning failure with 
> SSL_R_BAD_LENGTH error. In this place I hope we should set “tot” back 
> to “s->s3->wnum”. Otherwise when application calls back SSL_write with 
> correct buffer, it causes serious problem (“tot” is 0 and iLeft is not 
> NULL). I hope we should do like below.
>
>
>
> if (len < tot) {
>
> s->s3->wnum = tot;
>
> SSLerr(SSL_F_SSL3_WRITE_BYTES, SSL_R_BAD_LENGTH);
>
>return (-1);
>
> }

This is 1.0.2 code. The check appears to be earlier in master/1.1.0 (before 
wnum is reset) and so this isn't an issue there. Really, if an application 
passes a bad len value, then this is an application bug and shouldn't ever 
happen in a well-behaved application. I'm not sure you could really describe 
this as an OpenSSL bug (its a bit border line) so I'm not sure it justifies a 
patch to 1.0.2 (which only takes bug fixes).

>
> And also we should do one additional check for “len” as mentioned in 
> my previous mail.
>
>
>
> if ((len < tot) || ((tot != 0) && (len < (tot + 
> s->s3->wpend_tot{
>
> s->s3->wnum = tot;
>
> SSLerr(SSL_F_SSL3_WRITE_BYTES, SSL_R_BAD_LENGTH);
>
>return (-1);
>
> }

Please could you raise a github pull request for this suggestion? You will 
probably need two versions: one targeting master and one targeting
1.0.2 as the the code looks a little different in this area.

Matt
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] In ssl3_write_bytes, some checks related to hanlding write failure are missing

[Matt Caswell]

On 31/03/17 18:54, Raja ashok wrote:
> Hi All,
>
>
>
> In ssl3_write_bytes, if (len < tot) we are returning failure with
> SSL_R_BAD_LENGTH error. In this place I hope we should set “tot” back to
> “s->s3->wnum”. Otherwise when application calls back SSL_write with
> correct buffer, it causes serious problem (“tot” is 0 and iLeft is not
> NULL). I hope we should do like below.
>
>
>
> if (len < tot) {
>
> s->s3->wnum = tot;
>
> SSLerr(SSL_F_SSL3_WRITE_BYTES, SSL_R_BAD_LENGTH);
>
>return (-1);
>
> }

This is 1.0.2 code. The check appears to be earlier in master/1.1.0
(before wnum is reset) and so this isn't an issue there. Really, if an
application passes a bad len value, then this is an application bug and
shouldn't ever happen in a well-behaved application. I'm not sure you
could really describe this as an OpenSSL bug (its a bit border line) so
I'm not sure it justifies a patch to 1.0.2 (which only takes bug fixes).

>
> And also we should do one additional check for “len” as mentioned in my
> previous mail.
>
>
>
> if ((len < tot) || ((tot != 0) && (len < (tot + s->s3->wpend_tot{
>
> s->s3->wnum = tot;
>
> SSLerr(SSL_F_SSL3_WRITE_BYTES, SSL_R_BAD_LENGTH);
>
>return (-1);
>
> }

Please could you raise a github pull request for this suggestion? You
will probably need two versions: one targeting master and one targeting
1.0.2 as the the code looks a little different in this area.

Matt
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] In ssl3_write_bytes, some checks related to hanlding write failure are missing

[Raja ashok]

Hi All,

In ssl3_write_bytes, if (len < tot) we are returning failure with 
SSL_R_BAD_LENGTH error. In this place I hope we should set “tot” back to 
“s->s3->wnum”. Otherwise when application calls back SSL_write with correct 
buffer, it causes serious problem (“tot” is 0 and iLeft is not NULL). I hope we 
should do like below.

if (len < tot) {
s->s3->wnum = tot;
SSLerr(SSL_F_SSL3_WRITE_BYTES, SSL_R_BAD_LENGTH);
   return (-1);
}

And also we should do one additional check for “len” as mentioned in my 
previous mail.

if ((len < tot) || ((tot != 0) && (len < (tot + s->s3->wpend_tot{
s->s3->wnum = tot;
SSLerr(SSL_F_SSL3_WRITE_BYTES, SSL_R_BAD_LENGTH);
   return (-1);
}

Regards,
Ashok


[Company_logo]

Raja Ashok V K
Huawei Technologies
Bangalore, India
http://www.huawei.com

本邮件及其附件含有华为公司的保密信息，仅限于发送给上面地址中列出的个人或群组。禁
止任何其他人以任何形式使用（包括但不限于全部或部分地泄露、复制、或散发）本邮件中
的信息。如果您错收了本邮件，请您立即电话或邮件通知发件人并删除本邮件！
This e-mail and its attachments contain confidential information from HUAWEI, 
which
is intended only for the person or entity whose address is listed above. Any 
use of the
information contained herein in any way (including, but not limited to, total 
or partial
disclosure, reproduction, or dissemination) by persons other than the intended
recipient(s) is prohibited. If you receive this e-mail in error, please notify 
the sender by
phone or email immediately and delete it!

From: Raja ashok
Sent: 27 March 2017 13:55
To: 'openssl-us...@openssl.org'; 'openssl-dev@openssl.org'
Subject: In ssl3_write_bytes, some checks related to hanlding write failure are 
missing

Hi,

I feel there is a check missing in ssl3_write_bytes, in case of handling write 
failure.

Consider SSL_write is called with 2 bytes buffer, then internally in 
ssl3_write_bytes we try to send it as two record (16384 and 3616). If TCP send 
failed for the second record then we store the states internally (wnum, 
wpend_tot and wpend_buf) and return back the result.

Later application has to call SSL_write with same buffer, if it calls with 
different buffer of length 100 byte then we fail that in ssl3_write_bytes using 
the check (len < tot).

But consider application calls with buffer of size 18000 bytes and 
SSL_MODE_ACCEPT_MOVING_WRITE_BUFFER is enabled. Then (len < tot) will not 
succeed as tot is 16384. Then it will call ssl3_write_pending to send the 
remaining 3616 record. If it succeeds we are incrementing tot, (tot += i). Now 
tot will have 2.

Later there is a check (tot == len), this will not succeed. Then directly we 
are doing n = (len - tot), this will overflow and store a value close to 2^32 
in n. Then it will cause out of bound access to the application buffer "buf".

I hope we should have one more check (len < (tot + s->s3->wpend_tot)) before 
calling ssl3_write_pending.

if ((len < tot) || (len < (tot + s->s3->wpend_tot))){
SSLerr(SSL_F_SSL3_WRITE_BYTES, SSL_R_BAD_LENGTH);
return (-1);
}

Note : I am referring 1.0.2k version of OpenSSL.

Regards,
Ashok


[Company_logo]

Raja Ashok V K
Huawei Technologies
Bangalore, India
http://www.huawei.com

本邮件及其附件含有华为公司的保密信息，仅限于发送给上面地址中列出的个人或群组。禁
止任何其他人以任何形式使用（包括但不限于全部或部分地泄露、复制、或散发）本邮件中
的信息。如果您错收了本邮件，请您立即电话或邮件通知发件人并删除本邮件！
This e-mail and its attachments contain confidential information from HUAWEI, 
which
is intended only for the person or entity whose address is listed above. Any 
use of the
information contained herein in any way (including, but not limited to, total 
or partial
disclosure, reproduction, or dissemination) by persons other than the intended
recipient(s) is prohibited. If you receive this e-mail in error, please notify 
the sender by
phone or email immediately and delete it!

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] In ssl3_write_bytes, some checks related to hanlding write failure are missing

[Raja ashok]

Hi,

I feel there is a check missing in ssl3_write_bytes, in case of handling write 
failure.

Consider SSL_write is called with 2 bytes buffer, then internally in 
ssl3_write_bytes we try to send it as two record (16384 and 3616). If TCP send 
failed for the second record then we store the states internally (wnum, 
wpend_tot and wpend_buf) and return back the result.

Later application has to call SSL_write with same buffer, if it calls with 
different buffer of length 100 byte then we fail that in ssl3_write_bytes using 
the check (len < tot).

But consider application calls with buffer of size 18000 bytes and 
SSL_MODE_ACCEPT_MOVING_WRITE_BUFFER is enabled. Then (len < tot) will not 
succeed as tot is 16384. Then it will call ssl3_write_pending to send the 
remaining 3616 record. If it succeeds we are incrementing tot, (tot += i). Now 
tot will have 2.

Later there is a check (tot == len), this will not succeed. Then directly we 
are doing n = (len - tot), this will overflow and store a value close to 2^32 
in n. Then it will cause out of bound access to the application buffer "buf".

I hope we should have one more check (len < (tot + s->s3->wpend_tot)) before 
calling ssl3_write_pending.

if ((len < tot) || (len < (tot + s->s3->wpend_tot))){
SSLerr(SSL_F_SSL3_WRITE_BYTES, SSL_R_BAD_LENGTH);
return (-1);
}

Note : I am referring 1.0.2k version of OpenSSL.

Regards,
Ashok


[Company_logo]

Raja Ashok V K
Huawei Technologies
Bangalore, India
http://www.huawei.com

本邮件及其附件含有华为公司的保密信息，仅限于发送给上面地址中列出的个人或群组。禁
止任何其他人以任何形式使用（包括但不限于全部或部分地泄露、复制、或散发）本邮件中
的信息。如果您错收了本邮件，请您立即电话或邮件通知发件人并删除本邮件！
This e-mail and its attachments contain confidential information from HUAWEI, 
which
is intended only for the person or entity whose address is listed above. Any 
use of the
information contained herein in any way (including, but not limited to, total 
or partial
disclosure, reproduction, or dissemination) by persons other than the intended
recipient(s) is prohibited. If you receive this e-mail in error, please notify 
the sender by
phone or email immediately and delete it!

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] Still seeing test failure in openssl 1.0.2 SNAPHOT 20161031

[The Doctor]

On Tue, Nov 01, 2016 at 10:54:39AM +0100, Richard Levitte wrote:
> I just tested on two systems, Debian [unstable] and FreeBSD 8.4, and
> in both cases, that test goes through with no trouble at all.
> 
> Could you tell us your exact configuration?  If I recall correctly,
> you have your own hacked configuration, right?
> 
> Cheers,
> Richard

Certainly,

My configuration script is


#!/usr/local/bin/bash
CC=/usr/local/bin/clang39  ./Configure --prefix=/usr/ BSD-x86_64 enable-gmp 
experimental-jpake enable-rfc3779 enable-shared zlib-dynamic disable-sctp 
experimental-store enable-ssl-trace enable-unit-test; make depend

> 
> In message <20161031142938.ga97...@doctor.nl2k.ab.ca> on Mon, 31 Oct 2016 
> 08:29:38 -0600, The Doctor  said:
> 
> doctor> I saw this yesterday as well
> doctor> 
> doctor> ../util/shlib_wrap.sh ./heartbeat_test
> doctor> test_dtls1_not_bleeding failed: expected return value 0, received -1
> doctor> ** test_dtls1_not_bleeding failed **
> doctor> 
> doctor> test_dtls1_not_bleeding_empty_payload failed: expected return value 
> 0, received -1
> doctor> ** test_dtls1_not_bleeding_empty_payload failed **
> doctor> 
> doctor> test_tls1_not_bleeding failed: expected return value 0, received -1
> doctor> ** test_tls1_not_bleeding failed **
> doctor> 
> doctor> test_tls1_not_bleeding_empty_payload failed: expected return value 0, 
> received -1
> doctor> ** test_tls1_not_bleeding_empty_payload failed **
> doctor> 
> doctor> 4 tests failed
> doctor> *** Error code 1
> doctor> 
> doctor> Stop.
> doctor> make[1]: stopped in 
> /usr/source/openssl-1.0.2-stable-SNAP-20161031/test
> doctor> *** Error code 1
> doctor> 
> doctor> Please fix
> doctor> 
> doctor> -- 
> doctor> Member - Liberal International This is doctor@@nl2k.ab.ca Ici 
> doctor@@nl2k.ab.ca
> doctor> God,Queen and country!Never Satan President Republic!Beware 
> AntiChrist rising! 
> doctor> http://www.fullyfollow.me/rootnl2k  Look at Psalms 14 and 53 on 
> Atheism
> doctor> Time for the USA to hold a referendum on its republic and vote to 
> dissolve!! 
> doctor> -- 
> doctor> openssl-dev mailing list
> doctor> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
> doctor> 

-- 
Member - Liberal International This is doctor@@nl2k.ab.ca Ici doctor@@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
Time for the USA to hold a referendum on its republic and vote to dissolve!! 
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] Still seeing test failure in openssl 1.0.2 SNAPHOT 20161031

[Richard Levitte]

I just tested on two systems, Debian [unstable] and FreeBSD 8.4, and
in both cases, that test goes through with no trouble at all.

Could you tell us your exact configuration?  If I recall correctly,
you have your own hacked configuration, right?

Cheers,
Richard

In message <20161031142938.ga97...@doctor.nl2k.ab.ca> on Mon, 31 Oct 2016 
08:29:38 -0600, The Doctor  said:

doctor> I saw this yesterday as well
doctor> 
doctor> ../util/shlib_wrap.sh ./heartbeat_test
doctor> test_dtls1_not_bleeding failed: expected return value 0, received -1
doctor> ** test_dtls1_not_bleeding failed **
doctor> 
doctor> test_dtls1_not_bleeding_empty_payload failed: expected return value 0, 
received -1
doctor> ** test_dtls1_not_bleeding_empty_payload failed **
doctor> 
doctor> test_tls1_not_bleeding failed: expected return value 0, received -1
doctor> ** test_tls1_not_bleeding failed **
doctor> 
doctor> test_tls1_not_bleeding_empty_payload failed: expected return value 0, 
received -1
doctor> ** test_tls1_not_bleeding_empty_payload failed **
doctor> 
doctor> 4 tests failed
doctor> *** Error code 1
doctor> 
doctor> Stop.
doctor> make[1]: stopped in /usr/source/openssl-1.0.2-stable-SNAP-20161031/test
doctor> *** Error code 1
doctor> 
doctor> Please fix
doctor> 
doctor> -- 
doctor> Member - Liberal International This is doctor@@nl2k.ab.ca Ici 
doctor@@nl2k.ab.ca
doctor> God,Queen and country!Never Satan President Republic!Beware AntiChrist 
rising! 
doctor> http://www.fullyfollow.me/rootnl2k  Look at Psalms 14 and 53 on Atheism
doctor> Time for the USA to hold a referendum on its republic and vote to 
dissolve!! 
doctor> -- 
doctor> openssl-dev mailing list
doctor> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
doctor> 
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] Still seeing test failure in openssl 1.0.2 SNAPHOT 20161031

[The Doctor]

I saw this yesterday as well

../util/shlib_wrap.sh ./heartbeat_test
test_dtls1_not_bleeding failed: expected return value 0, received -1
** test_dtls1_not_bleeding failed **

test_dtls1_not_bleeding_empty_payload failed: expected return value 0, received 
-1
** test_dtls1_not_bleeding_empty_payload failed **

test_tls1_not_bleeding failed: expected return value 0, received -1
** test_tls1_not_bleeding failed **

test_tls1_not_bleeding_empty_payload failed: expected return value 0, received 
-1
** test_tls1_not_bleeding_empty_payload failed **

4 tests failed
*** Error code 1

Stop.
make[1]: stopped in /usr/source/openssl-1.0.2-stable-SNAP-20161031/test
*** Error code 1

Please fix

-- 
Member - Liberal International This is doctor@@nl2k.ab.ca Ici doctor@@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
Time for the USA to hold a referendum on its republic and vote to dissolve!! 
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl.org #4683] [BUG] Failure running openssl speed ecdh in master branch

[Nicola Tuveri via RT]

>
> There are several options which have varying impacts on what speed would
> actually be measuring, I'll outline them below:
> 1) I just remove X25519 support from OpenSSL speed. This is the easiest
> fix but means nobody can use speed to measure performance with the X25519
> curve anymore. This would be undesirable as the curve is becoming
> increasingly popular and well supported as an alternative to NIST curves.
> 2) I add a special case to the ECDH measurement function that uses the
> EVP_PKEY_* interfaces just for the X25519 curve. This adds complexity to
> speed and means X25519 is technically not really comparable with the other
> curves due to a different API entry point at a higher level.
> 3) I move all the ECDH curves in speed over to use the EVP_PKEY_*
> interfaces. This will make the curve measurement comparable but not with
> historical data from earlier openssl versions (this may not be important
> anyway).
> 4) I go the whole hog and move all the pkey operations that I can in speed
> over to use the EVP_PKEY_* interfaces. Again this would break historical
> comparisons.


I just noticed this thread: I was already working on option number 3 for a
side project where I had the need to compare benchmarks of ECDH with
different curves, including X25519, so [here is a pull request][0] to start
from if we want to revise which interface to use to access EC crypto in
apps/speed.

Hope this might save some time!



Kind regards,

Nicola Tuveri


[0] https://github.com/openssl/openssl/pull/1658

-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4683
Please log in as guest with password guest if prompted

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl.org #4683] [BUG] Failure running openssl speed ecdh in master branch

[Linsell, StevenX]

> Date: Thu, 22 Sep 2016 15:39:13 +
> From: "Linsell, StevenX via RT" <r...@openssl.org>

> Running against master branch (commit
> 39c136cc53d7b6fafdd1a0b52c035fd24358e01c - Updates CHANGES and NEWS
> for new release) we see a failure when running openssl speed with the ecdh
> parameter:
> 
> ./openssl speed ecdh

[SNIP] 

> ECDH failure.
> 140194445354752:error:100AE081:elliptic curve
> routines:EC_GROUP_new_by_curve_name:unknown
> group:crypto/ec/ec_curve.c:3100:
> 140194445354752:error:100AE081:elliptic curve
> routines:EC_GROUP_new_by_curve_name:unknown
> group:crypto/ec/ec_curve.c:3100:
> OpenSSL 1.1.1-dev  xx XXX 

I've had a bit more time to investigate this bug.
The issue was introduced by commit:

bc7bfb83b7189c052bf2898bd6b82f8e4b4fd3f6
Remove old EC based X25519 code.
Committed on August 11th

And is present in both OpenSSL_1_1_0-stable and master branch.
OpenSSL speed uses the EC methods to measure ECDH_compute_key operations 
including support for the X25519 curve.
Since the commit above the EC_KEY_new_by_curve_name call fails as X25519 is no 
longer supported.
I would like to work on a fix for this but I would like some feedback on the 
direction to take.
There are several options which have varying impacts on what speed would 
actually be measuring, I'll outline
them below:

1) I just remove X25519 support from OpenSSL speed. This is the easiest fix but 
means nobody can use speed to
measure performance with the X25519 curve anymore. This would be undesirable as 
the curve is becoming
increasingly popular and well supported as an alternative to NIST curves.

2) I add a special case to the ECDH measurement function that uses the 
EVP_PKEY_* interfaces just for the
X25519 curve. This adds complexity to speed and means X25519 is technically not 
really comparable with
the other curves due to a different API entry point at a higher level.

3) I move all the ECDH curves in speed over to use the EVP_PKEY_* interfaces. 
This will make the curve
measurement comparable but not with historical data from earlier openssl 
versions (this may not be important
anyway).

4) I go the whole hog and move all the pkey operations that I can in speed over 
to use the EVP_PKEY_*
interfaces. Again this would break historical comparisons.

Personally I would favour option 3 or possibly 4 depending on time constraints 
but I don't know if there is a 
historical reason why speed uses the low level API's? Is it so the speed 
measurements are focused tightly on
the algorithm they are measuring or is it just they were written that way and 
nobody has had the need to
change them?

Any comments would be appreciated before I spend time on this.

Kind Regards,

Steve Linsell   
Intel Shannon DCG/CID Software Development Team
stevenx.lins...@intel.com
--
Intel Research and Development Ireland Limited
Registered in Ireland
Registered Office: Collinstown Industrial Park, Leixlip, County Kildare
Registered Number: 308263


This e-mail and any attachments may contain confidential material for the sole
use of the intended recipient(s). Any review or distribution by others is
strictly prohibited. If you are not the intended recipient, please contact the
sender and delete all copies.

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] [openssl.org #4686] [BUG] Failure to compile if HAVE_CRYPTODEV is defined in OpenSSL 1.0.2i

[Richard Levitte via RT]

On Mon Sep 26 14:34:17 2016, rs...@akamai.com wrote:
> We have a fix waiting for internal review; see GitHub issue 1546.

That's not related to this issue.

Cheers,
Richard

--
Richard Levitte
levi...@openssl.org

-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4686
Please log in as guest with password guest if prompted

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] [openssl.org #4686] [BUG] Failure to compile if HAVE_CRYPTODEV is defined in OpenSSL 1.0.2i

[Richard Levitte via RT]

That has already been fixed in the 1.0.2 branch, and is part of 1.0.2j, which
was released today.

Cheers,
Richard

On Mon Sep 26 14:32:31 2016, jan-markus.pumpa...@bittium.com wrote:
>
>
> Hi,
>
> When building the OpenSSL 1.0.2i with -DHAVE_CRYPTODEV flag the build
> will fail in crypto/engine/eng_cryptodev.c. I am using 64-bit Ubuntu
> 14.04 in my build machine with gcc toolchain.
>
> For me it looks like there has been a typo in the OPENSSL_malloc
> return value check. Attached patch solves the issue. Below is the
> original error message:
>
> | gcc -I.. -I../.. -I../modes -I../asn1 -I../evp -I../../include
> -fPIC -DOPENSSL_PIC -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN
> -DHAVE_DLFCN_H -DL_ENDIAN -DTERMIO -i/build/tmp/sysroots/x86_64-
> linux/usr/include -O2 -pipe -Wall -Wa,--noexecstack -DHAVE_CRYPTODEV
> -DUSE_CRYPTODEV_DIGESTS -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT
> -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m -DRC4_ASM -DSHA1_ASM
> -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DAES_ASM -DVPAES_ASM -DBSAES_ASM
> -DWHIRLPOOL_ASM -DGHASH_ASM -DECP_NISTZ256_ASM
> -ibuild/tmp/sysroots/x86_64-linux/usr/include -c -o eng_cryptodev.o
> eng_cryptodev.c
> | eng_cryptodev.c: In function 'cryptodev_digest_copy':
> | eng_cryptodev.c:942:23: error: 'struct dev_crypto_state' has no
> member named 'ac_data'
> | if (dstate->ac_data == NULL) {
> | ^
> | make[2]: *** [eng_cryptodev.o] Error 1
>
>
> Kind regards,
> Jan-Markus Pumpanen
>
> 
> Please note: This e-mail may contain confidential information
> intended solely for the addressee. If you have received this
> e-mail in error, please do not disclose it to anyone, notify
> the sender promptly, and delete the message from your system.
> Thank you.


--
Richard Levitte
levi...@openssl.org

-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4686
Please log in as guest with password guest if prompted

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl.org #4686] [BUG] Failure to compile if HAVE_CRYPTODEV is defined in OpenSSL 1.0.2i

[Salz, Rich via RT]

We have a fix waiting for internal review; see GitHub issue 1546.



-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4686
Please log in as guest with password guest if prompted

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] [openssl.org #4686] [BUG] Failure to compile if HAVE_CRYPTODEV is defined in OpenSSL 1.0.2i

[Pumpanen Jan-Markus via RT]

Hi,

When building the OpenSSL 1.0.2i with -DHAVE_CRYPTODEV flag the build will fail 
in crypto/engine/eng_cryptodev.c. I am using 64-bit Ubuntu 14.04 in my build 
machine with gcc toolchain. 

For me it looks like there has been a typo in the OPENSSL_malloc return value 
check. Attached patch solves the issue. Below is the original error message:

| gcc -I.. -I../.. -I../modes -I../asn1 -I../evp -I../../include  -fPIC 
-DOPENSSL_PIC -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H 
-DL_ENDIAN  -DTERMIO -i/build/tmp/sysroots/x86_64-linux/usr/include -O2 
-pipe -Wall -Wa,--noexecstack -DHAVE_CRYPTODEV -DUSE_CRYPTODEV_DIGESTS 
-DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 
-DOPENSSL_BN_ASM_GF2m -DRC4_ASM -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM 
-DAES_ASM -DVPAES_ASM -DBSAES_ASM -DWHIRLPOOL_ASM -DGHASH_ASM 
-DECP_NISTZ256_ASM -ibuild/tmp/sysroots/x86_64-linux/usr/include  -c -o 
eng_cryptodev.o eng_cryptodev.c
| eng_cryptodev.c: In function 'cryptodev_digest_copy':
| eng_cryptodev.c:942:23: error: 'struct dev_crypto_state' has no member named 
'ac_data'
|  if (dstate->ac_data == NULL) {
|^
| make[2]: *** [eng_cryptodev.o] Error 1


Kind regards,
Jan-Markus Pumpanen


Please note: This e-mail may contain confidential information
intended solely for the addressee. If you have received this
e-mail in error, please do not disclose it to anyone, notify
the sender promptly, and delete the message from your system.
Thank you.


-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4686
Please log in as guest with password guest if prompted

--- clean-openssl-1.0.2i/crypto/engine/eng_cryptodev.c	2016-09-22 13:23:06.0 +0300
+++ openssl-1.0.2i/crypto/engine/eng_cryptodev.c	2016-09-26 16:07:24.724568163 +0300
@@ -939,7 +939,7 @@
 if (fstate->mac_len != 0) {
 if (fstate->mac_data != NULL) {
 dstate->mac_data = OPENSSL_malloc(fstate->mac_len);
-if (dstate->ac_data == NULL) {
+if (dstate->mac_data == NULL) {
 printf("cryptodev_digest_init: malloc failed\n");
 return 0;
 }
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] [openssl.org #4683] [BUG] Failure running openssl speed ecdh in master branch

[Linsell, StevenX via RT]

Running against master branch (commit 39c136cc53d7b6fafdd1a0b52c035fd24358e01c 
- Updates CHANGES and NEWS for new release) we see a failure when running 
openssl speed with the ecdh parameter:

./openssl speed ecdh
Doing 160 bit  ecdh's for 10s: 35676 160-bit ECDH ops in 9.98s
Doing 192 bit  ecdh's for 10s: 29928 192-bit ECDH ops in 9.98s
Doing 224 bit  ecdh's for 10s: 21881 224-bit ECDH ops in 9.98s
Doing 256 bit  ecdh's for 10s: 91839 256-bit ECDH ops in 9.98s
Doing 384 bit  ecdh's for 10s: 9642 384-bit ECDH ops in 9.98s
Doing 521 bit  ecdh's for 10s: 4737 521-bit ECDH ops in 9.98s
Doing 163 bit  ecdh's for 10s: 32911 163-bit ECDH ops in 9.98s
Doing 233 bit  ecdh's for 10s: 25740 233-bit ECDH ops in 9.98s
Doing 283 bit  ecdh's for 10s: 14392 283-bit ECDH ops in 9.98s
Doing 409 bit  ecdh's for 10s: 9203 409-bit ECDH ops in 9.98s
Doing 571 bit  ecdh's for 10s: 3866 571-bit ECDH ops in 9.98s
Doing 163 bit  ecdh's for 10s: 31212 163-bit ECDH ops in 9.98s
Doing 233 bit  ecdh's for 10s: 24564 233-bit ECDH ops in 9.98s
Doing 283 bit  ecdh's for 10s: 13510 283-bit ECDH ops in 9.97s
Doing 409 bit  ecdh's for 10s: 8603 409-bit ECDH ops in 9.98s
Doing 571 bit  ecdh's for 10s: 3572 571-bit ECDH ops in 9.98s
ECDH failure.
140194445354752:error:100AE081:elliptic curve 
routines:EC_GROUP_new_by_curve_name:unknown group:crypto/ec/ec_curve.c:3100:
140194445354752:error:100AE081:elliptic curve 
routines:EC_GROUP_new_by_curve_name:unknown group:crypto/ec/ec_curve.c:3100:
OpenSSL 1.1.1-dev  xx XXX 

This bug appears to have been introduced by the recent refactoring of X25519.
I'm not up to speed on the X25519 curve refactoring and how that curve should 
be used from the libCrypto interfaces now, so I'm not sure how this issue 
should be resolved. I could have made a pull request to just remove X25519 from 
the tested curves but that seemed to be a retrograde step.
Let me know if that is the route you would like to take and I can submit a pull 
request for that if you like.

Kind Regards,

Steve Linsell   
Intel Shannon DCG/CID Software Development Team
stevenx.lins...@intel.com

--
Intel Research and Development Ireland Limited
Registered in Ireland
Registered Office: Collinstown Industrial Park, Leixlip, County Kildare
Registered Number: 308263


This e-mail and any attachments may contain confidential material for the sole
use of the intended recipient(s). Any review or distribution by others is
strictly prohibited. If you are not the intended recipient, please contact the
sender and delete all copies.


-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4683
Please log in as guest with password guest if prompted

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] [openssl.org #4661] OpenSSL 1.1.0 ssltest_old assertion failure in Windows requires interaction

[Ray Satiro via RT]

I recently built OpenSSL 1.1.0 x64 debug using Visual Studio 2010, like 
this:

perl Configure debug-VC-WIN64A no-asm
nmake

Then I ran the tests

nmake test

At test\recipes\80-test_ssl_old.t a message box popped up with an 
assertion failure, I debugged it and saved the information. However when 
the tests completed it said 'All tests successful', so I'm not sure 
what's happened here. Maybe you expect that test to fail with an 
assertion? If that is the case I don't think you want interaction with a 
message box pop up, perhaps you want something like 
SetErrorMode(SEM_FAILCRITICALERRORS|SEM_NOGPFAULTERRORBOX|SEM_NOOPENFILEERRORBOX);

Here is the information from the test. I got this information by 
recording the process command line, and running the process a second 
time and debugging it.

 >libssl-1_1-x64.dll!ssl_free_wbio_buffer(ssl_st * s)  Line 3327 + 
0x26 bytesC
  libssl-1_1-x64.dll!SSL_free(ssl_st * s)  Line 981C
  ssltest_old.exe!main(int argc, char * * argv)  Line 1920C
  ssltest_old.exe!__tmainCRTStartup()  Line 555 + 0x19 bytes C
  ssltest_old.exe!mainCRTStartup()  Line 371C
  kernel32.dll!BaseThreadInitThunk()  + 0xd bytes
  ntdll.dll!RtlUserThreadStart()  + 0x21 bytes

ssltest_old.exe  -s_key keyU.ss -s_cert certU.ss -c_key keyU.ss -c_cert 
certU.ss -s_cipher EDH -c_cipher EDH:@SECLEVEL=1 -dhe512
8132:error:1408518A:SSL routines:ssl3_ctx_ctrl:dh key too 
small:ssl\s3_lib.c:3265:
8132:error:1408518A:SSL routines:ssl3_ctx_ctrl:dh key too 
small:ssl\s3_lib.c:3265:
8132:error:02001003:system library:fopen:No such 
process:crypto\bio\bss_file.c:74:fopen('C:\Program Files\Common 
Files\SSL/ct_log_list.cnf','rb')
8132:error:2006D080:BIO routines:BIO_new_file:no such 
file:crypto\bio\bss_file.c:77:
8132:error:0E078072:configuration file routines:def_load:no such 
file:crypto\conf\conf_def.c:144:
8132:error:3207B06D:CT routines:CTLOG_STORE_load_file:log conf 
invalid:crypto\ct\ct_log.c:207:
Doing handshakes=1 bytes=256
ERROR in SERVER
8132:error:1417A0C1:SSL routines:tls_post_process_client_hello:no shared 
cipher:ssl\statem\statem_srvr.c:1422:
TLSv1.2, cipher (NONE) (NONE)
Assertion failed: s->wbio != NULL, file ssl\ssl_lib.c, line 3327


-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4661
Please log in as guest with password guest if prompted

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] [openssl.org #4657] Bug - SSL Library Error - BUF_MEM_grow:malloc failure

[Nomalatha Aerampu via RT]

Hi,

Our product (32-bit process) uses OpenSSL third-party libraries for EAP 
protocols. During the debugging of a customer issue in PEAP protocol, we got to 
understand that SSL_Accept has returned failure.

STATE_HANDSHAKE SSL_ERROR_SSL error retrun code [1] and peak error translate 
code [39] and err_get_reason [1048] // Error code, Error cases(Reason)
8900:error:14094418:SSL routines:SSL3_READ_BYTES:tlsv1 alert unknown 
ca:.\ssl\s3_pkt.c:1235:SSL alert number 48 // Error Queue
SSL_ERROR_SSL Handshake failure

On further analyzing, we found that handshake failure is due to the 
"BUF_MEM_grow : malloc failure" in the server after the 'n' number of 
authentications.
The memory buffer gets completely allocated and handshake is failed when we 
tried to allocate the memory.

STATE_HANDSHAKE SSL_ERROR_SSL error retrun code [1] and peak error translate 
code [2] and err_get_reason [65]
7820:error:07064041:memory buffer routines:BUF_MEM_grow:malloc 
failure:.\crypto\buffer\buffer.c:122:
SSL_ERROR_SSL Handshake failure

Total memory that is installed on the server: 4GB
Process memory size when the issue occurs: 360 ~ 370 MB

Operating System Version - Windows Server 2008
OpenSSL version - 0.9.7e, 1.0.0s

Please let us know if there are known issues related to the same or let us know 
if you require further information for your debugging.

Regards,
Nomalatha A

-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4657
Please log in as guest with password guest if prompted

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl.org #4633] EVP self test failure with ARMv8 and Aarch32 flags

[Andy Polyakov via RT]

>>> (gdb) r test/evptests.txt
>>> Starting program: /home/jwalton/openssl/test/evp_test test/evptests.txt
>>> [Thread debugging using libthread_db enabled]
>>> Using host libthread_db library 
>>> "/lib/arm-linux-gnueabihf/libthread_db.so.1".
>>>
>>> Program received signal SIGBUS, Bus error.
>>> CRYPTO_ccm128_decrypt (ctx=ctx@entry=0x33788,
>>> inp=inp@entry=0x33649
>>> "\232_\314ʹ\317\004\347)='u\314v\244\210\360B8-\224\233C\267ֻ+\230dxg&",
>>> out=,
>>> out@entry=0x335d8
>>> "\004\065\331v\004\065\331v)='u\314v\244\210\360B8-\224\233C\267ֻ+\230dxg&",
>>> len=len@entry=0x20) at crypto/modes/ccm128.c:253
>>> 253ctx->cmac.u[0] ^= (scratch.u[0] ^= temp.u[0]);
>>> (gdb)
>>
>> This line is within #if defined(STRICT_ALIGNMENT), which means that
>> compiler is responsible for aligning data, and SIGBUS means that it
>> failed. And indeed, looking at disassembler output it crashes in vld1.64
>> {d16-d17}, [r6 :64], instruction that requires 64-bit alignment. So
>> compiler generated the instruction, but didn't care to ensure the
>> alignment. There is no other conclusion one can draw but that is indeed
>> a compiler bug. Besides, default ./config works just fine and (once
>> again) I see no compelling reason for not using it.
> 
> I think these are the lines:
> 
> #if defined(STRICT_ALIGNMENT)
> union {
> u64 u[2];
> u8 c[16];
> } temp;
> #endif
> 
> ...
> 
> #if defined(STRICT_ALIGNMENT)
> memcpy(temp.c, inp, 16);
> ctx->cmac.u[0] ^= (scratch.u[0] ^= temp.u[0]);
> ctx->cmac.u[1] ^= (scratch.u[1] ^= temp.u[1]);
> ...
> #endif
> 
> I *thought* accessing a union member through its inactive member is
> undefined behavior.

Really? It says "When a value is stored in a member of an object of
union type, the bytes of the object representation that do not
correspond to that member but do correspond to other members take
unspecified values." Referred members fully overlap and there are no
bytes that correspond to one and not another.

> Once 'scratch.c' and 'temp.c' were used, using
> 'temp.c' and 'temp.u' leads to the UB.

But either way union with u64 member has to be aligned, so references to
.u should not cause SIGBUS.


-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4633
Please log in as guest with password guest if prompted

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl.org #4633] EVP self test failure with ARMv8 and Aarch32 flags

[noloa...@gmail.com via RT]

>> (gdb) r test/evptests.txt
>> Starting program: /home/jwalton/openssl/test/evp_test test/evptests.txt
>> [Thread debugging using libthread_db enabled]
>> Using host libthread_db library "/lib/arm-linux-gnueabihf/libthread_db.so.1".
>>
>> Program received signal SIGBUS, Bus error.
>> CRYPTO_ccm128_decrypt (ctx=ctx@entry=0x33788,
>> inp=inp@entry=0x33649
>> "\232_\314ʹ\317\004\347)='u\314v\244\210\360B8-\224\233C\267ֻ+\230dxg&",
>> out=,
>> out@entry=0x335d8
>> "\004\065\331v\004\065\331v)='u\314v\244\210\360B8-\224\233C\267ֻ+\230dxg&",
>> len=len@entry=0x20) at crypto/modes/ccm128.c:253
>> 253ctx->cmac.u[0] ^= (scratch.u[0] ^= temp.u[0]);
>> (gdb)
>
> This line is within #if defined(STRICT_ALIGNMENT), which means that
> compiler is responsible for aligning data, and SIGBUS means that it
> failed. And indeed, looking at disassembler output it crashes in vld1.64
> {d16-d17}, [r6 :64], instruction that requires 64-bit alignment. So
> compiler generated the instruction, but didn't care to ensure the
> alignment. There is no other conclusion one can draw but that is indeed
> a compiler bug. Besides, default ./config works just fine and (once
> again) I see no compelling reason for not using it.

I think these are the lines:

#if defined(STRICT_ALIGNMENT)
union {
u64 u[2];
u8 c[16];
} temp;
#endif

...

#if defined(STRICT_ALIGNMENT)
memcpy(temp.c, inp, 16);
ctx->cmac.u[0] ^= (scratch.u[0] ^= temp.u[0]);
ctx->cmac.u[1] ^= (scratch.u[1] ^= temp.u[1]);
...
#endif

I *thought* accessing a union member through its inactive member is
undefined behavior. Once 'scratch.c' and 'temp.c' were used, using
'temp.c' and 'temp.u' leads to the UB.

Maybe my wires are crossed somewhere

Jeff


-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4633
Please log in as guest with password guest if prompted

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl.org #4633] EVP self test failure with ARMv8 and Aarch32 flags

[Andy Polyakov via RT]

On 7/30/2016 8:18 PM, Andy Polyakov via RT wrote:
>>> (gdb) bt full
>>> #0  0x76eef56c in CRYPTO_ccm128_decrypt () from ./libcrypto.so.1.1
>>> No symbol table info available.
>>> #1  0x76ed6708 in aes_ccm_cipher () from ./libcrypto.so.1.1
>>> No symbol table info available.
>>> #2  0x76edcac0 in EVP_DecryptUpdate () from ./libcrypto.so.1.1
>>> No symbol table info available.
>>> #3  0x000149cc in cipher_test_run ()
>>> No symbol table info available.
>>> #4  0x0001408c in setup_test ()
>>> No symbol table info available.
>>> #5  0x00011a48 in main ()
>>> No symbol table info available.
>>
>> OK, -O1 failed to reproduce it; but -O2 reproduced it:
> 
> Well, what can I say? This is first indication that it's a compiler bug...
> 
>> (gdb) r test/evptests.txt
>> Starting program: /home/jwalton/openssl/test/evp_test test/evptests.txt
>> [Thread debugging using libthread_db enabled]
>> Using host libthread_db library "/lib/arm-linux-gnueabihf/libthread_db.so.1".
>>
>> Program received signal SIGBUS, Bus error.
>> CRYPTO_ccm128_decrypt (ctx=ctx@entry=0x33788,
>> inp=inp@entry=0x33649
>> "\232_\314ʹ\317\004\347)='u\314v\244\210\360B8-\224\233C\267ֻ+\230dxg&",
>> out=,
>> out@entry=0x335d8
>> "\004\065\331v\004\065\331v)='u\314v\244\210\360B8-\224\233C\267ֻ+\230dxg&",
>> len=len@entry=0x20) at crypto/modes/ccm128.c:253
>> 253ctx->cmac.u[0] ^= (scratch.u[0] ^= temp.u[0]);
>> (gdb)
> 
> This line is within #if defined(STRICT_ALIGNMENT), which means that
> compiler is responsible for aligning data, and SIGBUS means that it
> failed. And indeed, looking at disassembler output it crashes in vld1.64
> {d16-d17}, [r6 :64], instruction that requires 64-bit alignment. So
> compiler generated the instruction, but didn't care to ensure the
> alignment. There is no other conclusion one can draw but that is indeed
> a compiler bug.

Problematic option seems to be -mfpu=crypto-neon-fp-armv8.

> Besides, default ./config works just fine and (once
> again) I see no compelling reason for not using it.

For reference, specifying -mfpu doesn't really give you an advantage in
OpenSSL. There are no floating-point calculations on
performance-critical paths. And performance-critical cases when NEON is
used for crypto operations, it's done irregardless -mfpu flag. I mean it
will use NEON even if you don't pass -mfpu. In other words, stick to
default configuration...



-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4633
Please log in as guest with password guest if prompted

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl.org #4633] EVP self test failure with ARMv8 and Aarch32 flags

[Andy Polyakov via RT]

>> (gdb) bt full
>> #0  0x76eef56c in CRYPTO_ccm128_decrypt () from ./libcrypto.so.1.1
>> No symbol table info available.
>> #1  0x76ed6708 in aes_ccm_cipher () from ./libcrypto.so.1.1
>> No symbol table info available.
>> #2  0x76edcac0 in EVP_DecryptUpdate () from ./libcrypto.so.1.1
>> No symbol table info available.
>> #3  0x000149cc in cipher_test_run ()
>> No symbol table info available.
>> #4  0x0001408c in setup_test ()
>> No symbol table info available.
>> #5  0x00011a48 in main ()
>> No symbol table info available.
> 
> OK, -O1 failed to reproduce it; but -O2 reproduced it:

Well, what can I say? This is first indication that it's a compiler bug...

> (gdb) r test/evptests.txt
> Starting program: /home/jwalton/openssl/test/evp_test test/evptests.txt
> [Thread debugging using libthread_db enabled]
> Using host libthread_db library "/lib/arm-linux-gnueabihf/libthread_db.so.1".
> 
> Program received signal SIGBUS, Bus error.
> CRYPTO_ccm128_decrypt (ctx=ctx@entry=0x33788,
> inp=inp@entry=0x33649
> "\232_\314ʹ\317\004\347)='u\314v\244\210\360B8-\224\233C\267ֻ+\230dxg&",
> out=,
> out@entry=0x335d8
> "\004\065\331v\004\065\331v)='u\314v\244\210\360B8-\224\233C\267ֻ+\230dxg&",
> len=len@entry=0x20) at crypto/modes/ccm128.c:253
> 253ctx->cmac.u[0] ^= (scratch.u[0] ^= temp.u[0]);
> (gdb)

This line is within #if defined(STRICT_ALIGNMENT), which means that
compiler is responsible for aligning data, and SIGBUS means that it
failed. And indeed, looking at disassembler output it crashes in vld1.64
{d16-d17}, [r6 :64], instruction that requires 64-bit alignment. So
compiler generated the instruction, but didn't care to ensure the
alignment. There is no other conclusion one can draw but that is indeed
a compiler bug. Besides, default ./config works just fine and (once
again) I see no compelling reason for not using it.


-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4633
Please log in as guest with password guest if prompted

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl.org #4633] EVP self test failure with ARMv8 and Aarch32 flags

[noloa...@gmail.com via RT]

> (gdb) bt full
> #0  0x76eef56c in CRYPTO_ccm128_decrypt () from ./libcrypto.so.1.1
> No symbol table info available.
> #1  0x76ed6708 in aes_ccm_cipher () from ./libcrypto.so.1.1
> No symbol table info available.
> #2  0x76edcac0 in EVP_DecryptUpdate () from ./libcrypto.so.1.1
> No symbol table info available.
> #3  0x000149cc in cipher_test_run ()
> No symbol table info available.
> #4  0x0001408c in setup_test ()
> No symbol table info available.
> #5  0x00011a48 in main ()
> No symbol table info available.

OK, -O1 failed to reproduce it; but -O2 reproduced it:

(gdb) r test/evptests.txt
Starting program: /home/jwalton/openssl/test/evp_test test/evptests.txt
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/arm-linux-gnueabihf/libthread_db.so.1".

Program received signal SIGBUS, Bus error.
CRYPTO_ccm128_decrypt (ctx=ctx@entry=0x33788,
inp=inp@entry=0x33649
"\232_\314ʹ\317\004\347)='u\314v\244\210\360B8-\224\233C\267ֻ+\230dxg&",
out=,
out@entry=0x335d8
"\004\065\331v\004\065\331v)='u\314v\244\210\360B8-\224\233C\267ֻ+\230dxg&",
len=len@entry=0x20) at crypto/modes/ccm128.c:253
253ctx->cmac.u[0] ^= (scratch.u[0] ^= temp.u[0]);
(gdb)


Jeff


-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4633
Please log in as guest with password guest if prompted

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl.org #4633] EVP self test failure with ARMv8 and Aarch32 flags

[noloa...@gmail.com via RT]

>> $ make test V=1
>>
>> ok 1 - running enginetest
>> ../util/shlib_wrap.sh ./enginetest => 0
>> ok
>> ../test/recipes/30-test_evp.t ..
>> 1..1
>> not ok 1 - running evp_test evptests.txt
>> ../util/shlib_wrap.sh ./evp_test ../test/evptests.txt => 135
>>
>> #   Failed test 'running evp_test evptests.txt'
>> #   at ../test/recipes/30-test_evp.t line 18.
>> # Looks like you failed 1 test of 1.
>
> Could you execute it manually and tell with line in evptests.txt it fails?

$ LD_LIBRARY_PATH=".:$LD_LIBRARY_PATH" test/evp_test test/evptests.txt
Bus error

Probing further:

$ LD_LIBRARY_PATH=".:$LD_LIBRARY_PATH" gdb test/evp_test
GNU gdb (GDB) 7.11.1
...
Reading symbols from test/evp_test...(no debugging symbols found)...done.
(gdb) r test/evptests.txt
Starting program: /home/jwalton/openssl/test/evp_test test/evptests.txt
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/arm-linux-gnueabihf/libthread_db.so.1".

Program received signal SIGBUS, Bus error.
0x76eef56c in CRYPTO_ccm128_decrypt () from ./libcrypto.so.1.1
(gdb) where
#0  0x76eef56c in CRYPTO_ccm128_decrypt () from ./libcrypto.so.1.1
#1  0x76ed6708 in aes_ccm_cipher () from ./libcrypto.so.1.1
#2  0x76edcac0 in EVP_DecryptUpdate () from ./libcrypto.so.1.1
#3  0x000149cc in cipher_test_run ()
#4  0x0001408c in setup_test ()
#5  0x00011a48 in main ()

(gdb) bt full
#0  0x76eef56c in CRYPTO_ccm128_decrypt () from ./libcrypto.so.1.1
No symbol table info available.
#1  0x76ed6708 in aes_ccm_cipher () from ./libcrypto.so.1.1
No symbol table info available.
#2  0x76edcac0 in EVP_DecryptUpdate () from ./libcrypto.so.1.1
No symbol table info available.
#3  0x000149cc in cipher_test_run ()
No symbol table info available.
#4  0x0001408c in setup_test ()
No symbol table info available.
#5  0x00011a48 in main ()
No symbol table info available.

I've added every directory that has symbols ab object files using 'set
debug-file-directory' and 'set solib-search-path'. It looks like
Aarch64 is another platform GDB is broken on:

(gdb) show debug-file-directory
The directory where separate debug symbols are searched for is
"/usr/local/lib/debug".
(gdb)

Jeff


-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4633
Please log in as guest with password guest if prompted

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl.org #4633] EVP self test failure with ARMv8 and Aarch32 flags

[Andy Polyakov via RT]

> Working from 1a627771634adba9d4f3b5cf7be74d6bab428a5f on a Raspberry
> Pi 3. Its ARMv8 with Broadcom SoC using A53 cores. It lacks Crypto
> extensions, but includes vmull and crc32 (vmull include arrangements
> other than u8).

??? If you're referring to polynomial multiplication, then it's p8, not
u8. But even if you are implying that it implements p64, then I'd ask
where does this information come from? And how would it align with
Cortex-A53 reference manual which says that AES extension and PMULL
availability is denoted by one and same flag? I mean according to
reference there shouldn't be PMULL-capable processor, which is not also
AES-capable...

> The gadget also runs Raspian, which is a 32-bit OS
> with hard floats.
> 
> $ make test V=1
> 
> ok 1 - running enginetest
> ../util/shlib_wrap.sh ./enginetest => 0
> ok
> ../test/recipes/30-test_evp.t ..
> 1..1
> not ok 1 - running evp_test evptests.txt
> ../util/shlib_wrap.sh ./evp_test ../test/evptests.txt => 135
> 
> #   Failed test 'running evp_test evptests.txt'
> #   at ../test/recipes/30-test_evp.t line 18.
> # Looks like you failed 1 test of 1.

Could you execute it manually and tell with line in evptests.txt it fails?


-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4633
Please log in as guest with password guest if prompted

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] [openssl.org #4633] EVP self test failure with ARMv8 and Aarch32 flags

[noloa...@gmail.com via RT]

Working from 1a627771634adba9d4f3b5cf7be74d6bab428a5f on a Raspberry
Pi 3. Its ARMv8 with Broadcom SoC using A53 cores. It lacks Crypto
extensions, but includes vmull and crc32 (vmull include arrangements
other than u8). The gadget also runs Raspian, which is a 32-bit OS
with hard floats.

$ make test V=1

ok 1 - running enginetest
../util/shlib_wrap.sh ./enginetest => 0
ok
../test/recipes/30-test_evp.t ..
1..1
not ok 1 - running evp_test evptests.txt
../util/shlib_wrap.sh ./evp_test ../test/evptests.txt => 135

#   Failed test 'running evp_test evptests.txt'
#   at ../test/recipes/30-test_evp.t line 18.
# Looks like you failed 1 test of 1.
Dubious, test returned 1 (wstat 256, 0x100)
Failed 1/1 subtests
../test/recipes/30-test_evp_extra.t 
1..1
PASS

**

$ ./config -march=armv8-a+crc -mtune=cortex-a53
-mfpu=crypto-neon-fp-armv8 -mfloat-abi=hard
Operating system: armv7l-whatever-linux2
Configuring for linux-armv4
Configuring OpenSSL version 1.1.0-pre6-dev (0x0x1016L)
no-asan [default]  OPENSSL_NO_ASAN (skip dir)
no-crypto-mdebug [default]  OPENSSL_NO_CRYPTO_MDEBUG (skip dir)
no-crypto-mdebug-backtrace [default]
OPENSSL_NO_CRYPTO_MDEBUG_BACKTRACE (skip dir)
no-ec_nistp_64_gcc_128 [default]  OPENSSL_NO_EC_NISTP_64_GCC_128 (skip dir)
no-egd  [default]  OPENSSL_NO_EGD (skip dir)
no-fuzz-afl [default]  OPENSSL_NO_FUZZ_AFL (skip dir)
no-fuzz-libfuzzer [default]  OPENSSL_NO_FUZZ_LIBFUZZER (skip dir)
no-heartbeats   [default]  OPENSSL_NO_HEARTBEATS (skip dir)
no-md2  [default]  OPENSSL_NO_MD2 (skip dir)
no-msan [default]  OPENSSL_NO_MSAN (skip dir)
no-rc5  [default]  OPENSSL_NO_RC5 (skip dir)
no-sctp [default]  OPENSSL_NO_SCTP (skip dir)
no-ssl-trace[default]  OPENSSL_NO_SSL_TRACE (skip dir)
no-ssl3 [default]  OPENSSL_NO_SSL3 (skip dir)
no-ssl3-method  [default]  OPENSSL_NO_SSL3_METHOD (skip dir)
no-ubsan[default]  OPENSSL_NO_UBSAN (skip dir)
no-unit-test[default]  OPENSSL_NO_UNIT_TEST (skip dir)
no-weak-ssl-ciphers [default]  OPENSSL_NO_WEAK_SSL_CIPHERS (skip dir)
no-zlib [default]
no-zlib-dynamic [default]
Configuring for linux-armv4
CC=gcc
CFLAG =-Wall -O3 -pthread  -march=armv8-a+crc
-mtune=cortex-a53 -mfpu=crypto-neon-fp-armv8 -mfloat-abi=hard
-march=armv7-a -Wa,--noexecstack
SHARED_CFLAG  =-fPIC
DEFINES   =DSO_DLFCN HAVE_DLFCN_H NDEBUG OPENSSL_THREADS
OPENSSL_NO_STATIC_ENGINE OPENSSL_PIC OPENSSL_BN_ASM_MONT
OPENSSL_BN_ASM_GF2m SHA1_ASM SHA256_ASM SHA512_ASM AES_ASM BSAES_ASM
GHASH_ASM ECP_NISTZ256_ASM POLY1305_ASM
LFLAG =
PLIB_LFLAG=
EX_LIBS   =-ldl
APPS_OBJ  =
CPUID_OBJ =armcap.o armv4cpuid.o
UPLINK_OBJ=
BN_ASM=bn_asm.o armv4-mont.o armv4-gf2m.o
EC_ASM=ecp_nistz256.o ecp_nistz256-armv4.o
DES_ENC   =des_enc.o fcrypt_b.o
AES_ENC   =aes_cbc.o aes-armv4.o bsaes-armv7.o aesv8-armx.o
BF_ENC=bf_enc.o
CAST_ENC  =c_enc.o
RC4_ENC   =rc4_enc.o rc4_skey.o
RC5_ENC   =rc5_enc.o
MD5_OBJ_ASM   =
SHA1_OBJ_ASM  =sha1-armv4-large.o sha256-armv4.o sha512-armv4.o
RMD160_OBJ_ASM=
CMLL_ENC  =camellia.o cmll_misc.o cmll_cbc.o
MODES_OBJ =ghash-armv4.o ghashv8-armx.o
PADLOCK_OBJ   =
CHACHA_ENC=chacha-armv4.o
POLY1305_OBJ  =poly1305-armv4.o
BLAKE2_OBJ=
PROCESSOR =
RANLIB=ranlib
ARFLAGS   =
PERL  =/usr/bin/perl

THIRTY_TWO_BIT mode
BN_LLONG mode
RC4 uses unsigned char

Configured for linux-armv4.


-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4633
Please log in as guest with password guest if prompted

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] [openssl.org #3143] ENGINE_load_rdrand sane failure code

[Rich Salz via RT]

Seems to be a duplicate of RT 3421; closing.

-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=3143
Please log in as guest with password guest if prompted

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] [openssl.org #4581] [1.0.2] Running tests in parallel results in failure

[Richard Levitte via RT]

Like Rich says, our build system in 1.0.2 doesn't support parallell building or
testing. For upcoming 1.1.0, the build system has been remade from the ground
up, with parallell building in mind. Parallell testing hasn't been tested there
either, though... it might work, it might not. However, the '-j' option for
make till not affect the parallellism of testing in any way.

Closing this ticket.

Cheers,
Richard

On Tue Jun 21 13:14:12 2016, pmen...@molgen.mpg.de wrote:
> Dear OpenSSL folks,
>
>
> downloading the latest 1.0.1t release [1], building it, and running the
> tests in parallel I get the failure below.
>
> I am able to reproduce this, with the branch.*OpenSSL_1_0_2-stable* [2],
> but not with the branch *master*.
>
> With `-j1` and `-j2` the failure is unreproducible. With `-j3` it
> sometimes works and sometimes fails. With `-j4` and greater it reliably
> fails.
>
> ```
> ...long/negative scalar tests allowing precomputation ... without
> precomputation ... ok
> combined multiplication p -> p
> d -> d
> .camellia-128-cbc
> ..n -> d
> ..p -> d
> .camellia-128-cbc base64
> .d -> n
> ...n -> n
> ok
>
> ..testing internal curves: ..camellia-128-ecb
> ..p -> n
> d -> p
> ..n -> p
> .p -> p
> ... ok
>
> camellia-128-ecb base64
> .rsa
> .testing rsa conversions
> p -> d
> .Parsing test certificates
> ...camellia-192-cbc
> p -> p
> OK
> .camellia-192-cbc base64
> d -> d
> .testing crl conversions
> p -> d
> ..p -> d
> ..p -> p
> .camellia-192-ecb
> .d -> p
> ..p -> p
> d -> d
> ...p -> d
> camellia-192-ecb base64
> ..d -> p
> .../util/shlib_wrap.sh ./rsa_test
> ..p -> p
> PKCS #1 v1.5 encryption/decryption ok
> OAEP encryption/decryption ok
> ..camellia-256-cbc
> PKCS #1 v1.5 encryption/decryption ok
> OAEP encryption/decryption ok
> .PKCS #1 v1.5 encryption/decryption ok
> OAEP encryption/decryption ok
> ...testing session-id conversions
> p -> d
> ..p -> p
> ..d -> d
> ..camellia-256-cbc base64
> .p -> d
> ...PKCS #1 v1.5 encryption/decryption ok
> d -> p
> OAEP encryption/decryption ok
> .camellia-256-ecb
> ...PKCS #1 v1.5 encryption/decryption ok
> OAEP encryption/decryption ok
> p -> p
> ...PKCS #1 v1.5 encryption/decryption ok
> OAEP encryption/decryption ok
> ...camellia-256-ecb base64
> Generate and verify a certificate request
> .generating certificate request
> ...rsa
> .There should be a 2 sequences of .'s and some +'s.
> There should not be more that at most 80 per line
> This could take some time.
> cast
> ..Generating a 1024 bit RSA private key
> .cast base64
> ++
> ..cast-cbc
> ..testing req conversions
> ..p -> d
> ...cast-cbc base64
> .Makefile:237: recipe for target 'test_req' failed
> make[1]: *** [test_req] Error 1
> make[1]: *** Waiting for unfinished jobs
> ```
>
>
> Thanks,
>
> Paul
>
>
> PS: I am sorry, if Mozilla Thunderbird wraps the pasted lines.
>
>
> [1] https://www.openssl.org/source/openssl-1.0.1t.tar.gz
> [2] OpenSSL_1_0_2h-88-g4824496 (Fix missing opening braces)
> [3] 6feb3c5 Avoid using latest clang since repo not available
>


--
Richard Levitte
levi...@openssl.org

-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4581
Please log in as guest with password guest if prompted

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl.org #4581] [1.0.2] Running tests in parallel results in failure

[Salz, Rich via RT]

This is not supported.


-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4581
Please log in as guest with password guest if prompted

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl.org #4581] [1.0.2] Running tests in parallel results in failure

[Salz, Rich]

This is not supported.
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] [openssl.org #4581] [1.0.2] Running tests in parallel results in failure

[Paul Menzel via RT]

Dear OpenSSL folks,


downloading the latest 1.0.1t release [1], building it, and running the 
tests in parallel I get the failure below.

I am able to reproduce this, with the branch.*OpenSSL_1_0_2-stable* [2], 
but not with the branch *master*.

With `-j1` and `-j2` the failure is unreproducible. With `-j3` it 
sometimes works and sometimes fails. With `-j4` and greater it reliably 
fails.

```
...long/negative scalar tests allowing precomputation ... without 
precomputation ... ok
combined multiplication p -> p
d -> d
.camellia-128-cbc
..n -> d
..p -> d
.camellia-128-cbc base64
.d -> n
...n -> n
  ok

..testing internal curves: ..camellia-128-ecb
..p -> n
d -> p
..n -> p
.p -> p
... ok

camellia-128-ecb base64
.rsa
.testing rsa conversions
p -> d
.Parsing test certificates
...camellia-192-cbc
p -> p
OK
.camellia-192-cbc base64
d -> d
.testing crl conversions
p -> d
..p -> d
..p -> p
.camellia-192-ecb
.d -> p
..p -> p
d -> d
...p -> d
camellia-192-ecb base64
..d -> p
.../util/shlib_wrap.sh ./rsa_test
..p -> p
PKCS #1 v1.5 encryption/decryption ok
OAEP encryption/decryption ok
..camellia-256-cbc
PKCS #1 v1.5 encryption/decryption ok
OAEP encryption/decryption ok
.PKCS #1 v1.5 encryption/decryption ok
OAEP encryption/decryption ok
...testing session-id conversions
p -> d
..p -> p
..d -> d
..camellia-256-cbc base64
.p -> d
...PKCS #1 v1.5 encryption/decryption ok
d -> p
OAEP encryption/decryption ok
.camellia-256-ecb
...PKCS #1 v1.5 encryption/decryption ok
OAEP encryption/decryption ok
p -> p
...PKCS #1 v1.5 encryption/decryption ok
OAEP encryption/decryption ok
...camellia-256-ecb base64
Generate and verify a certificate request
.generating certificate request
...rsa
.There should be a 2 sequences of .'s and some +'s.
There should not be more that at most 80 per line
This could take some time.
cast
..Generating a 1024 bit RSA private key
.cast base64
++
..cast-cbc
..testing req conversions
..p -> d
...cast-cbc base64
.Makefile:237: recipe for target 'test_req' failed
make[1]: *** [test_req] Error 1
make[1]: *** Waiting for unfinished jobs
```


Thanks,

Paul


PS: I am sorry, if Mozilla Thunderbird wraps the pasted lines.


[1] https://www.openssl.org/source/openssl-1.0.1t.tar.gz
[2] OpenSSL_1_0_2h-88-g4824496 (Fix missing opening braces)
[3] 6feb3c5 Avoid using latest clang since repo not available


-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4581
Please log in as guest with password guest if prompted

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] [openssl.org #3129] Openssl not clearing session ticket upon handshake failure

[Rich Salz via RT]

This hasn't been shown to be repeatable, and it's not clear where the bug is.
Closing the ticket. Sorry for taking so long to get around to this. Please open
a new ticket if you can isolate the issue.

-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=3129
Please log in as guest with password guest if prompted

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] [openssl.org #4523] Failure - make test

[Rich Salz via RT]

Local environment issue; closing ticket.

-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4523
Please log in as guest with password guest if prompted

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] [openssl.org #4403] [PATCH] prevent OPENSSL_realloc() from clobbering old pointer value on failure in OpenSSL-1.1 pre-4

[Stephen Henson via RT]

Fixed now, along with a few similar cases. Thanks for the report.

Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org

-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4403
Please log in as guest with password guest if prompted

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl.org #4523] Failure - make test

[Andy Polyakov via RT]

Hi,

> I got an failure at "make test" sea end of Mail

Well, at the end of the mail it says that it failed to link. It's rather
indication of something going wrong with *your* compiler setup. We more
or less stand for correctness of code and you stand for providing sane
compiler environment it can be compiled in. In other words this is
likely to be non-OpenSSL problem. Judging from presented output it
indeed didn't attempt to build libssl, but why is that it's virtually
impossible to tell. Maybe there was a malformed leftover file left from
previous unsuccessful build attempt... Or in other words this particular
problem is likely for you to solve.

However! I want to point out that formally in this case we can't be held
responsible even for code correctness, because ...

> Target (default): linux-x86_64
> Target:   linux-generic32
> Compiler: Using built-in specs.
> Target: x86_64-suse-linux
> Configured with: ../configure --prefix=/usr --infodir=/usr/share/info 
> --mandir=/
> usr/share/man --libdir=/usr/lib64 --libexecdir=/usr/lib64 
> --enable-languages=c,c
> ++,objc,fortran,obj-c++,java,ada --enable-checking=release 
> --with-gxx-include-di
> r=/usr/include/c++/4.3 --enable-ssp --disable-libssp 
> --with-bugurl=http://bugs.o
> pensuse.org/ --with-pkgversion='SUSE Linux' --disable-libgcj 
> --disable-libmudfla
> p --with-slibdir=/lib64 --with-system-zlib --enable-__cxa_atexit 
> --enable-libstd
> cxx-allocator=new --disable-libstdcxx-pch 
> --enable-version-specific-runtime-libs
> --program-suffix=-4.3 --enable-linux-futex --without-system-libunwind 
> --with-cp
> u=generic --build=x86_64-suse-linux

... your compiler appears to be 64-bit one, but you configure for
linux-generic32. For 64-bit cases there is linux-generic64 and that's
what we support. The fact that linux-generic32 actually worked is
nothing but a fun fact, as we won't accept bug reports if it didn't. One
should also keep in mind that linux-generic* targets are for targets
that don't have explicit platform support. In the context it means that
while we won't refuse to answer the questions about linux-generic64 on
x86_64, we would still keep recommending to adhere to linux-x86_64
configuration on x86_64 Linux system, because that's what is explicitly
tested.


-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4523
Please log in as guest with password guest if prompted

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] [openssl.org #4405] 1.1.0 compile failure with no-comp

[Matt Caswell via RT]

This seems to be working now.

Closing.

Matt

-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4405
Please log in as guest with password guest if prompted

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] [openssl.org #4185] Bug in EVP_MD_CTX_copy_ex's malloc failure handling

[Matt Caswell via RT]

Seems to have been fixed by 6aa0ba4bb28.

Closing.

Matt

-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4185
Please log in as guest with password guest if prompted

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] [openssl.org #4523] Failure - make test

[Richard Levitte via RT]

This ticket is a usage problem. With any Openssl < 1.1.0, it's not a good idea
to run 'make test' without running 'make' first.

Closing this.

--
Richard Levitte
levi...@openssl.org

-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4523
Please log in as guest with password guest if prompted

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl.org #4500] Testing cipher AES-128-XTS(encrypt/decrypt) failure

[Andy Polyakov via RT]

> There is a bug in Hercules 3.12 and below as well as Hyperion.

In other words, not OpenSSL problem, cases are being dismissed.


-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4500
Please log in as guest with password guest if prompted

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl.org #4500] Testing cipher AES-128-XTS(encrypt/decrypt) failure

[Paul Dembry via RT]

There is a bug in Hercules 3.12 and below as well as Hyperion. Here is the fix 
information from the Hercules-390 yahoo group posted yesterday:

2.1 
Defects in PCC and KM instructions -- Patch available for testing 
Tue Apr 26, 2016 1:33 pm (PDT) . Posted by: 
juergen.winkelmann 
Hi All 


Finally, I think the problem originally reported by Paul is solved. The 
solution requires changes to the PCC and to the KM instructions, which is why I 
changed the subject of this thread. A tentative patch is now available for 
download at 


https://polybox.ethz.ch/index.php/s/o2knBR1aHwVCcV3 
https://polybox.ethz.ch/index.php/s/o2knBR1aHwVCcV3 


As usual, the archive contains two versions of the patch, one matching 
dyncrypt.c as found in Spinhawk (at the Hercules 3.12 release level) and 
another matching the current Hyperion. Before applying this patch please make 
sure that my earlier patch to dyncrypt (see the first mail of this thread at 
https://groups.yahoo.com/neo/groups/hercules-390/conversations/messages/78887 
https://groups.yahoo.com/neo/groups/hercules-390/conversations/messages/78887) 
is applied. Currently, Hyperion has it applied, but it isn't yet in Spinhawk. 


Given that the patch is non trivial, I don't recommend as of yet to commit it 
to any of the repositories. Instead I'd appreciate it being tested by users of 
the cryptographic instructions (if there are any). In particular I'd be 
grateful for feedback from Paul and Gert concerning the behavior of the OpenSSL 
installation tests after applying the patch. 


Problem description: 


The XTS related functions (codes 50, 52, 58 and 60 of the KM and the PCC 
instructions) deliver invalid results. Results are stable, except for PCC 
function codes 58 and 60, which deliver arbitrary results. None of the 
functions ever delivers a correct result. 


Root cause: 


The arbitrary results from PCC function codes 58 and 60 are caused by memory 
overlay due to an invalid length (too short) of the parameter block. Fixing 
this overlay makes the results stable, but equally invalid as with the other 
function codes. 
The invalid results come from a misinterpretation of the algorithm to use for 
the GF(2128) multiplication. All diagrams and descriptions in the POP suggest 
it is the same algorithm as used with function code 65 of the KIMD instruction. 
However, it is not: For the GCM situation in KIMD the specification found in 
NIST Special Publication 800-38D, dated November 2007, is relevant, while for 
the XTS situation in KM and PCC the specification found in IEEE standard 
1619-2007 is relevant. In fact, both algorithms are the same (and thus the POP 
is correct). However, the bit order of the arguments isn't the same in both 
standards, which isn't exactly mentioned in the POP (one can find it in the 
prefix pages, once one knows what to search for). 
Solution: 


Fix the memory overlay in PCC and use the correct algorithm for the GF(2128) 
multiplication in KM and PCC. 


Cheers 
Jürgen

**

If you need to get around this without doing the patch, change your Hercules 
configuration to use ARCHMODE ESAME instead of ARCHMODE Z/Arch. This disables 
the cryptography instruction emulation and uses software emulation (at a 
serious performance cost).

Many thanks to Jürgen who has been pounding on this bug ever since I noticed it.
Regards,
Paul




-Original Message-
From: Andy Polyakov via RT [mailto:r...@openssl.org] 
Sent: Wednesday, April 27, 2016 8:04 AM
To: p...@trifox.com
Cc: openssl-dev@openssl.org
Subject: Re: [openssl-dev] [openssl.org #4500] Testing cipher 
AES-128-XTS(encrypt/decrypt) failure

> Hi Paul,

It doesn't seem unlike that OP is not subscribed, so he won't see responses 
send to  alone. To ensure delivery and or reply to 
<r...@openssl.org>.

> I have not checked the code for the test, but I do get the expected 
> values with my little test program.

But what is your host, Massimiliano? Is it also Hercules, and if so which 
version? As Paul indicated later, it might be Hercules bug, and it would be 
helpful if you can tell what's your version. One has to keep in mind that not 
all version implement XTS support...

> Here's the dump (key and iv set to 0
> - block size is 32 bytes (i.e. 2 * 128bit units)):
> 
> AES XTS Encrypt:
> 
> 
> Plaintext (32):
> 0020 - 
> 
> Ciphertext 32:
>  - 91 7c f6 9e bd 68 b2 ec-9b 9f e9 a3 ea dd a6 92  
> .|...h..
> 0010 - cd 43 d2 f5 95 98 ed 85-8c 02 c2 65 2f bf 92 2e  
> .C.e/...
> 
> AES XTS Decrypt:
> 
> 
> Encrypted Data:
>  - 91 7c f6 9e bd 68 b2 ec-9b 9f e9 a3 ea dd a6 92  
> .|...h..
> 0010 - cd 43 d2 f5 95 98 ed 85-8c 02 c2 65 2f bf 92 2e  
> .C.e/...
> 
> Decrypt Offset: 0
> Original Start: 0
> Throw Away: 0
> 
&

Re: [openssl-dev] [openssl.org #4500] Testing cipher AES-128-XTS(encrypt/decrypt) failure

[Andy Polyakov via RT]

> Hi Paul,

It doesn't seem unlike that OP is not subscribed, so he won't see
responses send to  alone. To ensure delivery and or reply
to .

> I have not checked the code for the test, but I do get the expected
> values with my little test program.

But what is your host, Massimiliano? Is it also Hercules, and if so
which version? As Paul indicated later, it might be Hercules bug, and it
would be helpful if you can tell what's your version. One has to keep in
mind that not all version implement XTS support...

> Here's the dump (key and iv set to 0
> - block size is 32 bytes (i.e. 2 * 128bit units)):
> 
> AES XTS Encrypt:
> 
> 
> Plaintext (32):
> 0020 - 
> 
> Ciphertext 32:
>  - 91 7c f6 9e bd 68 b2 ec-9b 9f e9 a3 ea dd a6 92  
> .|...h..
> 0010 - cd 43 d2 f5 95 98 ed 85-8c 02 c2 65 2f bf 92 2e  
> .C.e/...
> 
> AES XTS Decrypt:
> 
> 
> Encrypted Data:
>  - 91 7c f6 9e bd 68 b2 ec-9b 9f e9 a3 ea dd a6 92  
> .|...h..
> 0010 - cd 43 d2 f5 95 98 ed 85-8c 02 c2 65 2f bf 92 2e  
> .C.e/...
> 
> Decrypt Offset: 0
> Original Start: 0
> Throw Away: 0
> 
> Clear Text 32:
> 0020 - 
> 
> My guess is that the second part of the key is not all zeros - this
> would cause you to get the first part of the message encrypted correctly
> and the second part not having the good values... this is just my guess,
> of course.
> 
> Cheers,
> Max


-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4500
Please log in as guest with password guest if prompted

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl.org #4520] Camellia asm build failure for 1.1.0pre5 on Solaris (typo in build.info)

[Andy Polyakov via RT]

> The change
> 
> https://github.com/openssl/openssl/commit/5384d1e4ebd58f31a06b2f5d1f6c4b28f63d72ed
> 
> introduced a typo in the last line of file crypto/camellia/build.info.

Fixed. Thanks for report.



-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4520
Please log in as guest with password guest if prompted

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] [openssl.org #4520] Camellia asm build failure for 1.1.0pre5 on Solaris (typo in build.info)

[Rainer Jung via RT]

The change

https://github.com/openssl/openssl/commit/5384d1e4ebd58f31a06b2f5d1f6c4b28f63d72ed

introduced a typo in the last line of file crypto/camellia/build.info.

The fix is:

--- crypto/camellia/build.info2016-03-16 19:18:09.0 +0100
+++ crypto/camellia/build.info2016-04-19 19:39:11.449856000 +0200
@@ -8,4 +8,4 @@
  GENERATE[cmll-x86_64.s]=asm/cmll-x86_64.pl $(PERLASM_SCHEME)
  GENERATE[cmllt4-sparcv9.S]=asm/cmllt4-sparcv9.pl $(PERLASM_SCHEME)
  INCLUDE[cmllt4-sparcv9.o]=..
-DEPEND[cmllt4-sparcv9.S]=../perlasm/sparcv9-modes.pl
+DEPEND[cmllt4-sparcv9.S]=../perlasm/sparcv9_modes.pl

The correct Perl script name contains an underscore.

This was already reported on dev@ on 2016-04-19. I just wanted to make 
sure it doesn't get missed, therefore this RT.

Regards,

Rainer


-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4520
Please log in as guest with password guest if prompted

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] Camellia asm build failure for 1.1.0pre5 on Solaris (typo in build.info)

[Rainer Jung]

The change

https://github.com/openssl/openssl/commit/5384d1e4ebd58f31a06b2f5d1f6c4b28f63d72ed

introduced a typo in the last line of file crypto/camellia/build.info. 
Fix is:


--- crypto/camellia/build.info  2016-03-16 19:18:09.0 +0100
+++ crypto/camellia/build.info  2016-04-19 19:39:11.449856000 +0200
@@ -8,4 +8,4 @@
 GENERATE[cmll-x86_64.s]=asm/cmll-x86_64.pl $(PERLASM_SCHEME)
 GENERATE[cmllt4-sparcv9.S]=asm/cmllt4-sparcv9.pl $(PERLASM_SCHEME)
 INCLUDE[cmllt4-sparcv9.o]=..
-DEPEND[cmllt4-sparcv9.S]=../perlasm/sparcv9-modes.pl
+DEPEND[cmllt4-sparcv9.S]=../perlasm/sparcv9_modes.pl

The Perl script name contains an underscore.

Regards,

Rainer
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] [openssl.org #4505] RE: Testing cipher AES-128-XTS(encrypt/decrypt) failure

[Paul Dembry via RT]

I lost the email that assigned a request number to this submittal. This may
in fact be an error in the Hercules emulator's implementation of some 390
cryptography instructions so please disregard it. I will re-submit it if it
turns out that it is not a Hercules problem.

Paul

 

From: Paul Dembry [mailto:p...@trifox.com] 
Sent: Wednesday, April 6, 2016 5:56 PM
To: r...@openssl.org
Subject: Testing cipher AES-128-XTS(encrypt/decrypt) failure

 

OpenSSL: Version 1.0.2g

OS: Linux tri26 3.0.13-0.27-default #1 SMP Wed Feb 15 13:33:49 UTC 2012
(d73692b) s390x s390x s390x GNU/Linux

Hardware: Hercules 3.11 emulator, running on Linux rad5 2.6.18.2-34-default
#1 SMP Mon Nov 27 11:46:27 UTC 2006 x86_64 x86_64 x86_64 GNU/Linux

 

make test

 

Testing cipher AES-128-XTS(encrypt/decrypt)

Key

 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

0010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

IV

 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

Plaintext

 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

0010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

Ciphertext

 91 7c f6 9e bd 68 b2 ec 9b 9f e9 a3 ea dd a6 92

0010 cd 43 d2 f5 95 98 ed 85 8c 02 c2 65 2f bf 92 2e

Ciphertext mismatch

Got

 91 7c f6 9e bd 68 b2 ec 9b 9f e9 a3 ea dd a6 92

0010 89 36 96 08 51 3b fa 4f 4e 41 fd cf 81 18 01 b4

Expected

 91 7c f6 9e bd 68 b2 ec 9b 9f e9 a3 ea dd a6 92

0010 cd 43 d2 f5 95 98 ed 85 8c 02 c2 65 2f bf 92 2e

make[1]: *** [test_evp] Error 9

make[1]: Leaving directory `/usr4/tmp/openssl-1.0.2g/test'

make: *** [tests] Error 2

 

Regards,

Paul


-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4505
Please log in as guest with password guest if prompted

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl.org #4500] Testing cipher AES-128-XTS(encrypt/decrypt) failure

[Dr. Pala]

Hi Paul,

I have not checked the code for the test, but I do get the expected 
values with my little test program. Here's the dump (key and iv set to 0 
- block size is 32 bytes (i.e. 2 * 128bit units)):


   AES XTS Encrypt:
   

   Plaintext (32):
   0020 - 

   Ciphertext 32:
    - 91 7c f6 9e bd 68 b2 ec-9b 9f e9 a3 ea dd a6 92 .|...h..
   0010 - cd 43 d2 f5 95 98 ed 85-8c 02 c2 65 2f bf 92 2e .C.e/...

   AES XTS Decrypt:
   

   Encrypted Data:
    - 91 7c f6 9e bd 68 b2 ec-9b 9f e9 a3 ea dd a6 92 .|...h..
   0010 - cd 43 d2 f5 95 98 ed 85-8c 02 c2 65 2f bf 92 2e .C.e/...

   Decrypt Offset: 0
   Original Start: 0
   Throw Away: 0

   Clear Text 32:
   0020 - 

My guess is that the second part of the key is not all zeros - this 
would cause you to get the first part of the message encrypted correctly 
and the second part not having the good values... this is just my guess, 
of course.


Cheers,
Max


On 4/6/16 11:03 PM, Paul Dembry via RT wrote:

OpenSSL: Version 1.0.2g

OS: Linux tri26 3.0.13-0.27-default #1 SMP Wed Feb 15 13:33:49 UTC 2012
(d73692b) s390x s390x s390x GNU/Linux

Hardware: Hercules 3.11 emulator, running on Linux rad5 2.6.18.2-34-default
#1 SMP Mon Nov 27 11:46:27 UTC 2006 x86_64 x86_64 x86_64 GNU/Linux

  


make test

  


Testing cipher AES-128-XTS(encrypt/decrypt)

Key

 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

0010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

IV

 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

Plaintext

 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

0010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

Ciphertext

 91 7c f6 9e bd 68 b2 ec 9b 9f e9 a3 ea dd a6 92

0010 cd 43 d2 f5 95 98 ed 85 8c 02 c2 65 2f bf 92 2e

Ciphertext mismatch

Got

 91 7c f6 9e bd 68 b2 ec 9b 9f e9 a3 ea dd a6 92

0010 89 36 96 08 51 3b fa 4f 4e 41 fd cf 81 18 01 b4

Expected

 91 7c f6 9e bd 68 b2 ec 9b 9f e9 a3 ea dd a6 92

0010 cd 43 d2 f5 95 98 ed 85 8c 02 c2 65 2f bf 92 2e

make[1]: *** [test_evp] Error 9

make[1]: Leaving directory `/usr4/tmp/openssl-1.0.2g/test'

make: *** [tests] Error 2

  


Regards,

Paul





--
Massimiliano Pala, PhD
Director at OpenCA Labs
twitter: @openca

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] [openssl.org #4500] Testing cipher AES-128-XTS(encrypt/decrypt) failure

[Paul Dembry via RT]

OpenSSL: Version 1.0.2g

OS: Linux tri26 3.0.13-0.27-default #1 SMP Wed Feb 15 13:33:49 UTC 2012
(d73692b) s390x s390x s390x GNU/Linux

Hardware: Hercules 3.11 emulator, running on Linux rad5 2.6.18.2-34-default
#1 SMP Mon Nov 27 11:46:27 UTC 2006 x86_64 x86_64 x86_64 GNU/Linux

 

make test

 

Testing cipher AES-128-XTS(encrypt/decrypt)

Key

 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

0010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

IV

 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

Plaintext

 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

0010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

Ciphertext

 91 7c f6 9e bd 68 b2 ec 9b 9f e9 a3 ea dd a6 92

0010 cd 43 d2 f5 95 98 ed 85 8c 02 c2 65 2f bf 92 2e

Ciphertext mismatch

Got

 91 7c f6 9e bd 68 b2 ec 9b 9f e9 a3 ea dd a6 92

0010 89 36 96 08 51 3b fa 4f 4e 41 fd cf 81 18 01 b4

Expected

 91 7c f6 9e bd 68 b2 ec 9b 9f e9 a3 ea dd a6 92

0010 cd 43 d2 f5 95 98 ed 85 8c 02 c2 65 2f bf 92 2e

make[1]: *** [test_evp] Error 9

make[1]: Leaving directory `/usr4/tmp/openssl-1.0.2g/test'

make: *** [tests] Error 2

 

Regards,

Paul


-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4500
Please log in as guest with password guest if prompted

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] [openssl.org #4405] 1.1.0 compile failure with no-comp

[Paul Kehrer via RT]

When trying to compile 1.1.0 with no-comp no-shared flags current master fails 
with the following error on linux:

./libcrypto.so: undefined reference to `COMP_zlib_cleanup'  
collect2: error: ld returned 1 exit status

And perhaps a more instructive one on OS X:

Undefined symbols for architecture x86_64:
  "_COMP_zlib_cleanup", referenced from:
      _OPENSSL_cleanup in libcrypto.a(init.o)
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
make[1]: *** [link_dso.darwin] Error 1
make: *** [engines/dasync.dylib] Error 2


-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4405
Please log in as guest with password guest if prompted

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] [openssl.org #4403] [PATCH] prevent OPENSSL_realloc() from clobbering old pointer value on failure in OpenSSL-1.1 pre-4

[Bill Parker via RT]

Hello All,

In reviewing code in directory 'crypto/modes', file 'ocb128.c', there is a
call to OPENSSL_realloc() which has the potential to clobber the old value
of
variable 'ctx->l', if the call returns NULL.

The patch file below uses a void *tmp_ptr to prevent this from occuring:

--- ocb128.c.orig   2016-03-08 16:29:47.856436204 -0800
+++ ocb128.c2016-03-08 16:31:51.241117763 -0800
@@ -140,6 +140,7 @@
 static OCB_BLOCK *ocb_lookup_l(OCB128_CONTEXT *ctx, size_t idx)
 {
 size_t l_index = ctx->l_index;
+void *tmp_ptr;

 if (idx <= l_index) {
 return ctx->l + idx;
@@ -157,10 +158,11 @@
  * the index.
  */
 ctx->max_l_index += (idx - ctx->max_l_index + 4) & ~3;
-ctx->l =
+tmp_ptr =
 OPENSSL_realloc(ctx->l, ctx->max_l_index * sizeof(OCB_BLOCK));
-if (ctx->l == NULL)
+if (tmp_ptr == NULL) /* prevent ctx->l from being clobbered */
 return NULL;
+   ctx->l = tmp_ptr;
 }
 while (l_index < idx) {
 ocb_double(ctx->l + l_index, ctx->l + l_index + 1);

-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4403
Please log in as guest with password guest if prompted



ocb128.c.patch
Description: Binary data
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] 1.0.2g MacOSX x86_64 build failure (1.0.2f and 1.0.1s are fine)

[Andy Polyakov]

> The only plausible change from 1.0.2f to 1.0.2g that I see that might
> be related to this is below. Does it work if you revert this change
> (patch -R): commit 10c639a8a56c90bec9e332c7ca76ef552b3952ac [snip] 
 Confirmed.  Reverting that commit fixes the build.

>>>
>>> Does the alternate patch from RT #3885 (i.e., from
>>> https://github.com/openssl/openssl/pull/597) cause a similar build breakage?
>>>
>>
>> Confirmed, this alternate patch worked (or at least compiled) fine:
>> https://github.com/akamai/openssl/commit/c4af68c317c025c7d0c4f0495b8115d6426a25be.patch
> 
> I can also confirm that this patch does not have the problem. The test
> suite passes. Is this going to be fixed?

It was addressed in
http://git.openssl.org/gitweb/?p=openssl.git;a=commitdiff;h=6e42e3ff9cde4383049fdafa2a8b37b9485b
(which was cherry-picked to 1.0.2). For the record, why other
suggestions were effectively dismissed. For example there was suggestion
to 'use bigint'. It was not considered as preferable, because as general
rule I try to make *minimal* assumption about availability of add-on
packages. In other words if there is a way to solve it without add-on
package, it would be preferred. myoct was ok, but I've chosen to kind of
emphasize commentary section that precedes those lines, i.e. that that
conversion is really just a prequel to next expression that gets rid of
multiplications (and divisions). I mean that oct thing was there
exclusively in order to simplify that next expression. So I figured why
convert at all, if there are no multiplications (or divisions).

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] 1.0.2g MacOSX x86_64 build failure (1.0.2f and 1.0.1s are fine)

[Clemens Lang]

On Tue, Mar 01, 2016 at 04:52:06PM -0500, Brad House wrote:
> On 03/01/2016 04:27 PM, Benjamin Kaduk wrote:
> > On 03/01/2016 03:18 PM, Brad House wrote:
> >> On 03/01/2016 02:15 PM, Viktor Dukhovni wrote:
> >>> On Tue, Mar 01, 2016 at 12:50:46PM -0500, Brad House wrote:
> >>>
> >>> The only plausible change from 1.0.2f to 1.0.2g that I see that might
> >>> be related to this is below. Does it work if you revert this change
> >>> (patch -R): commit 10c639a8a56c90bec9e332c7ca76ef552b3952ac [snip] 
> >> Confirmed.  Reverting that commit fixes the build.
> >>
> > 
> > Does the alternate patch from RT #3885 (i.e., from
> > https://github.com/openssl/openssl/pull/597) cause a similar build breakage?
> > 
> 
> Confirmed, this alternate patch worked (or at least compiled) fine:
> https://github.com/akamai/openssl/commit/c4af68c317c025c7d0c4f0495b8115d6426a25be.patch

I can also confirm that this patch does not have the problem. The test
suite passes. Is this going to be fixed?

-- 
Clemens Lang
MacPorts
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] Solaris 10 80-test_ca failure

[Erik Forsberg]

My patch will work for both solaris versions then.
Can someone commit the fix ?

>-- Original Message --
>
>Am 03.03.2016 um 18:51 schrieb Erik Forsberg:
>>
>> I have been having 32-bit only test failures from test_ca
>> for quite a while now on Solaris 10 (1.1.pre), Finally figured
>> out what is wrong.
>>
>> I build both 32-bit and 64-bit libraries.
>> My /usr/local/bin/perl is always 64-bit,
>> used to be required for assembler support.
>>
>> LD_PRELOAD is used to force newly built libs into the test process
>> using util/shlib_wrap.sh
>>
>> So, when building 32-bit libs, shlib_wrap tries to preload a 32-bit
>> libcrypto/libssl into the 64-bit perl process when CA.pl is invoked.
>> This causes failure on Solaris 10, but seems to be ignored on Solaris 11.
>>
>> There was specific support to handle 64-bit builds in shlib_wrap, this
>> method also needs to be used for 32-bit builds.
>>
>> This patch makes it work in all cases for me.
>> Someone using SPARC should review what /usr/bin/file
>> reports for an old 32-bit SPARC library (if such still exists)
>> I have no access to SPARC hardware.
>
>% /usr/bin/file /lib/libc.so.1
>
>/lib/libc.so.1: ELF 32-bit MSB dynamic lib SPARC32PLUS Version 1, V8+ 
>Required, dynamically linked, not stripped, no debugging information 
>available
>
>% /usr/bin/file /lib/sparcv9/libc.so
>
>/lib/sparcv9/libc.so:   ELF 64-bit MSB dynamic lib SPARCV9 Version 1, 
>dynamically linked, not stripped, no debugging information available
>
>This was on Solaris 10 Sparc.
>
>Regards,
>
>Rainer
>
>> *** shlib_wrap.sh   Tue Feb 16 23:55:51 2016
>> --- /usr/local/src/openssl-1.1//shlib_wrap.sh   Tue Mar  1 23:21:23 2016
>> ***
>> *** 27,32 
>> --- 27,37 
>>  LD_PRELOAD_64="$LIBCRYPTOSO $LIBSSLSO"; export LD_PRELOAD_64
>>  preload_var=LD_PRELOAD_64
>>  ;;
>> +   *ELF\ 32*SPARC*|*ELF\ 32*80386*)
>> +   [ -n "$LD_LIBRARY_PATH_32" ] && rld_var=LD_LIBRARY_PATH_32
>> +   LD_PRELOAD_32="$LIBCRYPTOSO $LIBSSLSO"; export LD_PRELOAD_32
>> +   preload_var=LD_PRELOAD_32
>> +   ;;
>>  # Why are newly built .so's preloaded anyway? Because run-time
>>  # .so lookup path embedded into application takes precedence
>>  # over LD_LIBRARY_PATH and as result application ends up linking
>>
>
>-- 
>openssl-dev mailing list
>To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] Solaris 10 80-test_ca failure

[Rainer Jung]

Am 03.03.2016 um 18:51 schrieb Erik Forsberg:


I have been having 32-bit only test failures from test_ca
for quite a while now on Solaris 10 (1.1.pre), Finally figured
out what is wrong.

I build both 32-bit and 64-bit libraries.
My /usr/local/bin/perl is always 64-bit,
used to be required for assembler support.

LD_PRELOAD is used to force newly built libs into the test process
using util/shlib_wrap.sh

So, when building 32-bit libs, shlib_wrap tries to preload a 32-bit
libcrypto/libssl into the 64-bit perl process when CA.pl is invoked.
This causes failure on Solaris 10, but seems to be ignored on Solaris 11.

There was specific support to handle 64-bit builds in shlib_wrap, this
method also needs to be used for 32-bit builds.

This patch makes it work in all cases for me.
Someone using SPARC should review what /usr/bin/file
reports for an old 32-bit SPARC library (if such still exists)
I have no access to SPARC hardware.


% /usr/bin/file /lib/libc.so.1

/lib/libc.so.1: ELF 32-bit MSB dynamic lib SPARC32PLUS Version 1, V8+ 
Required, dynamically linked, not stripped, no debugging information 
available


% /usr/bin/file /lib/sparcv9/libc.so

/lib/sparcv9/libc.so:   ELF 64-bit MSB dynamic lib SPARCV9 Version 1, 
dynamically linked, not stripped, no debugging information available


This was on Solaris 10 Sparc.

Regards,

Rainer


*** shlib_wrap.sh   Tue Feb 16 23:55:51 2016
--- /usr/local/src/openssl-1.1//shlib_wrap.sh   Tue Mar  1 23:21:23 2016
***
*** 27,32 
--- 27,37 
 LD_PRELOAD_64="$LIBCRYPTOSO $LIBSSLSO"; export LD_PRELOAD_64
 preload_var=LD_PRELOAD_64
 ;;
+   *ELF\ 32*SPARC*|*ELF\ 32*80386*)
+   [ -n "$LD_LIBRARY_PATH_32" ] && rld_var=LD_LIBRARY_PATH_32
+   LD_PRELOAD_32="$LIBCRYPTOSO $LIBSSLSO"; export LD_PRELOAD_32
+   preload_var=LD_PRELOAD_32
+   ;;
 # Why are newly built .so's preloaded anyway? Because run-time
 # .so lookup path embedded into application takes precedence
 # over LD_LIBRARY_PATH and as result application ends up linking



--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] Solaris 10 80-test_ca failure

[Erik Forsberg]

I have been having 32-bit only test failures from test_ca
for quite a while now on Solaris 10 (1.1.pre), Finally figured
out what is wrong.

I build both 32-bit and 64-bit libraries.
My /usr/local/bin/perl is always 64-bit,
used to be required for assembler support.

LD_PRELOAD is used to force newly built libs into the test process
using util/shlib_wrap.sh

So, when building 32-bit libs, shlib_wrap tries to preload a 32-bit
libcrypto/libssl into the 64-bit perl process when CA.pl is invoked.
This causes failure on Solaris 10, but seems to be ignored on Solaris 11.

There was specific support to handle 64-bit builds in shlib_wrap, this
method also needs to be used for 32-bit builds.

This patch makes it work in all cases for me.
Someone using SPARC should review what /usr/bin/file
reports for an old 32-bit SPARC library (if such still exists)
I have no access to SPARC hardware.


*** shlib_wrap.sh   Tue Feb 16 23:55:51 2016
--- /usr/local/src/openssl-1.1//shlib_wrap.sh   Tue Mar  1 23:21:23 2016
***
*** 27,32 
--- 27,37 
LD_PRELOAD_64="$LIBCRYPTOSO $LIBSSLSO"; export LD_PRELOAD_64
preload_var=LD_PRELOAD_64
;;
+   *ELF\ 32*SPARC*|*ELF\ 32*80386*)
+   [ -n "$LD_LIBRARY_PATH_32" ] && rld_var=LD_LIBRARY_PATH_32
+   LD_PRELOAD_32="$LIBCRYPTOSO $LIBSSLSO"; export LD_PRELOAD_32
+   preload_var=LD_PRELOAD_32
+   ;;
# Why are newly built .so's preloaded anyway? Because run-time
# .so lookup path embedded into application takes precedence
# over LD_LIBRARY_PATH and as result application ends up linking
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] 1.0.2g MacOSX x86_64 build failure (1.0.2f and 1.0.1s are fine)

[Brad House]

On 03/01/2016 04:27 PM, Benjamin Kaduk wrote:
> On 03/01/2016 03:18 PM, Brad House wrote:
>> On 03/01/2016 02:15 PM, Viktor Dukhovni wrote:
>>> On Tue, Mar 01, 2016 at 12:50:46PM -0500, Brad House wrote:
>>>
>>> The only plausible change from 1.0.2f to 1.0.2g that I see that might
>>> be related to this is below. Does it work if you revert this change
>>> (patch -R): commit 10c639a8a56c90bec9e332c7ca76ef552b3952ac [snip] 
>> Confirmed.  Reverting that commit fixes the build.
>>
> 
> Does the alternate patch from RT #3885 (i.e., from
> https://github.com/openssl/openssl/pull/597) cause a similar build breakage?
> 

Confirmed, this alternate patch worked (or at least compiled) fine:
https://github.com/akamai/openssl/commit/c4af68c317c025c7d0c4f0495b8115d6426a25be.patch

-Brad
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] 1.0.2g MacOSX x86_64 build failure (1.0.2f and 1.0.1s are fine)

[Benjamin Kaduk]

On 03/01/2016 03:18 PM, Brad House wrote:
> On 03/01/2016 02:15 PM, Viktor Dukhovni wrote:
>> On Tue, Mar 01, 2016 at 12:50:46PM -0500, Brad House wrote:
>>
>> The only plausible change from 1.0.2f to 1.0.2g that I see that might
>> be related to this is below. Does it work if you revert this change
>> (patch -R): commit 10c639a8a56c90bec9e332c7ca76ef552b3952ac [snip] 
> Confirmed.  Reverting that commit fixes the build.
>

Does the alternate patch from RT #3885 (i.e., from
https://github.com/openssl/openssl/pull/597) cause a similar build breakage?

-Ben
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] 1.0.2g MacOSX x86_64 build failure (1.0.2f and 1.0.1s are fine)

[Brad House]

On 03/01/2016 02:15 PM, Viktor Dukhovni wrote:
> On Tue, Mar 01, 2016 at 12:50:46PM -0500, Brad House wrote:
> 
>> We have a Mac build system running an older version (10.7), targeting 10.6, 
>> which is
>> using this compiler:
>>
>> $ cc --version
>> i686-apple-darwin11-llvm-gcc-4.2 (GCC) 4.2.1 (Based on Apple Inc. build 
>> 5658) (LLVM build 2336.1.00)
>>
>>
>> And while building 1.0.2g released today, we found a build regression for 
>> x86_64, this
>> regression appears to only impact 1.0.2g (1.0.1s also released today is 
>> unaffected,
>> as is the prior 1.0.2f, and 1.0.2g when building 32bit/i386 too is 
>> unaffected).
>>
>> The build error is:
>>
>> cc -I.. -I../.. -I../modes -I../asn1 -I../evp -I../../include  -fPIC 
>> -fno-common -DOPENSSL_PIC -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN 
>> -DHAVE_DLFCN_H -isysroot /Developer/SDKs/MacOSX10.6.sdk/ 
>> -mmacosx-version-min=10.6 -arch x86_64 -O3 -DL_ENDIAN -Wall 
>> -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT
>> -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m 
>> -I/usr/local//ssl-fips-2.0.11-x86_64/include -DSHA1_ASM -DSHA256_ASM 
>> -DSHA512_ASM -DMD5_ASM -DAES_ASM -DVPAES_ASM -DBSAES_ASM -DWHIRLPOOL_ASM 
>> -DGHASH_ASM -DECP_NISTZ256_ASM -c  -o sha1-x86_64.o sha1-x86_64.s
>> sha1-x86_64.s:1243:missing or invalid immediate expression `0b00011011' 
>> taken as 0
>> sha1-x86_64.s:1243:suffix or operands invalid for `pshufd'
>> sha1-x86_64.s:1245:missing or invalid immediate expression `0b00011011' 
>> taken as 0
>> sha1-x86_64.s:1245:suffix or operands invalid for `pshufd'
>> sha1-x86_64.s:1395:missing or invalid immediate expression `0b00011011' 
>> taken as 0
>> sha1-x86_64.s:1395:suffix or operands invalid for `pshufd'
>> sha1-x86_64.s:1396:missing or invalid immediate expression `0b00011011' 
>> taken as 0
>> sha1-x86_64.s:1396:suffix or operands invalid for `pshufd'
> 
> The only plausible change from 1.0.2f to 1.0.2g that I see that
> might be related to this is below.  Does it work if you revert this
> change (patch -R):
> 
> commit 10c639a8a56c90bec9e332c7ca76ef552b3952ac
> [snip]

Confirmed.  Reverting that commit fixes the build.

-Brad
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] 1.0.2g MacOSX x86_64 build failure (1.0.2f and 1.0.1s are fine)

[Viktor Dukhovni]

On Tue, Mar 01, 2016 at 12:50:46PM -0500, Brad House wrote:

> We have a Mac build system running an older version (10.7), targeting 10.6, 
> which is
> using this compiler:
> 
> $ cc --version
> i686-apple-darwin11-llvm-gcc-4.2 (GCC) 4.2.1 (Based on Apple Inc. build 5658) 
> (LLVM build 2336.1.00)
> 
> 
> And while building 1.0.2g released today, we found a build regression for 
> x86_64, this
> regression appears to only impact 1.0.2g (1.0.1s also released today is 
> unaffected,
> as is the prior 1.0.2f, and 1.0.2g when building 32bit/i386 too is 
> unaffected).
> 
> The build error is:
> 
> cc -I.. -I../.. -I../modes -I../asn1 -I../evp -I../../include  -fPIC 
> -fno-common -DOPENSSL_PIC -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN 
> -DHAVE_DLFCN_H -isysroot /Developer/SDKs/MacOSX10.6.sdk/ 
> -mmacosx-version-min=10.6 -arch x86_64 -O3 -DL_ENDIAN -Wall 
> -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT
> -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m 
> -I/usr/local//ssl-fips-2.0.11-x86_64/include -DSHA1_ASM -DSHA256_ASM 
> -DSHA512_ASM -DMD5_ASM -DAES_ASM -DVPAES_ASM -DBSAES_ASM -DWHIRLPOOL_ASM 
> -DGHASH_ASM -DECP_NISTZ256_ASM -c  -o sha1-x86_64.o sha1-x86_64.s
> sha1-x86_64.s:1243:missing or invalid immediate expression `0b00011011' 
> taken as 0
> sha1-x86_64.s:1243:suffix or operands invalid for `pshufd'
> sha1-x86_64.s:1245:missing or invalid immediate expression `0b00011011' 
> taken as 0
> sha1-x86_64.s:1245:suffix or operands invalid for `pshufd'
> sha1-x86_64.s:1395:missing or invalid immediate expression `0b00011011' 
> taken as 0
> sha1-x86_64.s:1395:suffix or operands invalid for `pshufd'
> sha1-x86_64.s:1396:missing or invalid immediate expression `0b00011011' 
> taken as 0
> sha1-x86_64.s:1396:suffix or operands invalid for `pshufd'

The only plausible change from 1.0.2f to 1.0.2g that I see that
might be related to this is below.  Does it work if you revert this
change (patch -R):

commit 10c639a8a56c90bec9e332c7ca76ef552b3952ac
Author: Andy Polyakov 
Date:   Wed Feb 10 15:11:40 2016 +0100

perlasm/x86_64-xlate.pl: pass pure constants verbatim.

RT#3885

Reviewed-by: Rich Salz 
(cherry picked from commit fd7dc201d3b9d43972de6a0e659f7ef6421c99cc)

diff --git a/crypto/perlasm/x86_64-xlate.pl b/crypto/perlasm/x86_64-xlate.pl
index 9c70b8c..ee04221 100755
--- a/crypto/perlasm/x86_64-xlate.pl
+++ b/crypto/perlasm/x86_64-xlate.pl
@@ -198,8 +198,11 @@ my %globals;
if ($gas) {
# Solaris /usr/ccs/bin/as can't handle multiplications
# in $self->{value}
-   $self->{value} =~ s/(?{value} =~ s/([0-9]+\s*[\*\/\%]\s*[0-9]+)/eval($1)/eg;
+   my $value = $self->{value};
+   $value =~ s/(?{value} = $value;
+   }
sprintf "\$%s",$self->{value};
} else {
$self->{value} =~ s/(0b[0-1]+)/oct($1)/eig;

-- 
Viktor.
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] 1.0.2g MacOSX x86_64 build failure (1.0.2f and 1.0.1s are fine)

[Brad House]

We have a Mac build system running an older version (10.7), targeting 10.6, 
which is
using this compiler:

$ cc --version
i686-apple-darwin11-llvm-gcc-4.2 (GCC) 4.2.1 (Based on Apple Inc. build 5658) 
(LLVM build 2336.1.00)


And while building 1.0.2g released today, we found a build regression for 
x86_64, this
regression appears to only impact 1.0.2g (1.0.1s also released today is 
unaffected,
as is the prior 1.0.2f, and 1.0.2g when building 32bit/i386 too is unaffected).

The build error is:

cc -I.. -I../.. -I../modes -I../asn1 -I../evp -I../../include  -fPIC 
-fno-common -DOPENSSL_PIC -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN 
-DHAVE_DLFCN_H -isysroot /Developer/SDKs/MacOSX10.6.sdk/ 
-mmacosx-version-min=10.6 -arch x86_64 -O3 -DL_ENDIAN -Wall -DOPENSSL_IA32_SSE2 
-DOPENSSL_BN_ASM_MONT
-DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m 
-I/usr/local//ssl-fips-2.0.11-x86_64/include -DSHA1_ASM -DSHA256_ASM 
-DSHA512_ASM -DMD5_ASM -DAES_ASM -DVPAES_ASM -DBSAES_ASM -DWHIRLPOOL_ASM 
-DGHASH_ASM -DECP_NISTZ256_ASM -c  -o sha1-x86_64.o sha1-x86_64.s
sha1-x86_64.s:1243:missing or invalid immediate expression `0b00011011' 
taken as 0
sha1-x86_64.s:1243:suffix or operands invalid for `pshufd'
sha1-x86_64.s:1245:missing or invalid immediate expression `0b00011011' 
taken as 0
sha1-x86_64.s:1245:suffix or operands invalid for `pshufd'
sha1-x86_64.s:1395:missing or invalid immediate expression `0b00011011' 
taken as 0
sha1-x86_64.s:1395:suffix or operands invalid for `pshufd'
sha1-x86_64.s:1396:missing or invalid immediate expression `0b00011011' 
taken as 0
sha1-x86_64.s:1396:suffix or operands invalid for `pshufd'



-Brad
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] [openssl.org #4316] Build failure with OPENSSL_NO_DES or OPENSSL_NO_AES defined

[Michele Cicciotti via RT]

Affected version: 1.0.2f

crypto/cms/cms_kari.c calls EVP_des_ede3_wrap without checking whether 
OPENSSL_NO_DES is defined, and EVP_aes_XXX_wrap without checking if 
OPENSSL_NO_AES is defined. See the attached patch for the fix

-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4316
Please log in as guest with password guest if prompted

--- crypto/cms/cms_kari.c
+++ crypto/cms/cms_kari.c
@@ -402,13 +402,22 @@
  * DES3 wrap otherwise use AES wrap similar to key size.
  */
 if (EVP_CIPHER_type(cipher) == NID_des_ede3_cbc)
+#ifdef OPENSSL_NO_DES
+return 0;
+#else
 kekcipher = EVP_des_ede3_wrap();
-else if (keylen <= 16)
+#endif
+else
+#ifdef OPENSSL_NO_AES
+return 0;
+#else
+if (keylen <= 16)
 kekcipher = EVP_aes_128_wrap();
 else if (keylen <= 24)
 kekcipher = EVP_aes_192_wrap();
 else
 kekcipher = EVP_aes_256_wrap();
+#endif
 return EVP_EncryptInit_ex(ctx, kekcipher, NULL, NULL, NULL);
 }
 
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl.org #4171] Compile failure on OS X 10.7 clang with OpenSSL 1.0.2e

[Andy Polyakov via RT]

Hi,

> https://git.openssl.org/gitweb/?p=openssl.git;a=commitdiff;h=301a6dcd4590fb2f69d08259577e215b4cc3caa3#patch5
>  added a check to see if it should use the ADDX instructions based on the 
> clang version. Unfortunately, on older versions of clang on OS X this check 
> incorrectly returns true and compilation then fails due to not knowing the 
> instructions:
> 
> x86_64-mont.s:966:2 error: invalid instruction mnemonic 'adcxq'
> adcxq %rax,%r12
> ^
> 
> The version of the compiler in question is: `Apple LLVM version 4.2 
> (clang-425.0.28) (based on LLVM 3.2svn)` (On an ancient OS X 10.7 VM)
> 
> This issue was also filed in Github 
> (https://github.com/openssl/openssl/issues/494)

This was addressed in
http://git.openssl.org/gitweb/?p=openssl.git;a=commitdiff;h=b9749432346f69b29d82070041e71b237d718ce7
by giving "based on LLVM" higher priority.


-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4171
Please log in as guest with password guest if prompted

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] [openssl.org #4087] Patch for openssl_1_0_2 link failure when OPENSSL_NO_SHA512 defined

[Rich Salz via RT]

Can you re-org the patch so that it doesn't break into the middle if a compound
statement? (across the else)
thanks.
--
Rich Salz, OpenSSL dev team; rs...@openssl.org


-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4087
Please log in as guest with password guest if prompted

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] [openssl.org #3009] test failure, x64 openssl 1.0.1.e on OS X

[Rich Salz via RT]

Sorry we didn't get to this sooner. We're only taking security fixes for 1.0.1
now.
Please open a new ticket if this is still an issue with current releases.
--
Rich Salz, OpenSSL dev team; rs...@openssl.org

___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] [openssl.org #3642] Bug in OpenSSL 1.0.1j version: Decode error in TLS 1.2 handshake failure from client

[Rich Salz via RT]

No reply, cannot reproduce it, closing the ticket.
--
Rich Salz, OpenSSL dev team; rs...@openssl.org

___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] [openssl.org #2298] Build failure on WinCE platform openssl-1.0.0 & 1.0.0a

[Rich Salz via RT]

This is reported against 0.9.x; please open a new ticket if still a problem
with current releases.
--
Rich Salz, OpenSSL dev team; rs...@openssl.org

___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] [openssl.org #2699] openssl dgst -sha1 -verify ... sais verification failure whet it is ok in a concrete set of data

[Rich Salz via RT]

This is reported against 0.9.x and/or 1.0.0; please open a new ticket if still
a problem with current releases.
--
Rich Salz, OpenSSL dev team; rs...@openssl.org

___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] openssl-1.1.0-pre2 make failure with perl-5.8.8 on Linux

[Richard Levitte]

In message  
on Tue, 2 Feb 2016 00:04:57 +0530, J Mohan Rao Arisankala  
said:

mohan> I have a development environment, which uses a very old perl version
mohan> (5.8.8).

That is a very old perl indeed.

That particular issue has been fixed.  However, with such an old perl
version, you might end up in more trouble when testing...  nothing
that can't be fixed with a CPAN install, but...

Is that something that we need to talk about?

Cheers,
Richard

-- 
Richard Levitte levi...@openssl.org
OpenSSL Project http://www.openssl.org/~levitte/
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] [openssl.org #2669] make test failure

[Rich Salz via RT]

This is an issue reported against 0.9.x/1.0.0 If still an issue with current
release, please open a new ticket.
--
Rich Salz, OpenSSL dev team; rs...@openssl.org

___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] [openssl.org #607]: Openssl v1.0.2e: t1_lib.c: Check for incorrect return value leading to SSL negotiation failure

[Chatrath, Neha via RT]

Hello,

I upgraded from OpenSSL version v1.0.2 to v1.0.2e and started observing issues 
in SSL negotiations randomly.
I observed that as part of v1.0.2e, while processing CLIENT_HELLO message in 
t1_lib.c, extra checks for checking return value of HMAC_Update() have been 
added while decrypting the  ticket IE.
Following is the code flow:
ssl3_get_client_hello()
|-ssl_get_prev_session
  |-tls1_process_ticket
|-tls_decrypt_ticket
  |-HMAC_Update   > Check for this function to return a value 
has been added as part of OpenSSL v1.0.2e.
|-EVP_DigestUpdate
  |-ctx->update(ctx, data, count)

The update function in EVP_MD_CTX has a return type void.

Thus, HMAC_Update function end up checking for random values. When the value is 
greater than 0, SSL negotiations are successful but for other values, the 
failure is percolated to the calling functions which typically lead to 
ssl3_accept() failures in my case.

Following is the reference  to the issue in GitHub: 
https://github.com/openssl/openssl/issues/607

As part of the fix, I suggest removing the check for checking the return type 
of HMAC_Update function in tls_decrypt_ticket().

Please find attached patch for the same.

Thanks and regards
Neha Chatrath


DISCLAIMER:
Privileged and/or Confidential information may be contained in this
message. If you are not the addressee of this message, you may not
copy, use or deliver this message to anyone. In such event, you
should destroy the message and kindly notify the sender by reply
e-mail. It is understood that opinions or conclusions that do not
relate to the official business of the company are neither given
nor endorsed by the company.
Thank You.

diff -ur openssl-1.0.2f/ssl/t1_lib.c openssl-1.0.2f_work/ssl/t1_lib.c
--- openssl-1.0.2f/ssl/t1_lib.c 2016-01-28 08:56:08.0 -0500
+++ openssl-1.0.2f_work/ssl/t1_lib.c2016-02-01 19:58:57.0 -0500
@@ -3401,8 +3401,8 @@
 }
 eticklen -= mlen;
 /* Check HMAC of encrypted ticket */
-if (HMAC_Update(, etick, eticklen) <= 0
-|| HMAC_Final(, tick_hmac, NULL) <= 0) {
+HMAC_Update(, etick, eticklen);
+if (HMAC_Final(, tick_hmac, NULL) <= 0) {
 goto err;
 }
 HMAC_CTX_cleanup();
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] openssl-1.1.0-pre2 make failure with perl-5.8.8 on Linux

[J Mohan Rao Arisankala]

Hi,

I have a development environment, which uses a very old perl version
(5.8.8).

The compilation of openssl-1.1.0-pre2 fails with the following error, I
have attached a patch below that worked for me:

make[5]: Entering directory
`/mail/src/mohan/v6.0/buildinstructions/openssl1.1/build64/openssl'
Bareword found where operator expected at util/mkdef.pl line 1573, near
"s/\./_/gr"
Unquoted string "r" may clash with future reserved word at util/mkdef.pl
line 1573.
syntax error at util/mkdef.pl line 1573, near "s/\./_/gr"
Execution of util/mkdef.pl aborted due to compilation errors.
/opt/gcc-4.7.2/lib/gcc/x86_64-unknown-linux-gnu/4.7.2/../../../../x86_64-unknown-linux-gnu/bin/ld:crypto.map:1:
syntax error in VERSION script
collect2: error: ld returned 1 exit status
make[5]: *** [link_a.linux-shared] Error 1



$ perl -v

This is perl, v5.8.8 built for i686-linux-thread-multi

Copyright 1987-2006, Larry Wall
...

+++ +
diff -Nur ../openssl-1.1.0-pre2/util/mkdef.pl ./util/mkdef.pl
--- ../openssl-1.1.0-pre2/util/mkdef.pl 2016-01-14 01:51:33.0 -0800
+++ ./util/mkdef.pl 2016-02-01 09:08:00.0 -0800
@@ -1569,8 +1569,10 @@

  while() {
  if (/OPENSSL_VERSION_TEXT\s+"OpenSSL (\d\.\d\.)(\d[a-z]*)(-| )/) {
+ my $basev = $1;
  my $suffix = $2;
- my $baseversion = $1 =~ s/\./_/gr;
+$basev =~ s/\./_/g;
+ my $baseversion = $basev;
  close IN;
  return ($baseversion."0", $baseversion.$suffix);
  }
+++ +

After applying the patch, the compilation is successful and here is the
openssl version.

$ openssl version -a
OpenSSL 1.1.0-pre2 (alpha) 14 Jan 2016
built on: reproducible build, date unspecified
platform: linux-x86_64
compiler: gcc -I. -I.. -I../include -Iinclude  -fPIC -DOPENSSL_PIC
-DOPENSSL_THREADS -pthread -DDSO_DLFCN -DHAVE_DLFCN_H -I/usr/local/include
-DPURIFY -m64 -DL_ENDIAN -Wall -O3 -DOPENSSL_IA32_SSE2
-DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m
-DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DAES_ASM -DVPAES_ASM
-DBSAES_ASM -DWHIRLPOOL_ASM -DGHASH_ASM -DECP_NISTZ256_ASM
OPENSSLDIR: "/usr/local/etc/ssl"

Please let me know if you need any additional info.

Thanks,
Mohan
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] [openssl.org #3689] Bug report - OpenSSL 0.9.8ze with FIPS canister 1.2.4 big number test failure

[Rich Salz via RT]

we were only taking security fixes back then. closing this.
--
Rich Salz, OpenSSL dev team; rs...@openssl.org

___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] renegotiation failure causes SSL_shutdown to return 1?

[Judson Wilson]

Cool!  Thanks for doing that :)

On Wed, Jan 20, 2016 at 6:04 AM, Matt Caswell  wrote:

>
>
> On 05/12/15 09:42, Judson Wilson wrote:
> > I am noticing the following sequence of events:
> >
> > 1) SSL_renegotiate(...), followed by SSL_write(..., 0) fails when a web
> > server rejects it by sending a TCP FIN
> > 2) SSL_get_error returns SSL_ERROR_SSL
> > 3) SSL_in_init(...) is true
> > 4) SSL_shutdown returns 1 <-- this seems strange.
> >
> > I'm not sure that this is the right behavior.  Shutting down in a
> > handshake without sending/receiving close_notify shouldn't give the
> > "everything shutdown gracefully" signal. Perhaps it would be better to
> > return -1 and signal SSL_ERROR_SSL?
>
> This is fixed now (in master and 1.0.2).
>
> Matt
>
> ___
> openssl-dev mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
>
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl.org #4185] Bug in EVP_MD_CTX_copy_ex's malloc failure handling

[Kurt Roeckx via RT]

On Wed, Dec 16, 2015 at 11:34:56PM +, David Benjamin via RT wrote:
> EVP_MD_CTX_copy_ex is implemented with memcpy, followed by manually fixing
> up |out->pctx| and |out->md_data|.
> 
> https://git.openssl.org/gitweb/?p=openssl.git;a=blob;f=crypto/evp/digest.c;h=5da0e01039a6da039942db9f1bf8b70753f509f2;hb=HEAD#l292
> 
> If allocating |out->md_data| fails, then both |out->pctx| and |in->pctx|
> may point to the same EVP_PKEY_CTX and freeing |out| will cause problems.
> 
> We fixed this by not using memcpy.
> https://boringssl.googlesource.com/boringssl/+/306ece31bcaaed49e0240a2ef8901ebb2d45%5E%21/crypto/digest/digest.c

This patch won't apply as is since we have more fields (engine,
flags).

We also don't have pctx_ops, but have update instead, but already
seem to copy that anyway.


Kurt


___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl.org #4185] Bug in EVP_MD_CTX_copy_ex's malloc failure handling

[David Benjamin via RT]

On Thu, Dec 17, 2015 at 2:43 PM Kurt Roeckx via RT  wrote:

> On Wed, Dec 16, 2015 at 11:34:56PM +, David Benjamin via RT wrote:
> > EVP_MD_CTX_copy_ex is implemented with memcpy, followed by manually
> fixing
> > up |out->pctx| and |out->md_data|.
> >
> >
> https://git.openssl.org/gitweb/?p=openssl.git;a=blob;f=crypto/evp/digest.c;h=5da0e01039a6da039942db9f1bf8b70753f509f2;hb=HEAD#l292
> >
> > If allocating |out->md_data| fails, then both |out->pctx| and |in->pctx|
> > may point to the same EVP_PKEY_CTX and freeing |out| will cause problems.
> >
> > We fixed this by not using memcpy.
> >
> https://boringssl.googlesource.com/boringssl/+/306ece31bcaaed49e0240a2ef8901ebb2d45%5E%21/crypto/digest/digest.c
>
> This patch won't apply as is since we have more fields (engine,
> flags).
>
> We also don't have pctx_ops, but have update instead, but already
> seem to copy that anyway.
>

Right, we've diverged enough at this point that patches not applying as-is
is the norm. :-) That was meant as a reference, but someone will need to do
the equivalent change in OpenSSL if you all like the approach.

David

___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] [openssl.org #4185] Bug in EVP_MD_CTX_copy_ex's malloc failure handling

[Richard Levitte via RT]

Considering we just had a substantial change in digest.c et al, inspiration is
the way to go. I figured that these two lines after the first memcpy() would be
good enough, as those are the variables that get populated afterward:

out->md_data = NULL; out->pctx = NULL;
Cheers,
Richard
Vid Thu, 17 Dec 2015 kl. 19.58.49, skrev david...@google.com:
> On Thu, Dec 17, 2015 at 2:43 PM Kurt Roeckx via RT 
> wrote:
>
> > On Wed, Dec 16, 2015 at 11:34:56PM +, David Benjamin via RT
> > wrote:
> > > EVP_MD_CTX_copy_ex is implemented with memcpy, followed by manually
> > fixing
> > > up |out->pctx| and |out->md_data|.
> > >
> > >
> >
https://git.openssl.org/gitweb/?p=openssl.git;a=blob;f=crypto/evp/digest.c;h=5da0e01039a6da039942db9f1bf8b70753f509f2;hb=HEAD#l292
> > >
> > > If allocating |out->md_data| fails, then both |out->pctx| and |in-
> > > >pctx|
> > > may point to the same EVP_PKEY_CTX and freeing |out| will cause
> > > problems.
> > >
> > > We fixed this by not using memcpy.
> > >
> >
https://boringssl.googlesource.com/boringssl/+/306ece31bcaaed49e0240a2ef8901ebb2d45%5E%21/crypto/digest/digest.c
> >
> > This patch won't apply as is since we have more fields (engine,
> > flags).
> >
> > We also don't have pctx_ops, but have update instead, but already
> > seem to copy that anyway.
> >
>
> Right, we've diverged enough at this point that patches not applying
> as-is
> is the norm. :-) That was meant as a reference, but someone will need
> to do
> the equivalent change in OpenSSL if you all like the approach.
>
> David


--
Richard Levitte
levi...@openssl.org

___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] [openssl.org #4185] Bug in EVP_MD_CTX_copy_ex's malloc failure handling

[David Benjamin via RT]

EVP_MD_CTX_copy_ex is implemented with memcpy, followed by manually fixing
up |out->pctx| and |out->md_data|.

https://git.openssl.org/gitweb/?p=openssl.git;a=blob;f=crypto/evp/digest.c;h=5da0e01039a6da039942db9f1bf8b70753f509f2;hb=HEAD#l292

If allocating |out->md_data| fails, then both |out->pctx| and |in->pctx|
may point to the same EVP_PKEY_CTX and freeing |out| will cause problems.

We fixed this by not using memcpy.
https://boringssl.googlesource.com/boringssl/+/306ece31bcaaed49e0240a2ef8901ebb2d45%5E%21/crypto/digest/digest.c

David

___
openssl-bugs-mod mailing list
openssl-bugs-...@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] [openssl.org #4171] Compile failure on OS X 10.7 clang with OpenSSL 1.0.2e

[Paul Kehrer via RT]

https://git.openssl.org/gitweb/?p=openssl.git;a=commitdiff;h=301a6dcd4590fb2f69d08259577e215b4cc3caa3#patch5
 added a check to see if it should use the ADDX instructions based on the clang 
version. Unfortunately, on older versions of clang on OS X this check 
incorrectly returns true and compilation then fails due to not knowing the 
instructions:

x86_64-mont.s:966:2 error: invalid instruction mnemonic 'adcxq'
adcxq %rax,%r12
^

The version of the compiler in question is: `Apple LLVM version 4.2 
(clang-425.0.28) (based on LLVM 3.2svn)` (On an ancient OS X 10.7 VM)

This issue was also filed in Github 
(https://github.com/openssl/openssl/issues/494)
___
openssl-bugs-mod mailing list
openssl-bugs-...@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] renegotiation failure causes SSL_shutdown to return 1?

[Judson Wilson]

I am noticing the following sequence of events:

1) SSL_renegotiate(...), followed by SSL_write(..., 0) fails when a web
server rejects it by sending a TCP FIN
2) SSL_get_error returns SSL_ERROR_SSL
3) SSL_in_init(...) is true
4) SSL_shutdown returns 1 <-- this seems strange.

I'm not sure that this is the right behavior.  Shutting down in a handshake
without sending/receiving close_notify shouldn't give the "everything
shutdown gracefully" signal. Perhaps it would be better to return -1 and
signal SSL_ERROR_SSL?
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] [openssl.org #4160] Candidate bug, malloc failure related issues in s3_enc.c, hm_pmeth.c

[Trevor Larock via RT]

Hi folks,

Can I ask about malloc failure handling issues, seems affecting OpenSSL 1.0.1p 
and 1.0.2d,

1. In s3_enc.c::ssl3_digest_cached_records, we have the below code.

s->s3->handshake_dgst =
OPENSSL_malloc(SSL_MAX_DIGEST * sizeof(EVP_MD_CTX *));
memset(s->s3->handshake_dgst, 0, SSL_MAX_DIGEST * sizeof(EVP_MD_CTX *));

We are not checking for the return value of the malloc resulting in a straight 
null dereference in the memset.

2. In hm_pmeth.c::pkey_hmac_cleanup

HMAC_PKEY_CTX *hctx = ctx->data;
HMAC_CTX_cleanup(>ctx);

Using hctx when it can be NULL. We could have failed to allocate ctx->data in 
int_ctx_new which calls pmeth->init (alloc can return error here).

Thanks
Trev



___
openssl-bugs-mod mailing list
openssl-bugs-...@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl.org #4083] possible fix to make test failure with openssl-1.0.2d on MinGW...

[Support]

Hi Christian,

A similar patch was already applied to the master branch - see
https://rt.openssl.org/Ticket/Display.html?id=3346 and commit
028bac0670c167f154438742eb4d0fbed73df209

You could cherry-pick the commit and apply it to the 1.0.2 branch.


Cheers,


Peter Mosmans

On 12-10-2015 12:03, christian fafard via RT wrote:
> I'm sorry for that mess with the previous message.There was no CRLF because 
> it was copy-pasted from emacs.
> What i tried to say basically is that the "negate regex match" (!/^0$$/) 
> constructused in the line 244 of 'test/Makefile' does not work with some 
> versions of perl.Like for exemple, perl v5.8.8 in the MinGW/msys distibution.
> That's the reason why 'make test' fail on that platform.
> My proposal is to invert the if/else actions to get rid of the negation in 
> the expression (/^0$$/).
> So the line:
> @ () {if (/^test (.*)/) {print STDERR "\nverify $$1";} elsif (!/^0$$/) 
> {die "\nFailed! bc: $$_";} else {print STDERR "."; $$i++;}} print STDERR 
> "\n$$i tests passed\n"'
> would became:
> @ () {if (/^test (.*)/) {print STDERR "\nverify $$1";} elsif (/^0$$/) 
> {print STDERR "."; $$i++;} else {die "\nFailed! bc: $$_";}} print STDERR 
> "\n$$i tests passed\n"'
> I attached a patch.
> ThanksChristian 
>
>
> ___
> openssl-dev mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl.org #4083] possible fix to make test failure with openssl-1.0.2d on MinGW...

[Support via RT]

Hi Christian,

A similar patch was already applied to the master branch - see
https://rt.openssl.org/Ticket/Display.html?id=3346 and commit
028bac0670c167f154438742eb4d0fbed73df209

You could cherry-pick the commit and apply it to the 1.0.2 branch.


Cheers,


Peter Mosmans

On 12-10-2015 12:03, christian fafard via RT wrote:
> I'm sorry for that mess with the previous message.There was no CRLF because 
> it was copy-pasted from emacs.
> What i tried to say basically is that the "negate regex match" (!/^0$$/) 
> constructused in the line 244 of 'test/Makefile' does not work with some 
> versions of perl.Like for exemple, perl v5.8.8 in the MinGW/msys distibution.
> That's the reason why 'make test' fail on that platform.
> My proposal is to invert the if/else actions to get rid of the negation in 
> the expression (/^0$$/).
> So the line:
> @ () {if (/^test (.*)/) {print STDERR "\nverify $$1";} elsif (!/^0$$/) 
> {die "\nFailed! bc: $$_";} else {print STDERR "."; $$i++;}} print STDERR 
> "\n$$i tests passed\n"'
> would became:
> @ () {if (/^test (.*)/) {print STDERR "\nverify $$1";} elsif (/^0$$/) 
> {print STDERR "."; $$i++;} else {die "\nFailed! bc: $$_";}} print STDERR 
> "\n$$i tests passed\n"'
> I attached a patch.
> ThanksChristian 
>
>
> ___
> openssl-dev mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev


___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl.org #4083] possible fix to make test failure with openssl-1.0.2d on MinGW...

[christian fafard via RT]

Hi Peter,
 
You are completely right! Windows carriage return is the real problem.
 
I should have done better testing before posting a ticket.
 
I'll use your patch until it get commited to the 1.0.2 branch.
 
Thank you
Christian
 
> Subject: Re: [openssl-dev] [openssl.org #4083] possible fix to make test 
> failure with openssl-1.0.2d on MinGW...
> From: r...@openssl.org
> To: c...@hotmail.com
> CC: openssl-dev@openssl.org
> Date: Mon, 12 Oct 2015 06:03:23 +
> 
> 
> Hi Christian,
> 
> A similar patch was already applied to the master branch - see
> https://rt.openssl.org/Ticket/Display.html?id=3346 and commit
> 028bac0670c167f154438742eb4d0fbed73df209
> 
> You could cherry-pick the commit and apply it to the 1.0.2 branch.
> 
> 
> Cheers,
> 
> 
> Peter Mosmans
> 
> On 12-10-2015 12:03, christian fafard via RT wrote:
> > I'm sorry for that mess with the previous message.There was no CRLF because 
> > it was copy-pasted from emacs.
> > What i tried to say basically is that the "negate regex match" (!/^0$$/) 
> > constructused in the line 244 of 'test/Makefile' does not work with some 
> > versions of perl.Like for exemple, perl v5.8.8 in the MinGW/msys 
> > distibution.
> > That's the reason why 'make test' fail on that platform.
> > My proposal is to invert the if/else actions to get rid of the negation in 
> > the expression (/^0$$/).
> > So the line:
> > @ > () {if (/^test (.*)/) {print STDERR "\nverify $$1";} elsif (!/^0$$/) 
> > {die "\nFailed! bc: $$_";} else {print STDERR "."; $$i++;}} print STDERR 
> > "\n$$i tests passed\n"'
> > would became:
> > @ > () {if (/^test (.*)/) {print STDERR "\nverify $$1";} elsif (/^0$$/) 
> > {print STDERR "."; $$i++;} else {die "\nFailed! bc: $$_";}} print STDERR 
> > "\n$$i tests passed\n"'
> > I attached a patch.
> > ThanksChristian   
> >
> >
> > ___
> > openssl-dev mailing list
> > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
> 
> 
  
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl.org #4083] possible fix to make test failure with openssl-1.0.2d on MinGW...

[christian fafard via RT]

I'm sorry for that mess with the previous message.There was no CRLF because it 
was copy-pasted from emacs.
What i tried to say basically is that the "negate regex match" (!/^0$$/) 
constructused in the line 244 of 'test/Makefile' does not work with some 
versions of perl.Like for exemple, perl v5.8.8 in the MinGW/msys distibution.
That's the reason why 'make test' fail on that platform.
My proposal is to invert the if/else actions to get rid of the negation in the 
expression (/^0$$/).
So the line:
@) 
{if (/^test (.*)/) {print STDERR "\nverify $$1";} elsif (!/^0$$/) {die 
"\nFailed! bc: $$_";} else {print STDERR "."; $$i++;}} print STDERR "\n$$i 
tests passed\n"'
would became:
@) 
{if (/^test (.*)/) {print STDERR "\nverify $$1";} elsif (/^0$$/) {print STDERR 
"."; $$i++;} else {die "\nFailed! bc: $$_";}} print STDERR "\n$$i tests 
passed\n"'
I attached a patch.
ThanksChristian   


openssl-1.0.2d-MINGW32.patch
Description: Binary data
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] [openssl.org #4087] Patch for openssl_1_0_2 link failure when OPENSSL_NO_SHA512 defined

[John Peck via RT]

I discovered that when OPENSSL_NO_SHA512 is defined, the openssl_1_0_2 stable 
branch build fails during the link step with unresolved symbol EVP_sha384. The 
attached patch fixes this issue. 

p...@bay2sierra.com 


>From 235d61e3b8d1c0635d18216384c72cdeded3c961 Mon Sep 17 00:00:00 2001
From: John Peck 
Date: Fri, 9 Oct 2015 09:29:08 -0700
Subject: [PATCH] Fixed compile error when OPENSSL_NO_SHA512 is defined

---
 ssl/t1_lib.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/ssl/t1_lib.c b/ssl/t1_lib.c
index 210a5e8..8db3b93 100644
--- a/ssl/t1_lib.c
+++ b/ssl/t1_lib.c
@@ -886,8 +886,10 @@ static int tls1_check_cert_param(SSL *s, X509 *x, int set_ee_md)
 /* Check to see we have necessary signing algorithm */
 if (curve_id[1] == TLSEXT_curve_P_256)
 check_md = NID_ecdsa_with_SHA256;
+# ifndef OPENSSL_NO_SHA512
 else if (curve_id[1] == TLSEXT_curve_P_384)
 check_md = NID_ecdsa_with_SHA384;
+# endif
 else
 return 0;   /* Should never happen */
 for (i = 0; i < c->shared_sigalgslen; i++)
@@ -899,7 +901,11 @@ static int tls1_check_cert_param(SSL *s, X509 *x, int set_ee_md)
 if (check_md == NID_ecdsa_with_SHA256)
 c->pkeys[SSL_PKEY_ECC].digest = EVP_sha256();
 else
+# ifndef OPENSSL_NO_SHA512
 c->pkeys[SSL_PKEY_ECC].digest = EVP_sha384();
+# else
+	return 0; 	/* Should never happen */
+# endif
 }
 }
 return rv;
-- 
1.9.1

___
openssl-bugs-mod mailing list
openssl-bugs-...@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] Patch for openssl_1_0_2 link failure when OPENSSL_NO_SHA512 defined

[John Peck]

I discovered that when OPENSSL_NO_SHA512 is defined, the openssl_1_0_2 stable 
branch build fails during the link step with unresolved symbol EVP_sha384.  The 
attached patch fixes this issue. 

p...@bay2sierra.com 
Mobile: +1-415-420-8449 

From 235d61e3b8d1c0635d18216384c72cdeded3c961 Mon Sep 17 00:00:00 2001
From: John Peck 
Date: Fri, 9 Oct 2015 09:29:08 -0700
Subject: [PATCH] Fixed compile error when OPENSSL_NO_SHA512 is defined

---
 ssl/t1_lib.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/ssl/t1_lib.c b/ssl/t1_lib.c
index 210a5e8..8db3b93 100644
--- a/ssl/t1_lib.c
+++ b/ssl/t1_lib.c
@@ -886,8 +886,10 @@ static int tls1_check_cert_param(SSL *s, X509 *x, int set_ee_md)
 /* Check to see we have necessary signing algorithm */
 if (curve_id[1] == TLSEXT_curve_P_256)
 check_md = NID_ecdsa_with_SHA256;
+# ifndef OPENSSL_NO_SHA512
 else if (curve_id[1] == TLSEXT_curve_P_384)
 check_md = NID_ecdsa_with_SHA384;
+# endif
 else
 return 0;   /* Should never happen */
 for (i = 0; i < c->shared_sigalgslen; i++)
@@ -899,7 +901,11 @@ static int tls1_check_cert_param(SSL *s, X509 *x, int set_ee_md)
 if (check_md == NID_ecdsa_with_SHA256)
 c->pkeys[SSL_PKEY_ECC].digest = EVP_sha256();
 else
+# ifndef OPENSSL_NO_SHA512
 c->pkeys[SSL_PKEY_ECC].digest = EVP_sha384();
+# else
+	return 0; 	/* Should never happen */
+# endif
 }
 }
 return rv;
-- 
1.9.1

___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] [openssl.org #4083] possible fix to make test failure with openssl-1.0.2d on MinGW...

[christian fafard via RT]

With version 'openssl-1.0.2d',in file 'test/Makefile',at line 244 shown above,
@) {if (/^test (.*)/) {print STDERR "\nverify $$1";} elsif (!/^0$$/) 
{die "\nFailed! bc: $$_";} else {print STDERR "."; $$i++;}} print STDERR "\n$$i 
tests passed\n"'
Make test fail because you use this snippet of perl's code '(!/^0$$/)' to match 
any lines not containing only a single zero.It doesn't work as expected with 
the version 5.8.8 of perl distributed with mingw32, as you can see from the 
message above.
verify BN_addFailed! bc: 0make[1]: *** [test_bn] Error 255
I use this equivalent line to avoid the problematic negation of regex match 
'!//',
@) {if (/^test (.*)/) {print STDERR "\nverify $$1";} elsif (/^0$$/) 
{print STDERR "."; $$i++;} else {die "\nFailed! bc: $$_";}} print STDERR "\n$$i 
tests passed\n"'
I'm not expert enough to know if this code is more portable on every platforms 
and versions of perl, i'll leave it to you.
ThanksChristian Fafard
___
openssl-bugs-mod mailing list
openssl-bugs-...@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] [openssl.org #2481] Full-duplex SSL/TLS renegotiation failure (reproducible 100% of the time)

[Matt Caswell via RT]

This as a duplicate of 3712. Closing this ticket in favour of that one. See the
patch associated with that ticket.

Matt

___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] [openssl.org #4062] [PATCH] Fix build failure

[Alessandro Ghedini via RT]

Hello,

due to commit a93d3e0 the ./config script currently fails with the error:

> Operating system: x86_64-whatever-linux2
> This system (linux-x86_64) is not supported. See file INSTALL for details.

see the following GitHub pull request for a fix:
https://github.com/openssl/openssl/pull/412

Cheers

___
openssl-bugs-mod mailing list
openssl-bugs-...@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod

___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] [openssl.org #4062] [PATCH] Fix build failure

[Matt Caswell via RT]

Patch applied. Thanks.

Matt

___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] [openssl.org #4036] Invalid use of memcpy() causing decrypt failure

[John Foley via RT]

We're seeing intermittent failures in the AES key wrap test cases in
test/evp_test in the 1.0.2d release.  We believe the problem is due to
using memcpy() with overlapping src/dst memory regions.  The following
thread provides some insight into this memcpy() issue:

https://bugzilla.redhat.com/show_bug.cgi?id=638477

The documentation for memcpy() states to use memmove() when the memory
regions overlap.  The attached patch resolves the problem.  Please
consider accepting this patch in the 1.0.2 stable and master branches.

Thank you.

diff --git a/crypto/modes/wrap128.c b/crypto/modes/wrap128.c
index 9755cac..979b640 100644
--- a/crypto/modes/wrap128.c
+++ b/crypto/modes/wrap128.c
@@ -76,7 +76,7 @@ size_t CRYPTO_128_wrap(void *key, const unsigned char *iv,
 return 0;
 A = B;
 t = 1;
-memcpy(out + 8, in, inlen);
+memmove(out + 8, in, inlen);
 if (!iv)
 iv = default_iv;
 
@@ -113,7 +113,7 @@ size_t CRYPTO_128_unwrap(void *key, const unsigned char *iv,
 A = B;
 t = 6 * (inlen >> 3);
 memcpy(A, in, 8);
-memcpy(out, in + 8, inlen);
+memmove(out, in + 8, inlen);
 for (j = 0; j < 6; j++) {
 R = out + inlen - 8;
 for (i = 0; i < inlen; i += 8, t--, R -= 8) {
___
openssl-bugs-mod mailing list
openssl-bugs-...@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] [openssl.org #4036] Invalid use of memcpy() causing decrypt failure

[Stephen Henson via RT]

Fixed now in 1.0.2, it was already fixed in master.

Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org

___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] [openssl.org #3484] s3_pkt.c build failure for openssl-SNAP-20140804

[Emilia Käsper via RT]

It's been fixed.

___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] Test failure for windows mingw

[dcruette]

Hello

On the openssl-SNAP-20150824 daily snapshot on Windows Mingw config, I 
have a build failure :


@@@ START test_ec -- private

ec
testing ec private conversions
p - d

read EC key
writing EC key
p - p

read EC key
writing EC key
d - d

read EC key
unable to load Key
4764:error:0D07207B:asn1 encoding routines:ASN1_get_object:header too 
long:asn1_lib.c:149:
4764:error:0D068066:asn1 encoding routines:ASN1_CHECK_TLEN:bad object 
header:tasn_dec.c:1116:
4764:error:0D08403A:asn1 encoding routines:ASN1_TEMPLATE_EX_D2I:nested 
asn1 error:tasn_dec.c:476:Field=parameters, Type=EC_PRIVATEKEY
4764:error:10092010:elliptic curve routines:d2i_ECPrivateKey:EC 
lib:ec_asn1.c:1001:


Didier
http://www.qualitesys.com/

___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] Build failure on SLES11

[Blumenthal, Uri - 0553 - MITLL]

Just to let you ‎know that I thoroughly enjoyed your reply. :-)

Sent from my BlackBerry 10 smartphone on the Verizon Wireless 4G LTE network.

  Original Message  
From: Andy Polyakov
Sent: Thursday, June 11, 2015 10:14
To: openssl-dev@openssl.org
Reply To: openssl-dev@openssl.org
Subject: Re: [openssl-dev] Build failure on SLES11

 It could be the gcc version is too old. Trying to recall, gcc needs to
 be something like 4.4 or newer to support the Intel carry-less multiply
 instruction.

It's pure assembler issue, not compiler. You can compile the module with
gcc 3.x if you wish (I actually do) as long as you have new enough 'as'
on your $PATH.

 I've been trying to build OpenSSL-1.0.2a on an outdated SLES11 system.
 It fails unless I configure with no-asm. Here is the relevant output:

 ghash-x86_64.s: Assembler messages:
 ghash-x86_64.s:1281: Error: no such instruction: `vpclmulqdq
 $17,%xmm2,%xmm0,%xmm1'
 ghash-x86_64.s:1282: Error: no such instruction: `vpclmulqdq
 $0,%xmm2,%xmm0,%xmm0'
 [ ... many identical errors omitted ]


 I believe a check inside ./crypto/modes/asm/ghash-x86_64.pl is
 failing. Here is relevant output that might be of help:

 $ gcc -Wa,-v -c -o /dev/null -x assembler /dev/null
 GNU assembler version 2.19 (x86_64-suse-linux) using BFD version (GNU
 Binutils; SUSE Linux Enterprise 11) 2.19

It's can as well be wrong. I mean it might have to be adjusted as
$1=2.20 instead of 2.19. While AVX support was added in binutils 2.19,
they might have omitted specifically vpclmulqdq. Can you confirm if it
works if you replace 2.19 with 2.20?

___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev



smime.p7s
Description: S/MIME cryptographic signature
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev