From rt at openssl.org  Sun May  1 00:44:52 2016
From: rt at openssl.org (Stephen Henson via RT)
Date: Sun, 01 May 2016 00:44:52 +0000
Subject: [openssl-dev] [openssl.org #4524] [BUG] TLS 1.2 handshake hangs for
	TLS 1.0 only hosts
In-Reply-To: <rt-4.0.19-30104-1462051410-626.4524-6-0@openssl.org>
References: <RT-Ticket-4524@openssl.org>
 <C48F89DA-9096-4D65-A5BB-DD4258ADDC39@newdawn.dk>
 <rt-4.0.19-30103-1462049986-1750.4524-6-0@openssl.org>
 <C355B0E2AAA5D39B.C071986C-E275-46C5-9C71-5D1C65A872EC@mail.outlook.com>
 <rt-4.0.19-30104-1462051410-626.4524-6-0@openssl.org>
Message-ID: <rt-4.0.19-30104-1462063492-749.4524-6-0@openssl.org>

On Sat Apr 30 21:23:30 2016, henrik at newdawn.dk wrote:
> Since this is a MS IIS 7.0 server I would argue that it'd be in the
> interest of openssl to handle the situation rather than accept this
> scenario - since IIS is likely powering more than a few hosts? It is
> possible to have the host correctly list its supported protocols using
> nmap - i'd assume the TLS1.2 attempt can be avoided altogether (
> without knowing any implementation details or if tht adds overhead
> though ) ?
>

As others have indicated this is a known bug with a load balancer and not IIS.

As well as the solutions suggested you can try the -bugs option to s_client
which pads client hellos to workaround this issue.

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=4524
Please log in as guest with password guest if prompted


From rt at openssl.org  Sun May  1 07:32:17 2016
From: rt at openssl.org (Henrik Hofmeister via RT)
Date: Sun, 01 May 2016 07:32:17 +0000
Subject: [openssl-dev] [openssl.org #4524] [BUG] TLS 1.2 handshake hangs
	for TLS 1.0 only hosts
In-Reply-To: <C355B0E2AAA5D39B.C593CA01-8589-47AA-9CE7-F2501ADF957B@mail.outlook.com>
References: <RT-Ticket-4524@openssl.org>
 <C48F89DA-9096-4D65-A5BB-DD4258ADDC39@newdawn.dk>
 <rt-4.0.19-30103-1462049986-1750.4524-6-0@openssl.org>
 <C355B0E2AAA5D39B.C071986C-E275-46C5-9C71-5D1C65A872EC@mail.outlook.com>
 <rt-4.0.19-30104-1462051410-626.4524-6-0@openssl.org>
 <rt-4.0.19-30104-1462063492-749.4524-6-0@openssl.org>
 <C355B0E2AAA5D39B.C593CA01-8589-47AA-9CE7-F2501ADF957B@mail.outlook.com>
Message-ID: <rt-4.0.19-2506-1462087937-1912.4524-6-0@openssl.org>

Thank you all for the assistance - trying to convince Qt/C++ SSL sockets to do as you've described by cutting down on ciphers. I did check std Google Chrome ClientHello which does only contain about 10 cipher suites - where Qt seems to include a lot more (all supported) - so what i'm trying to determine now is which can I safely skip - based on name , bit, protocol - this is for a web browser so if anyone have any insight into which ciphers makes sense here that'd be greatly appreciated - for now i'm trying to just use the same as other browsers.
Thank you again!





On Sat, Apr 30, 2016 at 5:44 PM -0700, "Stephen Henson via RT" <rt at openssl.org> wrote:










On Sat Apr 30 21:23:30 2016, henrik at newdawn.dk wrote:
> Since this is a MS IIS 7.0 server I would argue that it'd be in the
> interest of openssl to handle the situation rather than accept this
> scenario - since IIS is likely powering more than a few hosts? It is
> possible to have the host correctly list its supported protocols using
> nmap - i'd assume the TLS1.2 attempt can be avoided altogether (
> without knowing any implementation details or if tht adds overhead
> though ) ?
>

As others have indicated this is a known bug with a load balancer and not IIS.

As well as the solutions suggested you can try the -bugs option to s_client
which pads client hellos to workaround this issue.

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=4524
Please log in as guest with password guest if prompted







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


From rt at openssl.org  Sun May  1 12:16:27 2016
From: rt at openssl.org (Stephen Henson via RT)
Date: Sun, 01 May 2016 12:16:27 +0000
Subject: [openssl-dev] [openssl.org #4524] [BUG] TLS 1.2 handshake hangs for
	TLS 1.0 only hosts
In-Reply-To: <rt-4.0.19-2506-1462087937-1225.4524-6-0@openssl.org>
References: <RT-Ticket-4524@openssl.org>
 <C48F89DA-9096-4D65-A5BB-DD4258ADDC39@newdawn.dk>
 <rt-4.0.19-30103-1462049986-1750.4524-6-0@openssl.org>
 <C355B0E2AAA5D39B.C071986C-E275-46C5-9C71-5D1C65A872EC@mail.outlook.com>
 <rt-4.0.19-30104-1462051410-626.4524-6-0@openssl.org>
 <rt-4.0.19-30104-1462063492-749.4524-6-0@openssl.org>
 <C355B0E2AAA5D39B.C593CA01-8589-47AA-9CE7-F2501ADF957B@mail.outlook.com>
 <rt-4.0.19-2506-1462087937-1225.4524-6-0@openssl.org>
Message-ID: <rt-4.0.19-2534-1462104987-659.4524-6-0@openssl.org>

On Sun May 01 07:32:17 2016, henrik at newdawn.dk wrote:
> Thank you all for the assistance - trying to convince Qt/C++ SSL
> sockets to do as you've described by cutting down on ciphers. I did
> check std Google Chrome ClientHello which does only contain about 10
> cipher suites - where Qt seems to include a lot more (all supported) -
> so what i'm trying to determine now is which can I safely skip - based
> on name , bit, protocol - this is for a web browser so if anyone have
> any insight into which ciphers makes sense here that'd be greatly
> appreciated - for now i'm trying to just use the same as other
> browsers.

Ah I should've been a bit clearer. The -bugs option does *not* cut down the
number of ciphersuites it adds a bug workaround. If you set the flag
SSL_OP_TLSEXT_PADDING it should work with that server.

In a bit more detail. The original problem was triggered by a ClientHello 256
or more bytes in size and is the load balancer bug. After some consultation
with the vendor it turns out that the bug is triggered by a ClientHello between
256 and 511 bytes in size.So a workaround was developed that pads the
ClientHello so it exceeds 511 bytes in size if it would otherwise be between
256 and 511 bytes.

That's what that flag does if you set it.

So why isn't this the default behaviour of OpenSSL? Well it was at one point
but it turned out a separate implementation (which was OK otherwise) couldn't
handle the larger ClientHello with padding. So some buggy servers choke without
the flag and some with it.

The proper fix of course is for the affected server to update its load
balancing software: the bug is actually several years old now.

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=4524
Please log in as guest with password guest if prompted


From shubham13099 at iiitd.ac.in  Mon May  2 06:53:25 2016
From: shubham13099 at iiitd.ac.in (Shubham Chauhan)
Date: Mon, 2 May 2016 12:23:25 +0530
Subject: [openssl-dev] Storing session in file and reusing at client side
Message-ID: <CAP=zTkNmY=7y_r9bY1nm+AWF_Zq-JVbCuQQMnN6MzHt5O_Cafg@mail.gmail.com>

Hello,

I wanted to store the freshly negotiated ssl/tls session in a file and
reuse it (via SSL_set_session()), in the next handshake. I was not able to
do that since the handshake got terminated giving a fatal error - illegal
parameters (47).

Although this works perfectly fine when I store the session in a global
variable at the client side and use it the next time. But I need to use the
same session across multiple clients (I hope session does not store the IP
and DNS entries).

I had the following questions-
1). Why is the session, when stored in an external file, resulting into the
"illegal parameter" error?
2). Is there some other way to handle the same session among different
client *.c files? Something better than writing down the session in a file
(well, even this does not seems to work for me!)

It'll be great if someone could help me out on this.
Thanks in advance.


-- 
Regards
Shubham Chauhan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20160502/58ae435f/attachment.html>

From janjust at nikhef.nl  Mon May  2 08:06:54 2016
From: janjust at nikhef.nl (Jan Just Keijser)
Date: Mon, 02 May 2016 10:06:54 +0200
Subject: [openssl-dev] Are you using "TLS proxy certificates"?
In-Reply-To: <0215c1be002346f1a1496350f4a48b61@usma1ex-dag1mb1.msg.corp.akamai.com>
References: <0215c1be002346f1a1496350f4a48b61@usma1ex-dag1mb1.msg.corp.akamai.com>
Message-ID: <57270A9E.30806@nikhef.nl>

Hi Rich,

On 27/04/16 18:45, Salz, Rich wrote:
>
> If so, please let us know.  Replies to me will be summarized for the 
> lists.
>
>
what exactly do you mean by 'TLS proxy certificates' ?  if you mean 
RFC3820 (5280) proxy certificates, then yes, we use them extensively 
within grid computing.

regards,

JJK / Jan Just Keijser
Nikhef
Amsterdam


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20160502/2231e748/attachment-0001.html>

From rt at openssl.org  Mon May  2 12:33:23 2016
From: rt at openssl.org (=?UTF-8?B?TMOpbyBMb2dlYXJ0?= via RT)
Date: Mon, 02 May 2016 12:33:23 +0000
Subject: [openssl-dev] [openssl.org #4525] [PATCH] SRP client key
	computation (PR #1017)
In-Reply-To: <CACO4KgY_LsSH3w+vKcK4GdjaaRdMDwAwGQ0UdCFJ6xBLpJwDnQ@mail.gmail.com>
References: <RT-Ticket-4525@openssl.org>
 <CACO4KgY_LsSH3w+vKcK4GdjaaRdMDwAwGQ0UdCFJ6xBLpJwDnQ@mail.gmail.com>
Message-ID: <rt-4.0.19-2506-1462192403-698.4525-21-0@openssl.org>

Hello openSSL devs,

I have found an issue in the computation of the SRP session key on the
client side.
When computing *K = (B ? kg^x**)^(a+ux) mod N*, the computations in the
exponent should not be mod N. Meaning that *(a+ux)* should not go through *mod
N* . It rarely happens that *(a+ux) > N *but when it is, the key computed
on the client side is different from the server's one.

There is a pull request pending to delete the mod operation in the exponent
computation (PR #1017).

Best regards,

Leo Logeart

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


From rt at openssl.org  Mon May  2 12:33:23 2016
From: rt at openssl.org (Ty Baen-Price via RT)
Date: Mon, 02 May 2016 12:33:23 +0000
Subject: [openssl-dev] [openssl.org #4526] bug: use of ExitProcess on
	Windows platforms, 1.0.2g
In-Reply-To: <SN1PR0501MB2078D511BE23F0E661979EB9D8780@SN1PR0501MB2078.namprd05.prod.outlook.com>
References: <RT-Ticket-4526@openssl.org>
 <SN1PR0501MB2078D511BE23F0E661979EB9D8780@SN1PR0501MB2078.namprd05.prod.outlook.com>
Message-ID: <rt-4.0.19-8026-1462192403-1516.4526-21-0@openssl.org>

Hi,

I'm working in the 1.0.2g version of OpenSSL, in a Windows desktop environment, specifically Win 7, 8.1, and 10 (and their equivalent server and R2 versions). 

Problem and Resolution:
The following lines of code make use of the Microsoft API ExitProcess:

Apps\Speed.c line 335:	ExitProcess(ret);
Ms\uplink.c line 22: ExitProcess(1);

These function calls are made after fatal errors are detected and program termination is desired. ExitProcess(), however causes *orderly* shutdown of a process and all its threads, i.e. it unloads all dlls and runs all destructors. See MSDN for details of exactly what happens (https://msdn.microsoft.com/en-us/library/windows/desktop/ms682658(v=vs.85).aspx). The MSDN page states that ExitProcess should never be called unless it is *known to be safe* to call it. These calls should simply be replaced with calls to TerminateProcess(), which is what should be called for *disorderly* shutdown.

An example of usage:
TerminateProcess(GetCurrentProcess(), exitcode);


Effect of Problem:
Because of a compilation error (wrong c++ runtime), my program executed the uplink.c ExitProcess() call. This caused the single OpenSSL thread to start executing the destructors of all my dlls, and their objects. Unfortunately, about 30 other threads were happily using those objects at that time, eventually causing a 0xC0000005 ACCESS_VIOLATION. Obviously an ACCESS_VIOLATION is the best case scenario, as I'm sure you can imagine at the consequences of undiscovered memory corruption, even in a terminating process.

Regards,

Ty Baen-Price
JADE Development Team Leader
Wynyard Group

DDI?+64 3 367 8453

Powerful Software. Connecting the Dots.
wynyardgroup.com



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


From rt at openssl.org  Mon May  2 12:33:25 2016
From: rt at openssl.org (Harry Reimann via RT)
Date: Mon, 02 May 2016 12:33:25 +0000
Subject: [openssl-dev] [openssl.org #4527] Bug in d2i_PrivateKey
	(openssl-1.1.0-pre5)
In-Reply-To: <OF7AF90420.5AB3EE6E-ONC1257FA7.002F4258-C1257FA7.003292B4@rohde-schwarz.com>
References: <RT-Ticket-4527@openssl.org>
 <OF7AF90420.5AB3EE6E-ONC1257FA7.002F4258-C1257FA7.003292B4@rohde-schwarz.com>
Message-ID: <rt-4.0.19-2506-1462192404-481.4527-21-0@openssl.org>

There is a bug in the implementation of d2i_PrivateKey in 
crypto/asn1/d2i_pr.c.
If the function is called with *a != NULL and returns NULL, the value of 
*a is not changed, but the EVP_PKEY it refers to might have been freed or 
not depending on whether line 100 was reached or not. If the caller makes 
the wrong guess this can result in a crash due to a double free or in a 
memory leak.

Best regards
Harry Reimann


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


From rsalz at akamai.com  Mon May  2 12:33:57 2016
From: rsalz at akamai.com (Salz, Rich)
Date: Mon, 2 May 2016 12:33:57 +0000
Subject: [openssl-dev] Are you using "TLS proxy certificates"?
In-Reply-To: <57270A9E.30806@nikhef.nl>
References: <0215c1be002346f1a1496350f4a48b61@usma1ex-dag1mb1.msg.corp.akamai.com>
 <57270A9E.30806@nikhef.nl>
Message-ID: <9ac67e49a17d4896a7a7daeb81ded777@usma1ex-dag1mb1.msg.corp.akamai.com>

Thank you, yes, I mean that.


--
Senior Architect, Akamai Technologies
IM: richsalz at jabber.at Twitter: RichSalz
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20160502/75e9e88b/attachment.html>

From openssl-users at dukhovni.org  Mon May  2 14:04:08 2016
From: openssl-users at dukhovni.org (Viktor Dukhovni)
Date: Mon, 2 May 2016 14:04:08 +0000
Subject: [openssl-dev] Storing session in file and reusing at client side
In-Reply-To: <CAP=zTkNmY=7y_r9bY1nm+AWF_Zq-JVbCuQQMnN6MzHt5O_Cafg@mail.gmail.com>
References: <CAP=zTkNmY=7y_r9bY1nm+AWF_Zq-JVbCuQQMnN6MzHt5O_Cafg@mail.gmail.com>
Message-ID: <20160502140408.GP3300@mournblade.imrryr.org>

On Mon, May 02, 2016 at 12:23:25PM +0530, Shubham Chauhan wrote:

> I wanted to store the freshly negotiated ssl/tls session in a file and
> reuse it (via SSL_set_session()), in the next handshake. I was not able to
> do that since the handshake got terminated giving a fatal error - illegal
> parameters (47).

Client-side sessions can be serialized via i2d_SSL_SESSION and the
resulting binary data can be stored in a file for reuse by a client
via d2i_SSL_SESSION() followed by SSL_set_session() (which copies
the session, so you can free the session obtained via d2i at that
point).

Of course the client needs to want to reconnect to the same SSL
peer with the same security policy, otherwise session reuse is
unwise.

-- 
	Viktor.

From rt at openssl.org  Mon May  2 15:56:23 2016
From: rt at openssl.org (Florent Gluck via RT)
Date: Mon, 02 May 2016 15:56:23 +0000
Subject: [openssl-dev] [openssl.org #4528] Bugfix for linux-armv4 build
In-Reply-To: <57274B95.5030702@hesge.ch>
References: <RT-Ticket-4528@openssl.org> <57274B95.5030702@hesge.ch>
Message-ID: <rt-4.0.19-8026-1462204583-1900.4528-21-0@openssl.org>

Hi,

When compiling for linux-armv4 there is a bug in the master branch, 
version d244dd559d0e6e594e4a0f911e49509e8a7b158b, there is a missing 
backslash in ssl/record/rec_layer_s3.c.
Here is patch for the fix:

--- ssl/record/rec_layer_s3.c.ori 2016-05-02 14:32:28.913137297 +0200
+++ ssl/record/rec_layer_s3.c    2016-05-02 14:35:35.145497035 +0200
@@ -125,7 +125,7 @@
  #if     defined(OPENSSL_SMALL_FOOTPRINT) || \
          !(      defined(AES_ASM) &&     ( \
                  defined(__x86_64)       || defined(__x86_64__)  || \
-                defined(_M_AMD64)       || defined(_M_X64)      )
+                defined(_M_AMD64)       || defined(_M_X64)      ) \
          )
  # undef EVP_CIPH_FLAG_TLS1_1_MULTIBLOCK
  # define EVP_CIPH_FLAG_TLS1_1_MULTIBLOCK 0

Best regards,

-- 
Florent Gluck
Professor
University of Applied Sciences Western Switzerland
HES-SO hepia
Rue de la Prairie 4 - 1202 Geneva - Switzerland
Phone: +41.22.54625.52


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


From rt at openssl.org  Mon May  2 16:01:45 2016
From: rt at openssl.org (Kaduk, Ben via RT)
Date: Mon, 02 May 2016 16:01:45 +0000
Subject: [openssl-dev] [openssl.org #4528] Bugfix for linux-armv4 build
In-Reply-To: <572779E7.6050808@akamai.com>
References: <RT-Ticket-4528@openssl.org> <57274B95.5030702@hesge.ch>
 <rt-4.0.19-8026-1462204583-1900.4528-21-0@openssl.org>
 <572779E7.6050808@akamai.com>
Message-ID: <rt-4.0.19-8026-1462204905-206.4528-6-0@openssl.org>

On 05/02/2016 10:56 AM, Florent Gluck via RT wrote:
> Hi,
>
> When compiling for linux-armv4 there is a bug in the master branch, 
> version d244dd559d0e6e594e4a0f911e49509e8a7b158b, there is a missing 
> backslash in ssl/record/rec_layer_s3.c.
>

Already fixed in commit fbaf30d087a2db2b4e22279e819d481fca21ac5c

-Ben


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


From rt at openssl.org  Mon May  2 16:04:41 2016
From: rt at openssl.org (Rich Salz via RT)
Date: Mon, 02 May 2016 16:04:41 +0000
Subject: [openssl-dev] [openssl.org #4528] Bugfix for linux-armv4 build
In-Reply-To: <57274B95.5030702@hesge.ch>
References: <RT-Ticket-4528@openssl.org> <57274B95.5030702@hesge.ch>
Message-ID: <rt-4.0.19-8026-1462205081-1756.4528-6-0@openssl.org>

commit fbaf30d087a2db2b4e22279e819d481fca21ac5c
Author: Andy Polyakov <appro at openssl.org>
Date: Mon May 2 15:20:41 2016 +0200

ssl/record/rec_layer_s3.c: fix typo from previous commit.

Reviewed-by: Richard Levitte <levitte at openssl.org>

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


From shubham13099 at iiitd.ac.in  Mon May  2 16:33:18 2016
From: shubham13099 at iiitd.ac.in (Shubham Chauhan)
Date: Mon, 2 May 2016 22:03:18 +0530
Subject: [openssl-dev] [openssl-users] Storing session in file and
 reusing at client side
In-Reply-To: <20160502140408.GP3300@mournblade.imrryr.org>
References: <CAP=zTkNmY=7y_r9bY1nm+AWF_Zq-JVbCuQQMnN6MzHt5O_Cafg@mail.gmail.com>
 <20160502140408.GP3300@mournblade.imrryr.org>
Message-ID: <CAP=zTkMax-RRqpY=B+jJXUCt_u++7HVE9UjrXtaAPzcVSJD1mA@mail.gmail.com>

Thanks Viktor.

>
> Client-side sessions can be serialized via i2d_SSL_SESSION and the
> resulting binary data can be stored in a file for reuse by a client
> via d2i_SSL_SESSION() followed by SSL_set_session() (which copies
> the session, so you can free the session obtained via d2i at that
> point).
>
> I did this thing using PEM_write_SSL_SESSION and PEM_write_SSL_SESSION
respectively, which seemed to work for the server side session handling.
But when I use the above mentioned methods, it gives me that illegal
parameter (47) error.
As a matter of fact, I was able to load the session_id into the Client
hello message, and even the server method responded with the same
session_id. But the next message was the fatal error which terminated the
handshake.



> Of course the client needs to want to reconnect to the same SSL
> peer with the same security policy, otherwise session reuse is
> unwise.
>
> I ensured I am using the same client_method (security policy), but still
can't figure out why the error comes up.


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



-- 
Regards
Shubham Chauhan
2013099
B.Tech CSE
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20160502/cefc2b6a/attachment-0001.html>

From rt at openssl.org  Mon May  2 19:00:03 2016
From: rt at openssl.org (Withers John Z via RT)
Date: Mon, 02 May 2016 19:00:03 +0000
Subject: [openssl-dev] [openssl.org #4529] Output of -hash option
	incompatible 64-bit Linux vs 32-bit Linux
In-Reply-To: <CF59E2BB6EB04C4AB71CBCF5716C635666F90617@MTB0120CP3XF04.ds.irsnet.gov>
References: <RT-Ticket-4529@openssl.org>
 <CF59E2BB6EB04C4AB71CBCF5716C635666F90617@MTB0120CP3XF04.ds.irsnet.gov>
Message-ID: <rt-4.0.19-8026-1462215603-430.4529-21-0@openssl.org>

To whom it may concern,

I have built OpenSSL 1.0.1s for 64-bit and 32-bit version of RHEL5.11.  The reasons for this are long and involve my employer, so I would detail them in this message.

I successfully built and deployed to a 64-bit RHEL 5.11 server (using a local installation path) and was able to configure the issuer certificate cache for my applications.  I built a separate package for 32-bit RHEL 5.11 (again, using a local installation path).  After installation, I observed that the -hash option of the openssl command (and hence the c_rehash utility) computed incorrect subject hashes for the issuer certificates in the cache.  Identical certificates from the 64-bit installation were installed but the hash values were different.  Tracing the operation of the s_client module with strace indicated that the hash values computed internally matched the hash values produced on the 64-bit system.  I replicated the symbolic links for the issuer certificates from the 64-bit system to the 32-bit system and the certificates presented by the remote server for my application were verified.

Thanks!

John Withers
Enterprise Operations
Directory Services Branch - OS:CTO:EO:ISD:DSB:PKI
Champaign, Illinois

Phone: (217) 974-7736

"A positive attitude may not solve all of your problems, but it will annoy enough people to make it worth the effort"


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


From rt at openssl.org  Mon May  2 19:13:25 2016
From: rt at openssl.org (Stephen Henson via RT)
Date: Mon, 02 May 2016 19:13:25 +0000
Subject: [openssl-dev] [openssl.org #4529] Output of -hash option
	incompatible 64-bit Linux vs 32-bit Linux
In-Reply-To: <CF59E2BB6EB04C4AB71CBCF5716C635666F90617@MTB0120CP3XF04.ds.irsnet.gov>
References: <RT-Ticket-4529@openssl.org>
 <CF59E2BB6EB04C4AB71CBCF5716C635666F90617@MTB0120CP3XF04.ds.irsnet.gov>
Message-ID: <rt-4.0.19-8026-1462216405-1254.4529-6-0@openssl.org>

On Mon May 02 19:00:03 2016, John.Withers at irs.gov wrote:
>
> I successfully built and deployed to a 64-bit RHEL 5.11 server (using
> a local installation path) and was able to configure the issuer
> certificate cache for my applications. I built a separate package for
> 32-bit RHEL 5.11 (again, using a local installation path). After
> installation, I observed that the -hash option of the openssl command
> (and hence the c_rehash utility) computed incorrect subject hashes for
> the issuer certificates in the cache. Identical certificates from the
> 64-bit installation were installed but the hash values were different.
> Tracing the operation of the s_client module with strace indicated
> that the hash values computed internally matched the hash values
> produced on the 64-bit system. I replicated the symbolic links for
> the issuer certificates from the 64-bit system to the 32-bit system
> and the certificates presented by the remote server for my application
> were verified.
>

That shouldn't happen: the alrgorithms used are independent of the platform so
whether it is 32 or 64 bits or a completely different OS shouldn't matter.

Is it possible you were accidentally using OpenSSL 0.9.8 (maybe the system
version) at some point? The hash algorithm used is different between 0.9.8 and
1.0.0+

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=4529
Please log in as guest with password guest if prompted


From rt at openssl.org  Mon May  2 23:18:24 2016
From: rt at openssl.org (=?UTF-8?B?RW1pbGlhIEvDpHNwZXI=?= via RT)
Date: Mon, 02 May 2016 23:18:24 +0000
Subject: [openssl-dev] [openssl.org #4433] Memory leak in X509_REQ_to_X509
In-Reply-To: <B0E19000-8E78-4C09-8EB3-E733C5AB6593@mediafon.id>
References: <RT-Ticket-4433@openssl.org>
 <B0E19000-8E78-4C09-8EB3-E733C5AB6593@mediafon.id>
Message-ID: <rt-4.0.19-8026-1462231104-801.4433-6-0@openssl.org>

X509_REQ_to_X509 returns a newly allocated X509 structure.

If you believe that it leaks somewhere else, then please reopen this ticket
with fully self-contained code, and a trace (e.g., from valgrind) showing where
the leak happens.

Emilia

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


From rt at openssl.org  Mon May  2 23:20:58 2016
From: rt at openssl.org (=?UTF-8?B?RW1pbGlhIEvDpHNwZXI=?= via RT)
Date: Mon, 02 May 2016 23:20:58 +0000
Subject: [openssl-dev] [openssl.org #4506] Add SSL_CTX_get_ciphers() [GitHub
	PR #957]
In-Reply-To: <5ec8171e-2d59-c7e9-bb84-5f3a2795c9b8@rhe.jp>
References: <RT-Ticket-4506@openssl.org>
 <5ec8171e-2d59-c7e9-bb84-5f3a2795c9b8@rhe.jp>
Message-ID: <rt-4.0.19-8026-1462231258-1169.4506-6-0@openssl.org>

Resolving, this has been merged.

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


From janjust at nikhef.nl  Tue May  3 10:59:46 2016
From: janjust at nikhef.nl (Jan Just Keijser)
Date: Tue, 03 May 2016 12:59:46 +0200
Subject: [openssl-dev] [openssl.org #4529] Output of -hash
 option	incompatible 64-bit Linux vs 32-bit Linux
In-Reply-To: <rt-4.0.19-8026-1462215603-430.4529-21-0@openssl.org>
References: <RT-Ticket-4529@openssl.org>
 <CF59E2BB6EB04C4AB71CBCF5716C635666F90617@MTB0120CP3XF04.ds.irsnet.gov>
 <rt-4.0.19-8026-1462215603-430.4529-21-0@openssl.org>
Message-ID: <572884A2.1020600@nikhef.nl>

Withers John Z via RT wrote:
> To whom it may concern,
>
> I have built OpenSSL 1.0.1s for 64-bit and 32-bit version of RHEL5.11.  The reasons for this are long and involve my employer, so I would detail them in this message.
>
> I successfully built and deployed to a 64-bit RHEL 5.11 server (using a local installation path) and was able to configure the issuer certificate cache for my applications.  I built a separate package for 32-bit RHEL 5.11 (again, using a local installation path).  After installation, I observed that the -hash option of the openssl command (and hence the c_rehash utility) computed incorrect subject hashes for the issuer certificates in the cache.  Identical certificates from the 64-bit installation were installed but the hash values were different.  Tracing the operation of the s_client module with strace indicated that the hash values computed internally matched the hash values produced on the 64-bit system.  I replicated the symbolic links for the issuer certificates from the 64-bit system to the 32-bit system and the certificates presented by the remote server for my application were verified.
>
>   

FWIW: I've downloaded and built openssl-1.0.1s on my EL 5.11 box in both 
32bit and 64bit mode (I needed to hack ./Configure for that, BTW).  The 
resulting
  openssl x509 -hash
command prints out the exact same hash for both the 32bit and 64bit 
versions.

HTH,

JJK / Jan Just Keijser
Nikhef
Amsterdam



From rt at openssl.org  Tue May  3 11:33:09 2016
From: rt at openssl.org (Jan Just Keijser via RT)
Date: Tue, 03 May 2016 11:33:09 +0000
Subject: [openssl-dev] [openssl.org #4529] Output of -hash option
	incompatible 64-bit Linux vs 32-bit Linux
In-Reply-To: <572884A2.1020600@nikhef.nl>
References: <RT-Ticket-4529@openssl.org>
 <CF59E2BB6EB04C4AB71CBCF5716C635666F90617@MTB0120CP3XF04.ds.irsnet.gov>
 <rt-4.0.19-8026-1462215603-430.4529-21-0@openssl.org>
 <572884A2.1020600@nikhef.nl>
Message-ID: <rt-4.0.19-2506-1462275189-971.4529-6-0@openssl.org>

Withers John Z via RT wrote:
> To whom it may concern,
>
> I have built OpenSSL 1.0.1s for 64-bit and 32-bit version of RHEL5.11.  The reasons for this are long and involve my employer, so I would detail them in this message.
>
> I successfully built and deployed to a 64-bit RHEL 5.11 server (using a local installation path) and was able to configure the issuer certificate cache for my applications.  I built a separate package for 32-bit RHEL 5.11 (again, using a local installation path).  After installation, I observed that the -hash option of the openssl command (and hence the c_rehash utility) computed incorrect subject hashes for the issuer certificates in the cache.  Identical certificates from the 64-bit installation were installed but the hash values were different.  Tracing the operation of the s_client module with strace indicated that the hash values computed internally matched the hash values produced on the 64-bit system.  I replicated the symbolic links for the issuer certificates from the 64-bit system to the 32-bit system and the certificates presented by the remote server for my application were verified.
>
>   

FWIW: I've downloaded and built openssl-1.0.1s on my EL 5.11 box in both 
32bit and 64bit mode (I needed to hack ./Configure for that, BTW).  The 
resulting
  openssl x509 -hash
command prints out the exact same hash for both the 32bit and 64bit 
versions.

HTH,

JJK / Jan Just Keijser
Nikhef
Amsterdam



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


From rt at openssl.org  Tue May  3 13:08:54 2016
From: rt at openssl.org (Withers John Z via RT)
Date: Tue, 03 May 2016 13:08:54 +0000
Subject: [openssl-dev] [openssl.org #4529] Output of -hash option
	incompatible 64-bit Linux vs 32-bit Linux
In-Reply-To: <CF59E2BB6EB04C4AB71CBCF5716C635666F91E66@MTB0120CP3XF04.ds.irsnet.gov>
References: <RT-Ticket-4529@openssl.org>
 <CF59E2BB6EB04C4AB71CBCF5716C635666F90617@MTB0120CP3XF04.ds.irsnet.gov>
 <rt-4.0.19-8026-1462215603-430.4529-21-0@openssl.org>
 <572884A2.1020600@nikhef.nl>
 <rt-4.0.19-2506-1462275189-971.4529-6-0@openssl.org>
 <CF59E2BB6EB04C4AB71CBCF5716C635666F91E66@MTB0120CP3XF04.ds.irsnet.gov>
Message-ID: <rt-4.0.19-8026-1462280934-1014.4529-6-0@openssl.org>

Thanks to all for their responses.

I repeated my testing several times before submitting my original comment.  Now, it appears, it was a classic case of 'user error' where the PATH was not set correctly.

My apologies for any inconvenience.

I was able to build the package into an RPM for both 32-bit and 64-bit RHEL 5.11.  I had to make a number of editorial changes to the RPMBUILD spec file as files were not included and paths were hard coded.

John Withers
Enterprise Operations
Directory Services Branch - OS:CTO:EO:ISD:DSB:PKI
Champaign, Illinois
?
Phone: (217) 974-7736

-----Original Message-----
From: Jan Just Keijser via RT [mailto:rt at openssl.org] 
Sent: Tuesday, May 03, 2016 6:33 AM
To: Withers John Z
Cc: openssl-dev at openssl.org
Subject: Re: [openssl-dev] [openssl.org #4529] Output of -hash option incompatible 64-bit Linux vs 32-bit Linux

Withers John Z via RT wrote:
> To whom it may concern,
>
> I have built OpenSSL 1.0.1s for 64-bit and 32-bit version of RHEL5.11.  The reasons for this are long and involve my employer, so I would detail them in this message.
>
> I successfully built and deployed to a 64-bit RHEL 5.11 server (using a local installation path) and was able to configure the issuer certificate cache for my applications.  I built a separate package for 32-bit RHEL 5.11 (again, using a local installation path).  After installation, I observed that the -hash option of the openssl command (and hence the c_rehash utility) computed incorrect subject hashes for the issuer certificates in the cache.  Identical certificates from the 64-bit installation were installed but the hash values were different.  Tracing the operation of the s_client module with strace indicated that the hash values computed internally matched the hash values produced on the 64-bit system.  I replicated the symbolic links for the issuer certificates from the 64-bit system to the 32-bit system and the certificates presented by the remote server for my application were verified.
>
>   

FWIW: I've downloaded and built openssl-1.0.1s on my EL 5.11 box in both 
32bit and 64bit mode (I needed to hack ./Configure for that, BTW).  The 
resulting
  openssl x509 -hash
command prints out the exact same hash for both the 32bit and 64bit 
versions.

HTH,

JJK / Jan Just Keijser
Nikhef
Amsterdam



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


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


From rt at openssl.org  Tue May  3 13:14:59 2016
From: rt at openssl.org (Rich Salz via RT)
Date: Tue, 03 May 2016 13:14:59 +0000
Subject: [openssl-dev] [openssl.org #4529] Output of -hash option
	incompatible 64-bit Linux vs 32-bit Linux
In-Reply-To: <CF59E2BB6EB04C4AB71CBCF5716C635666F90617@MTB0120CP3XF04.ds.irsnet.gov>
References: <RT-Ticket-4529@openssl.org>
 <CF59E2BB6EB04C4AB71CBCF5716C635666F90617@MTB0120CP3XF04.ds.irsnet.gov>
Message-ID: <rt-4.0.19-2506-1462281299-90.4529-6-0@openssl.org>

Closing as it was a PATH confusion, not a bug.

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


From openssl at openssl.org  Tue May  3 14:02:15 2016
From: openssl at openssl.org (OpenSSL)
Date: Tue, 3 May 2016 14:02:15 +0000
Subject: [openssl-dev] OpenSSL version 1.0.1t published
Message-ID: <20160503140215.GA9895@openssl.org>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


   OpenSSL version 1.0.1t released
   ===============================

   OpenSSL - The Open Source toolkit for SSL/TLS
   https://www.openssl.org/

   The OpenSSL project team is pleased to announce the release of
   version 1.0.1t of our open source toolkit for SSL/TLS. For details
   of changes and known issues see the release notes at:

        https://www.openssl.org/news/openssl-1.0.1-notes.html

   OpenSSL 1.0.1t is available for download via HTTP and FTP from the
   following master locations (you can find the various FTP mirrors under
   https://www.openssl.org/source/mirror.html):

     * https://www.openssl.org/source/
     * ftp://ftp.openssl.org/source/

   The distribution file name is:

    o openssl-1.0.1t.tar.gz
      Size: 4556447
      SHA1 checksum: a684ba59d6721a90f354b1953e19611646be7e7d
      SHA256 checksum: 4a6ee491a2fdb22e519c76fdc2a628bb3cec12762cd456861d207996c8a07088

   The checksums were calculated using the following commands:

    openssl sha1 openssl-1.0.1t.tar.gz
    openssl sha256 openssl-1.0.1t.tar.gz

   Yours,

   The OpenSSL Project Team.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQEcBAEBAgAGBQJXKKyEAAoJENnE0m0OYESRqdwH/19mvgPkcFwhZf8BEOcLNp8R
ZMm6Equ16mZ6V/cpFiQX8YgFE3+4xAZu8c7K8luolVB/T5Y6DT7hk6j0T2HNyg39
osuKPrJI88MBGSGOyxE0mxtoktbM5TKQpkEhlUrqRkr3CA8Lr6IVDyG5xNHnKoPx
1BX0UdbCPWn3hHqcCVbQ4c5ShkDO8fRvtBp0btiwjdui8j2sTMzYHwvpWYhjj44o
kOHeqXYmi++rWE9yRlH0ZhKg2RiRR7a2PEoe4eVgz3OCmiY9l4HsvJgA+yxkA0PH
2ZkitzB36UGDOEZm/6+/BbH2GzwXByrK3j01NGNAZlIQIehHepG/DT3THwE6kk4=
=L527
-----END PGP SIGNATURE-----

From openssl at openssl.org  Tue May  3 14:02:32 2016
From: openssl at openssl.org (OpenSSL)
Date: Tue, 3 May 2016 14:02:32 +0000
Subject: [openssl-dev] OpenSSL version 1.0.2h published
Message-ID: <20160503140232.GA9948@openssl.org>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


   OpenSSL version 1.0.2h released
   ===============================

   OpenSSL - The Open Source toolkit for SSL/TLS
   https://www.openssl.org/

   The OpenSSL project team is pleased to announce the release of
   version 1.0.2h of our open source toolkit for SSL/TLS. For details
   of changes and known issues see the release notes at:

        https://www.openssl.org/news/openssl-1.0.2-notes.html

   OpenSSL 1.0.2h is available for download via HTTP and FTP from the
   following master locations (you can find the various FTP mirrors under
   https://www.openssl.org/source/mirror.html):

     * https://www.openssl.org/source/
     * ftp://ftp.openssl.org/source/

   The distribution file name is:

    o openssl-1.0.2h.tar.gz
      Size: 5274412
      SHA1 checksum: 577585f5f5d299c44dd3c993d3c0ac7a219e4949
      SHA256 checksum: 1d4007e53aad94a5b2002fe045ee7bb0b3d98f1a47f8b2bc851dcd1c74332919

   The checksums were calculated using the following commands:

    openssl sha1 openssl-1.0.2h.tar.gz
    openssl sha256 openssl-1.0.2h.tar.gz

   Yours,

   The OpenSSL Project Team.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQEcBAEBAgAGBQJXKKvFAAoJENnE0m0OYESRrO8H/A2os59q+XwypwIsCVMw7TQF
VlWEifT5DymXQosTQEQCZObi+JYsKNtl4ZijSiW13ZLKHC7hmTq4ml8AOEjZ+jfr
V7fyvd/Mmz+6hut2F0b1/HhUKiOQkmvMksNSHhBk7NT+Kqb8MahCjDVqg6MbCx4r
wdLLL5NEg4aUyAy6imK/KWsGuj6UfRXY+OaUmBslLMKwunvFR2SUht9E/iL1a492
9SSA+geJ0YQfqKTIVNaVzsz39gwUKrA2JVXJhUPF7e+9VElB5RyBB8IVuK5ce+5K
xkzzLpqJE9U0yIN/os40b5jxwjNulHgnK/2xeAnAo2qT5nQWj2MPpYheJWA+jjU=
=sGzF
-----END PGP SIGNATURE-----

From openssl at openssl.org  Tue May  3 14:04:55 2016
From: openssl at openssl.org (OpenSSL)
Date: Tue, 3 May 2016 14:04:55 +0000
Subject: [openssl-dev] OpenSSL Security Advisory
Message-ID: <20160503140455.GA10341@openssl.org>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

OpenSSL Security Advisory [3rd May 2016]
========================================

Memory corruption in the ASN.1 encoder (CVE-2016-2108)
======================================================

Severity: High

This issue affected versions of OpenSSL prior to April 2015. The bug
causing the vulnerability was fixed on April 18th 2015, and released
as part of the June 11th 2015 security releases. The security impact
of the bug was not known at the time.

In previous versions of OpenSSL, ASN.1 encoding the value zero
represented as a negative integer can cause a buffer underflow
with an out-of-bounds write in i2c_ASN1_INTEGER. The ASN.1 parser does
not normally create "negative zeroes" when parsing ASN.1 input, and
therefore, an attacker cannot trigger this bug.

However, a second, independent bug revealed that the ASN.1 parser
(specifically, d2i_ASN1_TYPE) can misinterpret a large universal tag
as a negative zero value. Large universal tags are not present in any
common ASN.1 structures (such as X509) but are accepted as part of ANY
structures.

Therefore, if an application deserializes untrusted ASN.1 structures
containing an ANY field, and later reserializes them, an attacker may
be able to trigger an out-of-bounds write. This has been shown to
cause memory corruption that is potentially exploitable with some
malloc implementations.

Applications that parse and re-encode X509 certificates are known to
be vulnerable. Applications that verify RSA signatures on X509
certificates may also be vulnerable; however, only certificates with
valid signatures trigger ASN.1 re-encoding and hence the
bug. Specifically, since OpenSSL's default TLS X509 chain verification
code verifies the certificate chain from root to leaf, TLS handshakes
could only be targeted with valid certificates issued by trusted
Certification Authorities.

OpenSSL 1.0.2 users should upgrade to 1.0.2c
OpenSSL 1.0.1 users should upgrade to 1.0.1o

This vulnerability is a combination of two bugs, neither of which
individually has security impact. The first bug (mishandling of
negative zero integers) was reported to OpenSSL by Huzaifa Sidhpurwala
(Red Hat) and independently by Hanno B??ck in April 2015. The second
issue (mishandling of large universal tags) was found using libFuzzer,
and reported on the public issue tracker on March 1st 2016. The fact
that these two issues combined present a security vulnerability was
reported by David Benjamin (Google) on March 31st 2016. The fixes were
developed by Steve Henson of the OpenSSL development team, and David
Benjamin.  The OpenSSL team would also like to thank Mark Brand and
Ian Beer from the Google Project Zero team for their careful analysis
of the impact.

The fix for the "negative zero" memory corruption bug can be
identified by commits

3661bb4e7934668bd99ca777ea8b30eedfafa871 (1.0.2)
and
32d3b0f52f77ce86d53f38685336668d47c5bdfe (1.0.1)

Padding oracle in AES-NI CBC MAC check (CVE-2016-2107)
======================================================

Severity: High

A MITM attacker can use a padding oracle attack to decrypt traffic
when the connection uses an AES CBC cipher and the server support
AES-NI.

This issue was introduced as part of the fix for Lucky 13 padding
attack (CVE-2013-0169). The padding check was rewritten to be in
constant time by making sure that always the same bytes are read and
compared against either the MAC or padding bytes. But it no longer
checked that there was enough data to have both the MAC and padding
bytes.

OpenSSL 1.0.2 users should upgrade to 1.0.2h
OpenSSL 1.0.1 users should upgrade to 1.0.1t

This issue was reported to OpenSSL on 13th of April 2016 by Juraj
Somorovsky using TLS-Attacker. The fix was developed by Kurt Roeckx
of the OpenSSL development team.

EVP_EncodeUpdate overflow (CVE-2016-2105)
=========================================

Severity: Low

An overflow can occur in the EVP_EncodeUpdate() function which is used for
Base64 encoding of binary data. If an attacker is able to supply very large
amounts of input data then a length check can overflow resulting in a heap
corruption.

Internally to OpenSSL the EVP_EncodeUpdate() function is primarly used by the
PEM_write_bio* family of functions. These are mainly used within the OpenSSL
command line applications. These internal uses are not considered vulnerable
because all calls are bounded with length checks so no overflow is possible.
User applications that call these APIs directly with large amounts of untrusted
data may be vulnerable. (Note: Initial analysis suggested that the
PEM_write_bio* were vulnerable, and this is reflected in the patch commit
message. This is no longer believed to be the case).

OpenSSL 1.0.2 users should upgrade to 1.0.2h
OpenSSL 1.0.1 users should upgrade to 1.0.1t

This issue was reported to OpenSSL on 3rd March 2016 by Guido Vranken. The
fix was developed by Matt Caswell of the OpenSSL development team.

EVP_EncryptUpdate overflow (CVE-2016-2106)
==========================================

Severity: Low

An overflow can occur in the EVP_EncryptUpdate() function. If an attacker is
able to supply very large amounts of input data after a previous call to
EVP_EncryptUpdate() with a partial block then a length check can overflow
resulting in a heap corruption. Following an analysis of all OpenSSL internal
usage of the EVP_EncryptUpdate() function all usage is one of two forms.
The first form is where the EVP_EncryptUpdate() call is known to be the first
called function after an EVP_EncryptInit(), and therefore that specific call
must be safe. The second form is where the length passed to EVP_EncryptUpdate()
can be seen from the code to be some small value and therefore there is no
possibility of an overflow. Since all instances are one of these two forms, it
is believed that there can be no overflows in internal code due to this problem.
It should be noted that EVP_DecryptUpdate() can call EVP_EncryptUpdate() in
certain code paths. Also EVP_CipherUpdate() is a synonym for
EVP_EncryptUpdate(). All instances of these calls have also been analysed too
and it is believed there are no instances in internal usage where an overflow
could occur.

This could still represent a security issue for end user code that calls this
function directly.

OpenSSL 1.0.2 users should upgrade to 1.0.2h
OpenSSL 1.0.1 users should upgrade to 1.0.1t

This issue was reported to OpenSSL on 3rd March 2016 by Guido Vranken. The
fix was developed by Matt Caswell of the OpenSSL development team.

ASN.1 BIO excessive memory allocation (CVE-2016-2109)
=====================================================

Severity: Low

When ASN.1 data is read from a BIO using functions such as d2i_CMS_bio()
a short invalid encoding can casuse allocation of large amounts of memory
potentially consuming excessive resources or exhausting memory.

Any application parsing untrusted data through d2i BIO functions is affected.
The memory based functions such as d2i_X509() are *not* affected. Since the
memory based functions are used by the TLS library, TLS applications are not
affected.

OpenSSL 1.0.2 users should upgrade to 1.0.2h
OpenSSL 1.0.1 users should upgrade to 1.0.1t

This issue was reported to OpenSSL on 4th April 2016 by Brian Carpenter.
The fix was developed by Stephen Henson of the OpenSSL development team.

EBCDIC overread (CVE-2016-2176)
===============================

Severity: Low

ASN1 Strings that are over 1024 bytes can cause an overread in applications
using the X509_NAME_oneline() function on EBCDIC systems. This could result in
arbitrary stack data being returned in the buffer.

OpenSSL 1.0.2 users should upgrade to 1.0.2h
OpenSSL 1.0.1 users should upgrade to 1.0.1t

This issue was reported to OpenSSL on 5th March 2016 by Guido Vranken. The
fix was developed by Matt Caswell of the OpenSSL development team.

Note
====

As per our previous announcements and our Release Strategy
(https://www.openssl.org/policies/releasestrat.html), support for OpenSSL
version 1.0.1 will cease on 31st December 2016. No security updates for that
version will be provided after that date. Users of 1.0.1 are advised to
upgrade.

Support for versions 0.9.8 and 1.0.0 ended on 31st December 2015. Those
versions are no longer receiving security updates.

References
==========

URL for this Security Advisory:
https://www.openssl.org/news/secadv/20160503.txt

Note: the online version of the advisory may be updated with additional details
over time.

For details of OpenSSL severity classifications please see:
https://www.openssl.org/policies/secpolicy.html
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQEcBAEBAgAGBQJXKK1XAAoJENnE0m0OYESRoEEH/RWG0sYKTrsYFC7Pqv56Pm1y
DuH3txuEMI+P+vS4o0NVVOdhRgxNI4dDef/g60g+sCZlgD7lSJkw0iLvTn+/DvZg
W+9b7VQlvqBG8HnvHsrHk11IT4eTg6nvjX0SsCU80feh3c4owpyht/meFYb4RCrJ
9UNCkyhaUNNXVwz3so9PgMpLugDEiymjjTyO4C/nb5vpVLHUP0qy6KPIlMPJD1mc
wfU4kSwNzPwiCWHSYheaCbhPv8R+mQnX/LnwDeog913ojLdOGqTG8m392uf9Njzj
SgBTrTPCE343qkyRgK8aKVxpu/TkCtGiSHCrqi0/2WrX0JZnuq2kUWKERO2ai1c=
=2Tl5
-----END PGP SIGNATURE-----

From rt at openssl.org  Tue May  3 20:49:28 2016
From: rt at openssl.org (Andy Polyakov via RT)
Date: Tue, 03 May 2016 20:49:28 +0000
Subject: [openssl-dev] [openssl.org #4508] BUG in openssl-1.1.0-pre4
	(and current GIT master)
In-Reply-To: <57290ED3.7060803@openssl.org>
References: <RT-Ticket-4508@openssl.org>
 <OF3210432F.056B39F3-ONC1257F92.0022C1A8-C1257F92.00239878@rohde-schwarz.com>
 <rt-4.0.19-19203-1460358133-1351.4508-21-0@openssl.org>
 <57290ED3.7060803@openssl.org>
Message-ID: <rt-4.0.19-2506-1462308568-343.4508-6-0@openssl.org>

> Openssl-1.1.0-pre4 can't be built for linux-ppc with options no-chacha or 
> no-poly1305 since crypto/ppccap.c doesn't use OPENSSL_NO_CHACHA and 
> OPENSSL_NO_POLY1305.

This was fixed. Closing ticket.


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


From appro at openssl.org  Tue May  3 21:10:09 2016
From: appro at openssl.org (Andy Polyakov)
Date: Tue, 3 May 2016 23:10:09 +0200
Subject: [openssl-dev] aarch64 build breaking
In-Reply-To: <DUB127-W9050A9D1C1F6C0C916AB12DE9E0@phx.gbl>
References: <DUB127-W9050A9D1C1F6C0C916AB12DE9E0@phx.gbl>
Message-ID: <572913B1.7000809@openssl.org>

Hi,

> When attempting to build for aarch64 the build breaks while testing here: 
> 
> http://pastebin.com/ucy8gKPA
> 
> I can work around this issue by adding no-asm flags to the configure, I
> assume theres some asm code aarch64 isn't happy with? Is this a known
> issue or is it more likely my setup? Possibly outdated qemu.

I can't reproduce this, not with qemu (2.1.50) or on real hardware. In
other words it's unlikely that it's problem with your setup.


From appro at openssl.org  Tue May  3 21:21:34 2016
From: appro at openssl.org (Andy Polyakov)
Date: Tue, 3 May 2016 23:21:34 +0200
Subject: [openssl-dev] Add cross-compile helpers to official OpenSSL
 sources?
In-Reply-To: <CAH8yC8n6MiPLUnvJRPJ26HbJFob0LQBd__9NFrwdCAaYPh224A@mail.gmail.com>
References: <CAH8yC8n6MiPLUnvJRPJ26HbJFob0LQBd__9NFrwdCAaYPh224A@mail.gmail.com>
Message-ID: <5729165E.60500@openssl.org>

> OpenSSL has a few scripts it uses for platforms like Android and iOS.
> In addition, there are other helper scripts like incore_macho used on
> the platforms.
> 
> As far as I know, the bits are not under version control.

Yes, they are, see OpenSSL-fips-2_0-dev branch.


From rt at openssl.org  Tue May  3 21:37:43 2016
From: rt at openssl.org (Andy Polyakov via RT)
Date: Tue, 03 May 2016 21:37:43 +0000
Subject: [openssl-dev] [openssl.org #4483] Wrong results with Poly1305
	functions
In-Reply-To: <57291A27.1050004@openssl.org>
References: <RT-Ticket-4483@openssl.org> <RT-Ticket-4482@openssl.org>
 <20160325115042.5b8be48f@pc1>
 <rt-4.0.19-25249-1458907832-664.4482-21-0@openssl.org>
 <56F58C7F.8010109@openssl.org>
 <rt-4.0.19-25249-1458932864-666.4483-6-0@openssl.org>
 <CAF8qwaBFh1A67w-GnT4P_drFeVzePVfWMhL1PcAMWVnx0nLS-Q@mail.gmail.com>
 <CAF8qwaBxf6xwD2Pwv5N3dVetuP-hhvmJ9wY41ZR-2v9d4w06fQ@mail.gmail.com>
 <rt-4.0.19-27056-1459006902-443.4483-6-0@openssl.org>
 <57291A27.1050004@openssl.org>
Message-ID: <rt-4.0.19-8026-1462311463-220.4483-6-0@openssl.org>

>> Right. What I meant is that a fully reduced h has $h2 < 4. Is it possible
>> that $h2, after that adc, ends up at 4, exceeding that bound? If it were,
>> that would require one more reduction.
>>
>> In the non-SIMD paths, I believe this is fine because $r0's and $r1's
>> cleared high bits mean we should have plenty of slack to leave that
>> unreduced. (And indeed its normally not reduced on input from the
>> addition.) Then poly1305_emit's reduction after adding s will resolve
>> things before output. But, in the SIMD paths, __poly1305_blocks is called
>> and then bits are shifted without any reduction. Wouldn't that cause a
>> problem? Or is this situation impossible?
>>
> 
> Pondering this some more, I missed that the base 2^26 representation still
> has six bits extra, so we shouldn't immediately lose that bit. How tolerant
> is the SIMD code to a partially-reduced h? (I haven't puzzled out how it
> works yet.) Is this within its bounds?

https://git.openssl.org/gitweb/?p=openssl.git;a=commitdiff;h=dc3c5067cd90f3f2159e5d53c57b92730c687d7e
provides background information (and ensures paper-n-pencil boundary
condition on ARM and x86). Ticket is being closed.




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


From appro at openssl.org  Tue May  3 21:52:45 2016
From: appro at openssl.org (Andy Polyakov)
Date: Tue, 3 May 2016 23:52:45 +0200
Subject: [openssl-dev] aarch64 build breaking
In-Reply-To: <572913B1.7000809@openssl.org>
References: <DUB127-W9050A9D1C1F6C0C916AB12DE9E0@phx.gbl>
 <572913B1.7000809@openssl.org>
Message-ID: <57291DAD.1020004@openssl.org>

>> When attempting to build for aarch64 the build breaks while testing here: 
>>
>> http://pastebin.com/ucy8gKPA
>>
>> I can work around this issue by adding no-asm flags to the configure, I
>> assume theres some asm code aarch64 isn't happy with? Is this a known
>> issue or is it more likely my setup? Possibly outdated qemu.
> 
> I can't reproduce this, not with qemu (2.1.50) or on real hardware. In
> other words it's unlikely that it's problem with your setup.

I naturally meant it's *not* unlike that it's a problem with your setup.


From rt at openssl.org  Tue May  3 22:10:08 2016
From: rt at openssl.org (Andy Polyakov via RT)
Date: Tue, 03 May 2016 22:10:08 +0000
Subject: [openssl-dev] [openssl.org #4463] Undefined behavior in
	cast/c_enc.c
In-Reply-To: <572921BD.6030007@openssl.org>
References: <RT-Ticket-4463@openssl.org>
 <CAH8yC8nZebrfZsr5iwn5TmDKdneEg7ya4Ng7NUx+CgrYSLQFHQ@mail.gmail.com>
 <rt-4.0.19-19985-1458553886-774.4463-21-0@openssl.org>
 <572921BD.6030007@openssl.org>
Message-ID: <rt-4.0.19-2506-1462313408-1754.4463-6-0@openssl.org>

> $ ./config -fsanitize=undefined

Sanitized builds might have to be complemented with -DPEDANTIC. Quoting
Configure:

# ... Incidentally -DPEDANTIC has
# to be used even in sanitized builds, because sanitizer too is
# supposed to and does take notice of non-standard behaviour.

Similar rule applies to cases when you try to pass harder standard
compliance flags like you discussed in other RTs. Bottom line is that
while it's possible to pass additional compiler flags to ./config, it
doesn't mean that arbitrary combination is guaranteed to work. Sanitized
builds are exercised through travis-ci.org and you can find find the
flags in .travis.yml.

> ...
> $ make test HARNESS_VERBOSE=yes
> ...
> 
> ../test/recipes/05-test_cast.t ............
> 1..1
> crypto/cast/c_enc.c:78:5: runtime error: shift exponent 32 is too
> large for 32-bit type 'unsigned int'

Though this particular code was modified to pass sanitized independent
on -DPEDANTIC.

I'm closing this ticket.


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


From rt at openssl.org  Tue May  3 22:13:42 2016
From: rt at openssl.org (Naftali Santos via RT)
Date: Tue, 03 May 2016 22:13:42 +0000
Subject: [openssl-dev] [openssl.org #4530] [BUG] OpenSSL crash on Windows 10
In-Reply-To: <SN2PR0801MB2223F8965BFDDCBD616182129A7A0@SN2PR0801MB2223.namprd08.prod.outlook.com>
References: <RT-Ticket-4530@openssl.org>
 <SN2PR0801MB2223F8965BFDDCBD616182129A7A0@SN2PR0801MB2223.namprd08.prod.outlook.com>
Message-ID: <rt-4.0.19-2506-1462313621-705.4530-21-0@openssl.org>

Hi, our team have been experiencing a crash in some production machines (which I cannot reproduce in development machines) caused by the libeay32 module in 64 bits Windows 10 machines.

I was able to create a simple "crash application" and was able to get the dump of the crash along with PDB files for both the libeay32.dll and the sample application.

The exception code being thrown is 0xC0000005 (invalid memory access) and occurs inside sha1_block_data_order_shaext(), sha1-x86_64.asm, line 1435. The version used was 1.0.2g (but older versions also crash - the latest dev version from github crash as well).

You can download all the objects needed for debugging in this link<https://drive.google.com/file/d/0B0fX_HX2d8NAZVV3WWVJdWo0R2M/view?usp=sharing>: PDB, sample code, binaries used, etc.

It's worth noting that there is a libeay32.dll shipped in this machine that do work, but we don't know why. Maybe some compilation changes?

Anyway, I tried two binaries: The one downloaded from this website<https://slproweb.com/products/Win32OpenSSL.html>. And the one I compiled myself (both of them crashed).

The command lines I used to compile were:

> perl Configure VC-WIN64A
> call ms\do_win64a
> nmake -f ms\ntdll.mak

Thank you,

[Fit Instituto de Tecnologia]


Naftali Andrade
Sr. Software Developer

Phone.: +55 15 4009-0607

www.fit-tecnologia.org.br<http://www.fit-tecnologia.org.br/>

[Fit Instituto de Tecnologia]




Legal Disclaimer:
The information contained in this message may be privileged and confidential. It is intended to be read only by the individual or entity to whom it is addressed or by their designee. If the reader of this message is not the intended recipient, you are on notice that any distribution of this message, in any form, is strictly prohibited. If you have received this message in error, please immediately notify the sender and delete or destroy any copy of this message!
-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4530
Please log in as guest with password guest if prompted

-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.jpg
Type: image/jpeg
Size: 19486 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20160503/2da5968a/attachment-0002.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.jpg
Type: image/jpeg
Size: 8716 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20160503/2da5968a/attachment-0003.jpg>

From rt at openssl.org  Wed May  4 12:02:52 2016
From: rt at openssl.org (Stephen Henson via RT)
Date: Wed, 04 May 2016 12:02:52 +0000
Subject: [openssl-dev] [openssl.org #4527] Bug in d2i_PrivateKey
	(openssl-1.1.0-pre5)
In-Reply-To: <OF7AF90420.5AB3EE6E-ONC1257FA7.002F4258-C1257FA7.003292B4@rohde-schwarz.com>
References: <RT-Ticket-4527@openssl.org>
 <OF7AF90420.5AB3EE6E-ONC1257FA7.002F4258-C1257FA7.003292B4@rohde-schwarz.com>
Message-ID: <rt-4.0.19-8026-1462363372-1075.4527-6-0@openssl.org>

Fixed, 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=4527
Please log in as guest with password guest if prompted


From rt at openssl.org  Wed May  4 12:38:43 2016
From: rt at openssl.org (Stephen Henson via RT)
Date: Wed, 04 May 2016 12:38:43 +0000
Subject: [openssl-dev] [openssl.org #4514] [BUG] PKCS12_key_gen_uni()
	crashes when used with Blake
In-Reply-To: <004101d199b4$ef3d4cb0$cdb7e610$@sales@free.fr>
References: <RT-Ticket-4514@openssl.org>
 <004101d199b4$ef3d4cb0$cdb7e610$@sales@free.fr>
Message-ID: <rt-4.0.19-8026-1462365523-1260.4514-6-0@openssl.org>

This has now been fixed. I've addred checks for the block length and set the
Blake2 block length properly.

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=4514
Please log in as guest with password guest if prompted


From ytrezq at sdf-eu.org  Wed May  4 13:04:51 2016
From: ytrezq at sdf-eu.org (none)
Date: Wed, 04 May 2016 15:04:51 +0200
Subject: [openssl-dev] null byte in hostname validation.
Message-ID: <74d32904a5f33b2d8b606325d8571d5e@mx.sdfeu.org>

Hello, where are the parts of the code that check if a null byte is used 
in a string part of a x509 certificate??


This is purely informative. I already know about 
https://www.openssl.org/docs/manmaster/crypto/X509_check_host.html. 
However I failed to find in which function and source file that part is 
located.

From brauckmann at dfn-cert.de  Wed May  4 13:52:06 2016
From: brauckmann at dfn-cert.de (=?UTF-8?Q?J=c3=bcrgen_Brauckmann?=)
Date: Wed, 4 May 2016 15:52:06 +0200
Subject: [openssl-dev] openssl 1.0.2h: Parsing really large CRLs fails,
 side effect of change in x_name.c?
Message-ID: <5729FE86.1080504@dfn-cert.de>

[double-post; sent this previously to rt at openssl.org, and didn't get a 
ticket reply or something. As I feel that potentially a large number of 
people is affected, e.g. via Apache crl parsing etc., re-sent to 
openssl-dev.]

Hi.

Openssl 1.0.2h cannot parse really large CRLs anymore. "Really large" 
means > some 1MB.

It seems as if the new check in line 202 in x_name.c, commited 5 days 
ago, has a side effect beyond name decoding:

https://github.com/openssl/openssl/blob/OpenSSL_1_0_2-stable/crypto/asn1/x_name.c#L202

# openssl crl -in large_crl.pem
unable to load CRL
3078178440:error:0D09E09B:asn1 encoding routines:X509_NAME_EX_D2I:too 
long:x_name.c:203:
3078178440:error:0D08303A:asn1 encoding 
routines:ASN1_TEMPLATE_NOEXP_D2I:nested asn1 
error:tasn_dec.c:697:Field=issuer, Type=X509_CRL_INFO
3078178440:error:0D08303A:asn1 encoding 
routines:ASN1_TEMPLATE_NOEXP_D2I:nested asn1 
error:tasn_dec.c:697:Field=crl, Type=X509_CRL
3078178440:error:0906700D:PEM routines:PEM_ASN1_read_bio:ASN1 
lib:pem_oth.c:83:
[root at strangepork ~]# /services/inst/openssl/openssl-1.0.2g/bin/openssl 
crl -out c -in cacrl.pem
[root at strangepork ~]# /services/inst/openssl/openssl-1.0.2h/bin/openssl 
crl -out c -in cacrl.pem
unable to load CRL

All name structures in "large_crl.pem" have normal sizes, but the crl 
contains a large number of revoked certificates:

# openssl-102g crl -in large_crl.pem -noout -issuer
issuer=/C=DE/O=client-1/CN=Testinstanz client-1

# openssl-102g crl -in large_crl.pem -noout  | grep "Revocation Date:" | 
wc -l
49813

Best regards,
   J?rgen

From rt at openssl.org  Wed May  4 14:05:16 2016
From: rt at openssl.org (=?UTF-8?B?SsO8cmdlbiBCcmF1Y2ttYW5u?= via RT)
Date: Wed, 04 May 2016 14:05:16 +0000
Subject: [openssl-dev] [openssl.org #4531] openssl 1.0.2h: Parsing really
	large CRLs fails, side effect of change in x_name.c?
In-Reply-To: <5729F76C.4090501@dfn-cert.de>
References: <RT-Ticket-4531@openssl.org> <5729F76C.4090501@dfn-cert.de>
Message-ID: <rt-4.0.19-2506-1462370716-1563.4531-21-0@openssl.org>

Hi.

Openssl 1.0.2h cannot parse really large CRLs anymore. "Really large" 
means > some 1MB.

It seems as if the new check in line 202 in x_name.c, commited 5 days 
ago, has a side effect beyond name decoding:

https://github.com/openssl/openssl/blob/OpenSSL_1_0_2-stable/crypto/asn1/x_name.c#L202

# openssl crl -in large_crl.pem
unable to load CRL
3078178440:error:0D09E09B:asn1 encoding routines:X509_NAME_EX_D2I:too 
long:x_name.c:203:
3078178440:error:0D08303A:asn1 encoding 
routines:ASN1_TEMPLATE_NOEXP_D2I:nested asn1 
error:tasn_dec.c:697:Field=issuer, Type=X509_CRL_INFO
3078178440:error:0D08303A:asn1 encoding 
routines:ASN1_TEMPLATE_NOEXP_D2I:nested asn1 
error:tasn_dec.c:697:Field=crl, Type=X509_CRL
3078178440:error:0906700D:PEM routines:PEM_ASN1_read_bio:ASN1 
lib:pem_oth.c:83:
[root at strangepork ~]# /services/inst/openssl/openssl-1.0.2g/bin/openssl 
crl -out c -in cacrl.pem
[root at strangepork ~]# /services/inst/openssl/openssl-1.0.2h/bin/openssl 
crl -out c -in cacrl.pem
unable to load CRL

All name structures in "large_crl.pem" have normale sizes, but it 
contains a large number of revoked certificates:

# openssl-102g crl -in large_crl.pem -noout -issuer
issuer=/C=DE/O=client-1/CN=Testinstanz client-1

# openssl-102g crl -in large_crl.pem -noout  | grep "Revocation Date:" | 
wc -l
49813

Best regards,
   J?rgen


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


From levitte at openssl.org  Wed May  4 14:08:26 2016
From: levitte at openssl.org (Richard Levitte)
Date: Wed, 04 May 2016 16:08:26 +0200 (CEST)
Subject: [openssl-dev] openssl 1.0.2h: Parsing really large CRLs fails,
 side effect of change in x_name.c?
In-Reply-To: <5729FE86.1080504@dfn-cert.de>
References: <5729FE86.1080504@dfn-cert.de>
Message-ID: <20160504.160826.1568227666787692666.levitte@openssl.org>

In message <5729FE86.1080504 at dfn-cert.de> on Wed, 4 May 2016 15:52:06 +0200, J?rgen Brauckmann <brauckmann at dfn-cert.de> said:

brauckmann> [double-post; sent this previously to rt at openssl.org, and didn't get a
brauckmann> ticket reply or something. As I feel that potentially a large number
brauckmann> of people is affected, e.g. via Apache crl parsing etc., re-sent to
brauckmann> openssl-dev.]

rt at openssl.org is moderated.  A little now and then, someone in the
team goes and checks for messages on hold (that is, everything that
comes in), lets messages such as yours through and tosses the load of
crap that came as well (you can't imagine the load of SPAM getting to
that address).

So, ticket replies aren't immediate.

Cheers,
Richard

-- 
Richard Levitte         levitte at openssl.org
OpenSSL Project         http://www.openssl.org/~levitte/

From rt at openssl.org  Wed May  4 14:26:41 2016
From: rt at openssl.org (=?UTF-8?B?SsO8cmdlbiBCcmF1Y2ttYW5u?= via RT)
Date: Wed, 04 May 2016 14:26:41 +0000
Subject: [openssl-dev] [openssl.org #4531] openssl 1.0.2h: Parsing
	really large CRLs fails, side effect of change in x_name.c?
In-Reply-To: <572A069E.106@dfn-cert.de>
References: <RT-Ticket-4531@openssl.org> <5729F76C.4090501@dfn-cert.de>
 <rt-4.0.19-2506-1462370716-1563.4531-21-0@openssl.org>
 <572A069E.106@dfn-cert.de>
Message-ID: <rt-4.0.19-2506-1462372001-1731.4531-6-0@openssl.org>

The following CRL triggers this behaviour:

https://info.pca.dfn.de/doc/large_crl.pem

Thanks,
   J?rgen


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


From bkaduk at akamai.com  Wed May  4 16:04:41 2016
From: bkaduk at akamai.com (Benjamin Kaduk)
Date: Wed, 4 May 2016 11:04:41 -0500
Subject: [openssl-dev] [openssl-users] Problems with OpenSSL 1.0.2 h
In-Reply-To: <9abc3eea-a9b6-18c9-94d3-5d49ffbd543f@web.de>
References: <9abc3eea-a9b6-18c9-94d3-5d49ffbd543f@web.de>
Message-ID: <572A1D99.5070003@akamai.com>

Hello,

On 05/04/2016 05:21 AM, Dirk Menstermann wrote:
> Hi,
>
> I've trouble with the newest OpenSSL as I'm operating a webserver application
> that answers with HTTP1.x and HTTP2.
>
> I registered the ALPN callback and in this the cipher list was adjusted
> "SSL_set_cipher_list (ssl, "ECDHE-RSA-AES128-GCM-SHA256")" if H2 was negotiated.
>
> With versions < OpenSSL 1.0.2h this works, but now it seems that this cipher
> selection will be ignored, resulting in using a cipher that is black listed for
> HTTP2 (Firefox and Chrome refuse to connect)
>
> Was there an indented change or is there an official way to select the cipher
> based on the ALPN extension value?
>

There was an intended change to the order in which ALPN extensions were
processed, see
https://github.com/openssl/openssl/commit/af2db04c9979554ada88d969da6332a827a47599
-- ALPN is now processed after SNI, since the ALPN callback is attached
to the SSL_CTX, and SNI processing is likely to swap out the SSL_CTX in
use.  It does look like "late" TLS extensions are now handled after
cipher selection, so the ALPN callback can no longer affect the
negotiated cipher.

Even at the specification level, how all the TLS extensions are supposed
to interact with each other and the rest of the handshake is not
terribly well specified, so adding -dev to discuss what the desired
behavior actually is.

-Ben

From tshort at akamai.com  Wed May  4 16:16:19 2016
From: tshort at akamai.com (Short, Todd)
Date: Wed, 4 May 2016 16:16:19 +0000
Subject: [openssl-dev] [openssl-users] Problems with OpenSSL 1.0.2 h
In-Reply-To: <572A1D99.5070003@akamai.com>
References: <9abc3eea-a9b6-18c9-94d3-5d49ffbd543f@web.de>
 <572A1D99.5070003@akamai.com>
Message-ID: <01226300-B4C2-47B7-B75E-A434B9901347@akamai.com>

Have you tried to configure this cipher at the top of your cipher list initially with SSL_OP_SERVER_CIPHER_PREFERENCE?

--
-Todd Short
// tshort at akamai.com<mailto:tshort at akamai.com>
// "One if by land, two if by sea, three if by the Internet."

On May 4, 2016, at 12:04 PM, Benjamin Kaduk <bkaduk at akamai.com<mailto:bkaduk at akamai.com>> wrote:

Hello,

On 05/04/2016 05:21 AM, Dirk Menstermann wrote:
Hi,

I've trouble with the newest OpenSSL as I'm operating a webserver application
that answers with HTTP1.x and HTTP2.

I registered the ALPN callback and in this the cipher list was adjusted
"SSL_set_cipher_list (ssl, "ECDHE-RSA-AES128-GCM-SHA256")" if H2 was negotiated.

With versions < OpenSSL 1.0.2h this works, but now it seems that this cipher
selection will be ignored, resulting in using a cipher that is black listed for
HTTP2 (Firefox and Chrome refuse to connect)

Was there an indented change or is there an official way to select the cipher
based on the ALPN extension value?


There was an intended change to the order in which ALPN extensions were
processed, see
https://github.com/openssl/openssl/commit/af2db04c9979554ada88d969da6332a827a47599
-- ALPN is now processed after SNI, since the ALPN callback is attached
to the SSL_CTX, and SNI processing is likely to swap out the SSL_CTX in
use.  It does look like "late" TLS extensions are now handled after
cipher selection, so the ALPN callback can no longer affect the
negotiated cipher.

Even at the specification level, how all the TLS extensions are supposed
to interact with each other and the rest of the handshake is not
terribly well specified, so adding -dev to discuss what the desired
behavior actually is.

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20160504/3a1ce398/attachment-0001.html>

From rt at openssl.org  Wed May  4 17:36:20 2016
From: rt at openssl.org (Adam Langley via RT)
Date: Wed, 04 May 2016 17:36:20 +0000
Subject: [openssl-dev] =?utf-8?q?=5Bopenssl=2Eorg_=234532=5D_Replacing_the?=
	=?utf-8?q?_=E2=80=9Cdiv=5Fspoiler=E2=80=9D_hack_in_CBC_code_with_B?=
	=?utf-8?q?arrett_reduction=2E?=
In-Reply-To: <CAL9PXLyrAheUMaK4QJ8mpTxhJz2kFYfei7YDTSprhjfjK7wMFA@mail.gmail.com>
References: <RT-Ticket-4532@openssl.org>
 <CAL9PXLyrAheUMaK4QJ8mpTxhJz2kFYfei7YDTSprhjfjK7wMFA@mail.gmail.com>
Message-ID: <rt-4.0.19-8026-1462383380-829.4532-21-0@openssl.org>

(This is a pointer to a pull request:
https://github.com/openssl/openssl/pull/1027)

The ?div_spoiler? was designed to always trigger the slow path division
on Intel chips and be sufficiently obfuscated to stop the compiler
optimising it away. It was always a huge hack but I didn't know the
correct solution at the time.

Replace that hack with Barrett reduction, which solves the problem
without using division in the first place.

This change has been running in BoringSSL for some time without
issues.

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


From openssl-users at dukhovni.org  Wed May  4 20:01:43 2016
From: openssl-users at dukhovni.org (Viktor Dukhovni)
Date: Wed, 4 May 2016 20:01:43 +0000
Subject: [openssl-dev] null byte in hostname validation.
In-Reply-To: <74d32904a5f33b2d8b606325d8571d5e@mx.sdfeu.org>
References: <74d32904a5f33b2d8b606325d8571d5e@mx.sdfeu.org>
Message-ID: <20160504200143.GG3300@mournblade.imrryr.org>

On Wed, May 04, 2016 at 03:04:51PM +0200, none wrote:

> Hello, where are the parts of the code that check if a null byte is used in
> a string part of a x509 certificate??
> 
> This is purely informative. I already know about
> https://www.openssl.org/docs/manmaster/crypto/X509_check_host.html. However
> I failed to find in which function and source file that part is located.

See crypto/x509v3/v3_utl.c:

    X509_check_host()
    X509_check_email()
    equal_nocase()	(just in case :-)

-- 
	Viktor.

From rt at openssl.org  Wed May  4 21:46:03 2016
From: rt at openssl.org (Kurt Cancemi via RT)
Date: Wed, 04 May 2016 21:46:03 +0000
Subject: [openssl-dev] [openssl.org #4533] [PATCH] Add missing NULL check in
	i2d_PrivateKey()
In-Reply-To: <CADujJWVMMsKu=7bpPecxOv-fWakw2Qw041_9oaTtZ_FuQ_P+CQ@mail.gmail.com>
References: <RT-Ticket-4533@openssl.org>
 <CADujJWVMMsKu=7bpPecxOv-fWakw2Qw041_9oaTtZ_FuQ_P+CQ@mail.gmail.com>
Message-ID: <rt-4.0.19-8026-1462398363-1450.4533-21-0@openssl.org>

The attached patch adds a missing NULL check in i2d_PrivateKey(), it
also removes the parentheses around the last return value to be
consistent with the rest of the function.

--
Kurt Cancemi
https://www.x64architecture.com


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


From rt at openssl.org  Wed May  4 21:47:01 2016
From: rt at openssl.org (Kurt Cancemi via RT)
Date: Wed, 04 May 2016 21:47:01 +0000
Subject: [openssl-dev] [openssl.org #4534] Re: [PATCH] Add missing NULL
	check in i2d_PrivateKey()
In-Reply-To: <CADujJWVqvTFwAkvdRyBeTs=K9s=ZrBwE+9PdP0o_1FBdUzcQqw@mail.gmail.com>
References: <RT-Ticket-4534@openssl.org>
 <CADujJWVMMsKu=7bpPecxOv-fWakw2Qw041_9oaTtZ_FuQ_P+CQ@mail.gmail.com>
 <CADujJWVqvTFwAkvdRyBeTs=K9s=ZrBwE+9PdP0o_1FBdUzcQqw@mail.gmail.com>
Message-ID: <rt-4.0.19-8026-1462398421-437.4534-21-0@openssl.org>

Attached is the patch to fix the issue

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-Add-missing-NULL-check-in-i2d_PrivateKey.patch
Type: text/x-patch
Size: 909 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20160504/a164c693/attachment.bin>

From rt at openssl.org  Wed May  4 21:52:21 2016
From: rt at openssl.org (Kurt Cancemi via RT)
Date: Wed, 04 May 2016 21:52:21 +0000
Subject: [openssl-dev] [openssl.org #4533] AutoReply: [PATCH] Add
	missing NULL check in i2d_PrivateKey()
In-Reply-To: <CADujJWVY3U88hooeAW9FRd7Owp0cWiCQmbezVorm7rCGqUf0ng@mail.gmail.com>
References: <RT-Ticket-4533@openssl.org>
 <CADujJWVY3U88hooeAW9FRd7Owp0cWiCQmbezVorm7rCGqUf0ng@mail.gmail.com>
Message-ID: <rt-4.0.19-8026-1462398741-50.4533-6-0@openssl.org>

Attached is the patch to fix the issue, also please close RT#4534 I
sent an invalid reply which got translated into another RT issue.

--
Kurt Cancemi
https://www.x64architecture.com

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-Add-missing-NULL-check-in-i2d_PrivateKey.patch
Type: text/x-patch
Size: 909 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20160504/2482a1fc/attachment.bin>

From dcruette at qualitesys.com  Wed May  4 20:32:38 2016
From: dcruette at qualitesys.com (dcruette at qualitesys.com)
Date: Wed, 04 May 2016 22:32:38 +0200
Subject: [openssl-dev] Make under windows
Message-ID: <37d47403029a56ad3095af56b7323077@qualitesys.com>

Hi

I used to compile and test the daily tarball under jenkins CI 
successfully, under windows, perl, mingw.
I am facing a new issue.
The make depend command runs fine.
The make command fails, the \ character seams to be removed.

Could you help me ?

Thanks
Didier


D:\LogicielDeBaseQcr\Jenkins\jobs\qcr-maven-plugin-testsunitaires-qcr4cpp-openssl-daily-de-base-windows\workspace\openssl-SNAP-20160504>perl 
./Configure mingw

Configuring OpenSSL version 1.1.0-pre6-dev (0x0x10100006L)
     no-crypto-mdebug [default]  OPENSSL_NO_CRYPTO_MDEBUG (skip dir)
     no-crypto-mdebug-backtrace [forced]   
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-heartbeats   [default]  OPENSSL_NO_HEARTBEATS (skip dir)
     no-md2          [default]  OPENSSL_NO_MD2 (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-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 mingw

CC            =gcc
CFLAG         =-DL_ENDIAN -DWIN32_LEAN_AND_MEAN -DUNICODE -D_UNICODE 
-m32 -Wall -O3 -fomit-frame-pointer -D_MT
SHARED_CFLAG  =-D_WINDLL
DEFINES       =OPENSSL_USE_APPLINK DSO_WIN32 NDEBUG OPENSSL_THREADS 
OPENSSL_NO_STATIC_ENGINE OPENSSL_PIC OPENSSL_BN_ASM_PART_WORDS 
OPENSSL_IA32_SSE2 OPENSSL_BN_ASM_MONT OPENSSL_BN_ASM_GF2m SHA1_ASM 
SHA256_ASM SHA512_ASM MD5_ASM RMD160_ASM AES_ASM VPAES_ASM WHIRLPOOL_ASM 
GHASH_ASM ECP_NISTZ256_ASM POLY1305_ASM
LFLAG         =
PLIB_LFLAG    =
EX_LIBS       =-lws2_32 -lgdi32 -lcrypt32
APPS_OBJ      =../ms/applink.o
CPUID_OBJ     =x86cpuid.o
UPLINK_OBJ    =../ms/uplink.o uplink-x86.o
BN_ASM        =bn-586.o co-586.o x86-mont.o x86-gf2m.o
EC_ASM        =ecp_nistz256.o ecp_nistz256-x86.o
DES_ENC       =des-586.o crypt586.o
AES_ENC       =aes-586.o vpaes-x86.o aesni-x86.o
BF_ENC        =bf-586.o
CAST_ENC      =c_enc.o
RC4_ENC       =rc4-586.o
RC5_ENC       =rc5-586.o
MD5_OBJ_ASM   =md5-586.o
SHA1_OBJ_ASM  =sha1-586.o sha256-586.o sha512-586.o
RMD160_OBJ_ASM=rmd-586.o
CMLL_ENC      =cmll-x86.o
MODES_OBJ     =ghash-x86.o
PADLOCK_OBJ   =e_padlock-x86.o
CHACHA_ENC    =chacha-x86.o
POLY1305_OBJ  =poly1305-x86.o
BLAKE2_OBJ    =
PROCESSOR     =
RANLIB        =true
ARFLAGS       =
PERL          =D:\LogicielDeBaseQcr\Perl\bin\perl.exe

THIRTY_TWO_BIT mode
BN_LLONG mode

Configured for mingw.


D:\LogicielDeBaseQcr\Jenkins\jobs\qcr-maven-plugin-testsunitaires-qcr4cpp-openssl-daily-de-base-windows\workspace\openssl-SNAP-20160504>make 
depend

D:\LogicielDeBaseQcr\Jenkins\jobs\qcr-maven-plugin-testsunitaires-qcr4cpp-openssl-daily-de-base-windows\workspace\openssl-SNAP-20160504>make

CC="gcc" D:\LogicielDeBaseQcr\Perl\bin\perl.exe 
crypto\aes\asm\aes-586.pl coff -DOPENSSL_USE_APPLINK -DDSO_WIN32 
-DNDEBUG -DOPENSSL_THREADS -DOPENSSL_NO_STATIC_ENGINE -DOPENSSL_PIC 
-DOPENSSL_BN_ASM_PART_WORDS -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT 
-DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM 
-DRMD160_ASM -DAES_ASM -DVPAES_ASM -DWHIRLPOOL_ASM -DGHASH_ASM 
-DECP_NISTZ256_ASM -DPOLY1305_ASM -DOPENSSLDIR="\"\usr\local\ssl\"" 
-DENGINESDIR="\"\usr\local\lib\engines\"" -DL_ENDIAN 
-DWIN32_LEAN_AND_MEAN -DUNICODE -D_UNICODE -m32 -Wall -O3 
-fomit-frame-pointer -D_MT  -D_WINDLL  crypto\aes\aes-586.s
/bin/sh: D:LogicielDeBaseQcrPerlbinperl.exe: command not found
make: *** [crypto\aes\aes-586.s] Error 127

D:\LogicielDeBaseQcr\Jenkins\jobs\qcr-maven-plugin-testsunitaires-qcr4cpp-openssl-daily-de-base-windows\workspace\openssl-SNAP-20160504>make 
test

gcc -DOPENSSL_USE_APPLINK -DDSO_WIN32 -DNDEBUG -DOPENSSL_THREADS 
-DOPENSSL_NO_STATIC_ENGINE -DOPENSSL_PIC -DOPENSSL_BN_ASM_PART_WORDS 
-DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_GF2m 
-DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DRMD160_ASM -DAES_ASM 
-DVPAES_ASM -DWHIRLPOOL_ASM -DGHASH_ASM -DECP_NISTZ256_ASM 
-DPOLY1305_ASM -DOPENSSLDIR="\"\usr\local\ssl\"" 
-DENGINESDIR="\"\usr\local\lib\engines\"" -DL_ENDIAN 
-DWIN32_LEAN_AND_MEAN -DUNICODE -D_UNICODE -m32 -Wall -O3 
-fomit-frame-pointer -D_MT   -Iinclude -I. -MMD -MF apps\app_rand.d.tmp 
-MT apps\app_rand.o -c -o apps\app_rand.o apps\app_rand.c
gcc.exe: error: appsapp_rand.c: No such file or directory
gcc.exe: fatal error: no input files
compilation terminated.
make: *** [apps\app_rand.o] Error 1

D:\LogicielDeBaseQcr\Jenkins\jobs\qcr-maven-plugin-testsunitaires-qcr4cpp-openssl-daily-de-base-windows\workspace\openssl-SNAP-20160504>exit 
2
Build step 'Ex?cuter une ligne de commande batch Windows' marked build 
as failure

From levitte at openssl.org  Thu May  5 06:38:45 2016
From: levitte at openssl.org (Richard Levitte)
Date: Thu, 05 May 2016 08:38:45 +0200 (CEST)
Subject: [openssl-dev] Make under windows
In-Reply-To: <37d47403029a56ad3095af56b7323077@qualitesys.com>
References: <37d47403029a56ad3095af56b7323077@qualitesys.com>
Message-ID: <20160505.083845.1462163947383356678.levitte@openssl.org>

If you configure for mingw, you need to do so from inside a MSYS/MingW
shell.  If you want to build inside a cmd shell, you have to configure
natively, i.e. for one of the VC-* configuration targets.

Cheers,
Richard

In message <37d47403029a56ad3095af56b7323077 at qualitesys.com> on Wed, 04 May 2016 22:32:38 +0200, dcruette at qualitesys.com said:

dcruette> Hi
dcruette> 
dcruette> I used to compile and test the daily tarball under jenkins CI
dcruette> successfully, under windows, perl, mingw.
dcruette> I am facing a new issue.
dcruette> The make depend command runs fine.
dcruette> The make command fails, the \ character seams to be removed.
dcruette> 
dcruette> Could you help me ?
dcruette> 
dcruette> Thanks
dcruette> Didier
dcruette> 
dcruette> 
dcruette> D:\LogicielDeBaseQcr\Jenkins\jobs\qcr-maven-plugin-testsunitaires-qcr4cpp-openssl-daily-de-base-windows\workspace\openssl-SNAP-20160504>perl
dcruette> ./Configure mingw
dcruette> 
dcruette> Configuring OpenSSL version 1.1.0-pre6-dev (0x0x10100006L)
dcruette>     no-crypto-mdebug [default]  OPENSSL_NO_CRYPTO_MDEBUG (skip dir)
dcruette>     no-crypto-mdebug-backtrace [forced] OPENSSL_NO_CRYPTO_MDEBUG_BACKTRACE
dcruette>     (skip dir)
dcruette>     no-ec_nistp_64_gcc_128 [default] OPENSSL_NO_EC_NISTP_64_GCC_128 (skip
dcruette>     dir)
dcruette>     no-egd          [default]  OPENSSL_NO_EGD (skip dir)
dcruette>     no-heartbeats   [default]  OPENSSL_NO_HEARTBEATS (skip dir)
dcruette>     no-md2          [default]  OPENSSL_NO_MD2 (skip dir)
dcruette>     no-rc5          [default]  OPENSSL_NO_RC5 (skip dir)
dcruette>     no-sctp         [default]  OPENSSL_NO_SCTP (skip dir)
dcruette>     no-ssl-trace    [default]  OPENSSL_NO_SSL_TRACE (skip dir)
dcruette>     no-ssl3         [default]  OPENSSL_NO_SSL3 (skip dir)
dcruette>     no-ssl3-method  [default]  OPENSSL_NO_SSL3_METHOD (skip dir)
dcruette>     no-unit-test    [default]  OPENSSL_NO_UNIT_TEST (skip dir)
dcruette>     no-weak-ssl-ciphers [default]  OPENSSL_NO_WEAK_SSL_CIPHERS (skip dir)
dcruette>     no-zlib         [default]
dcruette>     no-zlib-dynamic [default]
dcruette> Configuring for mingw
dcruette> 
dcruette> CC            =gcc
dcruette> CFLAG =-DL_ENDIAN -DWIN32_LEAN_AND_MEAN -DUNICODE -D_UNICODE -m32
dcruette> -Wall -O3 -fomit-frame-pointer -D_MT
dcruette> SHARED_CFLAG  =-D_WINDLL
dcruette> DEFINES =OPENSSL_USE_APPLINK DSO_WIN32 NDEBUG OPENSSL_THREADS
dcruette> OPENSSL_NO_STATIC_ENGINE OPENSSL_PIC OPENSSL_BN_ASM_PART_WORDS
dcruette> OPENSSL_IA32_SSE2 OPENSSL_BN_ASM_MONT OPENSSL_BN_ASM_GF2m SHA1_ASM
dcruette> SHA256_ASM SHA512_ASM MD5_ASM RMD160_ASM AES_ASM VPAES_ASM
dcruette> WHIRLPOOL_ASM GHASH_ASM ECP_NISTZ256_ASM POLY1305_ASM
dcruette> LFLAG         =
dcruette> PLIB_LFLAG    =
dcruette> EX_LIBS       =-lws2_32 -lgdi32 -lcrypt32
dcruette> APPS_OBJ      =../ms/applink.o
dcruette> CPUID_OBJ     =x86cpuid.o
dcruette> UPLINK_OBJ    =../ms/uplink.o uplink-x86.o
dcruette> BN_ASM        =bn-586.o co-586.o x86-mont.o x86-gf2m.o
dcruette> EC_ASM        =ecp_nistz256.o ecp_nistz256-x86.o
dcruette> DES_ENC       =des-586.o crypt586.o
dcruette> AES_ENC       =aes-586.o vpaes-x86.o aesni-x86.o
dcruette> BF_ENC        =bf-586.o
dcruette> CAST_ENC      =c_enc.o
dcruette> RC4_ENC       =rc4-586.o
dcruette> RC5_ENC       =rc5-586.o
dcruette> MD5_OBJ_ASM   =md5-586.o
dcruette> SHA1_OBJ_ASM  =sha1-586.o sha256-586.o sha512-586.o
dcruette> RMD160_OBJ_ASM=rmd-586.o
dcruette> CMLL_ENC      =cmll-x86.o
dcruette> MODES_OBJ     =ghash-x86.o
dcruette> PADLOCK_OBJ   =e_padlock-x86.o
dcruette> CHACHA_ENC    =chacha-x86.o
dcruette> POLY1305_OBJ  =poly1305-x86.o
dcruette> BLAKE2_OBJ    =
dcruette> PROCESSOR     =
dcruette> RANLIB        =true
dcruette> ARFLAGS       =
dcruette> PERL          =D:\LogicielDeBaseQcr\Perl\bin\perl.exe
dcruette> 
dcruette> THIRTY_TWO_BIT mode
dcruette> BN_LLONG mode
dcruette> 
dcruette> Configured for mingw.
dcruette> 
dcruette> 
dcruette> D:\LogicielDeBaseQcr\Jenkins\jobs\qcr-maven-plugin-testsunitaires-qcr4cpp-openssl-daily-de-base-windows\workspace\openssl-SNAP-20160504>make
dcruette> depend
dcruette> 
dcruette> D:\LogicielDeBaseQcr\Jenkins\jobs\qcr-maven-plugin-testsunitaires-qcr4cpp-openssl-daily-de-base-windows\workspace\openssl-SNAP-20160504>make
dcruette> 
dcruette> CC="gcc" D:\LogicielDeBaseQcr\Perl\bin\perl.exe crypto\aes\asm\aes-586.pl coff -DOPENSSL_USE_APPLINK -DDSO_WIN32 -DNDEBUG -DOPENSSL_THREADS -DOPENSSL_NO_STATIC_ENGINE -DOPENSSL_PIC -DOPENSSL_BN_ASM_PART_WORDS -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DRMD160_ASM -DAES_ASM -DVPAES_ASM -DWHIRLPOOL_ASM -DGHASH_ASM -DECP_NISTZ256_ASM -DPOLY1305_ASM -DOPENSSLDIR="\"\usr\local\ssl\"" -DENGINESDIR="\"\usr\local\lib\engines\"" -DL_ENDIAN -DWIN32_LEAN_AND_MEAN -DUNICODE -D_UNICODE -m32 -Wall -O3 -fomit-frame-pointer -D_MT  -D_WINDLL  crypto\aes\aes-586.s
dcruette> /bin/sh: D:LogicielDeBaseQcrPerlbinperl.exe: command not found
dcruette> make: *** [crypto\aes\aes-586.s] Error 127
dcruette> 
dcruette> D:\LogicielDeBaseQcr\Jenkins\jobs\qcr-maven-plugin-testsunitaires-qcr4cpp-openssl-daily-de-base-windows\workspace\openssl-SNAP-20160504>make test
dcruette> 
dcruette> gcc -DOPENSSL_USE_APPLINK -DDSO_WIN32 -DNDEBUG -DOPENSSL_THREADS -DOPENSSL_NO_STATIC_ENGINE -DOPENSSL_PIC -DOPENSSL_BN_ASM_PART_WORDS -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DRMD160_ASM -DAES_ASM -DVPAES_ASM -DWHIRLPOOL_ASM -DGHASH_ASM -DECP_NISTZ256_ASM -DPOLY1305_ASM -DOPENSSLDIR="\"\usr\local\ssl\"" -DENGINESDIR="\"\usr\local\lib\engines\"" -DL_ENDIAN -DWIN32_LEAN_AND_MEAN -DUNICODE -D_UNICODE -m32 -Wall -O3 -fomit-frame-pointer -D_MT   -Iinclude -I. -MMD -MF apps\app_rand.d.tmp -MT apps\app_rand.o -c -o apps\app_rand.o apps\app_rand.c
dcruette> gcc.exe: error: appsapp_rand.c: No such file or directory
dcruette> gcc.exe: fatal error: no input files
dcruette> compilation terminated.
dcruette> make: *** [apps\app_rand.o] Error 1
dcruette> 
dcruette> D:\LogicielDeBaseQcr\Jenkins\jobs\qcr-maven-plugin-testsunitaires-qcr4cpp-openssl-daily-de-base-windows\workspace\openssl-SNAP-20160504>exit 2
dcruette> Build step 'Ex?cuter une ligne de commande batch Windows' marked build as failure
dcruette> -- 
dcruette> openssl-dev mailing list
dcruette> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

From appro at openssl.org  Thu May  5 07:54:58 2016
From: appro at openssl.org (Andy Polyakov)
Date: Thu, 5 May 2016 09:54:58 +0200
Subject: [openssl-dev] Make under windows
In-Reply-To: <20160505.083845.1462163947383356678.levitte@openssl.org>
References: <37d47403029a56ad3095af56b7323077@qualitesys.com>
 <20160505.083845.1462163947383356678.levitte@openssl.org>
Message-ID: <572AFC52.7020908@openssl.org>

> If you configure for mingw, you need to do so from inside a MSYS/MingW
> shell.  If you want to build inside a cmd shell, you have to configure
> natively,

In addition a "matching perl" is likely to be required. I mean one can
start MSYS shell and have ActiveState Perl first on the $PATH and that
is not directly supported combination. It might work, but if it doesn't,
we don't want to figure out why exactly. So one also better ensures that
MSYS shell calls MSYS perl. But one should keep in mind that "matching"
applies to build environment rather than configuration target. For
example one can compile for mingw not only from MSYS shell, but even
from within Cygwin and Linux. Probably most correct definition of
"matching" is "one that matches make utility".


From rt at openssl.org  Thu May  5 08:20:16 2016
From: rt at openssl.org (Matt Caswell via RT)
Date: Thu, 05 May 2016 08:20:16 +0000
Subject: [openssl-dev] [openssl.org #4534] Re: [PATCH] Add missing NULL
	check in i2d_PrivateKey()
In-Reply-To: <CADujJWVqvTFwAkvdRyBeTs=K9s=ZrBwE+9PdP0o_1FBdUzcQqw@mail.gmail.com>
References: <RT-Ticket-4534@openssl.org>
 <CADujJWVMMsKu=7bpPecxOv-fWakw2Qw041_9oaTtZ_FuQ_P+CQ@mail.gmail.com>
 <CADujJWVqvTFwAkvdRyBeTs=K9s=ZrBwE+9PdP0o_1FBdUzcQqw@mail.gmail.com>
Message-ID: <rt-4.0.19-2506-1462436416-1738.4534-6-0@openssl.org>

Closing this ticket at request of submitter. Erroneous duplicate of #4533

Matt

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


From theno at gmx.net  Thu May  5 08:20:56 2016
From: theno at gmx.net (Theodor Nolte)
Date: Thu, 5 May 2016 10:20:56 +0200
Subject: [openssl-dev] Test for RT#4531 fix
Message-ID: <trinity-3700ea10-6331-4f33-9b9d-e7cdb5779664-1462436456361@3capp-gmx-bs04>

Hi,

I think there should be a test in order to avoid the same regression in future. For example, run `test/tcrl` against a large crl list, which would have been failed before of the fix for ticket RT#4531:

    cd test
    sh tcrl large_crl.pem


Theo.

From rt at openssl.org  Thu May  5 12:54:11 2016
From: rt at openssl.org (Kash, Howard M CIV USARMY RDECOM ARL via RT)
Date: Thu, 05 May 2016 12:54:11 +0000
Subject: [openssl-dev] [openssl.org #4535] BUG: X509_NAME_MAX too small for
	CRL processing
In-Reply-To: <8B01299690A8A94AB8629283FAFED8F1F0C33F8C@UMECHPA67.easf.csd.disa.mil>
References: <RT-Ticket-4535@openssl.org>
 <8B01299690A8A94AB8629283FAFED8F1F0C33F8C@UMECHPA67.easf.csd.disa.mil>
Message-ID: <rt-4.0.19-8026-1462452851-1816.4535-21-0@openssl.org>


OpenSSL 1.0.2h fails to process large CRLs (anything over 1MB) with the
error "X509_NAME_EX_D2I:too long:x_name.c:203" due to X509_NAME_MAX being
set to 1024*1024.  The CRLs I'm examining with "openssl crl -in <filename>
-nextupdate -noout" are up to 37MB (and growing).  I have set X509_NAME_MAX
to 64*1024*1024 as a temporary workaround.


Howard

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5583 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20160505/95df3917/attachment.bin>

From rt at openssl.org  Thu May  5 13:08:36 2016
From: rt at openssl.org (Stephen Henson via RT)
Date: Thu, 05 May 2016 13:08:36 +0000
Subject: [openssl-dev] [openssl.org #4535] BUG: X509_NAME_MAX too small for
	CRL processing
In-Reply-To: <8B01299690A8A94AB8629283FAFED8F1F0C33F8C@UMECHPA67.easf.csd.disa.mil>
References: <RT-Ticket-4535@openssl.org>
 <8B01299690A8A94AB8629283FAFED8F1F0C33F8C@UMECHPA67.easf.csd.disa.mil>
Message-ID: <rt-4.0.19-8026-1462453716-1145.4535-6-0@openssl.org>

On Thu May 05 12:54:11 2016, howard.m.kash.civ at mail.mil wrote:
>
> OpenSSL 1.0.2h fails to process large CRLs (anything over 1MB) with the
> error "X509_NAME_EX_D2I:too long:x_name.c:203" due to X509_NAME_MAX being
> set to 1024*1024. The CRLs I'm examining with "openssl crl -in <filename>
> -nextupdate -noout" are up to 37MB (and growing). I have set X509_NAME_MAX
> to 64*1024*1024 as a temporary workaround.
>

Already fixed in current 1.0.2 stable branch. See commit a1eef756cc1948e

Clsoing ticket.

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=4535
Please log in as guest with password guest if prompted


From rt at openssl.org  Thu May  5 13:19:15 2016
From: rt at openssl.org (Stephen Henson via RT)
Date: Thu, 05 May 2016 13:19:15 +0000
Subject: [openssl-dev] [openssl.org #4493] [PATCH] crypto/ec: fix setting
	the private key.
In-Reply-To: <1459259703-25067-1-git-send-email-justus@gnupg.org>
References: <RT-Ticket-4493@openssl.org>
 <1459259703-25067-1-git-send-email-justus@gnupg.org>
Message-ID: <rt-4.0.19-2506-1462454355-1054.4493-6-0@openssl.org>

Fixed in commit acde647fb0347f64af8

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=4493
Please log in as guest with password guest if prompted


From rt at openssl.org  Thu May  5 13:57:47 2016
From: rt at openssl.org (Salz, Rich via RT)
Date: Thu, 05 May 2016 13:57:47 +0000
Subject: [openssl-dev] [openssl.org #4522] Update to openssl.spec
	supplied with 1.0.1s
In-Reply-To: <be448272154a482bac463dcffe98a7ab@usma1ex-dag1mb1.msg.corp.akamai.com>
References: <RT-Ticket-4522@openssl.org>
 <CF59E2BB6EB04C4AB71CBCF5716C635666F8C43A@MTB0120CP3XF04.ds.irsnet.gov>
 <rt-4.0.19-21242-1461969594-1031.4522-21-0@openssl.org>
 <be448272154a482bac463dcffe98a7ab@usma1ex-dag1mb1.msg.corp.akamai.com>
Message-ID: <rt-4.0.19-23551-1462456667-1575.4522-6-0@openssl.org>



1.0.1 is at end-of life and is only getting security fixes for the rest of the year.
1.0.2 is LTS and maybe this needs to be ported there (and master) as well?


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


From rt at openssl.org  Thu May  5 14:13:59 2016
From: rt at openssl.org (Stephen Henson via RT)
Date: Thu, 05 May 2016 14:13:59 +0000
Subject: [openssl-dev] [openssl.org #4466] Memory leak in PKCS12_newpass
	function
In-Reply-To: <58FDFB4D-CDDA-4A93-ACCA-015F4A90CA9F@gmail.com>
References: <RT-Ticket-4466@openssl.org>
 <58FDFB4D-CDDA-4A93-ACCA-015F4A90CA9F@gmail.com>
Message-ID: <rt-4.0.19-2506-1462457639-1364.4466-6-0@openssl.org>

On Mon Mar 21 13:02:56 2016, ramunas.jurgilas at gmail.com wrote:
> I did write function which changes PKCS12 passphrase. I noticed that
> PKCS12_newpass function leaks memory. Memory leak disappears when
> commenting out line where is PKCS12_newpass func.
>
> Below I posted this code which I am using.
> I am using OpneSSL 1.0.2g version.
>
> Could you please give me information what I am doing wrong? Or it is
> known issue?
>

I can confirm there is a leak in that function and it's a bug in OpenSSL.
Looking into it.

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=4466
Please log in as guest with password guest if prompted


From rt at openssl.org  Thu May  5 15:13:43 2016
From: rt at openssl.org (Stephen Henson via RT)
Date: Thu, 05 May 2016 15:13:43 +0000
Subject: [openssl-dev] [openssl.org #4510] SSL certificate problem: unable
	to get local issuer certificate. Bug?
In-Reply-To: <CALC5Oe=Jx82z7yN0cOrThAae9FXKRV_SngCLvjQZbFj31oP1VQ@mail.gmail.com>
References: <RT-Ticket-4510@openssl.org>
 <CALC5Oe=Jx82z7yN0cOrThAae9FXKRV_SngCLvjQZbFj31oP1VQ@mail.gmail.com>
Message-ID: <rt-4.0.19-23551-1462461223-1977.4510-6-0@openssl.org>

On Tue Apr 12 13:41:51 2016, nbhfgq at gmail.com wrote:
> On my test server running OpenSSL 1.0.2e on Windows Server 2012. The
> "newest" cacert.pem fails with an error "SSL certificate problem: unable to
> get local issuer certificate", however, the one from 2014 works. I am
> attaching both.
>

Can you try a newer version of OpenSSL? I can't reproduce this with the latest
OpenSSL 1.0.2 stable branch.

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=4510
Please log in as guest with password guest if prompted


From rt at openssl.org  Thu May  5 17:19:36 2016
From: rt at openssl.org (ndof@gmx.li via RT)
Date: Thu, 05 May 2016 17:19:36 +0000
Subject: [openssl-dev] [openssl.org #4536] [Req] Android
	arm-v8/arm64/aarch64 Support
In-Reply-To: <5d6fa4ea-523c-cfd9-1420-76af09ba3b6c@gmx.li>
References: <RT-Ticket-4536@openssl.org>
 <5d6fa4ea-523c-cfd9-1420-76af09ba3b6c@gmx.li>
Message-ID: <rt-4.0.19-23551-1462468776-1836.4536-21-0@openssl.org>

Hello,
in the Configure file only support for Android arm-v7 are found.
But general arm-v8/arm64/aarch64 are included for the Linux target.


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


From rt at openssl.org  Thu May  5 23:05:11 2016
From: rt at openssl.org (Stephen Henson via RT)
Date: Thu, 05 May 2016 23:05:11 +0000
Subject: [openssl-dev] [openssl.org #4504] Openssl cms encrypt bug.
In-Reply-To: <CAE2+cY2_bVyymeQxJ81XK7Z8oCrP0kutMAzh9p=BWYD5PQF74A@mail.gmail.com>
References: <RT-Ticket-4504@openssl.org>
 <CAE2+cY2_bVyymeQxJ81XK7Z8oCrP0kutMAzh9p=BWYD5PQF74A@mail.gmail.com>
Message-ID: <rt-4.0.19-23551-1462489511-1906.4504-6-0@openssl.org>

Fixed now, 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=4504
Please log in as guest with password guest if prompted


From rt at openssl.org  Fri May  6 11:45:13 2016
From: rt at openssl.org (Stephen Henson via RT)
Date: Fri, 06 May 2016 11:45:13 +0000
Subject: [openssl-dev] [openssl.org #4503] RSA: the docs still talk about
	RSA_PKCS1_SSLeay
In-Reply-To: <5706D396.2010705@drbeat.li>
References: <RT-Ticket-4503@openssl.org> <5706D396.2010705@drbeat.li>
Message-ID: <rt-4.0.19-25938-1462535113-1362.4503-6-0@openssl.org>

Looks like this was addressed with commit a6eef4c81b62bbab8d.

Thanks for the contribution.

Closing ticket.

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=4503
Please log in as guest with password guest if prompted


From rt at openssl.org  Fri May  6 12:10:26 2016
From: rt at openssl.org (Stephen Henson via RT)
Date: Fri, 06 May 2016 12:10:26 +0000
Subject: [openssl-dev] [openssl.org #4429] Cannot decrypt RC4-encrypted CMS
	object
In-Reply-To: <56E67126.5040706@pdflib.com>
References: <RT-Ticket-4429@openssl.org> <56E67126.5040706@pdflib.com>
Message-ID: <rt-4.0.19-25938-1462536626-1552.4429-6-0@openssl.org>

The bug was that to support CMS a cipher needs to be able to handle the ASN.1
associated with the cipher and (AFAIK) no standard exists for RC4. The decrypt
code checked to see if ASN.1 handling was supported and threw the error because
it was not. The encrypt side only tried to use ASN.1 if the IV length was
non-zero, which is a bug.

So this has been fixed to check properly on encrypt too. The result is that you
get an error when trying to encrypt with RC4 as well as decrypt because the
operation isn't supported.

If anyone does know of a CMS standard to support RC4 (or just a way of using it
with ASN.1 as a symmetric cipher) then please let us know.

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=4429
Please log in as guest with password guest if prompted


From rt at openssl.org  Fri May  6 12:55:44 2016
From: rt at openssl.org (Richard Levitte via RT)
Date: Fri, 06 May 2016 12:55:44 +0000
Subject: [openssl-dev] [openssl.org #4519] [openssl.org bug #993] New bug
	report
In-Reply-To: <20160425151536.465BF601754@mx1.sk.ee>
References: <RT-Ticket-4519@openssl.org> <20160425151536.465BF601754@mx1.sk.ee>
Message-ID: <rt-4.0.19-25938-1462539344-1495.4519-6-0@openssl.org>

The issue in this bug report is that the input was CMS-wrapped, while OpenSSL
currently only supports PKCS#7 wrapping.

The suggestion is to make a feature request for CMS-wrapping of TS responses.

Ticket closed.

--
Richard Levitte
levitte at openssl.org

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


From rt at openssl.org  Fri May  6 13:12:49 2016
From: rt at openssl.org (Richard Levitte via RT)
Date: Fri, 06 May 2016 13:12:49 +0000
Subject: [openssl-dev] [openssl.org #4522] Update to openssl.spec supplied
	with 1.0.1s
In-Reply-To: <rt-4.0.19-23551-1462456667-147.4522-6-0@openssl.org>
References: <RT-Ticket-4522@openssl.org>
 <CF59E2BB6EB04C4AB71CBCF5716C635666F8C43A@MTB0120CP3XF04.ds.irsnet.gov>
 <rt-4.0.19-21242-1461969594-1031.4522-21-0@openssl.org>
 <be448272154a482bac463dcffe98a7ab@usma1ex-dag1mb1.msg.corp.akamai.com>
 <rt-4.0.19-23551-1462456667-147.4522-6-0@openssl.org>
Message-ID: <rt-4.0.19-25938-1462540369-31.4522-6-0@openssl.org>

Vid Thu, 05 May 2016 kl. 13.57.47, skrev rsalz at akamai.com:
>
>
> 1.0.1 is at end-of life and is only getting security fixes for the
> rest of the year.
> 1.0.2 is LTS and maybe this needs to be ported there (and master) as
> well?

master, without a doubt. I think 1.0.2 as well.

There's one think I must question though... the attached openssl.spec removes
all the architecture variants. Why?

Cheers,
Richard

--
Richard Levitte
levitte at openssl.org

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


From rt at openssl.org  Fri May  6 13:26:03 2016
From: rt at openssl.org (Withers John Z via RT)
Date: Fri, 06 May 2016 13:26:03 +0000
Subject: [openssl-dev] [openssl.org #4522] Update to openssl.spec
	supplied with 1.0.1s
In-Reply-To: <CF59E2BB6EB04C4AB71CBCF5716C635666F9467A@MTB0120CP3XF04.ds.irsnet.gov>
References: <RT-Ticket-4522@openssl.org>
 <CF59E2BB6EB04C4AB71CBCF5716C635666F8C43A@MTB0120CP3XF04.ds.irsnet.gov>
 <rt-4.0.19-21242-1461969594-1031.4522-21-0@openssl.org>
 <be448272154a482bac463dcffe98a7ab@usma1ex-dag1mb1.msg.corp.akamai.com>
 <rt-4.0.19-23551-1462456667-147.4522-6-0@openssl.org>
 <rt-4.0.19-25938-1462540369-31.4522-6-0@openssl.org>
 <CF59E2BB6EB04C4AB71CBCF5716C635666F9467A@MTB0120CP3XF04.ds.irsnet.gov>
Message-ID: <rt-4.0.19-23551-1462541163-1869.4522-6-0@openssl.org>

(Replying to you instead of to the list as I can't ...)

That was an oversight on my part.  As part of the porting process, I was removing as many potential variables as possible.  I neglected to reinstate that code before posting the file.

I apologize for any confusion.

John Withers
Enterprise Operations
Directory Services Branch - OS:CTO:EO:ISD:DSB:PKI
Champaign, Illinois
?
Phone: (217) 974-7736

-----Original Message-----
From: Richard Levitte via RT [mailto:rt at openssl.org] 
Sent: Friday, May 06, 2016 8:13 AM
To: Withers John Z
Cc: openssl-dev at openssl.org
Subject: [openssl.org #4522] Update to openssl.spec supplied with 1.0.1s

Vid Thu, 05 May 2016 kl. 13.57.47, skrev rsalz at akamai.com:
>
>
> 1.0.1 is at end-of life and is only getting security fixes for the
> rest of the year.
> 1.0.2 is LTS and maybe this needs to be ported there (and master) as
> well?

master, without a doubt. I think 1.0.2 as well.

There's one think I must question though... the attached openssl.spec removes
all the architecture variants. Why?

Cheers,
Richard

--
Richard Levitte
levitte at openssl.org

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


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


From dcruette at qualitesys.com  Fri May  6 13:10:31 2016
From: dcruette at qualitesys.com (dcruette at qualitesys.com)
Date: Fri, 06 May 2016 15:10:31 +0200
Subject: [openssl-dev] Make under windows
In-Reply-To: <572AFC52.7020908@openssl.org>
References: <37d47403029a56ad3095af56b7323077@qualitesys.com>
 <20160505.083845.1462163947383356678.levitte@openssl.org>
 <572AFC52.7020908@openssl.org>
Message-ID: <9e8802e861c45309b26807d62ed731f2@qualitesys.com>

Hello

I am not expert of those tool configurations / installations.
Is it possible to update the INSTALL file for windows + mingw ?

Thanks for your help.

Didier

Le 05.05.2016 09:54, Andy Polyakov a ?crit?:
>> If you configure for mingw, you need to do so from inside a MSYS/MingW
>> shell.  If you want to build inside a cmd shell, you have to configure
>> natively,
> 
> In addition a "matching perl" is likely to be required. I mean one can
> start MSYS shell and have ActiveState Perl first on the $PATH and that
> is not directly supported combination. It might work, but if it 
> doesn't,
> we don't want to figure out why exactly. So one also better ensures 
> that
> MSYS shell calls MSYS perl. But one should keep in mind that "matching"
> applies to build environment rather than configuration target. For
> example one can compile for mingw not only from MSYS shell, but even
> from within Cygwin and Linux. Probably most correct definition of
> "matching" is "one that matches make utility".

From rsalz at akamai.com  Fri May  6 17:26:35 2016
From: rsalz at akamai.com (Salz, Rich)
Date: Fri, 6 May 2016 17:26:35 +0000
Subject: [openssl-dev] use of X.509 lookup methods,
 X509_OBJECT internal or opaque?
In-Reply-To: <571B8D25.2030100@roumenpetrov.info>
References: <571B8D25.2030100@roumenpetrov.info>
Message-ID: <0ceaba4b64d44e689f05225f480ba33f@usma1ex-dag1mb1.msg.corp.akamai.com>

So let me try to summarize.

You need 
    X509 *X509_STORE_get_X509_by_subject(X509_STORE_CTX *vs, X509_NAME *name)
    X509_CRL *X509_STORE_get_X509_CRL_by_subject(X509_STORE_CTX *vs,  X509_NAME *name)
And replace the existing "X509_STORE_get_X509_by_subject"

We also need X590_OBJECT_new() and X509_OBJECT_free and X509_CRL *X509_OBJECT_get0_X509_CRL(X509_OBJECT *a).

Make sure the memory issues are addressed and avoid double-free. 

Right?


From rsalz at akamai.com  Fri May  6 17:27:54 2016
From: rsalz at akamai.com (Salz, Rich)
Date: Fri, 6 May 2016 17:27:54 +0000
Subject: [openssl-dev] use of X.509 lookup methods,
 X509_OBJECT internal or opaque?
In-Reply-To: <0ceaba4b64d44e689f05225f480ba33f@usma1ex-dag1mb1.msg.corp.akamai.com>
References: <571B8D25.2030100@roumenpetrov.info>
 <0ceaba4b64d44e689f05225f480ba33f@usma1ex-dag1mb1.msg.corp.akamai.com>
Message-ID: <790538e8524942339cede3107cb60d43@usma1ex-dag1mb1.msg.corp.akamai.com>

> You need
>     X509 *X509_STORE_get_X509_by_subject(X509_STORE_CTX *vs,
> X509_NAME *name)
>     X509_CRL *X509_STORE_get_X509_CRL_by_subject(X509_STORE_CTX *vs,
> X509_NAME *name) And replace the existing
> "X509_STORE_get_X509_by_subject"
> 
> We also need X590_OBJECT_new() and X509_OBJECT_free and X509_CRL
> *X509_OBJECT_get0_X509_CRL(X509_OBJECT *a).
> 
> Make sure the memory issues are addressed and avoid double-free.
> 
> Right?

"You need" is misleading.  These are new accessors needed  because the X509_OBJECT was made opaque.  In other words we did it :)

From rt at openssl.org  Fri May  6 21:06:56 2016
From: rt at openssl.org (Stephen Henson via RT)
Date: Fri, 06 May 2016 21:06:56 +0000
Subject: [openssl-dev] [openssl.org #4478] DOCUMENTATION: PKCS12_newpass
In-Reply-To: <CAH8yC8k3nAirFQAdS3hv-8Y_xDNMARwzUAc5HiG6tk1wf4h_Zg@mail.gmail.com>
References: <RT-Ticket-4478@openssl.org>
 <CAH8yC8k3nAirFQAdS3hv-8Y_xDNMARwzUAc5HiG6tk1wf4h_Zg@mail.gmail.com>
Message-ID: <rt-4.0.19-23551-1462568816-1893.4478-6-0@openssl.org>

Added now. Thanks for the contribution.

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=4478
Please log in as guest with password guest if prompted


From rt at openssl.org  Fri May  6 21:07:48 2016
From: rt at openssl.org (Stephen Henson via RT)
Date: Fri, 06 May 2016 21:07:48 +0000
Subject: [openssl-dev] [openssl.org #4466] Memory leak in PKCS12_newpass
	function
In-Reply-To: <CAAwMTtXM81aE6eCyqNSJDpm2UgGfcGKFpEouR5u-8AWRRL9Y8w@mail.gmail.com>
References: <RT-Ticket-4466@openssl.org>
 <CAAwMTtXM81aE6eCyqNSJDpm2UgGfcGKFpEouR5u-8AWRRL9Y8w@mail.gmail.com>
Message-ID: <rt-4.0.19-23551-1462568868-1753.4466-6-0@openssl.org>

Fixed, 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=4466
Please log in as guest with password guest if prompted


From rt at openssl.org  Fri May  6 21:12:23 2016
From: rt at openssl.org (Stephen Henson via RT)
Date: Fri, 06 May 2016 21:12:23 +0000
Subject: [openssl-dev] [openssl.org #4449] PATCH: fix PKCS12_newpass does
	not take a cont char[]
In-Reply-To: <CAH8yC8nMPfL2hD1qdF-6cw_NBb1Qf5Ut80p8g9EJ1odphbB2KQ@mail.gmail.com>
References: <RT-Ticket-4449@openssl.org>
 <CAH8yC8nMPfL2hD1qdF-6cw_NBb1Qf5Ut80p8g9EJ1odphbB2KQ@mail.gmail.com>
Message-ID: <rt-4.0.19-23551-1462569143-1203.4449-6-0@openssl.org>

Fixed now, 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=4449
Please log in as guest with password guest if prompted


From rt at openssl.org  Fri May  6 21:19:56 2016
From: rt at openssl.org (Stephen Henson via RT)
Date: Fri, 06 May 2016 21:19:56 +0000
Subject: [openssl-dev] [openssl.org #4510] SSL certificate problem: unable
	to get local issuer certificate. Bug?
In-Reply-To: <rt-4.0.19-2506-1462494827-1054.4510-6-0@openssl.org>
References: <RT-Ticket-4510@openssl.org>
 <CALC5Oe=Jx82z7yN0cOrThAae9FXKRV_SngCLvjQZbFj31oP1VQ@mail.gmail.com>
 <rt-4.0.19-23551-1462461223-1977.4510-6-0@openssl.org>
 <CALC5Oe=Or-7=mrWX_Az7KTeqHqmvoh-Au=BYVGpeqaK-AGaY4w@mail.gmail.com>
 <rt-4.0.19-2506-1462494827-1054.4510-6-0@openssl.org>
Message-ID: <rt-4.0.19-23551-1462569596-1783.4510-6-0@openssl.org>

On Fri May 06 00:33:47 2016, nbhfgq at gmail.com wrote:
>
> I updated the openssl version to 1.0.2h and reran. Was able to
> reproduce. *Old
> pem works newer pem fails*.
>

Can you reproduce this using s_client?

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=4510
Please log in as guest with password guest if prompted


From rt at openssl.org  Fri May  6 22:18:46 2016
From: rt at openssl.org (SMS Conversation via RT)
Date: Fri, 06 May 2016 22:18:46 +0000
Subject: [openssl-dev] [openssl.org #4510] SSL certificate problem:
	unable to get local issuer certificate. Bug?
In-Reply-To: <CALC5Oektb0CzpdxL_MGGpxraHzotXWWi1+xxunVbMoMQ+EdKrQ@mail.gmail.com>
References: <RT-Ticket-4510@openssl.org>
 <CALC5Oe=Jx82z7yN0cOrThAae9FXKRV_SngCLvjQZbFj31oP1VQ@mail.gmail.com>
 <rt-4.0.19-23551-1462461223-1977.4510-6-0@openssl.org>
 <CALC5Oe=Or-7=mrWX_Az7KTeqHqmvoh-Au=BYVGpeqaK-AGaY4w@mail.gmail.com>
 <rt-4.0.19-2506-1462494827-1054.4510-6-0@openssl.org>
 <rt-4.0.19-23551-1462569596-1783.4510-6-0@openssl.org>
 <CALC5Oektb0CzpdxL_MGGpxraHzotXWWi1+xxunVbMoMQ+EdKrQ@mail.gmail.com>
Message-ID: <rt-4.0.19-23551-1462573126-1270.4510-6-0@openssl.org>

>
> PS C:\OpenSSL-Win32\bin> .\openssl s_client -connect
> www.googleapis.com:443
> CONNECTED(00000088)
> depth=2 C = US, O = GeoTrust Inc., CN = GeoTrust Global CA
> verify error:num=20:unable to get local issuer certificate
> ---
> Certificate chain
>  0 s:/C=US/ST=California/L=Mountain View/O=Google Inc/CN=*.googleapis.com
>    i:/C=US/O=Google Inc/CN=Google Internet Authority G2
>  1 s:/C=US/O=Google Inc/CN=Google Internet Authority G2
>    i:/C=US/O=GeoTrust Inc./CN=GeoTrust Global CA
>  2 s:/C=US/O=GeoTrust Inc./CN=GeoTrust Global CA
>    i:/C=US/O=Equifax/OU=Equifax Secure Certificate Authority
> ---
> Server certificate
> -----BEGIN CERTIFICATE-----
> MIIE3TCCA8WgAwIBAgIIDH5aJKS4GAgwDQYJKoZIhvcNAQELBQAwSTELMAkGA1UE
> BhMCVVMxEzARBgNVBAoTCkdvb2dsZSBJbmMxJTAjBgNVBAMTHEdvb2dsZSBJbnRl
> cm5ldCBBdXRob3JpdHkgRzIwHhcNMTYwNTA0MDkwNDQ5WhcNMTYwNzI3MDgzOTAw
> WjBqMQswCQYDVQQGEwJVUzETMBEGA1UECAwKQ2FsaWZvcm5pYTEWMBQGA1UEBwwN
> TW91bnRhaW4gVmlldzETMBEGA1UECgwKR29vZ2xlIEluYzEZMBcGA1UEAwwQKi5n
> b29nbGVhcGlzLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAI8B
> ycNrRlBbiRgDcbCJ9fDNbfXCbKZgU8ZVwlXQitVVd4WTPMvXBJc9Pqp8ZjdnC6wG
> bQZYogxOzWjDtkmlyHmjncfWN64yOhKUrOVcueylNtMaO7RP4mId9DKRcZK+omh4
> ONvJC3wb7HSu5oKWm2jf47XUU0/XXGuX2BXQNJmXP3g56vHnRkNzfO5iygqFbMtM
> 8Wu/M4agSa24HIcx55z5LhAzupoTBhNVYvyvegdIEjhXJQ1h8DyWaCnE7Ek57pba
> QjlEwW7cFFA0xOMwM8SrI34kfLh43eNGFaqZn1wHieFK51WK83WLFge8fG6+qZSL
> 63R+QtXlVRF5WvCvjHcCAwEAAaOCAaYwggGiMB0GA1UdJQQWMBQGCCsGAQUFBwMB
> BggrBgEFBQcDAjB0BgNVHREEbTBrghAqLmdvb2dsZWFwaXMuY29tghUqLmNsaWVu
> dHM2Lmdvb2dsZS5jb22CGCouY2xvdWRlbmRwb2ludHNhcGlzLmNvbYIWY2xvdWRl
> bmRwb2ludHNhcGlzLmNvbYIOZ29vZ2xlYXBpcy5jb20waAYIKwYBBQUHAQEEXDBa
> MCsGCCsGAQUFBzAChh9odHRwOi8vcGtpLmdvb2dsZS5jb20vR0lBRzIuY3J0MCsG
> CCsGAQUFBzABhh9odHRwOi8vY2xpZW50czEuZ29vZ2xlLmNvbS9vY3NwMB0GA1Ud
> DgQWBBSCEj3sYkh+7kTDbxl2z1RuBnZq1zAMBgNVHRMBAf8EAjAAMB8GA1UdIwQY
> MBaAFErdBhYbvPZotXb1gba7Yhq6WoEvMCEGA1UdIAQaMBgwDAYKKwYBBAHWeQIF
> ATAIBgZngQwBAgIwMAYDVR0fBCkwJzAloCOgIYYfaHR0cDovL3BraS5nb29nbGUu
> Y29tL0dJQUcyLmNybDANBgkqhkiG9w0BAQsFAAOCAQEAW3uduEkfbXschjzuWe1/
> tBFY5ZOMsaLRXyIHaHYdrrqi8NDHa/l+ukPiJZQLyEV3PKHUjFSjZKr88dw5Rw/R
> NGD0QaR/4iWcvR8bn0rbHtW1k/q34CsIHLHMqDRdBA3ciJSAViwJDqo7VxIGwkuX
> N0veDKwkPgbUL1Z8/HBtl74Acp11LeXP0RWEZYH/FhR9Q2XBnXDHMk8UmjIEKGTv
> +ubGxdvq8JN0d++y0hPJjM+RspdrOpLIGIlvIXZefTrobuFGuwiDzdG8P8q1MaVK
> 8dHSjECXVd/o81gCI3ZJ9ycHMPMpRxoC3JK21SGHDs16hHuEup2EBNW1w7JKsai5
> wQ==
> -----END CERTIFICATE-----
> subject=/C=US/ST=California/L=Mountain View/O=Google Inc/CN=*.
> googleapis.com
> issuer=/C=US/O=Google Inc/CN=Google Internet Authority G2
> ---
> No client certificate CA names sent
> Peer signing digest: SHA256
> Server Temp Key: ECDH, P-256, 256 bits
> ---
> SSL handshake has read 3820 bytes and written 433 bytes
> ---
> New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES128-GCM-SHA256
> Server public key is 2048 bit
> Secure Renegotiation IS supported
> Compression: NONE
> Expansion: NONE
> No ALPN negotiated
> SSL-Session:
>     Protocol  : TLSv1.2
>     Cipher    : ECDHE-RSA-AES128-GCM-SHA256
>     Session-ID:
> 9E26D6E32758E9BC908849E57A3DBD2A9C3905604D8E63FB044B0E195C00AF1F
>     Session-ID-ctx:
>     Master-Key:
> 6458E2E8555AE8A173D525FCDE2A84C39B50451CE645F81ABB1265133C3D6CF272B41F3D0F5F1E66CBB3445FB2FBBBCB
>     Key-Arg   : None
>     PSK identity: None
>     PSK identity hint: None
>     SRP username: None
>     TLS session ticket lifetime hint: 100800 (seconds)
>     TLS session ticket:
>     0000 - ec 61 29 b8 43 b5 f4 1c-d7 d8 87 e1 2c b1 77 cd
> .a).C.......,.w.
>     0010 - 22 1d df 2e 1c e5 27 e5-7e e5 5d 0a f4 8e 67 6a
> ".....'.~.]...gj
>     0020 - ef 3b 54 67 20 78 bb a3-1f 74 0f 0b 01 5e e2 71   .;Tg
> x...t...^.q
>     0030 - 88 62 1b 4d 62 d6 8b 88-61 51 51 da 4a de 6f bc
> .b.Mb...aQQ.J.o.
>     0040 - eb 00 f8 02 cd 25 ed 97-a7 a6 a6 8e c2 5b cd 6b
> .....%.......[.k
>     0050 - 7c 91 f9 56 8b bc 16 0e-ae 25 55 c3 b1 70 1a 5d
> |..V.....%U..p.]
>     0060 - f2 6e 91 5a a5 84 e1 a3-d3 68 27 60 47 03 f9 03
> .n.Z.....h'`G...
>     0070 - 5b 64 0c 7a f2 fd a5 07-fe 0d 4d 74 47 db 33 fb
> [d.z......MtG.3.
>     0080 - d9 0d fd 79 9d 21 3a c7-8f b8 5d 36 c4 f2 63 8d
> ...y.!:...]6..c.
>     0090 - 28 65 8e 72 20 e3 29 97-22 4f 13 3b b2 63 e1 20   (e.r
> .)."O.;.c.
>     00a0 - 2c a8 b8 4b                                       ,..K
>     Start Time: 1462572985
>     Timeout   : 300 (sec)
>     Verify return code: 20 (unable to get local issuer certificate)
> ---
>
>
> On Fri, May 6, 2016 at 2:19 PM, Stephen Henson via RT <rt at openssl.org>
> wrote:
> >
> > I updated the openssl version to 1.0.2h and reran. Was able to
> > reproduce. *Old
> > pem works newer pem fails*.
> >
> Can you reproduce this using s_client?
> 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=4510
> Please log in as guest with password guest if prompted
>
On Fri May 06 00:33:47 2016, nbhfgq at gmail.com wrote:
>

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


From rt at openssl.org  Fri May  6 22:37:55 2016
From: rt at openssl.org (SMS Conversation via RT)
Date: Fri, 06 May 2016 22:37:55 +0000
Subject: [openssl-dev] [openssl.org #4510] SSL certificate problem:
	unable to get local issuer certificate. Bug?
In-Reply-To: <CALC5OenYF34P8xjn-2r1n+yQRjXd9K1McBa=-YTbA9AsARfitA@mail.gmail.com>
References: <RT-Ticket-4510@openssl.org>
 <CALC5Oe=Jx82z7yN0cOrThAae9FXKRV_SngCLvjQZbFj31oP1VQ@mail.gmail.com>
 <rt-4.0.19-23551-1462461223-1977.4510-6-0@openssl.org>
 <CALC5Oe=Or-7=mrWX_Az7KTeqHqmvoh-Au=BYVGpeqaK-AGaY4w@mail.gmail.com>
 <rt-4.0.19-2506-1462494827-1054.4510-6-0@openssl.org>
 <rt-4.0.19-23551-1462569596-1783.4510-6-0@openssl.org>
 <CALC5OenYF34P8xjn-2r1n+yQRjXd9K1McBa=-YTbA9AsARfitA@mail.gmail.com>
Message-ID: <rt-4.0.19-23551-1462574275-1509.4510-6-0@openssl.org>

Hello Steve,

*If I do not indicate the location of the cert*
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>

> PS C:\OpenSSL-Win32\bin> .\openssl s_client -connect
> www.googleapis.com:443
> CONNECTED(00000088)
> depth=2 C = US, O = GeoTrust Inc., CN = GeoTrust Global CA
> verify error:num=20:unable to get local issuer certificate
> ---
> Certificate chain
>  0 s:/C=US/ST=California/L=Mountain View/O=Google Inc/CN=*.googleapis.com
>    i:/C=US/O=Google Inc/CN=Google Internet Authority G2
>  1 s:/C=US/O=Google Inc/CN=Google Internet Authority G2
>    i:/C=US/O=GeoTrust Inc./CN=GeoTrust Global CA
>  2 s:/C=US/O=GeoTrust Inc./CN=GeoTrust Global CA
>    i:/C=US/O=Equifax/OU=Equifax Secure Certificate Authority
> ---
> Server certificate
> -----BEGIN CERTIFICATE-----
> MIIE3TCCA8WgAwIBAgIIDH5aJKS4GAgwDQYJKoZIhvcNAQELBQAwSTELMAkGA1UE
> BhMCVVMxEzARBgNVBAoTCkdvb2dsZSBJbmMxJTAjBgNVBAMTHEdvb2dsZSBJbnRl
> cm5ldCBBdXRob3JpdHkgRzIwHhcNMTYwNTA0MDkwNDQ5WhcNMTYwNzI3MDgzOTAw
> WjBqMQswCQYDVQQGEwJVUzETMBEGA1UECAwKQ2FsaWZvcm5pYTEWMBQGA1UEBwwN
> TW91bnRhaW4gVmlldzETMBEGA1UECgwKR29vZ2xlIEluYzEZMBcGA1UEAwwQKi5n
> b29nbGVhcGlzLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAI8B
> ycNrRlBbiRgDcbCJ9fDNbfXCbKZgU8ZVwlXQitVVd4WTPMvXBJc9Pqp8ZjdnC6wG
> bQZYogxOzWjDtkmlyHmjncfWN64yOhKUrOVcueylNtMaO7RP4mId9DKRcZK+omh4
> ONvJC3wb7HSu5oKWm2jf47XUU0/XXGuX2BXQNJmXP3g56vHnRkNzfO5iygqFbMtM
> 8Wu/M4agSa24HIcx55z5LhAzupoTBhNVYvyvegdIEjhXJQ1h8DyWaCnE7Ek57pba
> QjlEwW7cFFA0xOMwM8SrI34kfLh43eNGFaqZn1wHieFK51WK83WLFge8fG6+qZSL
> 63R+QtXlVRF5WvCvjHcCAwEAAaOCAaYwggGiMB0GA1UdJQQWMBQGCCsGAQUFBwMB
> BggrBgEFBQcDAjB0BgNVHREEbTBrghAqLmdvb2dsZWFwaXMuY29tghUqLmNsaWVu
> dHM2Lmdvb2dsZS5jb22CGCouY2xvdWRlbmRwb2ludHNhcGlzLmNvbYIWY2xvdWRl
> bmRwb2ludHNhcGlzLmNvbYIOZ29vZ2xlYXBpcy5jb20waAYIKwYBBQUHAQEEXDBa
> MCsGCCsGAQUFBzAChh9odHRwOi8vcGtpLmdvb2dsZS5jb20vR0lBRzIuY3J0MCsG
> CCsGAQUFBzABhh9odHRwOi8vY2xpZW50czEuZ29vZ2xlLmNvbS9vY3NwMB0GA1Ud
> DgQWBBSCEj3sYkh+7kTDbxl2z1RuBnZq1zAMBgNVHRMBAf8EAjAAMB8GA1UdIwQY
> MBaAFErdBhYbvPZotXb1gba7Yhq6WoEvMCEGA1UdIAQaMBgwDAYKKwYBBAHWeQIF
> ATAIBgZngQwBAgIwMAYDVR0fBCkwJzAloCOgIYYfaHR0cDovL3BraS5nb29nbGUu
> Y29tL0dJQUcyLmNybDANBgkqhkiG9w0BAQsFAAOCAQEAW3uduEkfbXschjzuWe1/
> tBFY5ZOMsaLRXyIHaHYdrrqi8NDHa/l+ukPiJZQLyEV3PKHUjFSjZKr88dw5Rw/R
> NGD0QaR/4iWcvR8bn0rbHtW1k/q34CsIHLHMqDRdBA3ciJSAViwJDqo7VxIGwkuX
> N0veDKwkPgbUL1Z8/HBtl74Acp11LeXP0RWEZYH/FhR9Q2XBnXDHMk8UmjIEKGTv
> +ubGxdvq8JN0d++y0hPJjM+RspdrOpLIGIlvIXZefTrobuFGuwiDzdG8P8q1MaVK
> 8dHSjECXVd/o81gCI3ZJ9ycHMPMpRxoC3JK21SGHDs16hHuEup2EBNW1w7JKsai5
> wQ==
> -----END CERTIFICATE-----
> subject=/C=US/ST=California/L=Mountain View/O=Google Inc/CN=*.
> googleapis.com
> issuer=/C=US/O=Google Inc/CN=Google Internet Authority G2
> ---
> No client certificate CA names sent
> Peer signing digest: SHA256
> Server Temp Key: ECDH, P-256, 256 bits
> ---
> SSL handshake has read 3820 bytes and written 433 bytes
> ---
> New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES128-GCM-SHA256
> Server public key is 2048 bit
> Secure Renegotiation IS supported
> Compression: NONE
> Expansion: NONE
> No ALPN negotiated
> SSL-Session:
>     Protocol  : TLSv1.2
>     Cipher    : ECDHE-RSA-AES128-GCM-SHA256
>     Session-ID:
> 9E26D6E32758E9BC908849E57A3DBD2A9C3905604D8E63FB044B0E195C00AF1F
>     Session-ID-ctx:
>     Master-Key:
> 6458E2E8555AE8A173D525FCDE2A84C39B50451CE645F81ABB1265133C3D6CF272B41F3D0F5F1E66CBB3445FB2FBBBCB
>     Key-Arg   : None
>     PSK identity: None
>     PSK identity hint: None
>     SRP username: None
>     TLS session ticket lifetime hint: 100800 (seconds)
>     TLS session ticket:
>     0000 - ec 61 29 b8 43 b5 f4 1c-d7 d8 87 e1 2c b1 77 cd
> .a).C.......,.w.
>     0010 - 22 1d df 2e 1c e5 27 e5-7e e5 5d 0a f4 8e 67 6a
> ".....'.~.]...gj
>     0020 - ef 3b 54 67 20 78 bb a3-1f 74 0f 0b 01 5e e2 71   .;Tg
> x...t...^.q
>     0030 - 88 62 1b 4d 62 d6 8b 88-61 51 51 da 4a de 6f bc
> .b.Mb...aQQ.J.o.
>     0040 - eb 00 f8 02 cd 25 ed 97-a7 a6 a6 8e c2 5b cd 6b
> .....%.......[.k
>     0050 - 7c 91 f9 56 8b bc 16 0e-ae 25 55 c3 b1 70 1a 5d
> |..V.....%U..p.]
>     0060 - f2 6e 91 5a a5 84 e1 a3-d3 68 27 60 47 03 f9 03
> .n.Z.....h'`G...
>     0070 - 5b 64 0c 7a f2 fd a5 07-fe 0d 4d 74 47 db 33 fb
> [d.z......MtG.3.
>     0080 - d9 0d fd 79 9d 21 3a c7-8f b8 5d 36 c4 f2 63 8d
> ...y.!:...]6..c.
>     0090 - 28 65 8e 72 20 e3 29 97-22 4f 13 3b b2 63 e1 20   (e.r
> .)."O.;.c.
>     00a0 - 2c a8 b8 4b                                       ,..K
>     Start Time: 1462572985
>     Timeout   : 300 (sec)
>     Verify return code: 20 (unable to get local issuer certificate)

---


*I point to the the newest cert*
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>

> PS C:\OpenSSL-Win32\bin> .\openssl s_client -CAfile
> 'C:\xampp\php\cacert.pem' -connect www.googleapis.com:443
> CONNECTED(000000D8)
> depth=2 C = US, O = GeoTrust Inc., CN = GeoTrust Global CA
> verify return:1
> depth=1 C = US, O = Google Inc, CN = Google Internet Authority G2
> verify return:1
> depth=0 C = US, ST = California, L = Mountain View, O = Google Inc, CN = *.
> googleapis.com
> verify return:1
> ---
> Certificate chain
>  0 s:/C=US/ST=California/L=Mountain View/O=Google Inc/CN=*.googleapis.com
>    i:/C=US/O=Google Inc/CN=Google Internet Authority G2
>  1 s:/C=US/O=Google Inc/CN=Google Internet Authority G2
>    i:/C=US/O=GeoTrust Inc./CN=GeoTrust Global CA
>  2 s:/C=US/O=GeoTrust Inc./CN=GeoTrust Global CA
>    i:/C=US/O=Equifax/OU=Equifax Secure Certificate Authority
> ---
> Server certificate
> -----BEGIN CERTIFICATE-----
> MIIE3TCCA8WgAwIBAgIITVrtsF9kKrwwDQYJKoZIhvcNAQELBQAwSTELMAkGA1UE
> BhMCVVMxEzARBgNVBAoTCkdvb2dsZSBJbmMxJTAjBgNVBAMTHEdvb2dsZSBJbnRl
> cm5ldCBBdXRob3JpdHkgRzIwHhcNMTYwNDIwMTMyMzU0WhcNMTYwNzEzMTMwODAw
> WjBqMQswCQYDVQQGEwJVUzETMBEGA1UECAwKQ2FsaWZvcm5pYTEWMBQGA1UEBwwN
> TW91bnRhaW4gVmlldzETMBEGA1UECgwKR29vZ2xlIEluYzEZMBcGA1UEAwwQKi5n
> b29nbGVhcGlzLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAJpY
> rj57gYKRcXGpPuPQScAPqnrlIc+vLMoz9cSoC8QMh3G8M/eNeKGsOW6NT6nlKBEn
> gx1QthGh4mdyBzhYXFDun3csjMA/TSE0X3sNWU5byKJHOVqmjlTu0y3wqp/3EuuE
> QhJCFV+DFvcZM4w1SJANVJJzgKfpCW92NrnCSgd3fsHqUriMI5AfbARga7DyUHad
> WKs7oO7izR2tfgeh8RtRLkmTmxpLWaLJusVRzzfX5m8QU0s2D3thNpMsyH+VZqqU
> v0s5sSS6llM+KhFVT9xANSCTDCxBOGEg5DlhEWPfih/2pK+wUcLKbI7t+XJIr9yR
> +Myt43wTyAci+EvWX4ECAwEAAaOCAaYwggGiMB0GA1UdJQQWMBQGCCsGAQUFBwMB
> BggrBgEFBQcDAjB0BgNVHREEbTBrghAqLmdvb2dsZWFwaXMuY29tghUqLmNsaWVu
> dHM2Lmdvb2dsZS5jb22CGCouY2xvdWRlbmRwb2ludHNhcGlzLmNvbYIWY2xvdWRl
> bmRwb2ludHNhcGlzLmNvbYIOZ29vZ2xlYXBpcy5jb20waAYIKwYBBQUHAQEEXDBa
> MCsGCCsGAQUFBzAChh9odHRwOi8vcGtpLmdvb2dsZS5jb20vR0lBRzIuY3J0MCsG
> CCsGAQUFBzABhh9odHRwOi8vY2xpZW50czEuZ29vZ2xlLmNvbS9vY3NwMB0GA1Ud
> DgQWBBTs3g7lOYzfplaZC+O3gm5xj/bYxjAMBgNVHRMBAf8EAjAAMB8GA1UdIwQY
> MBaAFErdBhYbvPZotXb1gba7Yhq6WoEvMCEGA1UdIAQaMBgwDAYKKwYBBAHWeQIF
> ATAIBgZngQwBAgIwMAYDVR0fBCkwJzAloCOgIYYfaHR0cDovL3BraS5nb29nbGUu
> Y29tL0dJQUcyLmNybDANBgkqhkiG9w0BAQsFAAOCAQEAmWm01cSN344EyyLjEGQN
> 1y2eKIHg4n7qw9lz3Kjolv/OhMKSG17AURTIZm8O8n6g+OZUtLPaVie0bXsdt/vS
> fYjj4j2vzldj9fT9CNFi0DyuxOAOujOMtu4wRKREfXhHzmUNxSbscjD9ImLd0J92
> iHqP9QsFvmUz/dsyQixeZ4aqeW/ogOddje3GgB5EfINH3K8g+OFVJvJUc4wFvMMa
> JfPJoCBOudrejPM5Zp3yQCQZ1GhTf906PVfAtHtAXE/QQKMqqneem3SSn4cJV1+H
> zfejHoNYmh6eAA8W6Stw7HGDmsNCijzhwrROnsQ1p4QF5qYtdUhshZS6WdkBE4E1
> ZA==
> -----END CERTIFICATE-----
> subject=/C=US/ST=California/L=Mountain View/O=Google Inc/CN=*.
> googleapis.com
> issuer=/C=US/O=Google Inc/CN=Google Internet Authority G2
> ---
> No client certificate CA names sent
> Peer signing digest: SHA256
> Server Temp Key: ECDH, P-256, 256 bits
> ---
> SSL handshake has read 3820 bytes and written 433 bytes
> ---
> New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES128-GCM-SHA256
> Server public key is 2048 bit
> Secure Renegotiation IS supported
> Compression: NONE
> Expansion: NONE
> No ALPN negotiated
> SSL-Session:
>     Protocol  : TLSv1.2
>     Cipher    : ECDHE-RSA-AES128-GCM-SHA256
>     Session-ID:
> E2EFF653C6852A4ABF4A3045702E9EF0C82EC8DEB46F522F70B5654A8A43CFA5
>     Session-ID-ctx:
>     Master-Key:
> 76EB07CAD8978DC7CF53EB6DBAED18A2B564A8E4BBBE97FA3086631F791C631632D70E48546EEF9E07E379BD35B0EE5A
>     Key-Arg   : None
>     PSK identity: None
>     PSK identity hint: None
>     SRP username: None
>     TLS session ticket lifetime hint: 100800 (seconds)
>     TLS session ticket:
>     0000 - ec 61 29 b8 43 b5 f4 1c-d7 d8 87 e1 2c b1 77 cd
> .a).C.......,.w.
>     0010 - ea 29 f3 d0 b9 21 f1 0c-2c 04 ee 1a 1e b2 65 aa
> .)...!..,.....e.
>     0020 - 8b d6 1a 0f 9f 6e 8d 01-e2 1e 88 dc 43 29 dc bf
> .....n......C)..
>     0030 - 7e 92 e5 41 c8 3d 02 01-be 81 89 67 aa 9b a4 5c
> ~..A.=.....g...\
>     0040 - 59 7a ed 01 e1 ff 6d 6f-c0 65 f7 f0 aa 4a 46 ad
> Yz....mo.e...JF.
>     0050 - d4 d3 84 39 80 f2 84 98-bd 22 f5 31 9a ae 77 7d
> ...9.....".1..w}
>     0060 - 90 c0 35 7f c1 30 18 1a-8d 3a a5 47 9a fd 65 f0
> ..5..0...:.G..e.
>     0070 - 77 93 8c a2 95 8b a3 80-79 7d a3 6b 9d bf 62 8e
> w.......y}.k..b.
>     0080 - c3 d8 17 ac c2 9f c5 e9-51 a6 34 7e 65 9a 69 9b
> ........Q.4~e.i.
>     0090 - 92 7c cc 10 96 cb 14 d9-b6 60 f5 d5 f0 e1 bf f0
> .|.......`......
>     00a0 - 77 f1 0c 1b                                       w...
>     Start Time: 1462573288
>     Timeout   : 300 (sec)
>     Verify return code: 0 (ok)

---


*When I point to the old cert*
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>

> PS C:\OpenSSL-Win32\bin> .\openssl s_client -CAfile
> 'C:\xampp\php\cacert_old.pem' -connect www.googleapis.com:443
> CONNECTED(00000140)
> depth=3 C = US, O = Equifax, OU = Equifax Secure Certificate Authority
> verify return:1
> depth=2 C = US, O = GeoTrust Inc., CN = GeoTrust Global CA
> verify return:1
> depth=1 C = US, O = Google Inc, CN = Google Internet Authority G2
> verify return:1
> depth=0 C = US, ST = California, L = Mountain View, O = Google Inc, CN = *.
> googleapis.com
> verify return:1
> ---
> Certificate chain
>  0 s:/C=US/ST=California/L=Mountain View/O=Google Inc/CN=*.googleapis.com
>    i:/C=US/O=Google Inc/CN=Google Internet Authority G2
>  1 s:/C=US/O=Google Inc/CN=Google Internet Authority G2
>    i:/C=US/O=GeoTrust Inc./CN=GeoTrust Global CA
>  2 s:/C=US/O=GeoTrust Inc./CN=GeoTrust Global CA
>    i:/C=US/O=Equifax/OU=Equifax Secure Certificate Authority
> ---
> Server certificate
> -----BEGIN CERTIFICATE-----
> MIIE3TCCA8WgAwIBAgIIDH5aJKS4GAgwDQYJKoZIhvcNAQELBQAwSTELMAkGA1UE
> BhMCVVMxEzARBgNVBAoTCkdvb2dsZSBJbmMxJTAjBgNVBAMTHEdvb2dsZSBJbnRl
> cm5ldCBBdXRob3JpdHkgRzIwHhcNMTYwNTA0MDkwNDQ5WhcNMTYwNzI3MDgzOTAw
> WjBqMQswCQYDVQQGEwJVUzETMBEGA1UECAwKQ2FsaWZvcm5pYTEWMBQGA1UEBwwN
> TW91bnRhaW4gVmlldzETMBEGA1UECgwKR29vZ2xlIEluYzEZMBcGA1UEAwwQKi5n
> b29nbGVhcGlzLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAI8B
> ycNrRlBbiRgDcbCJ9fDNbfXCbKZgU8ZVwlXQitVVd4WTPMvXBJc9Pqp8ZjdnC6wG
> bQZYogxOzWjDtkmlyHmjncfWN64yOhKUrOVcueylNtMaO7RP4mId9DKRcZK+omh4
> ONvJC3wb7HSu5oKWm2jf47XUU0/XXGuX2BXQNJmXP3g56vHnRkNzfO5iygqFbMtM
> 8Wu/M4agSa24HIcx55z5LhAzupoTBhNVYvyvegdIEjhXJQ1h8DyWaCnE7Ek57pba
> QjlEwW7cFFA0xOMwM8SrI34kfLh43eNGFaqZn1wHieFK51WK83WLFge8fG6+qZSL
> 63R+QtXlVRF5WvCvjHcCAwEAAaOCAaYwggGiMB0GA1UdJQQWMBQGCCsGAQUFBwMB
> BggrBgEFBQcDAjB0BgNVHREEbTBrghAqLmdvb2dsZWFwaXMuY29tghUqLmNsaWVu
> dHM2Lmdvb2dsZS5jb22CGCouY2xvdWRlbmRwb2ludHNhcGlzLmNvbYIWY2xvdWRl
> bmRwb2ludHNhcGlzLmNvbYIOZ29vZ2xlYXBpcy5jb20waAYIKwYBBQUHAQEEXDBa
> MCsGCCsGAQUFBzAChh9odHRwOi8vcGtpLmdvb2dsZS5jb20vR0lBRzIuY3J0MCsG
> CCsGAQUFBzABhh9odHRwOi8vY2xpZW50czEuZ29vZ2xlLmNvbS9vY3NwMB0GA1Ud
> DgQWBBSCEj3sYkh+7kTDbxl2z1RuBnZq1zAMBgNVHRMBAf8EAjAAMB8GA1UdIwQY
> MBaAFErdBhYbvPZotXb1gba7Yhq6WoEvMCEGA1UdIAQaMBgwDAYKKwYBBAHWeQIF
> ATAIBgZngQwBAgIwMAYDVR0fBCkwJzAloCOgIYYfaHR0cDovL3BraS5nb29nbGUu
> Y29tL0dJQUcyLmNybDANBgkqhkiG9w0BAQsFAAOCAQEAW3uduEkfbXschjzuWe1/
> tBFY5ZOMsaLRXyIHaHYdrrqi8NDHa/l+ukPiJZQLyEV3PKHUjFSjZKr88dw5Rw/R
> NGD0QaR/4iWcvR8bn0rbHtW1k/q34CsIHLHMqDRdBA3ciJSAViwJDqo7VxIGwkuX
> N0veDKwkPgbUL1Z8/HBtl74Acp11LeXP0RWEZYH/FhR9Q2XBnXDHMk8UmjIEKGTv
> +ubGxdvq8JN0d++y0hPJjM+RspdrOpLIGIlvIXZefTrobuFGuwiDzdG8P8q1MaVK
> 8dHSjECXVd/o81gCI3ZJ9ycHMPMpRxoC3JK21SGHDs16hHuEup2EBNW1w7JKsai5
> wQ==
> -----END CERTIFICATE-----
> subject=/C=US/ST=California/L=Mountain View/O=Google Inc/CN=*.
> googleapis.com
> issuer=/C=US/O=Google Inc/CN=Google Internet Authority G2
> ---
> No client certificate CA names sent
> Peer signing digest: SHA256
> Server Temp Key: ECDH, P-256, 256 bits
> ---
> SSL handshake has read 3820 bytes and written 433 bytes
> ---
> New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES128-GCM-SHA256
> Server public key is 2048 bit
> Secure Renegotiation IS supported
> Compression: NONE
> Expansion: NONE
> No ALPN negotiated
> SSL-Session:
>     Protocol  : TLSv1.2
>     Cipher    : ECDHE-RSA-AES128-GCM-SHA256
>     Session-ID:
> AD9140FB81BD95DBE9B7E9DDAC5CCA6CA4463112D9A7CBB31E643F40A420F310
>     Session-ID-ctx:
>     Master-Key:
> E35F7968B42F46F0900D21A3ED08016893CCBE4723ECD1C11C6F130A5FA08F714B3C0D75DDD23C65A550F64643E7C74D
>     Key-Arg   : None
>     PSK identity: None
>     PSK identity hint: None
>     SRP username: None
>     TLS session ticket lifetime hint: 100800 (seconds)
>     TLS session ticket:
>     0000 - ec 61 29 b8 43 b5 f4 1c-d7 d8 87 e1 2c b1 77 cd
> .a).C.......,.w.
>     0010 - 0c f9 5f dc 91 1b 88 8b-01 a4 28 2f 02 24 56 89
> .._.......(/.$V.
>     0020 - f1 d4 11 fd 35 83 9d 0d-a2 35 9c c2 6b 0c b4 2b
> ....5....5..k..+
>     0030 - 21 d2 76 5e 99 16 ca 25-2d 6c 52 44 56 f8 e1 87
> !.v^...%-lRDV...
>     0040 - bd 3a 69 48 bd fe eb 53-c4 21 d4 4e ef ba b3 69
> .:iH...S.!.N...i
>     0050 - 2e 00 fe 7c 94 5f 62 fa-25 c0 3e 38 f5 22 ca 78
> ...|._b.%.>8.".x
>     0060 - 31 0a 73 9c 44 f5 6b 41-e5 f1 4a 56 e0 6e ee 38
> 1.s.D.kA..JV.n.8
>     0070 - e2 61 03 d6 96 f9 86 e1-98 03 c9 ea ea 53 b6 0c
> .a...........S..
>     0080 - aa 2c fb 3d bd f0 d7 5e-69 2e 16 cf ce 2c c3 1a
> .,.=...^i....,..
>     0090 - 2d b3 7f 61 c1 ad 87 87-8d 5d c6 7d d5 15 28 0b
> -..a.....].}..(.
>     00a0 - 1d c1 db ef                                       ....
>     Start Time: 1462573578
>     Timeout   : 300 (sec)
>     Verify return code: 0 (ok)
>
>

On Fri, May 6, 2016 at 2:19 PM, Stephen Henson via RT <rt at openssl.org>
wrote:

> On Fri May 06 00:33:47 2016, nbhfgq at gmail.com wrote:
> >
> > I updated the openssl version to 1.0.2h and reran. Was able to
> > reproduce. *Old
> > pem works newer pem fails*.
> >
>
> Can you reproduce this using s_client?
>
> 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=4510
> Please log in as guest with password guest if prompted
>
>

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


From openssl at roumenpetrov.info  Sat May  7 08:30:56 2016
From: openssl at roumenpetrov.info (Roumen Petrov)
Date: Sat, 07 May 2016 11:30:56 +0300
Subject: [openssl-dev] use of X.509 lookup methods,
 X509_OBJECT internal or opaque?
In-Reply-To: <790538e8524942339cede3107cb60d43@usma1ex-dag1mb1.msg.corp.akamai.com>
References: <571B8D25.2030100@roumenpetrov.info>
 <0ceaba4b64d44e689f05225f480ba33f@usma1ex-dag1mb1.msg.corp.akamai.com>
 <790538e8524942339cede3107cb60d43@usma1ex-dag1mb1.msg.corp.akamai.com>
Message-ID: <572DA7C0.6040706@roumenpetrov.info>

Hi Rich,

Scope of my request is "use of a lookup method".

Salz, Rich wrote:
>> You need
(1)
I test port to current openssl code with following definitions 
X509_OBJECT_new() and X509_OBJECT_get0_X509_CRL.  :
....
diff --git a/crypto/x509/x509_lu.c b/crypto/x509/x509_lu.c
index ff64821..8547b0d 100644
--- a/crypto/x509/x509_lu.c
+++ b/crypto/x509/x509_lu.c
@@ -450,6 +450,12 @@ int X509_OBJECT_get_type(X509_OBJECT *a)
      return a->type;
  }

+X509_OBJECT *X509_OBJECT_new()
+{
+    X509_OBJECT *ret;
+    return OPENSSL_malloc(sizeof (*ret));
+}
+
  void X509_OBJECT_free(X509_OBJECT *a)
  {
      if (a == NULL)
....
diff --git a/crypto/x509/x509_lu.c b/crypto/x509/x509_lu.c
index c4ca619..ff64821 100644
--- a/crypto/x509/x509_lu.c
+++ b/crypto/x509/x509_lu.c
@@ -433,9 +433,18 @@ void X509_OBJECT_up_ref_count(X509_OBJECT *a)

  X509 *X509_OBJECT_get0_X509(X509_OBJECT *a)
  {
+    if (a == NULL) return NULL;
+    if (a->type != X509_LU_X509) return NULL;
      return a->data.x509;
  }

+X509_CRL *X509_OBJECT_get0_X509_CRL(X509_OBJECT *a)
+{
+    if (a == NULL) return NULL;
+    if (a->type != X509_LU_CRL) return NULL;
+    return a->data.crl;
+}
+
  int X509_OBJECT_get_type(X509_OBJECT *a)
  {
      return a->type;
....

After port I note that two new functions (see bellow) will simplify code:

(2)
>>      X509 *X509_STORE_get_X509_by_subject(X509_STORE_CTX *vs,
>> X509_NAME *name)
>>      X509_CRL *X509_STORE_get_X509_CRL_by_subject(X509_STORE_CTX *vs,
>> X509_NAME *name) And replace the existing
>> "X509_STORE_get_X509_by_subject"

This is my request - to define:
- X509 *X509_STORE_get_X509_by_subject(X509_STORE_CTX *vs, X509_NAME *name)
- X509_CRL *X509_STORE_get_X509_CRL_by_subject(X509_STORE_CTX *vs, 
X509_NAME *name)
( Side effect is that with functions from (2) program code will avoid 
use of functions from (1) )


>> We also need X590_OBJECT_new() and X509_OBJECT_free and X509_CRL
>> *X509_OBJECT_get0_X509_CRL(X509_OBJECT *a).
It is good to have:
- X590_OBJECT_new()
- X509_CRL* X509_OBJECT_get0_X509_CRL(X509_OBJECT *)
- int X509_OBJECT_set0_X509_CRL(X509_OBJECT*, X509_CRL*)
- int X509_OBJECT_set0_X509(X509_OBJECT*, X509* )
but this is out of scope for now.

It is related to API for X509_LOOKUP_METHOD. Lets to discuss separately 
when accessors for X509_LOOKUP_METHOD are defined.

>> Make sure the memory issues are addressed and avoid double-free.
>>
>> Right?
> "You need" is misleading.  These are new accessors needed  because the X509_OBJECT was made opaque.  In other words we did it :)

Regards,
Roumen

From openssl at roumenpetrov.info  Sat May  7 08:45:32 2016
From: openssl at roumenpetrov.info (Roumen Petrov)
Date: Sat, 07 May 2016 11:45:32 +0300
Subject: [openssl-dev] use of X.509 lookup methods,
 X509_OBJECT internal or opaque?
In-Reply-To: <572DA7C0.6040706@roumenpetrov.info>
References: <571B8D25.2030100@roumenpetrov.info>
 <0ceaba4b64d44e689f05225f480ba33f@usma1ex-dag1mb1.msg.corp.akamai.com>
 <790538e8524942339cede3107cb60d43@usma1ex-dag1mb1.msg.corp.akamai.com>
 <572DA7C0.6040706@roumenpetrov.info>
Message-ID: <572DAB2C.1060000@roumenpetrov.info>

Roumen Petrov wrote:
> [SNIP]
> This is my request - to define:
> - X509 *X509_STORE_get_X509_by_subject(X509_STORE_CTX *vs, X509_NAME 
> *name)
> - X509_CRL *X509_STORE_get_X509_CRL_by_subject(X509_STORE_CTX *vs, 
> X509_NAME *name)
Perhaps X509_STORE_CTX_get... instead X509_STORE_get as first argument 
is X509_STORE_CTX.

Regards,
Roumen


From aaronngray.lists at gmail.com  Sat May  7 11:22:20 2016
From: aaronngray.lists at gmail.com (Aaron Gray)
Date: Sat, 7 May 2016 12:22:20 +0100
Subject: [openssl-dev] ASN.1 source
Message-ID: <CANkmNDeF=gGxsZX--ZviBMe50CA41b3KyjJZhbYk-6Zc5YPW1Q@mail.gmail.com>

Hi,

Where is the actual ASN.1 source ?

All I can find is the doctored generated C code !

Many thanks in advance,

Aaron

From rsalz at akamai.com  Sat May  7 12:22:03 2016
From: rsalz at akamai.com (Salz, Rich)
Date: Sat, 7 May 2016 12:22:03 +0000
Subject: [openssl-dev] ASN.1 source
In-Reply-To: <CANkmNDeF=gGxsZX--ZviBMe50CA41b3KyjJZhbYk-6Zc5YPW1Q@mail.gmail.com>
References: <CANkmNDeF=gGxsZX--ZviBMe50CA41b3KyjJZhbYk-6Zc5YPW1Q@mail.gmail.com>
Message-ID: <5f289b236b1647628a4f9c42a6fd929d@usma1ex-dag1mb1.msg.corp.akamai.com>


> Where is the actual ASN.1 source ?
> 
> All I can find is the doctored generated C code !

That's hand-written, not generated.

An ASN.1 compiler, and ASN.1 source, is not used in OpenSSL.

From aaronngray.lists at gmail.com  Sat May  7 12:26:05 2016
From: aaronngray.lists at gmail.com (Aaron Gray)
Date: Sat, 7 May 2016 13:26:05 +0100
Subject: [openssl-dev] ASN.1 source
In-Reply-To: <5f289b236b1647628a4f9c42a6fd929d@usma1ex-dag1mb1.msg.corp.akamai.com>
References: <CANkmNDeF=gGxsZX--ZviBMe50CA41b3KyjJZhbYk-6Zc5YPW1Q@mail.gmail.com>
 <5f289b236b1647628a4f9c42a6fd929d@usma1ex-dag1mb1.msg.corp.akamai.com>
Message-ID: <CANkmNDc_QztsNbLKdRU77H8kL9DOrxRbtHd+pGD2RZ4Hs+xvzg@mail.gmail.com>

weird AFAICS the file names follow an ASN.1 compilers output !

On 7 May 2016 at 13:22, Salz, Rich <rsalz at akamai.com> wrote:
>
>> Where is the actual ASN.1 source ?
>>
>> All I can find is the doctored generated C code !
>
> That's hand-written, not generated.
>
> An ASN.1 compiler, and ASN.1 source, is not used in OpenSSL.
> --
> openssl-dev mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

From rt at openssl.org  Sat May  7 13:37:53 2016
From: rt at openssl.org (Stephen Henson via RT)
Date: Sat, 07 May 2016 13:37:53 +0000
Subject: [openssl-dev] [openssl.org #4510] SSL certificate problem: unable
	to get local issuer certificate. Bug?
In-Reply-To: <rt-4.0.19-23551-1462574275-1130.4510-6-0@openssl.org>
References: <RT-Ticket-4510@openssl.org>
 <CALC5Oe=Jx82z7yN0cOrThAae9FXKRV_SngCLvjQZbFj31oP1VQ@mail.gmail.com>
 <rt-4.0.19-23551-1462461223-1977.4510-6-0@openssl.org>
 <CALC5Oe=Or-7=mrWX_Az7KTeqHqmvoh-Au=BYVGpeqaK-AGaY4w@mail.gmail.com>
 <rt-4.0.19-2506-1462494827-1054.4510-6-0@openssl.org>
 <rt-4.0.19-23551-1462569596-1783.4510-6-0@openssl.org>
 <CALC5OenYF34P8xjn-2r1n+yQRjXd9K1McBa=-YTbA9AsARfitA@mail.gmail.com>
 <rt-4.0.19-23551-1462574275-1130.4510-6-0@openssl.org>
Message-ID: <rt-4.0.19-25938-1462628273-1726.4510-6-0@openssl.org>

On Fri May 06 22:37:55 2016, nbhfgq at gmail.com wrote:
> Hello Steve,
>
> *If I do not indicate the location of the cert*
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>
> > PS C:\OpenSSL-Win32\bin> .\openssl s_client -connect
> > www.googleapis.com:443
> > CONNECTED(00000088)
> > depth=2 C = US, O = GeoTrust Inc., CN = GeoTrust Global CA
> > verify error:num=20:unable to get local issuer certificate
> > ---

OK we get an error above which is expected.

> > Verify return code: 20 (unable to get local issuer certificate)
>

And confirmed above.

>
> *I point to the the newest cert*
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>
> > PS C:\OpenSSL-Win32\bin> .\openssl s_client -CAfile
> > 'C:\xampp\php\cacert.pem' -connect www.googleapis.com:443
> > CONNECTED(000000D8)
> > depth=2 C = US, O = GeoTrust Inc., CN = GeoTrust Global CA
> > verify return:1
> > depth=1 C = US, O = Google Inc, CN = Google Internet Authority G2
> > verify return:1
> > depth=0 C = US, ST = California, L = Mountain View, O = Google Inc,
> > CN = *.
> > googleapis.com
> > verify return:1

No error.

> > Verify return code: 0 (ok)
>

And similarly above no error.

>
> *When I point to the old cert*
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>
> > PS C:\OpenSSL-Win32\bin> .\openssl s_client -CAfile
> > 'C:\xampp\php\cacert_old.pem' -connect www.googleapis.com:443
> > CONNECTED(00000140)
> > depth=3 C = US, O = Equifax, OU = Equifax Secure Certificate
> > Authority
> > verify return:1
> > depth=2 C = US, O = GeoTrust Inc., CN = GeoTrust Global CA
> > verify return:1
> > depth=1 C = US, O = Google Inc, CN = Google Internet Authority G2
> > verify return:1
> > depth=0 C = US, ST = California, L = Mountain View, O = Google Inc,
> > CN = *.
> > googleapis.com
> > verify return:1

Again no error.

> > Verify return code: 0 (ok)
> >
> >
>

And again confirmed above.

It looks like with s_client it is working in both the old and new cases.

So I'm not sure what the problem is: it doesn't seem to be an issue with
OpenSSL though.

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=4510
Please log in as guest with password guest if prompted


From deengert at gmail.com  Sat May  7 14:14:33 2016
From: deengert at gmail.com (Douglas E Engert)
Date: Sat, 7 May 2016 09:14:33 -0500
Subject: [openssl-dev] [openssl.org #4510] SSL certificate problem:
 unable to get local issuer certificate. Bug?
In-Reply-To: <rt-4.0.19-25938-1462628273-1726.4510-6-0@openssl.org>
References: <RT-Ticket-4510@openssl.org>
 <CALC5Oe=Jx82z7yN0cOrThAae9FXKRV_SngCLvjQZbFj31oP1VQ@mail.gmail.com>
 <rt-4.0.19-23551-1462461223-1977.4510-6-0@openssl.org>
 <CALC5Oe=Or-7=mrWX_Az7KTeqHqmvoh-Au=BYVGpeqaK-AGaY4w@mail.gmail.com>
 <rt-4.0.19-2506-1462494827-1054.4510-6-0@openssl.org>
 <rt-4.0.19-23551-1462569596-1783.4510-6-0@openssl.org>
 <CALC5OenYF34P8xjn-2r1n+yQRjXd9K1McBa=-YTbA9AsARfitA@mail.gmail.com>
 <rt-4.0.19-23551-1462574275-1130.4510-6-0@openssl.org>
 <rt-4.0.19-25938-1462628273-1726.4510-6-0@openssl.org>
Message-ID: <52466720-cc82-d173-fa2e-cfe79925f7a1@gmail.com>

The one that fails is using the default CAfile and CApath The ones that work specify
-CAfile C:\xampp\php\cacert.pem
Maybe the default locations are out of date?
Also  CApath "This directory must be in "hash format""
Are the hashes correct?

On 5/7/2016 8:37 AM, Stephen Henson via RT wrote:
> On Fri May 06 22:37:55 2016, nbhfgq at gmail.com wrote:
>> Hello Steve,
>>
>> *If I do not indicate the location of the cert*
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>
>>> PS C:\OpenSSL-Win32\bin> .\openssl s_client -connect
>>> www.googleapis.com:443
>>> CONNECTED(00000088)
>>> depth=2 C = US, O = GeoTrust Inc., CN = GeoTrust Global CA
>>> verify error:num=20:unable to get local issuer certificate
>>> ---
>
> OK we get an error above which is expected.
>
>>> Verify return code: 20 (unable to get local issuer certificate)
>>
>
> And confirmed above.
>
>>
>> *I point to the the newest cert*
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>
>>> PS C:\OpenSSL-Win32\bin> .\openssl s_client -CAfile
>>> 'C:\xampp\php\cacert.pem' -connect www.googleapis.com:443
>>> CONNECTED(000000D8)
>>> depth=2 C = US, O = GeoTrust Inc., CN = GeoTrust Global CA
>>> verify return:1
>>> depth=1 C = US, O = Google Inc, CN = Google Internet Authority G2
>>> verify return:1
>>> depth=0 C = US, ST = California, L = Mountain View, O = Google Inc,
>>> CN = *.
>>> googleapis.com
>>> verify return:1
>
> No error.
>
>>> Verify return code: 0 (ok)
>>
>
> And similarly above no error.
>
>>
>> *When I point to the old cert*
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>
>>> PS C:\OpenSSL-Win32\bin> .\openssl s_client -CAfile
>>> 'C:\xampp\php\cacert_old.pem' -connect www.googleapis.com:443
>>> CONNECTED(00000140)
>>> depth=3 C = US, O = Equifax, OU = Equifax Secure Certificate
>>> Authority
>>> verify return:1
>>> depth=2 C = US, O = GeoTrust Inc., CN = GeoTrust Global CA
>>> verify return:1
>>> depth=1 C = US, O = Google Inc, CN = Google Internet Authority G2
>>> verify return:1
>>> depth=0 C = US, ST = California, L = Mountain View, O = Google Inc,
>>> CN = *.
>>> googleapis.com
>>> verify return:1
>
> Again no error.
>
>>> Verify return code: 0 (ok)
>>>
>>>
>>
>
> And again confirmed above.
>
> It looks like with s_client it is working in both the old and new cases.
>
> So I'm not sure what the problem is: it doesn't seem to be an issue with
> OpenSSL though.
>
> Steve.
> --
> Dr Stephen N. Henson. OpenSSL project core developer.
> Commercial tech support now available see: http://www.openssl.org
>

-- 

  Douglas E. Engert  <DEEngert at gmail.com>


From rt at openssl.org  Sat May  7 15:02:28 2016
From: rt at openssl.org (SMS Conversation via RT)
Date: Sat, 07 May 2016 15:02:28 +0000
Subject: [openssl-dev] [openssl.org #4510] SSL certificate problem:
	unable to get local issuer certificate. Bug?
In-Reply-To: <CALC5OekJszN-Y89MbHg=8U2imznR_GHMfi5=N_joFdDSqWJLaA@mail.gmail.com>
References: <RT-Ticket-4510@openssl.org>
 <CALC5Oe=Jx82z7yN0cOrThAae9FXKRV_SngCLvjQZbFj31oP1VQ@mail.gmail.com>
 <rt-4.0.19-23551-1462461223-1977.4510-6-0@openssl.org>
 <CALC5Oe=Or-7=mrWX_Az7KTeqHqmvoh-Au=BYVGpeqaK-AGaY4w@mail.gmail.com>
 <rt-4.0.19-2506-1462494827-1054.4510-6-0@openssl.org>
 <rt-4.0.19-23551-1462569596-1783.4510-6-0@openssl.org>
 <CALC5OenYF34P8xjn-2r1n+yQRjXd9K1McBa=-YTbA9AsARfitA@mail.gmail.com>
 <rt-4.0.19-23551-1462574275-1130.4510-6-0@openssl.org>
 <rt-4.0.19-25938-1462628273-1726.4510-6-0@openssl.org>
 <CALC5OekJszN-Y89MbHg=8U2imznR_GHMfi5=N_joFdDSqWJLaA@mail.gmail.com>
Message-ID: <rt-4.0.19-23551-1462633348-1768.4510-6-0@openssl.org>

Hello Steve,

Any suggestions where to turn?  This is a new windows image with xampp and
very little else.  The program seems to be straightforward.

Your guidance would be helpful, but you can consider this issue closed for
openssl.

Thanks... George

On Sat, May 7, 2016 at 6:37 AM, Stephen Henson via RT <rt at openssl.org>
wrote:

> On Fri May 06 22:37:55 2016, nbhfgq at gmail.com wrote:
> > Hello Steve,
> >
> > *If I do not indicate the location of the cert*
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >
> > > PS C:\OpenSSL-Win32\bin> .\openssl s_client -connect
> > > www.googleapis.com:443
> > > CONNECTED(00000088)
> > > depth=2 C = US, O = GeoTrust Inc., CN = GeoTrust Global CA
> > > verify error:num=20:unable to get local issuer certificate
> > > ---
>
> OK we get an error above which is expected.
>
> > > Verify return code: 20 (unable to get local issuer certificate)
> >
>
> And confirmed above.
>
> >
> > *I point to the the newest cert*
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >
> > > PS C:\OpenSSL-Win32\bin> .\openssl s_client -CAfile
> > > 'C:\xampp\php\cacert.pem' -connect www.googleapis.com:443
> > > CONNECTED(000000D8)
> > > depth=2 C = US, O = GeoTrust Inc., CN = GeoTrust Global CA
> > > verify return:1
> > > depth=1 C = US, O = Google Inc, CN = Google Internet Authority G2
> > > verify return:1
> > > depth=0 C = US, ST = California, L = Mountain View, O = Google Inc,
> > > CN = *.
> > > googleapis.com
> > > verify return:1
>
> No error.
>
> > > Verify return code: 0 (ok)
> >
>
> And similarly above no error.
>
> >
> > *When I point to the old cert*
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >
> > > PS C:\OpenSSL-Win32\bin> .\openssl s_client -CAfile
> > > 'C:\xampp\php\cacert_old.pem' -connect www.googleapis.com:443
> > > CONNECTED(00000140)
> > > depth=3 C = US, O = Equifax, OU = Equifax Secure Certificate
> > > Authority
> > > verify return:1
> > > depth=2 C = US, O = GeoTrust Inc., CN = GeoTrust Global CA
> > > verify return:1
> > > depth=1 C = US, O = Google Inc, CN = Google Internet Authority G2
> > > verify return:1
> > > depth=0 C = US, ST = California, L = Mountain View, O = Google Inc,
> > > CN = *.
> > > googleapis.com
> > > verify return:1
>
> Again no error.
>
> > > Verify return code: 0 (ok)
> > >
> > >
> >
>
> And again confirmed above.
>
> It looks like with s_client it is working in both the old and new cases.
>
> So I'm not sure what the problem is: it doesn't seem to be an issue with
> OpenSSL though.
>
> 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=4510
> Please log in as guest with password guest if prompted
>
>

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


From kurt at x64architecture.com  Sun May  8 07:52:20 2016
From: kurt at x64architecture.com (Kurt Cancemi)
Date: Sun, 8 May 2016 03:52:20 -0400
Subject: [openssl-dev] [Suggestion] crypto/threads_win.c: Follow Consistent
	Return Style
Message-ID: <CADujJWUW9FAhdyPOWArybTwOTsKnDUwWzmNaYwrW07Kc8A0W8A@mail.gmail.com>

Every function that returns an int in crypto/threads_win.c returns 0
immediately if the function called from inside the function fails
except CRYPTO_THREAD_run_once() which returns 1 immediately if the
function called from inside the function succeeds.

InitOnceExecuteOnce returns 0 on failure
https://msdn.microsoft.com/en-us/library/windows/desktop/ms683493%28v=vs.85%29.aspx

So my suggestion would be to follow this convention in
CRYPTO_THREAD_run_once() too:

--- crypto/threads_win.c    2016-05-08 03:42:44.401795919 -0400
+++ crypto/threads_win.c    2016-05-08 03:42:55.151796152 -0400
@@ -135,10 +135,10 @@

 int CRYPTO_THREAD_run_once(CRYPTO_ONCE *once, void (*init)(void))
 {
-    if (InitOnceExecuteOnce(once, once_cb, init, NULL))
-        return 1;
+    if (!InitOnceExecuteOnce(once, once_cb, init, NULL))
+        return 0;

-    return 0;
+    return 1;
 }

 # endif

--
Kurt Cancemi
https://www.x64architecture.com

From alessandro at ghedini.me  Sun May  8 11:15:56 2016
From: alessandro at ghedini.me (Alessandro Ghedini)
Date: Sun, 8 May 2016 12:15:56 +0100
Subject: [openssl-dev] TLSv1.3
Message-ID: <20160508111556.GA15126@kronk.local>

Hello everyone,

I know that I'm probably getting way ahead of myself here, but I thought it
would be interesting to start looking into adding TLS 1.3 support to OpenSSL
(for post 1.1.0 of course).

Unfortunately I didn't get very far, so I'm hoping someone more experienced
in TLS 1.3 and OpenSSL's internal workings can help me get unstuck.

My current (server-side only for now) implementation lives at [0]: the code is
pretty awful, incomplete and doesn't work yet. It will need a big clean-up at
some point, but I would like to get it to work first.

The status is that I can get it to generate the proper handshake keys and IVs,
but during record encryption the MAC generated is wrong. I think this is due
to the fact that the AEAD construction in 1.3 is different from the one in 1.2
[1] (note that I tried with both AES GCM and ChaCha20-Poly1305). Basically we'd
need to XOR the TLS record sequence number with the nonce on a per-record
basis.

It doesn't seem that the OpenSSL API allows me to provide a per-record nonce
(which would be needed here I think), but I'm hoping I can somehow work-around
this problem without having to introduce a whole new AEAD API (like the one
BoringSSL has).

Or maybe I'm just wrong and the problem is somewhere else... I'm kind of hoping
on that TBH :)

If any of you has a bit of time and is interested in TLS 1.3, please have a
look, any help would be appreciated.

Cheers

[0] https://github.com/ghedo/openssl/tree/tls1.3
[1] https://tlswg.github.io/tls13-spec/#rfc.section.5.2.2
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20160508/a14ee414/attachment.sig>

From rsalz at akamai.com  Sun May  8 13:39:14 2016
From: rsalz at akamai.com (Salz, Rich)
Date: Sun, 8 May 2016 13:39:14 +0000
Subject: [openssl-dev] TLSv1.3
In-Reply-To: <20160508111556.GA15126@kronk.local>
References: <20160508111556.GA15126@kronk.local>
Message-ID: <050a003576e9420795ea5a5433deeee8@usma1ex-dag1mb1.msg.corp.akamai.com>

This is cool.

I think lots of things will be broken for TLS 1.3, but haven't looked at implementation at all.  And "early data" will mean API changes, although I'm fine if that doesn't happen in the first release :)

Good luck :)

From openssl-users at dukhovni.org  Sun May  8 16:21:06 2016
From: openssl-users at dukhovni.org (Viktor Dukhovni)
Date: Sun, 8 May 2016 16:21:06 +0000
Subject: [openssl-dev] TLSv1.3
In-Reply-To: <20160508111556.GA15126@kronk.local>
References: <20160508111556.GA15126@kronk.local>
Message-ID: <20160508162106.GP3300@mournblade.imrryr.org>

On Sun, May 08, 2016 at 12:15:56PM +0100, Alessandro Ghedini wrote:

> I know that I'm probably getting way ahead of myself here, but I thought it
> would be interesting to start looking into adding TLS 1.3 support to OpenSSL
> (for post 1.1.0 of course).

Even after 1.1.0, TLS 1.3 might not be the highest priority item
on the list.  We still need to introduce a suitable read/write
buffer abstraction into OpenSSL and migrate all the code that
serializes and de-serializes data from pointer-arithmetic to

	read, write, peek, rewind, clear, ...

operations on suitably abstracted "buffer with offset" objects.

In particular, the ASN.1 code needs to be updated to use safe buffer
management, and the SSL code needs to use a safe buffer API for
both reads and writes.  More bits of libcrypto are likely in scope,
for example EVP.

Though much cleanup has already taken place in 1.1.0, we still need
to do more, and I would prefer to see TLS 1.3 rest on more solid
foundations.

-- 
	Viktor.

From rt at openssl.org  Sun May  8 22:44:14 2016
From: rt at openssl.org (Stephen Henson via RT)
Date: Sun, 08 May 2016 22:44:14 +0000
Subject: [openssl-dev] [openssl.org #4147] TSA: SHA-1 update
In-Reply-To: <20151118130117.GA1978@carbon.cesnet.cz>
References: <RT-Ticket-4147@openssl.org>
 <20151118130117.GA1978@carbon.cesnet.cz>
Message-ID: <rt-4.0.19-5499-1462747454-481.4147-6-0@openssl.org>

No problems reported, ticket closed.

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=4147
Please log in as guest with password guest if prompted


From rt at openssl.org  Mon May  9 01:12:22 2016
From: rt at openssl.org (Stephen Henson via RT)
Date: Mon, 09 May 2016 01:12:22 +0000
Subject: [openssl-dev] [openssl.org #3826] Contribution/Patch
In-Reply-To: <554111CE.9000600@cisco.com>
References: <RT-Ticket-3826@openssl.org> <554111CE.9000600@cisco.com>
Message-ID: <rt-4.0.19-5499-1462756342-272.3826-6-0@openssl.org>

Fixed now, 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=3826
Please log in as guest with password guest if prompted


From rt at openssl.org  Mon May  9 01:24:05 2016
From: rt at openssl.org (Stephen Henson via RT)
Date: Mon, 09 May 2016 01:24:05 +0000
Subject: [openssl-dev] [openssl.org #4435] Pull request: Update
	EVP_CIPHER_CTX_set_padding documentation.
In-Reply-To: <CAHTptW8RQkDwNPsmCThCyvUrGLN3VBCDGWjS_-4UgJpPb_SfoA@mail.gmail.com>
References: <RT-Ticket-4435@openssl.org>
 <CAHTptW8RQkDwNPsmCThCyvUrGLN3VBCDGWjS_-4UgJpPb_SfoA@mail.gmail.com>
Message-ID: <rt-4.0.19-5500-1462757045-638.4435-6-0@openssl.org>

This has now been applied, thanks for the contribution.

Ticket closed.

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=4435
Please log in as guest with password guest if prompted


From matt at openssl.org  Mon May  9 09:41:25 2016
From: matt at openssl.org (Matt Caswell)
Date: Mon, 9 May 2016 10:41:25 +0100
Subject: [openssl-dev] [Suggestion] crypto/threads_win.c: Follow
 Consistent Return Style
In-Reply-To: <CADujJWUW9FAhdyPOWArybTwOTsKnDUwWzmNaYwrW07Kc8A0W8A@mail.gmail.com>
References: <CADujJWUW9FAhdyPOWArybTwOTsKnDUwWzmNaYwrW07Kc8A0W8A@mail.gmail.com>
Message-ID: <57305B45.4040209@openssl.org>

Looks ok to me. I suggest you raise it as a GitHub PR.

Matt

On 08/05/16 08:52, Kurt Cancemi wrote:
> Every function that returns an int in crypto/threads_win.c returns 0
> immediately if the function called from inside the function fails
> except CRYPTO_THREAD_run_once() which returns 1 immediately if the
> function called from inside the function succeeds.
> 
> InitOnceExecuteOnce returns 0 on failure
> https://msdn.microsoft.com/en-us/library/windows/desktop/ms683493%28v=vs.85%29.aspx
> 
> So my suggestion would be to follow this convention in
> CRYPTO_THREAD_run_once() too:
> 
> --- crypto/threads_win.c    2016-05-08 03:42:44.401795919 -0400
> +++ crypto/threads_win.c    2016-05-08 03:42:55.151796152 -0400
> @@ -135,10 +135,10 @@
> 
>  int CRYPTO_THREAD_run_once(CRYPTO_ONCE *once, void (*init)(void))
>  {
> -    if (InitOnceExecuteOnce(once, once_cb, init, NULL))
> -        return 1;
> +    if (!InitOnceExecuteOnce(once, once_cb, init, NULL))
> +        return 0;
> 
> -    return 0;
> +    return 1;
>  }
> 
>  # endif
> 
> --
> Kurt Cancemi
> https://www.x64architecture.com
> 

From kurt at x64architecture.com  Mon May  9 13:05:35 2016
From: kurt at x64architecture.com (Kurt Cancemi)
Date: Mon, 9 May 2016 09:05:35 -0400
Subject: [openssl-dev] [Suggestion] crypto/threads_win.c: Follow
 Consistent Return Style
In-Reply-To: <57305B45.4040209@openssl.org>
References: <CADujJWUW9FAhdyPOWArybTwOTsKnDUwWzmNaYwrW07Kc8A0W8A@mail.gmail.com>
 <57305B45.4040209@openssl.org>
Message-ID: <CADujJWXXtQ9T9XVRua7t7Pv0ftjeuxy1T27by4EXg7RAOuDtsQ@mail.gmail.com>

Link to GitHub PR: https://github.com/openssl/openssl/pull/1039

--
Kurt Cancemi
https://www.x64architecture.com


On Mon, May 9, 2016 at 5:41 AM, Matt Caswell <matt at openssl.org> wrote:
> Looks ok to me. I suggest you raise it as a GitHub PR.
>
> Matt
>

From rt at openssl.org  Mon May  9 14:01:46 2016
From: rt at openssl.org (Stephen Henson via RT)
Date: Mon, 09 May 2016 14:01:46 +0000
Subject: [openssl-dev] [openssl.org #4462] FEATURE: enable 'make test' to
	respond to 'V=1' or 'VERBOSE=1'
In-Reply-To: <CAH8yC8=XcJx86WT42qN_QAeRsjNhkdKVLzJLWvSjb_O7RFP2bw@mail.gmail.com>
References: <RT-Ticket-4462@openssl.org>
 <CAH8yC8=XcJx86WT42qN_QAeRsjNhkdKVLzJLWvSjb_O7RFP2bw@mail.gmail.com>
Message-ID: <rt-4.0.19-5500-1462802506-1518.4462-6-0@openssl.org>

Support added now for VERBOSE and V.

Closing ticket,

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=4462
Please log in as guest with password guest if prompted


From rt at openssl.org  Mon May  9 14:31:41 2016
From: rt at openssl.org (Matt Caswell via RT)
Date: Mon, 09 May 2016 14:31:41 +0000
Subject: [openssl-dev] [openssl.org #1241] apps/s_client.c: 2 changes in
	initial handshake
In-Reply-To: <4373CBCC.4020404@shomitefo.de>
References: <RT-Ticket-1241@openssl.org> <4373CBCC.4020404@shomitefo.de>
Message-ID: <rt-4.0.19-5500-1462804301-1703.1241-6-0@openssl.org>

These no longer apply due to the elapsed time.

The verify patch doesn't quite make sense (maybe it did when this was written)
because SSL_VERIFY_FAIL_IF_NO_PEER_CERT is a server side only option.

The "manual" option to starttls is quite a neat idea, but will not be applied
in its current state. A new patch should be developed against current master if
this is still wanted!!

Closing this ticket.

Matt

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


From rt at openssl.org  Mon May  9 14:33:12 2016
From: rt at openssl.org (Matt Caswell via RT)
Date: Mon, 09 May 2016 14:33:12 +0000
Subject: [openssl-dev] [openssl.org #1298] OpenSSL bug in
	libcrypto.so:RAND_poll() crashes apache2 @ startup
In-Reply-To: <20060322053011.GQ21005@dookie.chicago.hostway.net>
References: <RT-Ticket-1298@openssl.org>
 <20060322053011.GQ21005@dookie.chicago.hostway.net>
Message-ID: <rt-4.0.19-5500-1462804392-1404.1298-6-0@openssl.org>

Due to the elapsed time I am assuming this is no longer a problem for apache.
Please create a new ticket if this is still a problem!

Matt

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


From rt at openssl.org  Mon May  9 14:53:10 2016
From: rt at openssl.org (Matt Caswell via RT)
Date: Mon, 09 May 2016 14:53:10 +0000
Subject: [openssl-dev] [openssl.org #1769] bug report: Array overruns
In-Reply-To: <490849F2.1090608@sun.com>
References: <RT-Ticket-1769@openssl.org> <490849F2.1090608@sun.com>
Message-ID: <rt-4.0.19-5500-1462805590-1619.1769-6-0@openssl.org>

At some in the intervening period since this was raised these issues have been
fixed.

Closing.

Matt

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


From rt at openssl.org  Mon May  9 15:04:51 2016
From: rt at openssl.org (Matt Caswell via RT)
Date: Mon, 09 May 2016 15:04:51 +0000
Subject: [openssl-dev] [openssl.org #1833] [PATCH] Abbreviated Renegotiations
In-Reply-To: <D4A50788-5F0A-4B74-9822-513CEF1DCF9C@fh-muenster.de>
References: <RT-Ticket-1833@openssl.org>
 <D4A50788-5F0A-4B74-9822-513CEF1DCF9C@fh-muenster.de>
Message-ID: <rt-4.0.19-5500-1462806291-779.1833-6-0@openssl.org>

This doesn't seem to be the case any more.

Closing.

Matt

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


From rt at openssl.org  Mon May  9 15:05:32 2016
From: rt at openssl.org (Salz, Rich via RT)
Date: Mon, 09 May 2016 15:05:32 +0000
Subject: [openssl-dev] [openssl.org #1298] OpenSSL bug in
	libcrypto.so:RAND_poll() crashes apache2 @ startup
In-Reply-To: <c85add41e1d4492da4f8c5921b8d791c@usma1ex-dag1mb1.msg.corp.akamai.com>
References: <RT-Ticket-1298@openssl.org>
 <20060322053011.GQ21005@dookie.chicago.hostway.net>
 <rt-4.0.19-5500-1462804392-1404.1298-6-0@openssl.org>
 <c85add41e1d4492da4f8c5921b8d791c@usma1ex-dag1mb1.msg.corp.akamai.com>
Message-ID: <rt-4.0.19-5499-1462806332-1325.1298-6-0@openssl.org>

It's probably not an issue because the number of file descriptors has increased on the native O/S's.  But "file descriptor exhaustion" is still an issue for RNG's (google it) and we should keep it in mind for the future.  What's the best way to do that?


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


From rt at openssl.org  Mon May  9 15:07:10 2016
From: rt at openssl.org (Matt Caswell via RT)
Date: Mon, 09 May 2016 15:07:10 +0000
Subject: [openssl-dev] [openssl.org #1873] SMIME_write_PKCS7 and CRLF in
	base64 signature
In-Reply-To: <06c4c0ad1dc0a434c6fda884d66149a4@icewarp.com>
References: <RT-Ticket-1873@openssl.org>
 <06c4c0ad1dc0a434c6fda884d66149a4@icewarp.com>
Message-ID: <rt-4.0.19-5499-1462806430-780.1873-6-0@openssl.org>

This doesn't seem to match up in any way with current code so I guess it is no
longer relevant.

Closing.

Matt

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


From rt at openssl.org  Mon May  9 15:10:48 2016
From: rt at openssl.org (Matt Caswell via RT)
Date: Mon, 09 May 2016 15:10:48 +0000
Subject: [openssl-dev] [openssl.org #1875] Fwd: [PATCH] Small bug fixes and
	coding style corrections
In-Reply-To: <50f9409a0903260625j295e8221j29d8979f5b86bbcd@mail.gmail.com>
References: <RT-Ticket-1875@openssl.org>
 <50f9409a0903230723u23845197we934d221800432e3@mail.gmail.com>
 <50f9409a0903260625j295e8221j29d8979f5b86bbcd@mail.gmail.com>
Message-ID: <rt-4.0.19-5500-1462806648-167.1875-6-0@openssl.org>

These patches no longer apply and are no longer relevant.

Closing

Matt

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


From rt at openssl.org  Mon May  9 15:14:34 2016
From: rt at openssl.org (Matt Caswell via RT)
Date: Mon, 09 May 2016 15:14:34 +0000
Subject: [openssl-dev] [openssl.org #1912] BIO_printf/BIO_vprintf error in
	0.9.8k
In-Reply-To: <49F554AB.1080706@netlock.hu>
References: <RT-Ticket-1912@openssl.org> <49F554AB.1080706@netlock.hu>
Message-ID: <rt-4.0.19-5499-1462806874-56.1912-6-0@openssl.org>

I don't believe this is an issue any more as the maxlen increases along with
the dynamic buffer so no truncation should take place.

Closing.

Matt

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


From rt at openssl.org  Mon May  9 15:21:06 2016
From: rt at openssl.org (Matt Caswell via RT)
Date: Mon, 09 May 2016 15:21:06 +0000
Subject: [openssl-dev] [openssl.org #1916] [PATCH] Fix for memleaks,
	use after free and optimizations
In-Reply-To: <50f9409a0905031315x343e14f5pd9602b0acafcadd2@mail.gmail.com>
References: <RT-Ticket-1916@openssl.org>
 <50f9409a0905031315x343e14f5pd9602b0acafcadd2@mail.gmail.com>
Message-ID: <rt-4.0.19-5499-1462807266-1654.1916-6-0@openssl.org>

These patches no longer apply and are no longer relevant to the latest
codebase.

Closing

Matt

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


From rt at openssl.org  Mon May  9 16:01:01 2016
From: rt at openssl.org (Richard Levitte via RT)
Date: Mon, 09 May 2016 16:01:01 +0000
Subject: [openssl-dev] [openssl.org #547] SSL_CTX_free messes with external
	session cache
References: <RT-Ticket-547@openssl.org>
Message-ID: <rt-4.0.19-5499-1462809661-146.547-6-0@openssl.org>

This is a very old ticket, and SSL_CTX_free() has been worked on along with the
rest of the code. Closing this one, and if the issue still exists, I trust
someone will generate a new ticket.

Vid Thu, 27 Mar 2003 kl. 22.10.04, skrev jaenicke:
> [nyh at math.technion.ac.il - Wed Mar 26 20:14:51 2003]:
>
> > I noticed that SSL_CTX_free() takes all the sessions in the given
> > CTX's
> > internal session cache, and also removes them from the external
> > session cache
> > (i.e., calls the delete-session callback).
>
> Thanks. I have added a slightly modified warning to the manual pages.
> Ticket should stay around until a final technical solution is found as
> the current behavious does not make too much sense :-)
>
> Best regards,
> Lutz

--
Richard Levitte
levitte at openssl.org

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


From rt at openssl.org  Mon May  9 16:11:46 2016
From: rt at openssl.org (Matt Caswell via RT)
Date: Mon, 09 May 2016 16:11:46 +0000
Subject: [openssl-dev] [openssl.org #1215] Bug Report for OpenSSL
In-Reply-To: <43471ED7.4080009@telus.net>
References: <RT-Ticket-1215@openssl.org> <43471ED7.4080009@telus.net>
Message-ID: <rt-4.0.19-5500-1462810306-1052.1215-6-0@openssl.org>

Fixed in commit 3105d69.

Matt

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


From rt at openssl.org  Mon May  9 16:14:46 2016
From: rt at openssl.org (Matt Caswell via RT)
Date: Mon, 09 May 2016 16:14:46 +0000
Subject: [openssl-dev] [openssl.org #1298] OpenSSL bug in
	libcrypto.so:RAND_poll() crashes apache2 @ startup
In-Reply-To: <rt-4.0.19-5499-1462806332-842.1298-6-0@openssl.org>
References: <RT-Ticket-1298@openssl.org>
 <20060322053011.GQ21005@dookie.chicago.hostway.net>
 <rt-4.0.19-5500-1462804392-1404.1298-6-0@openssl.org>
 <c85add41e1d4492da4f8c5921b8d791c@usma1ex-dag1mb1.msg.corp.akamai.com>
 <rt-4.0.19-5499-1462806332-842.1298-6-0@openssl.org>
Message-ID: <rt-4.0.19-5499-1462810486-1142.1298-6-0@openssl.org>

On Mon May 09 15:05:32 2016, rsalz at akamai.com wrote:
> It's probably not an issue because the number of file descriptors has
> increased on the native O/S's. But "file descriptor exhaustion" is
> still an issue for RNG's (google it) and we should keep it in mind for
> the future. What's the best way to do that?

We should incorporate it into the requirements for when we do the RNG rewrite
(post 1.1.0). Perhaps a feature request gh issue?

Matt

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


From rt at openssl.org  Mon May  9 16:58:53 2016
From: rt at openssl.org (Stephen Henson via RT)
Date: Mon, 09 May 2016 16:58:53 +0000
Subject: [openssl-dev] [openssl.org #4390] [PATCH] Don't send signature
	algorithms when client_version is below TLS 1.2.
In-Reply-To: <CAF8qwaDnFPiR7oLgsYVu-4baz+1vw+EL46vs6m9BTqrGX80FaQ@mail.gmail.com>
References: <RT-Ticket-4390@openssl.org>
 <CAF8qwaDnFPiR7oLgsYVu-4baz+1vw+EL46vs6m9BTqrGX80FaQ@mail.gmail.com>
Message-ID: <rt-4.0.19-5500-1462813133-214.4390-6-0@openssl.org>

Applied (in slightly modified form) 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=4390
Please log in as guest with password guest if prompted


From rsalz at akamai.com  Mon May  9 17:51:32 2016
From: rsalz at akamai.com (Salz, Rich)
Date: Mon, 9 May 2016 17:51:32 +0000
Subject: [openssl-dev] use of X.509 lookup methods,
 X509_OBJECT internal or opaque?
In-Reply-To: <572DAB2C.1060000@roumenpetrov.info>
References: <571B8D25.2030100@roumenpetrov.info>
 <0ceaba4b64d44e689f05225f480ba33f@usma1ex-dag1mb1.msg.corp.akamai.com>
 <790538e8524942339cede3107cb60d43@usma1ex-dag1mb1.msg.corp.akamai.com>
 <572DA7C0.6040706@roumenpetrov.info> <572DAB2C.1060000@roumenpetrov.info>
Message-ID: <4551491c54564abbb1adf251746867f6@usma1ex-dag1mb1.msg.corp.akamai.com>

Can you look at https://github.com/openssl/openssl/pull/1044 and see if it addresses the issues?

Thanks.
--  
Senior Architect, Akamai Technologies
IM: richsalz at jabber.at Twitter: RichSalz


> -----Original Message-----
> From: Roumen Petrov [mailto:openssl at roumenpetrov.info]
> Sent: Saturday, May 07, 2016 4:46 AM
> To: openssl-dev at openssl.org
> Subject: Re: [openssl-dev] use of X.509 lookup methods, X509_OBJECT
> internal or opaque?
> 
> Roumen Petrov wrote:
> > [SNIP]
> > This is my request - to define:
> > - X509 *X509_STORE_get_X509_by_subject(X509_STORE_CTX *vs,
> X509_NAME
> > *name)
> > - X509_CRL *X509_STORE_get_X509_CRL_by_subject(X509_STORE_CTX
> *vs,
> > X509_NAME *name)
> Perhaps X509_STORE_CTX_get... instead X509_STORE_get as first argument
> is X509_STORE_CTX.
> 
> Regards,
> Roumen
> 
> --
> openssl-dev mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

From rt at openssl.org  Mon May  9 19:31:54 2016
From: rt at openssl.org (Richard Levitte via RT)
Date: Mon, 09 May 2016 19:31:54 +0000
Subject: [openssl-dev] [openssl.org #2431] Member of Te4 in aes_core.c needs
	to be cast to u32 before being shifted
In-Reply-To: <courier.000000004D2F0C97.00004CD1@intron.ac>
References: <RT-Ticket-2431@openssl.org>
 <courier.000000004D2F0C97.00004CD1@intron.ac>
Message-ID: <rt-4.0.19-5500-1462822314-656.2431-6-0@openssl.org>

Age old ticket, and applied in all current release branches as well as master
as far as I can see. Time to close.

Vid Thu, 13 Jan 2011 kl. 18.01.15, skrev intron at intron.ac:
> In aes_core.c, Te4 is an array of u8. When its members are to be
> shifted, those members need to be cast to u32 explicitly. This is
> necessary especially in 8/16-bit embedded environments such as SDCC
> (http://sdcc.sourceforge.net/).
>
> My patch:
>
> Index: aes_core.c
> ===================================================================
> RCS file: /v/openssl/cvs/openssl/crypto/aes/aes_core.c,v
> retrieving revision 1.10
> diff -u -r1.10 aes_core.c
> --- aes_core.c 25 Jan 2007 20:47:00 -0000 1.10
> +++ aes_core.c 13 Jan 2011 14:27:14 -0000
> @@ -1229,10 +1229,10 @@
> while (1) {
> temp = rk[3];
> rk[4] = rk[0] ^
> - (Te4[(temp >> 16) & 0xff] << 24) ^
> - (Te4[(temp >> 8) & 0xff] << 16) ^
> - (Te4[(temp ) & 0xff] << 8) ^
> - (Te4[(temp >> 24) ]) ^
> + ((u32)Te4[(temp >> 16) & 0xff] << 24) ^
> + ((u32)Te4[(temp >> 8) & 0xff] << 16) ^
> + ((u32)Te4[(temp ) & 0xff] << 8) ^
> + ((u32)Te4[(temp >> 24) ]) ^
> rcon[i];
> rk[5] = rk[1] ^ rk[4];
> rk[6] = rk[2] ^ rk[5];
> @@ -1249,10 +1249,10 @@
> while (1) {
> temp = rk[ 5];
> rk[ 6] = rk[ 0] ^
> - (Te4[(temp >> 16) & 0xff] << 24) ^
> - (Te4[(temp >> 8) & 0xff] << 16) ^
> - (Te4[(temp ) & 0xff] << 8) ^
> - (Te4[(temp >> 24) ]) ^
> + ((u32)Te4[(temp >> 16) & 0xff] << 24) ^
> + ((u32)Te4[(temp >> 8) & 0xff] << 16) ^
> + ((u32)Te4[(temp ) & 0xff] << 8) ^
> + ((u32)Te4[(temp >> 24) ]) ^
> rcon[i];
> rk[ 7] = rk[ 1] ^ rk[ 6];
> rk[ 8] = rk[ 2] ^ rk[ 7];
> @@ -1271,10 +1271,10 @@
> while (1) {
> temp = rk[ 7];
> rk[ 8] = rk[ 0] ^
> - (Te4[(temp >> 16) & 0xff] << 24) ^
> - (Te4[(temp >> 8) & 0xff] << 16) ^
> - (Te4[(temp ) & 0xff] << 8) ^
> - (Te4[(temp >> 24) ]) ^
> + ((u32)Te4[(temp >> 16) & 0xff] << 24) ^
> + ((u32)Te4[(temp >> 8) & 0xff] << 16) ^
> + ((u32)Te4[(temp ) & 0xff] << 8) ^
> + ((u32)Te4[(temp >> 24) ]) ^
> rcon[i];
> rk[ 9] = rk[ 1] ^ rk[ 8];
> rk[10] = rk[ 2] ^ rk[ 9];
> @@ -1284,10 +1284,10 @@
> }
> temp = rk[11];
> rk[12] = rk[ 4] ^
> - (Te4[(temp >> 24) ] << 24) ^
> - (Te4[(temp >> 16) & 0xff] << 16) ^
> - (Te4[(temp >> 8) & 0xff] << 8) ^
> - (Te4[(temp ) & 0xff]);
> + ((u32)Te4[(temp >> 24) ] << 24) ^
> + ((u32)Te4[(temp >> 16) & 0xff] << 16) ^
> + ((u32)Te4[(temp >> 8) & 0xff] << 8) ^
> + ((u32)Te4[(temp ) & 0xff]);
> rk[13] = rk[ 5] ^ rk[12];
> rk[14] = rk[ 6] ^ rk[13];
> rk[15] = rk[ 7] ^ rk[14];
>
>
> ------------------------------------------------------------------------
> From Beijing, China


--
Richard Levitte
levitte at openssl.org

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


From rt at openssl.org  Mon May  9 20:22:39 2016
From: rt at openssl.org (Richard Levitte via RT)
Date: Mon, 09 May 2016 20:22:39 +0000
Subject: [openssl-dev] [openssl.org #4523] Failure - make test
In-Reply-To: <D368120842644E438A175B140D0C165973FF177D@AGDEHENSEX03.bechtle.net>
References: <RT-Ticket-4523@openssl.org>
 <D368120842644E438A175B140D0C165973FF177D@AGDEHENSEX03.bechtle.net>
Message-ID: <rt-4.0.19-5500-1462825359-1853.4523-6-0@openssl.org>

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
levitte at openssl.org

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


From rt at openssl.org  Mon May  9 20:31:44 2016
From: rt at openssl.org (Richard Levitte via RT)
Date: Mon, 09 May 2016 20:31:44 +0000
Subject: [openssl-dev] [openssl.org #4533] [PATCH] Add missing NULL check in
	i2d_PrivateKey()
In-Reply-To: <rt-4.0.19-8026-1462398741-865.4533-6-0@openssl.org>
References: <RT-Ticket-4533@openssl.org>
 <CADujJWVY3U88hooeAW9FRd7Owp0cWiCQmbezVorm7rCGqUf0ng@mail.gmail.com>
 <rt-4.0.19-8026-1462398741-865.4533-6-0@openssl.org>
Message-ID: <rt-4.0.19-5499-1462825904-604.4533-6-0@openssl.org>

Applied after a bit of adaptation.

Thank you!

Vid Ons, 04 May 2016 kl. 21.52.21, skrev kurt at x64architecture.com:
> Attached is the patch to fix the issue, also please close RT#4534 I
> sent an invalid reply which got translated into another RT issue.
>
> --
> Kurt Cancemi
> https://www.x64architecture.com


--
Richard Levitte
levitte at openssl.org

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


From rt at openssl.org  Tue May 10 09:57:20 2016
From: rt at openssl.org (Matt Caswell via RT)
Date: Tue, 10 May 2016 09:57:20 +0000
Subject: [openssl-dev] [openssl.org #4176] Add support for async jobs in
	OpenSSL speed
In-Reply-To: <02DF9A39E1EE92419A8C5BBE62973A231A450CAA@IRSMSX108.ger.corp.intel.com>
References: <RT-Ticket-4176@openssl.org>
 <02DF9A39E1EE92419A8C5BBE62973A231A450CAA@IRSMSX108.ger.corp.intel.com>
Message-ID: <rt-4.0.19-5499-1462874240-1852.4176-6-0@openssl.org>

Added in commit 8b0b80d923. Closing.

Matt

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


From rt at openssl.org  Tue May 10 09:59:50 2016
From: rt at openssl.org (Matt Caswell via RT)
Date: Tue, 10 May 2016 09:59:50 +0000
Subject: [openssl-dev] [openssl.org #4177] opaque X509 struct issues
In-Reply-To: <alpine.DEB.2.11.1512101723030.25965@tvnag.unkk.fr>
References: <RT-Ticket-4177@openssl.org>
 <alpine.DEB.2.11.1512101723030.25965@tvnag.unkk.fr>
Message-ID: <rt-4.0.19-5499-1462874390-1845.4177-6-0@openssl.org>

Stephen answered this issue. The X509_get0_extensions() function does now seem
to be documented.

Closing this ticket.

Matt

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


From rt at openssl.org  Tue May 10 10:15:43 2016
From: rt at openssl.org (Matt Caswell via RT)
Date: Tue, 10 May 2016 10:15:43 +0000
Subject: [openssl-dev] [openssl.org #4178] [patch] OpenSSL 1.1.0 fails when
	configure with no-nextproto
In-Reply-To: <000001d1346e$9d894140$d89bc3c0$@sales@free.fr>
References: <RT-Ticket-4178@openssl.org>
 <000001d1346e$9d894140$d89bc3c0$@sales@free.fr>
Message-ID: <rt-4.0.19-5499-1462875343-79.4178-6-0@openssl.org>

This seems to be working now.

Closing ticket.

Matt

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


From rt at openssl.org  Tue May 10 10:37:02 2016
From: rt at openssl.org (Matt Caswell via RT)
Date: Tue, 10 May 2016 10:37:02 +0000
Subject: [openssl-dev] [openssl.org #4185] Bug in EVP_MD_CTX_copy_ex's
	malloc failure handling
In-Reply-To: <CAF8qwaAAP=FqX5sDz0SzbHPrPu9jD2gyKNwrVKFfUO7jFGpfDg@mail.gmail.com>
References: <RT-Ticket-4185@openssl.org>
 <CAF8qwaAAP=FqX5sDz0SzbHPrPu9jD2gyKNwrVKFfUO7jFGpfDg@mail.gmail.com>
Message-ID: <rt-4.0.19-5500-1462876622-1190.4185-6-0@openssl.org>

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


From rt at openssl.org  Tue May 10 10:40:58 2016
From: rt at openssl.org (Matt Caswell via RT)
Date: Tue, 10 May 2016 10:40:58 +0000
Subject: [openssl-dev] [openssl.org #4201] Feature Request: Support dumping
	session keys in NSS key log format
In-Reply-To: <F476D676-3AB0-4094-A107-B1476F6AA152@lukasa.co.uk>
References: <RT-Ticket-4201@openssl.org>
 <F476D676-3AB0-4094-A107-B1476F6AA152@lukasa.co.uk>
Message-ID: <rt-4.0.19-5499-1462876858-221.4201-6-0@openssl.org>

Github pull 570 which was associated with this ticket has been closed, so
closing this too.

Matt

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


From rt at openssl.org  Tue May 10 10:49:36 2016
From: rt at openssl.org (Matt Caswell via RT)
Date: Tue, 10 May 2016 10:49:36 +0000
Subject: [openssl-dev] [openssl.org #4207] engine key format in 1.1
In-Reply-To: <5682A73C.70305@roumenpetrov.info>
References: <RT-Ticket-4207@openssl.org> <5682A73C.70305@roumenpetrov.info>
Message-ID: <rt-4.0.19-5500-1462877376-41.4207-6-0@openssl.org>

Seems to have been mostly fixed by dd9589740d, but it looks like there may be a
few things in this patch not covered by that commit. Keeping this open for now.

Matt

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


From rt at openssl.org  Tue May 10 10:53:45 2016
From: rt at openssl.org (Matt Caswell via RT)
Date: Tue, 10 May 2016 10:53:45 +0000
Subject: [openssl-dev] [openssl.org #4212] Compilation of master branch
	fails with 's_nbio' undeclared (first use in this function).
In-Reply-To: <56870460.70406@gmx.de>
References: <RT-Ticket-4212@openssl.org> <56870460.70406@gmx.de>
Message-ID: <rt-4.0.19-5499-1462877625-731.4212-6-0@openssl.org>

Looks like this was fixed by ba8108154d.

Closing.

Matt

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


From rt at openssl.org  Tue May 10 10:55:13 2016
From: rt at openssl.org (Matt Caswell via RT)
Date: Tue, 10 May 2016 10:55:13 +0000
Subject: [openssl-dev] [openssl.org #4217] Fixing DJGPP port of openssl
	master branch.
In-Reply-To: <568A77AE.8090801@gmx.de>
References: <RT-Ticket-4217@openssl.org> <568A77AE.8090801@gmx.de>
Message-ID: <rt-4.0.19-5499-1462877712-1174.4217-6-0@openssl.org>

Ping Richard Levitte.

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


From rt at openssl.org  Tue May 10 11:02:43 2016
From: rt at openssl.org (Matt Caswell via RT)
Date: Tue, 10 May 2016 11:02:43 +0000
Subject: [openssl-dev] [openssl.org #4227] openssl rand 10000000000 does not
	produce 10000000000 random bytes
In-Reply-To: <CA+4vN7yPz2s8+kS+7=DzuZJ9eZg3Mesmat=_a27sysF1q5oBfg@mail.gmail.com>
References: <RT-Ticket-4227@openssl.org>
 <CA+4vN7yPz2s8+kS+7=DzuZJ9eZg3Mesmat=_a27sysF1q5oBfg@mail.gmail.com>
Message-ID: <rt-4.0.19-5499-1462878163-1619.4227-6-0@openssl.org>

The issue as originally described in this ticket has been fixed.

A comment was added at one point to this ticket:
"May I suggest the bug also becomes a wish for support for > 2GB
numbers, as that is what the user originally wanted?"

It's not clear that that is desirable and is unlikely to be added. Therefore
closing this ticket.

Matt

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


From rt at openssl.org  Tue May 10 11:12:52 2016
From: rt at openssl.org (Matt Caswell via RT)
Date: Tue, 10 May 2016 11:12:52 +0000
Subject: [openssl-dev] [openssl.org #4248] Link error under Windows
In-Reply-To: <5698E644.1080209@approach.be>
References: <RT-Ticket-4248@openssl.org> <5698E644.1080209@approach.be>
Message-ID: <rt-4.0.19-5500-1462878772-807.4248-6-0@openssl.org>

Appears to have been reopened in error. Closing again.

Matt

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


From rt at openssl.org  Tue May 10 11:14:29 2016
From: rt at openssl.org (Matt Caswell via RT)
Date: Tue, 10 May 2016 11:14:29 +0000
Subject: [openssl-dev] [openssl.org #4254] PR for BLAKE2 support
In-Reply-To: <CAOLP8p7G9MJqjGqE8uNnQopq4x+taLPLUeNE_NqxhxXGLvBBKg@mail.gmail.com>
References: <RT-Ticket-4254@openssl.org>
 <CAOLP8p7G9MJqjGqE8uNnQopq4x+taLPLUeNE_NqxhxXGLvBBKg@mail.gmail.com>
Message-ID: <rt-4.0.19-5500-1462878869-1214.4254-6-0@openssl.org>

This was merged previously.

Closing.

Matt

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


From rt at openssl.org  Tue May 10 11:19:45 2016
From: rt at openssl.org (Matt Caswell via RT)
Date: Tue, 10 May 2016 11:19:45 +0000
Subject: [openssl-dev] [openssl.org #4255] OpenSSL-1.1.0-pre2 failures using
	MinGW-W64
In-Reply-To: <1453060954.186021958.y9vnrjtk@frv39.fwdcdn.com>
References: <RT-Ticket-4255@openssl.org>
 <1453060954.186021958.y9vnrjtk@frv39.fwdcdn.com>
Message-ID: <rt-4.0.19-5500-1462879185-1604.4255-6-0@openssl.org>

This doesn't seem to be a problem with OpenSSL so closing.

Matt

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


From rt at openssl.org  Tue May 10 11:24:10 2016
From: rt at openssl.org (Matt Caswell via RT)
Date: Tue, 10 May 2016 11:24:10 +0000
Subject: [openssl-dev] [openssl.org #4257] Fix BN_gcd errors for curves with
	even order that do not play nicely with Montgomery arithmetic
In-Reply-To: <CAFeDd5ZP4vqPcL9xe8U7zNW=t_SwDjBmv1gAmFoQkwa-iUWJWw@mail.gmail.com>
References: <RT-Ticket-4257@openssl.org>
 <CAFeDd5ZP4vqPcL9xe8U7zNW=t_SwDjBmv1gAmFoQkwa-iUWJWw@mail.gmail.com>
Message-ID: <rt-4.0.19-5500-1462879450-477.4257-6-0@openssl.org>

This was merged in 3a6a4a9.

Closing

Matt

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


From rt at openssl.org  Tue May 10 11:25:54 2016
From: rt at openssl.org (Matt Caswell via RT)
Date: Tue, 10 May 2016 11:25:54 +0000
Subject: [openssl-dev] [openssl.org #4262] Fwd: Configure script warns when
	no configurations changes occur
In-Reply-To: <136C1EAA-AC99-4317-9211-690ED54505DE@akamai.com>
References: <RT-Ticket-4262@openssl.org>
 <DF469A45-8287-493E-826F-3F9A73D69BF4@akamai.com>
 <136C1EAA-AC99-4317-9211-690ED54505DE@akamai.com>
Message-ID: <rt-4.0.19-5499-1462879554-1021.4262-6-0@openssl.org>

Fixed differently in d20bb611d.

Closing.

Matt

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


From rt at openssl.org  Tue May 10 11:50:57 2016
From: rt at openssl.org (Kazuki Yamaguchi via RT)
Date: Tue, 10 May 2016 11:50:57 +0000
Subject: [openssl-dev] [openssl.org #4537] [PATCH] Fix a NULL dereference in
	chacha20_poly1305_init_key()
In-Reply-To: <20160510115034.17859-1-k@rhe.jp>
References: <RT-Ticket-4537@openssl.org> <20160510115034.17859-1-k@rhe.jp>
Message-ID: <rt-4.0.19-5499-1462881057-1650.4537-21-0@openssl.org>

chacha20_poly1305_init_key() dereferences NULL when called with inkey !=
NULL && iv == NULL. This function is called by EVP_EncryptInit_ex()
family, whose documentation allows setting key and iv in separate calls.
---
I also created a pull request on GitHub:
- https://github.com/openssl/openssl/pull/1049

 crypto/evp/e_chacha20_poly1305.c | 22 +++++++++++++---------
 1 file changed, 13 insertions(+), 9 deletions(-)

diff --git a/crypto/evp/e_chacha20_poly1305.c b/crypto/evp/e_chacha20_poly1305.c
index c3c72a1..cc3927f 100644
--- a/crypto/evp/e_chacha20_poly1305.c
+++ b/crypto/evp/e_chacha20_poly1305.c
@@ -205,7 +205,6 @@ static int chacha20_poly1305_init_key(EVP_CIPHER_CTX *ctx,
                                       const unsigned char *iv, int enc)
 {
     EVP_CHACHA_AEAD_CTX *actx = aead_data(ctx);
-    unsigned char temp[CHACHA_CTR_SIZE];
 
     if (!inkey && !iv)
         return 1;
@@ -216,16 +215,21 @@ static int chacha20_poly1305_init_key(EVP_CIPHER_CTX *ctx,
     actx->mac_inited = 0;
     actx->tls_payload_length = NO_TLS_PAYLOAD_LENGTH;
 
-    /* pad on the left */
-    memset(temp, 0, sizeof(temp));
-    if (actx->nonce_len <= CHACHA_CTR_SIZE)
-        memcpy(temp + CHACHA_CTR_SIZE - actx->nonce_len, iv, actx->nonce_len);
+    if (iv != NULL) {
+        unsigned char temp[CHACHA_CTR_SIZE] = { 0 };
 
-    chacha_init_key(ctx, inkey, temp, enc);
+        /* pad on the left */
+        if (actx->nonce_len <= CHACHA_CTR_SIZE)
+            memcpy(temp + CHACHA_CTR_SIZE - actx->nonce_len, iv, actx->nonce_len);
 
-    actx->nonce[0] = actx->key.counter[1];
-    actx->nonce[1] = actx->key.counter[2];
-    actx->nonce[2] = actx->key.counter[3];
+        chacha_init_key(ctx, inkey, temp, enc);
+
+        actx->nonce[0] = actx->key.counter[1];
+        actx->nonce[1] = actx->key.counter[2];
+        actx->nonce[2] = actx->key.counter[3];
+    } else {
+        chacha_init_key(ctx, inkey, NULL, enc);
+    }
 
     return 1;
 }
-- 
2.8.2.453.g21f6c40


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


From rt at openssl.org  Tue May 10 12:36:40 2016
From: rt at openssl.org (Matt Caswell via RT)
Date: Tue, 10 May 2016 12:36:40 +0000
Subject: [openssl-dev] [openssl.org #4255] OpenSSL-1.1.0-pre2 failures using
	MinGW-W64
In-Reply-To: <1453060954.186021958.y9vnrjtk@frv39.fwdcdn.com>
References: <RT-Ticket-4255@openssl.org>
 <1453060954.186021958.y9vnrjtk@frv39.fwdcdn.com>
Message-ID: <rt-4.0.19-5500-1462883800-338.4255-6-0@openssl.org>

Re-opening. OP reports there are still issues with "make test" hanging.

Matt

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


From rt at openssl.org  Tue May 10 12:38:15 2016
From: rt at openssl.org (Matt Caswell via RT)
Date: Tue, 10 May 2016 12:38:15 +0000
Subject: [openssl-dev] [openssl.org #4272] [BUG/PATCH] Unit tests fail when
	DTLS is disabled
In-Reply-To: <72FBC0B9-7C0C-46BD-8F44-871C2361A5CB@akamai.com>
References: <RT-Ticket-4272@openssl.org>
 <72FBC0B9-7C0C-46BD-8F44-871C2361A5CB@akamai.com>
Message-ID: <rt-4.0.19-5500-1462883895-1911.4272-6-0@openssl.org>

Looks like this pull request was merged so closing.

Matt

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


From rt at openssl.org  Tue May 10 12:39:27 2016
From: rt at openssl.org (Matt Caswell via RT)
Date: Tue, 10 May 2016 12:39:27 +0000
Subject: [openssl-dev] [openssl.org #4275] Test all built-in curves and let
	the library choose the EC_METHOD
In-Reply-To: <CAFeDd5YB3NTuNC--NAu8YGgyLTL+4V4eDUguEhOyFvxB9=4YyQ@mail.gmail.com>
References: <RT-Ticket-4275@openssl.org>
 <CAFeDd5YB3NTuNC--NAu8YGgyLTL+4V4eDUguEhOyFvxB9=4YyQ@mail.gmail.com>
Message-ID: <rt-4.0.19-5500-1462883967-823.4275-6-0@openssl.org>

Looks like this got merged so closing.

Matt

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


From rt at openssl.org  Tue May 10 12:49:15 2016
From: rt at openssl.org (Matt Caswell via RT)
Date: Tue, 10 May 2016 12:49:15 +0000
Subject: [openssl-dev] [openssl.org #4280] OpenSSL 1.1.0 pre 2: feature
	request: ECDSA_SIG_set0(const ECDSA_SIG*, BIGNUM *,
	BIGNUM *) is needed
In-Reply-To: <56AAF976.7010102@aleksey.com>
References: <RT-Ticket-4280@openssl.org> <56AAF976.7010102@aleksey.com>
Message-ID: <rt-4.0.19-5500-1462884555-72.4280-6-0@openssl.org>

Steve explained how to achieve what was wanted. Also the DSA_SIG_set0()
function also mentioned in this ticket seems to have been added.

Closing.

Matt

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


From rt at openssl.org  Tue May 10 12:51:49 2016
From: rt at openssl.org (Richard Levitte via RT)
Date: Tue, 10 May 2016 12:51:49 +0000
Subject: [openssl-dev] [openssl.org #4217] Fixing DJGPP port of openssl
	master branch.
In-Reply-To: <rt-4.0.19-11679-1452126320-995.4217-6-0@openssl.org>
References: <RT-Ticket-4217@openssl.org> <568A77AE.8090801@gmx.de>
 <rt-4.0.19-11137-1451936568-1413.4217-21-0@openssl.org>
 <20160104.212201.300039170238726481.levitte@openssl.org>
 <rt-4.0.19-11137-1451938935-1890.4217-6-0@openssl.org>
 <568B25A2.8000705@gmx.de>
 <rt-4.0.19-11679-1451963145-1881.4217-6-0@openssl.org>
 <568DA30C.6060109@gmx.de>
 <rt-4.0.19-11679-1452126320-995.4217-6-0@openssl.org>
Message-ID: <rt-4.0.19-5499-1462884709-440.4217-6-0@openssl.org>

Hi Juan,

sorry that I lost track of this, and thank you Matt for the ping.

I've made this a github PR, here: https://github.com/openssl/openssl/pull/1050

Could you verify that it still works correctly? Or anyone else that's
interested?
(we will proceed anyway if we haven't heard from you by the end of the week,
but it would be nice having things verified)

Cheers,
Richard

On Thu Jan 07 00:25:20 2016, juan.guerrero at gmx.de wrote:
> Am 05.01.2016 04:05, schrieb Juan Manuel Guerrero via RT:
> > Am 04.01.2016 21:22, schrieb Richard Levitte via RT:
> >> Hi Juan, and thanks.
> >>
> >> I'm looking at your fix, and have a couple of questions:
> [snip]
>
> This is the last and final patch to fix the DJGPP port. The only
> difference
> compared with the initial patch is that it checks mow all file names
> for LFN
> validity. The dirname part and the basename part of the file name are
> now
> checked for ilicit initial dots in the case that no LFN support is
> provided
> by the file system. I have attached the patch as gzip'ed file too.
>
> Similar patches are also provided for the openssl 1.0.1 branch and the
> openssl 1.0.2 branch too.
>
>
> Regards,
> Juan M. Guerrero
>
>
>
>
>
>
> 2016-01-06 Juan Manuel Guerrero <juan.guerrero at gmx.de>
>
> * Configure: Replaced -DTERMIO by -DTERMIOS in CFLAGS.
>
> * crypto/bio/bss_dgram.c [WATT32]: Remove obsolete redefinition of
> function names: sock_write, sock_read and sock_puts.
>
> * crypto/bio/bss_sock.c [WATT32]: For Watt-32 2.2.11 sock_write,
> sock_read and sock_puts are redefined to their private names so their
> names must be undefined first before they can be redefined again.
>
> * crypto/bio/bss_file.c (file_fopen) [OPENSSL_SYS_MSDOS]: Call
> dosify_filename to replace leading dot if file system does not support
> it.
> (dosify_filename): Replace leading dot in passed file name if file
> system does not support LFN. Replace all leading dots in the dirname
> part and the basname part of the file name.
>
> * e_os.h [__DJGPP__]: Undefine macro DEVRANDOM_EGD. Neither MS-DOS
> nor FreeDOS provide 'egd' sockets.
> New macro HAS_LFN_SUPPORT checks if underlying file system supports
> long file names or not.
> Include sys/un.h.
> Define WATT32_NO_OLDIES.
>
> * INSTALL.DJGPP: Update URL of WATT-32 library.
>
>
>
>
>
>
>
>
>
> diff --git a/Configurations/10-main.conf b/Configurations/10-main.conf
> index a82b95d..fad57a9 100644
> --- a/Configurations/10-main.conf
> +++ b/Configurations/10-main.conf
> @@ -1299,7 +1299,7 @@
> "DJGPP" => {
> inherit_from => [ asm("x86_asm") ],
> cc => "gcc",
> - cflags => "-I/dev/env/WATT_ROOT/inc -DTERMIO
> -DL_ENDIAN -fomit-frame-pointer -O2 -Wall",
> + cflags => "-I/dev/env/WATT_ROOT/inc -DTERMIOS
> -DL_ENDIAN -fomit-frame-pointer -O2 -Wall",
> sys_id => "MSDOS",
> lflags => "-L/dev/env/WATT_ROOT/lib -lwatt",
> bn_ops => "BN_LLONG ${x86_gcc_des}
> ${x86_gcc_opts}",
> diff --git a/INSTALL.DJGPP b/INSTALL.DJGPP
> index 1047ec9..23aed6a 100644
> --- a/INSTALL.DJGPP
> +++ b/INSTALL.DJGPP
> @@ -18,7 +18,7 @@
> files to download, see the DJGPP "ZIP PICKER" page at
> "http://www.delorie.com/djgpp/zip-picker.html". You also need to
> have
> the WATT-32 networking package installed before you try to compile
> - OpenSSL. This can be obtained from "http://www.bgnett.no/~giva/".
> + OpenSSL. This can be obtained from "http://www.watt-32.net/".
> The Makefile assumes that the WATT-32 code is in the directory
> specified by the environment variable WATT_ROOT. If you have watt-
> 32
> in directory "watt32" under your main DJGPP directory, specify
> diff --git a/crypto/bio/bss_dgram.c b/crypto/bio/bss_dgram.c
> index 5e934ce..ca318cf 100644
> --- a/crypto/bio/bss_dgram.c
> +++ b/crypto/bio/bss_dgram.c
> @@ -97,12 +97,6 @@
> ((a)->s6_addr32[2] == htonl(0x0000ffff)))
> # endif
>
> -# ifdef WATT32
> -# define sock_write SockWrite /* Watt-32 uses same names */
> -# define sock_read SockRead
> -# define sock_puts SockPuts
> -# endif
> -
> static int dgram_write(BIO *h, const char *buf, int num);
> static int dgram_read(BIO *h, char *buf, int size);
> static int dgram_puts(BIO *h, const char *str);
> diff --git a/crypto/bio/bss_file.c b/crypto/bio/bss_file.c
> index c09a9a9..f34161c 100644
> --- a/crypto/bio/bss_file.c
> +++ b/crypto/bio/bss_file.c
> @@ -95,6 +95,10 @@
>
> # if !defined(OPENSSL_NO_STDIO)
>
> +#ifdef OPENSSL_SYS_MSDOS
> +# include <libc/unconst.h>
> +static void dosify_filename(const char *filename);
> +#endif
> static int file_write(BIO *h, const char *buf, int num);
> static int file_read(BIO *h, char *buf, int size);
> static int file_puts(BIO *h, const char *str);
> @@ -161,6 +165,9 @@ static FILE *file_fopen(const char *filename,
> const char *mode)
> file = fopen(filename, mode);
> }
> # else
> +# ifdef OPENSSL_SYS_MSDOS
> + dosify_filename(filename);
> +# endif
> file = fopen(filename, mode);
> # endif
> return (file);
> @@ -467,6 +474,23 @@ static int file_puts(BIO *bp, const char *str)
> return (ret);
> }
>
> +#ifdef OPENSSL_SYS_MSDOS
> +static void dosify_filename(const char *filename)
> +{
> + if (filename && *filename && !HAS_LFN_SUPPORT(filename)) {
> + char *namestart = unconst(filename, char *);
> +
> + do {
> + if (namestart[0] == '/' && namestart[2] != '.' &&
> namestart[2] != '/') {
> +
> + /* Leading dot not allowed on plain DOS. */
> + if (namestart[1] == '.')
> + *++namestart = '_';
> + }
> + } while (*++namestart);
> + }
> +}
> +#endif
> #else
>
> static int file_write(BIO *b, const char *in, int inl)
> diff --git a/crypto/bio/bss_sock.c b/crypto/bio/bss_sock.c
> index 1673b32..5cef4f3 100644
> --- a/crypto/bio/bss_sock.c
> +++ b/crypto/bio/bss_sock.c
> @@ -66,7 +66,11 @@
> # include <openssl/bio.h>
>
> # ifdef WATT32
> -# define sock_write SockWrite /* Watt-32 uses same names */
> +/* Watt-32 uses same names */
> +# undef sock_write
> +# undef sock_read
> +# undef sock_puts
> +# define sock_write SockWrite
> # define sock_read SockRead
> # define sock_puts SockPuts
> # endif
> diff --git a/e_os.h b/e_os.h
> index 5ab4c89..6d52f13 100644
> --- a/e_os.h
> +++ b/e_os.h
> @@ -141,6 +141,7 @@ extern "C" {
> # define writesocket(s,b,n) send((s),(b),(n),0)
> # elif defined(__DJGPP__)
> # define WATT32
> +# define WATT32_NO_OLDIES
> # define get_last_socket_error() errno
> # define clear_socket_error() errno=0
> # define closesocket(s) close_s(s)
> @@ -194,11 +195,14 @@ extern "C" {
> # include <unistd.h>
> # include <sys/stat.h>
> # include <sys/socket.h>
> +# include <sys/un.h>
> # include <tcp.h>
> # include <netdb.h>
> # define _setmode setmode
> # define _O_TEXT O_TEXT
> # define _O_BINARY O_BINARY
> +# define HAS_LFN_SUPPORT(name) (pathconf((name), _PC_NAME_MAX) >
> 12)
> +# undef DEVRANDOM_EGD /* Neither MS-DOS nor FreeDOS provide 'egd'
> sockets. */
> # undef DEVRANDOM
> # define DEVRANDOM "/dev/urandom\x24"
> # endif /* __DJGPP__ */


--
Richard Levitte
levitte at openssl.org

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


From rt at openssl.org  Tue May 10 12:54:04 2016
From: rt at openssl.org (Matt Caswell via RT)
Date: Tue, 10 May 2016 12:54:04 +0000
Subject: [openssl-dev] [openssl.org #4282] Re: [PATCH] Allow downgrading
	when reusing sessions on client
In-Reply-To: <rt-4.0.19-12665-1454203230-70.4282-6-0@openssl.org>
References: <RT-Ticket-4282@openssl.org> <RT-Ticket-4281@openssl.org>
 <CAEv2VfJ4YHXe158p-CKv6TX9FvXoXgfONJd_Q_qjOfVkXwu5Ow@mail.gmail.com>
 <rt-4.0.19-12665-1454199241-328.4281-6-0@openssl.org>
 <CAEv2VfJva7TxzBP-cPx-=VY+sYpmU1FcZdZobQA6Onk2-6=L5w@mail.gmail.com>
 <rt-4.0.19-18549-1454202861-379.4281-6-0@openssl.org>
 <5e90dfb0f8fe468ebab26c66d47cbc62@usma1ex-dag1mb1.msg.corp.akamai.com>
 <rt-4.0.19-18549-1454202971-300.4281-6-0@openssl.org>
 <CAEv2VfJ1-VW0wd20bAAg-eAbe1pqjhL-a20caddHs01u2L7qmA@mail.gmail.com>
 <rt-4.0.19-12665-1454203230-70.4282-6-0@openssl.org>
Message-ID: <rt-4.0.19-5500-1462884844-1266.4282-6-0@openssl.org>

On Sun Jan 31 01:20:30 2016, fedor at indutny.com wrote:
> This actually sounds like a lovely idea.
>
> See: https://github.com/openssl/openssl/pull/603

The referenced pull got closed and replaced by
https://github.com/openssl/openssl/pull/852 which has been merged. Therefore
closing this ticket.

Matt

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


From rt at openssl.org  Tue May 10 13:08:07 2016
From: rt at openssl.org (Matt Caswell via RT)
Date: Tue, 10 May 2016 13:08:07 +0000
Subject: [openssl-dev] [openssl.org #4287] Option -attime for "openssl ts
	-verify"
In-Reply-To: <assp.084074222e.D7D593DE9808CC4C91ABC9D0461D2167506F8379@EX2010-MB.ipb-halle.de>
References: <RT-Ticket-4287@openssl.org>
 <assp.084074222e.D7D593DE9808CC4C91ABC9D0461D2167506F8379@EX2010-MB.ipb-halle.de>
Message-ID: <rt-4.0.19-5500-1462885687-1992.4287-6-0@openssl.org>

This got fixed as part of GitHub pull request 870, so closing this.

Matt

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


From rt at openssl.org  Tue May 10 13:10:56 2016
From: rt at openssl.org (Matt Caswell via RT)
Date: Tue, 10 May 2016 13:10:56 +0000
Subject: [openssl-dev] [openssl.org #4301] [BUG] OpenSSL 1.1.0-pre2 fails to
	parse x509 certificate in DER format
In-Reply-To: <CACB34uaz9nkwzOww88wLHZtVbaUf81jFk7_Si0W-uoKjmP5d4w@mail.gmail.com>
References: <RT-Ticket-4301@openssl.org>
 <CACB34uaz9nkwzOww88wLHZtVbaUf81jFk7_Si0W-uoKjmP5d4w@mail.gmail.com>
Message-ID: <rt-4.0.19-5500-1462885856-76.4301-6-0@openssl.org>

This is intended behaviour for the certificate in question, so closing this
ticket.

Matt

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


From rt at openssl.org  Tue May 10 13:13:50 2016
From: rt at openssl.org (Matt Caswell via RT)
Date: Tue, 10 May 2016 13:13:50 +0000
Subject: [openssl-dev] [openssl.org #4306] few cmds help cleanup
In-Reply-To: <CA+LSdEi50XXXTnZP+8srchpg=5vHUAzNEbzc2Bad3+g8O1VL1w@mail.gmail.com>
References: <RT-Ticket-4306@openssl.org>
 <CA+LSdEi50XXXTnZP+8srchpg=5vHUAzNEbzc2Bad3+g8O1VL1w@mail.gmail.com>
Message-ID: <rt-4.0.19-5500-1462886030-303.4306-6-0@openssl.org>

This got committed in 6c335b0.

Closing.

Matt

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


From rt at openssl.org  Tue May 10 13:13:59 2016
From: rt at openssl.org (Richard Levitte via RT)
Date: Tue, 10 May 2016 13:13:59 +0000
Subject: [openssl-dev] [openssl.org #4255] OpenSSL-1.1.0-pre2 failures using
	MinGW-W64
In-Reply-To: <rt-4.0.19-5500-1462883800-449.4255-6-0@openssl.org>
References: <RT-Ticket-4255@openssl.org>
 <1453060954.186021958.y9vnrjtk@frv39.fwdcdn.com>
 <rt-4.0.19-5500-1462883800-449.4255-6-0@openssl.org>
Message-ID: <rt-4.0.19-5500-1462886039-340.4255-6-0@openssl.org>

On Tue May 10 12:36:40 2016, matt wrote:
> Re-opening. OP reports there are still issues with "make test" hanging.

I would like OP to submit a 'make test' log, preferably verbose:

HARNESS_VERBOSE=yes make test

--
Richard Levitte
levitte at openssl.org

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


From rt at openssl.org  Tue May 10 13:18:22 2016
From: rt at openssl.org (Matt Caswell via RT)
Date: Tue, 10 May 2016 13:18:22 +0000
Subject: [openssl-dev] [openssl.org #4311] OpenSSL 1.1.0-pre3: quote
	PERL=$(PERL) in Makefiles
In-Reply-To: <56C36B8A.50507@kippdata.de>
References: <RT-Ticket-4311@openssl.org> <56C36B8A.50507@kippdata.de>
Message-ID: <rt-4.0.19-5500-1462886302-1490.4311-6-0@openssl.org>

Makefile.in doesn't exist any more. Ping Richard Levitte - does anything need
to be done for the new build system?

Matt

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


From rt at openssl.org  Tue May 10 13:21:05 2016
From: rt at openssl.org (Matt Caswell via RT)
Date: Tue, 10 May 2016 13:21:05 +0000
Subject: [openssl-dev] [openssl.org #4317] openssl-1.1.0-pre3 make error
	with Configure option "zlib-dynamic"
In-Reply-To: <371612.13391.qm@web101209.mail.kks.yahoo.co.jp>
References: <RT-Ticket-4317@openssl.org>
 <371612.13391.qm@web101209.mail.kks.yahoo.co.jp>
Message-ID: <rt-4.0.19-5500-1462886465-42.4317-6-0@openssl.org>

This seems to be working correctly now.

Closing.

Matt

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


From rt at openssl.org  Tue May 10 13:24:01 2016
From: rt at openssl.org (Richard Levitte via RT)
Date: Tue, 10 May 2016 13:24:01 +0000
Subject: [openssl-dev] [openssl.org #4245] OpenSSL-1.1-pre2 e_oss.h and
	inline conflicts
In-Reply-To: <d43bba94ae564a7d8f400e1f3021a1cc@usma1ex-dag1mb1.msg.corp.akamai.com>
References: <RT-Ticket-4245@openssl.org>
 <d43bba94ae564a7d8f400e1f3021a1cc@usma1ex-dag1mb1.msg.corp.akamai.com>
Message-ID: <rt-4.0.19-5500-1462886641-107.4245-6-0@openssl.org>

Checking if inline is defined and using that definition is the right thing to
do. To check for ossl_inline would be absurd, as the header file guard
(HEADER_E_OS2_H) already does that job.

Perhaps the commit f820b79248140419c1c2ced9873aa1d78b665a76 fixed the issue?

Closing this ticket for now.

On Fri Jan 15 19:45:42 2016, rsalz at akamai.com wrote:
> e_os.2 line 327::
>
> # if !defined(inline) && !defined(__cplusplus)
>
> Should this be:
>
> # if !defined(ossl_inline) && !defined(__cplusplus)
>
> The purpose of this section is to end up with a good definition for
> ossl_inline
>
> If some preceding header file (and I have run across this) does a
> #define inline
>
> The e_os2.h will not change the ossl_inline and the safestack.h and
> other header files will prodice pages of errors.


--
Richard Levitte
levitte at openssl.org

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


From rt at openssl.org  Tue May 10 13:26:44 2016
From: rt at openssl.org (Matt Caswell via RT)
Date: Tue, 10 May 2016 13:26:44 +0000
Subject: [openssl-dev] [openssl.org #4319] openssl-1.1.0-pre3 Configure does
	not set cflags correctly on Solaris10 x64
In-Reply-To: <109678.47711.qm@web101206.mail.kks.yahoo.co.jp>
References: <RT-Ticket-4319@openssl.org>
 <109678.47711.qm@web101206.mail.kks.yahoo.co.jp>
Message-ID: <rt-4.0.19-5500-1462886804-693.4319-6-0@openssl.org>

This seems to have been fixed at some point (at least it is working for me on
latest master). Closing.

Matt

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


From rt at openssl.org  Tue May 10 13:29:17 2016
From: rt at openssl.org (Richard Levitte via RT)
Date: Tue, 10 May 2016 13:29:17 +0000
Subject: [openssl-dev] [openssl.org #4311] OpenSSL 1.1.0-pre3: quote
	PERL=$(PERL) in Makefiles
In-Reply-To: <rt-4.0.19-5500-1462886302-337.4311-6-0@openssl.org>
References: <RT-Ticket-4311@openssl.org> <56C36B8A.50507@kippdata.de>
 <rt-4.0.19-5500-1462886302-337.4311-6-0@openssl.org>
Message-ID: <rt-4.0.19-5500-1462886957-1375.4311-6-0@openssl.org>

On Tue May 10 13:18:22 2016, matt wrote:
> Makefile.in doesn't exist any more. Ping Richard Levitte - does
> anything need
> to be done for the new build system?

The run_tests.pl line in Configurations/unix-Makefile.tmpl would still need
that change...

... but I don't quite understand the background story. What you end up with is
perl calls like this:

/usr/bin/env perl ... blah ...

and the difference between that and this is nil:

perl ... blah ...

--
Richard Levitte
levitte at openssl.org

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


From rt at openssl.org  Tue May 10 13:34:55 2016
From: rt at openssl.org (Matt Caswell via RT)
Date: Tue, 10 May 2016 13:34:55 +0000
Subject: [openssl-dev] [openssl.org #4321] Re: Missing accessor to the
	EVP_CIPHER_CTX member oiv
In-Reply-To: <CADqLbz+mbAWDusEomDb1Fxcz1tBNmAtq6NApCNx-r=CtNVV0qA@mail.gmail.com>
References: <RT-Ticket-4321@openssl.org> <RT-Ticket-4267@openssl.org>
 <CADqLbzKtPgUzQD-vxw5E=oXSZVGy6mHxNXP56CQ5JjnT7p=t5Q@mail.gmail.com>
 <rt-4.0.19-19276-1455702136-1968.4267-6-0@openssl.org>
 <CADqLbzLUXuFxEQdDLOeEb66hgW49Hjx=18KtEgOwOTqSnKDUKQ@mail.gmail.com>
 <rt-4.0.19-19276-1455702784-146.4267-6-0@openssl.org>
 <rt-4.0.19-19276-1455708326-283.4267-6-0@openssl.org>
 <rt-4.0.19-19276-1455820652-595.4267-6-0@openssl.org>
 <CADqLbz+mbAWDusEomDb1Fxcz1tBNmAtq6NApCNx-r=CtNVV0qA@mail.gmail.com>
Message-ID: <rt-4.0.19-5500-1462887295-1476.4321-6-0@openssl.org>

Seems to have been opened in error (reply to ticket 4267).

Closing.

Matt

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


From rt at openssl.org  Tue May 10 13:38:19 2016
From: rt at openssl.org (Matt Caswell via RT)
Date: Tue, 10 May 2016 13:38:19 +0000
Subject: [openssl-dev] [openssl.org #4343] master: EC_KEY_priv2buf (): check
	parameter sanity
In-Reply-To: <CA+LSdEgkR2gzGegL1L3BVA0nWJcPwTWTyMFw+pRLdFc8Eqq8=Q@mail.gmail.com>
References: <RT-Ticket-4343@openssl.org>
 <CA+LSdEgkR2gzGegL1L3BVA0nWJcPwTWTyMFw+pRLdFc8Eqq8=Q@mail.gmail.com>
Message-ID: <rt-4.0.19-5499-1462887499-1657.4343-6-0@openssl.org>

Steve explained how this should be done.

Closing.

Matt

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


From rt at openssl.org  Tue May 10 13:40:39 2016
From: rt at openssl.org (Matt Caswell via RT)
Date: Tue, 10 May 2016 13:40:39 +0000
Subject: [openssl-dev] [openssl.org #4326] Failed to configure for Cygwin-x64
In-Reply-To: <CAH8yC8msnyVTT+8tPaE-+Lh9Pv0wCPs+jh9nkCOCgWY-0DkrNA@mail.gmail.com>
References: <RT-Ticket-4326@openssl.org>
 <CAH8yC8msnyVTT+8tPaE-+Lh9Pv0wCPs+jh9nkCOCgWY-0DkrNA@mail.gmail.com>
Message-ID: <rt-4.0.19-5500-1462887639-359.4326-6-0@openssl.org>

This seems to have been fixed.

Closing.

Matt

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


From rt at openssl.org  Tue May 10 13:43:03 2016
From: rt at openssl.org (Matt Caswell via RT)
Date: Tue, 10 May 2016 13:43:03 +0000
Subject: [openssl-dev] [openssl.org #4327] SSL_CTX_use_serverinfo_file()
	causes issues for SSL_CTX with multiple certs
In-Reply-To: <1456021434.3968602.527141410.3B7F15DE@webmail.messagingengine.com>
References: <RT-Ticket-4327@openssl.org>
 <1456021434.3968602.527141410.3B7F15DE@webmail.messagingengine.com>
Message-ID: <rt-4.0.19-5500-1462887783-1723.4327-6-0@openssl.org>

This was fixed in github PR 914.

Closing.

Matt

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


From rt at openssl.org  Tue May 10 13:44:25 2016
From: rt at openssl.org (Matt Caswell via RT)
Date: Tue, 10 May 2016 13:44:25 +0000
Subject: [openssl-dev] [openssl.org #4328] Cygwin,
	self test and "./bctest: line 35: bc: command not found"
In-Reply-To: <CAH8yC8mm-mg_Gz3YnnOrUuL+QuKLz=Z=bTJ9iYoEQ09C0bUUJA@mail.gmail.com>
References: <RT-Ticket-4328@openssl.org>
 <CAH8yC8mm-mg_Gz3YnnOrUuL+QuKLz=Z=bTJ9iYoEQ09C0bUUJA@mail.gmail.com>
Message-ID: <rt-4.0.19-5500-1462887865-1961.4328-6-0@openssl.org>

Richard provided an answer for this.

Closing.

Matt

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


From rt at openssl.org  Tue May 10 13:49:53 2016
From: rt at openssl.org (Matt Caswell via RT)
Date: Tue, 10 May 2016 13:49:53 +0000
Subject: [openssl-dev] [openssl.org #4338] master: allocating memory for an
	unused variable in tls1_export_keying_material
In-Reply-To: <CA+LSdEjbv+kELdFRMQM84r_WkXKfFt-mJU-MujdC0TDhEOOVaA@mail.gmail.com>
References: <RT-Ticket-4338@openssl.org>
 <CA+LSdEjbv+kELdFRMQM84r_WkXKfFt-mJU-MujdC0TDhEOOVaA@mail.gmail.com>
Message-ID: <rt-4.0.19-5499-1462888193-669.4338-6-0@openssl.org>

The referenced pull request was merged.

Closing.

Matt

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


From rt at openssl.org  Tue May 10 13:50:29 2016
From: rt at openssl.org (Ivan Rancati via RT)
Date: Tue, 10 May 2016 13:50:29 +0000
Subject: [openssl-dev] [openssl.org #4538] Possible typo on
	https://www.openssl.org/docs/manmaster/apps/x509v3_config.html
In-Reply-To: <CALbgBj_kW=TdpjX1YQfXvLtydRVMjkMJ5GRELmm0YFviS-VHgQ@mail.gmail.com>
References: <RT-Ticket-4538@openssl.org>
 <CALbgBj_kW=TdpjX1YQfXvLtydRVMjkMJ5GRELmm0YFviS-VHgQ@mail.gmail.com>
Message-ID: <rt-4.0.19-5499-1462888228-1791.4538-21-0@openssl.org>

On the page
https://www.openssl.org/docs/manmaster/apps/x509v3_config.html

there is this paragraph

"These can either be object short names OF the dotted numerical form of OIDs
"

If I understand correctly, the paragraph should be "These can either be
object short names OR the dotted numerical form of OIDs"

Thanks and best regards
Ivan Rancati

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


From rt at openssl.org  Tue May 10 13:57:38 2016
From: rt at openssl.org (Matt Caswell via RT)
Date: Tue, 10 May 2016 13:57:38 +0000
Subject: [openssl-dev] [openssl.org #4357] NIST SP800-56A co-factor ECDH KATs
In-Reply-To: <CAFeDd5a6Op_Wv9eCVsvUyv6sqHrpBPaCp=+5Ryc2mpJ_Q0if-g@mail.gmail.com>
References: <RT-Ticket-4357@openssl.org>
 <CAFeDd5a6Op_Wv9eCVsvUyv6sqHrpBPaCp=+5Ryc2mpJ_Q0if-g@mail.gmail.com>
Message-ID: <rt-4.0.19-5500-1462888658-1644.4357-6-0@openssl.org>

The referenced pull request was merged so closing this ticket.

Matt

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


From rt at openssl.org  Tue May 10 14:19:03 2016
From: rt at openssl.org (Matt Caswell via RT)
Date: Tue, 10 May 2016 14:19:03 +0000
Subject: [openssl-dev] [openssl.org #4400] [PATCH] plug potential memory
	leak in OpenSSL 1.1 pre 4
In-Reply-To: <CAFrbyQxXSeQ20O0EiPOtATPuVzZuWxjqn8Mn9oUMpCPOKvQSyg@mail.gmail.com>
References: <RT-Ticket-4400@openssl.org>
 <CAFrbyQxXSeQ20O0EiPOtATPuVzZuWxjqn8Mn9oUMpCPOKvQSyg@mail.gmail.com>
Message-ID: <rt-4.0.19-5499-1462889943-1211.4400-6-0@openssl.org>

This patch doesn't look correct. I don't see a memory leak here.

Closing.

Matt

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


From rt at openssl.org  Tue May 10 14:21:51 2016
From: rt at openssl.org (Matt Caswell via RT)
Date: Tue, 10 May 2016 14:21:51 +0000
Subject: [openssl-dev] [openssl.org #4404] [PATCH] Missing Sanity Check for
	OPENSSL_strdup() in OpenSSL-1.1 pre-4
In-Reply-To: <CAFrbyQyHATphmyYZBerUm4Lpur8O=KSbnh8WQW0KrT3WVKwBMw@mail.gmail.com>
References: <RT-Ticket-4404@openssl.org>
 <CAFrbyQyHATphmyYZBerUm4Lpur8O=KSbnh8WQW0KrT3WVKwBMw@mail.gmail.com>
Message-ID: <rt-4.0.19-5499-1462890111-1200.4404-6-0@openssl.org>

This appears to have been fixed.

Closing.

Matt

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


From rt at openssl.org  Tue May 10 14:23:35 2016
From: rt at openssl.org (Matt Caswell via RT)
Date: Tue, 10 May 2016 14:23:35 +0000
Subject: [openssl-dev] [openssl.org #4405] 1.1.0 compile failure with no-comp
In-Reply-To: <etPan.56e02051.39902f02.375@atlas.local>
References: <RT-Ticket-4405@openssl.org>
 <etPan.56e02051.39902f02.375@atlas.local>
Message-ID: <rt-4.0.19-5499-1462890215-1342.4405-6-0@openssl.org>

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


From rt at openssl.org  Tue May 10 14:26:02 2016
From: rt at openssl.org (Matt Caswell via RT)
Date: Tue, 10 May 2016 14:26:02 +0000
Subject: [openssl-dev] [openssl.org #4409] bug OpenSSL 1.0.1p 9 Jul 2015
In-Reply-To: <CADTPv6Evi0jLxsjNC_5gYCaX3Nj7kn0KvBrQPYCJGicMtE-tVQ@mail.gmail.com>
References: <RT-Ticket-4409@openssl.org>
 <CADTPv6Evi0jLxsjNC_5gYCaX3Nj7kn0KvBrQPYCJGicMtE-tVQ@mail.gmail.com>
Message-ID: <rt-4.0.19-5499-1462890362-288.4409-6-0@openssl.org>

Not a bug. Closing.

Matt

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


From rt at openssl.org  Tue May 10 14:27:59 2016
From: rt at openssl.org (Matt Caswell via RT)
Date: Tue, 10 May 2016 14:27:59 +0000
Subject: [openssl-dev] [openssl.org #4413] Cygwin x86_64: make: *** No rule
	to make target '<user>/openssl/Configurations/unix-Makefile.tmpl',
	needed by 'configdata.pm'.
In-Reply-To: <CAH8yC8kuqnfpVP-TRLSmNsFT2hcxp4je=dFxx+pHdmhWt8JxHQ@mail.gmail.com>
References: <RT-Ticket-4413@openssl.org>
 <CAH8yC8kuqnfpVP-TRLSmNsFT2hcxp4je=dFxx+pHdmhWt8JxHQ@mail.gmail.com>
Message-ID: <rt-4.0.19-5500-1462890479-1341.4413-6-0@openssl.org>

OP reports this as fixed.

Closing.

Matt

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


From rt at openssl.org  Tue May 10 14:29:20 2016
From: rt at openssl.org (Matt Caswell via RT)
Date: Tue, 10 May 2016 14:29:20 +0000
Subject: [openssl-dev] [openssl.org #4418] Apple configuration delay does
	not respond to Ctrl-C, proceeds with configuration
In-Reply-To: <CAH8yC8nCUQ2hzDuJC5t9eNKXy7YON7aakUPZ=FSt2uSd=aXmrg@mail.gmail.com>
References: <RT-Ticket-4418@openssl.org>
 <CAH8yC8nCUQ2hzDuJC5t9eNKXy7YON7aakUPZ=FSt2uSd=aXmrg@mail.gmail.com>
Message-ID: <rt-4.0.19-5499-1462890560-1705.4418-6-0@openssl.org>

Ping Richard Levitte. Can this be closed?

Matt

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


From rt at openssl.org  Tue May 10 14:36:39 2016
From: rt at openssl.org (Matt Caswell via RT)
Date: Tue, 10 May 2016 14:36:39 +0000
Subject: [openssl-dev] [openssl.org #4434] Gentoo 13,
	x86_64: 4 failed self tests
In-Reply-To: <CAH8yC8=By36J-eXHpU4fqLu3j2AK-Ey+GPv7ois6wqLLA+uTOQ@mail.gmail.com>
References: <RT-Ticket-4434@openssl.org>
 <CAH8yC8=By36J-eXHpU4fqLu3j2AK-Ey+GPv7ois6wqLLA+uTOQ@mail.gmail.com>
Message-ID: <rt-4.0.19-5500-1462890999-1132.4434-6-0@openssl.org>

Jeff

Please can you check this again on latest master. Is this still an issue?

Thanks

Matt

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


From rt at openssl.org  Tue May 10 14:41:31 2016
From: rt at openssl.org (Matt Caswell via RT)
Date: Tue, 10 May 2016 14:41:31 +0000
Subject: [openssl-dev] [openssl.org #4440] Re: Openssl-SNAP-20160315 issue
	Re: Openssl-SNAP-20160314 Re: Openssl SNAP 20160313 issue Re:
	OPenSSL SNAP 20160312 issue
In-Reply-To: <20160317220742.GA24175@doctor.nl2k.ab.ca>
References: <RT-Ticket-4440@openssl.org>
 <20160315205022.GA26917@doctor.nl2k.ab.ca>
 <20160315.221350.1725521770011152083.levitte@openssl.org>
 <20160316182629.GA10733@doctor.nl2k.ab.ca>
 <20160316.200915.964875523300370144.levitte@openssl.org>
 <20160317220742.GA24175@doctor.nl2k.ab.ca>
Message-ID: <rt-4.0.19-5500-1462891291-1725.4440-6-0@openssl.org>

Ticket appears to have been opened in error.

Closing.

Matt

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


From rt at openssl.org  Tue May 10 14:44:10 2016
From: rt at openssl.org (Matt Caswell via RT)
Date: Tue, 10 May 2016 14:44:10 +0000
Subject: [openssl-dev] [openssl.org #4443] Re: VIA C7-D processor: Hang in
	30-test_afalg.t
In-Reply-To: <CAH8yC8kn+Oh+01FFg0jTjxvbfsh9nMYhqpmhDym4m7=LaAEzBA@mail.gmail.com>
References: <RT-Ticket-4443@openssl.org>
 <CAH8yC8ndihSr4y1v=kH=KYW_zx_gCgndy3_4epgKdVBsi4UqBA@mail.gmail.com>
 <CAH8yC8n2kHSieMp+Gs9CRyf=GAc9h=egkdiK3gKZPgqdZn7iNw@mail.gmail.com>
 <CAH8yC8kn+Oh+01FFg0jTjxvbfsh9nMYhqpmhDym4m7=LaAEzBA@mail.gmail.com>
Message-ID: <rt-4.0.19-5499-1462891450-714.4443-6-0@openssl.org>

Ticket appears to have been opened in error. This message should have been
against ticket 4411.

Closing.

Matt

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


From rt at openssl.org  Tue May 10 14:45:11 2016
From: rt at openssl.org (Matt Caswell via RT)
Date: Tue, 10 May 2016 14:45:11 +0000
Subject: [openssl-dev] [openssl.org #4445] Configure does not honor
	enable-afalgeng
In-Reply-To: <CAH8yC8kpCi3Bjz6r+M69CG+FOU6msyBzNpFUNHkU0zJWoRTwow@mail.gmail.com>
References: <RT-Ticket-4445@openssl.org>
 <CAH8yC8kpCi3Bjz6r+M69CG+FOU6msyBzNpFUNHkU0zJWoRTwow@mail.gmail.com>
Message-ID: <rt-4.0.19-5499-1462891511-344.4445-6-0@openssl.org>

Working as intended.

Closing.

Matt

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


From rt at openssl.org  Tue May 10 14:47:15 2016
From: rt at openssl.org (Matt Caswell via RT)
Date: Tue, 10 May 2016 14:47:15 +0000
Subject: [openssl-dev] [openssl.org #4451] OS X 10.8,
	x86_64: 01-test_abort.t... sh: line 1: 71522 Abort trap: 6
In-Reply-To: <CAH8yC8ka2G0jmndp20nnoiqdwit75P0zNKOkUwqcJG31ops8HA@mail.gmail.com>
References: <RT-Ticket-4451@openssl.org>
 <CAH8yC8ka2G0jmndp20nnoiqdwit75P0zNKOkUwqcJG31ops8HA@mail.gmail.com>
Message-ID: <rt-4.0.19-5500-1462891635-754.4451-6-0@openssl.org>

Reopened in error. Closing.

Matt

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


From rt at openssl.org  Tue May 10 14:51:23 2016
From: rt at openssl.org (Matt Caswell via RT)
Date: Tue, 10 May 2016 14:51:23 +0000
Subject: [openssl-dev] [openssl.org #4454] openssl-1.1.0-pre4: zlib-dynamic
	problems
In-Reply-To: <945595.50082.qm@web101212.mail.kks.yahoo.co.jp>
References: <RT-Ticket-4454@openssl.org>
 <945595.50082.qm@web101212.mail.kks.yahoo.co.jp>
Message-ID: <rt-4.0.19-5500-1462891883-1717.4454-6-0@openssl.org>

This should be fixed now.

Closing.

Matt

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


From rt at openssl.org  Tue May 10 14:52:22 2016
From: rt at openssl.org (Matt Caswell via RT)
Date: Tue, 10 May 2016 14:52:22 +0000
Subject: [openssl-dev] [openssl.org #4455] OpenSUSE 42: undefined reference
	to `engine_load_afalg_internal'
In-Reply-To: <CAH8yC8msPBpHx6=Vk3zpxtEQOzVhYo1x3dv9EPSWqWFjjO_VVA@mail.gmail.com>
References: <RT-Ticket-4455@openssl.org>
 <CAH8yC8msPBpHx6=Vk3zpxtEQOzVhYo1x3dv9EPSWqWFjjO_VVA@mail.gmail.com>
Message-ID: <rt-4.0.19-5500-1462891942-628.4455-6-0@openssl.org>

No response to last message. Assuming fixed.

Closing.

Matt

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


From rt at openssl.org  Tue May 10 14:54:56 2016
From: rt at openssl.org (Matt Caswell via RT)
Date: Tue, 10 May 2016 14:54:56 +0000
Subject: [openssl-dev] [openssl.org #4456] Fedora 1,
	i386: error: field `next_timeout` has incomplete type
In-Reply-To: <CAH8yC8nYG+fSJktLqgkKtgDyFk0Os=UiP52WmcnkYSCyxs-RSw@mail.gmail.com>
References: <RT-Ticket-4456@openssl.org>
 <CAH8yC8nYG+fSJktLqgkKtgDyFk0Os=UiP52WmcnkYSCyxs-RSw@mail.gmail.com>
Message-ID: <rt-4.0.19-5500-1462892096-1921.4456-6-0@openssl.org>

Ping Richard Levitte.

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


From rainer.jung at kippdata.de  Tue May 10 14:56:04 2016
From: rainer.jung at kippdata.de (Rainer Jung)
Date: Tue, 10 May 2016 16:56:04 +0200
Subject: [openssl-dev] [openssl.org #4311] OpenSSL 1.1.0-pre3: quote
 PERL=$(PERL) in Makefiles
In-Reply-To: <rt-4.0.19-5500-1462886957-1375.4311-6-0@openssl.org>
References: <RT-Ticket-4311@openssl.org> <56C36B8A.50507@kippdata.de>
 <rt-4.0.19-5500-1462886302-337.4311-6-0@openssl.org>
 <rt-4.0.19-5500-1462886957-1375.4311-6-0@openssl.org>
Message-ID: <8c38ec6c-080b-9060-17ab-d1519339c2e4@kippdata.de>

Am 10.05.2016 um 15:29 schrieb Richard Levitte via RT:
> On Tue May 10 13:18:22 2016, matt wrote:
>> Makefile.in doesn't exist any more. Ping Richard Levitte - does
>> anything need
>> to be done for the new build system?
>
> The run_tests.pl line in Configurations/unix-Makefile.tmpl would still need
> that change...
>
> ... but I don't quite understand the background story. What you end up with is
> perl calls like this:
>
> /usr/bin/env perl ... blah ...
>
> and the difference between that and this is nil:
>
> perl ... blah ...

No, this is about lines which set the PERL shell variable from the 
Makefile variable and then run a command on the same line, e.g.

PERL=$(PERL) /path/to/something

Now if the Makefile variable PERL is set to

PERL=/usr/bin/env perl

without quotes the shell command resolves to:

PERL=/usr/bin/env perl /path/to/something

so we call perl with argument /path/to/something and environment 
variable PERL set to /usr/bin/env.

With quotes it is

PERL="/usr/bin/env perl" /path/to/something

so we call /path/to/something with PERL env var set to "/usr/bin/env perl".

Currently (1.1.0pre5) I patch only one file before building, the 
unix-Makefile.tmpl file:

--- ./Configurations/unix-Makefile.tmpl.orig    2016-04-19 
18:51:16.000000000 +0200
+++ ./Configurations/unix-Makefile.tmpl 2016-04-19 19:39:11.000000000 +0200
@@ -231,7 +231,7 @@
         @ : {- output_on() if !$disabled{tests}; "" -}

  list-tests:
-       @TOP=$(SRCDIR) PERL=$(PERL) $(PERL) $(SRCDIR)/test/run_tests.pl list
+       @TOP=$(SRCDIR) PERL="$(PERL)" $(PERL) 
$(SRCDIR)/test/run_tests.pl list

  libclean:
         @set -e; for s in $(SHLIB_INFO); do \
@@ -939,7 +939,7 @@
  $target: $lib$libext $deps $ordinalsfile
         \$(MAKE) -f \$(SRCDIR)/Makefile.shared -e \\
                 PLATFORM=\$(PLATFORM) \\
-               PERL=\$(PERL) SRCDIR='\$(SRCDIR)' DSTDIR="$libd" \\
+               PERL="\$(PERL)" SRCDIR='\$(SRCDIR)' DSTDIR="$libd" \\
                 INSTALLTOP='\$(INSTALLTOP)' LIBDIR='\$(LIBDIR)' \\
                 LIBDEPS='\$(PLIB_LDFLAGS) '"$linklibs"' \$(EX_LIBS)' \\
                 LIBNAME=$libname 
LIBVERSION=\$(SHLIB_MAJOR).\$(SHLIB_MINOR) \\
@@ -975,7 +975,7 @@
  $target: $objs $deps
         \$(MAKE) -f \$(SRCDIR)/Makefile.shared -e \\
                 PLATFORM=\$(PLATFORM) \\
-               PERL=\$(PERL) SRCDIR='\$(SRCDIR)' DSTDIR="$libd" \\
+               PERL="\$(PERL)" SRCDIR='\$(SRCDIR)' DSTDIR="$libd" \\
                 LIBDEPS='\$(PLIB_LDFLAGS) '"$shlibdeps"' \$(EX_LIBS)' \\
                 LIBNAME=$libname LDFLAGS='\$(LDFLAGS)' \\
                 CC='\$(CC)' CFLAGS='\$(CFLAGS) \$(DSO_CFLAGS)' \\
@@ -1012,7 +1012,7 @@
  $bin$exeext: $objs $deps
         \$(RM) $bin$exeext
         \$(MAKE) -f \$(SRCDIR)/Makefile.shared -e \\
-               PERL=\$(PERL) SRCDIR=\$(SRCDIR) \\
+               PERL="\$(PERL)" SRCDIR=\$(SRCDIR) \\
                 APPNAME=$bin$exeext OBJECTS="$objs" \\
                 LIBDEPS='\$(PLIB_LDFLAGS) '"$linklibs"' \$(EX_LIBS)' \\
                 CC='\$(CC)' CFLAGS='\$(CFLAGS) \$(BIN_CFLAGS)' \\

I haven't checked for other platform files though.

Regards,

Rainer

From rt at openssl.org  Tue May 10 14:56:16 2016
From: rt at openssl.org (Rainer Jung via RT)
Date: Tue, 10 May 2016 14:56:16 +0000
Subject: [openssl-dev] [openssl.org #4311] OpenSSL 1.1.0-pre3: quote
	PERL=$(PERL) in Makefiles
In-Reply-To: <8c38ec6c-080b-9060-17ab-d1519339c2e4@kippdata.de>
References: <RT-Ticket-4311@openssl.org> <56C36B8A.50507@kippdata.de>
 <rt-4.0.19-5500-1462886302-337.4311-6-0@openssl.org>
 <rt-4.0.19-5500-1462886957-1375.4311-6-0@openssl.org>
 <8c38ec6c-080b-9060-17ab-d1519339c2e4@kippdata.de>
Message-ID: <rt-4.0.19-5500-1462892176-1199.4311-6-0@openssl.org>

Am 10.05.2016 um 15:29 schrieb Richard Levitte via RT:
> On Tue May 10 13:18:22 2016, matt wrote:
>> Makefile.in doesn't exist any more. Ping Richard Levitte - does
>> anything need
>> to be done for the new build system?
>
> The run_tests.pl line in Configurations/unix-Makefile.tmpl would still need
> that change...
>
> ... but I don't quite understand the background story. What you end up with is
> perl calls like this:
>
> /usr/bin/env perl ... blah ...
>
> and the difference between that and this is nil:
>
> perl ... blah ...

No, this is about lines which set the PERL shell variable from the 
Makefile variable and then run a command on the same line, e.g.

PERL=$(PERL) /path/to/something

Now if the Makefile variable PERL is set to

PERL=/usr/bin/env perl

without quotes the shell command resolves to:

PERL=/usr/bin/env perl /path/to/something

so we call perl with argument /path/to/something and environment 
variable PERL set to /usr/bin/env.

With quotes it is

PERL="/usr/bin/env perl" /path/to/something

so we call /path/to/something with PERL env var set to "/usr/bin/env perl".

Currently (1.1.0pre5) I patch only one file before building, the 
unix-Makefile.tmpl file:

--- ./Configurations/unix-Makefile.tmpl.orig    2016-04-19 
18:51:16.000000000 +0200
+++ ./Configurations/unix-Makefile.tmpl 2016-04-19 19:39:11.000000000 +0200
@@ -231,7 +231,7 @@
         @ : {- output_on() if !$disabled{tests}; "" -}

  list-tests:
-       @TOP=$(SRCDIR) PERL=$(PERL) $(PERL) $(SRCDIR)/test/run_tests.pl list
+       @TOP=$(SRCDIR) PERL="$(PERL)" $(PERL) 
$(SRCDIR)/test/run_tests.pl list

  libclean:
         @set -e; for s in $(SHLIB_INFO); do \
@@ -939,7 +939,7 @@
  $target: $lib$libext $deps $ordinalsfile
         \$(MAKE) -f \$(SRCDIR)/Makefile.shared -e \\
                 PLATFORM=\$(PLATFORM) \\
-               PERL=\$(PERL) SRCDIR='\$(SRCDIR)' DSTDIR="$libd" \\
+               PERL="\$(PERL)" SRCDIR='\$(SRCDIR)' DSTDIR="$libd" \\
                 INSTALLTOP='\$(INSTALLTOP)' LIBDIR='\$(LIBDIR)' \\
                 LIBDEPS='\$(PLIB_LDFLAGS) '"$linklibs"' \$(EX_LIBS)' \\
                 LIBNAME=$libname 
LIBVERSION=\$(SHLIB_MAJOR).\$(SHLIB_MINOR) \\
@@ -975,7 +975,7 @@
  $target: $objs $deps
         \$(MAKE) -f \$(SRCDIR)/Makefile.shared -e \\
                 PLATFORM=\$(PLATFORM) \\
-               PERL=\$(PERL) SRCDIR='\$(SRCDIR)' DSTDIR="$libd" \\
+               PERL="\$(PERL)" SRCDIR='\$(SRCDIR)' DSTDIR="$libd" \\
                 LIBDEPS='\$(PLIB_LDFLAGS) '"$shlibdeps"' \$(EX_LIBS)' \\
                 LIBNAME=$libname LDFLAGS='\$(LDFLAGS)' \\
                 CC='\$(CC)' CFLAGS='\$(CFLAGS) \$(DSO_CFLAGS)' \\
@@ -1012,7 +1012,7 @@
  $bin$exeext: $objs $deps
         \$(RM) $bin$exeext
         \$(MAKE) -f \$(SRCDIR)/Makefile.shared -e \\
-               PERL=\$(PERL) SRCDIR=\$(SRCDIR) \\
+               PERL="\$(PERL)" SRCDIR=\$(SRCDIR) \\
                 APPNAME=$bin$exeext OBJECTS="$objs" \\
                 LIBDEPS='\$(PLIB_LDFLAGS) '"$linklibs"' \$(EX_LIBS)' \\
                 CC='\$(CC)' CFLAGS='\$(CFLAGS) \$(BIN_CFLAGS)' \\

I haven't checked for other platform files though.

Regards,

Rainer


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


From rt at openssl.org  Tue May 10 15:00:22 2016
From: rt at openssl.org (Stephen Henson via RT)
Date: Tue, 10 May 2016 15:00:22 +0000
Subject: [openssl-dev] [openssl.org #4173] help to check whether handshake
	negociates SRP or PSK ciphersuite
In-Reply-To: <003401d13104$78233ae0$6869b0a0$@sales@free.fr>
References: <RT-Ticket-4173@openssl.org>
 <003401d13104$78233ae0$6869b0a0$@sales@free.fr>
Message-ID: <rt-4.0.19-5500-1462892422-809.4173-6-0@openssl.org>

This is now supported in the master branch with the SSL_CIPHER_get_auth_nid()
function.

The equivalent cannot be added to 1.0.2 as we do not add new features to stable
branches.

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=4173
Please log in as guest with password guest if prompted


From rt at openssl.org  Tue May 10 15:07:33 2016
From: rt at openssl.org (Matt Caswell via RT)
Date: Tue, 10 May 2016 15:07:33 +0000
Subject: [openssl-dev] [openssl.org #4494] Fix: check the FD_SETSIZE before
	the call to select() in speed.c
In-Reply-To: <02DF9A39E1EE92419A8C5BBE62973A231A4B1FE6@IRSMSX108.ger.corp.intel.com>
References: <RT-Ticket-4494@openssl.org>
 <02DF9A39E1EE92419A8C5BBE62973A231A4B1FE6@IRSMSX108.ger.corp.intel.com>
Message-ID: <rt-4.0.19-5499-1462892852-762.4494-6-0@openssl.org>

The referenced pull request was merged.

Closing.

Matt

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


From rt at openssl.org  Tue May 10 15:09:11 2016
From: rt at openssl.org (Matt Caswell via RT)
Date: Tue, 10 May 2016 15:09:11 +0000
Subject: [openssl-dev] [openssl.org #4497] openssl ciphers app possible bug
In-Reply-To: <DUB112-W955BB168E0E9359C2CC736E4980@phx.gbl>
References: <RT-Ticket-4497@openssl.org>
 <DUB112-W955BB168E0E9359C2CC736E4980@phx.gbl>
Message-ID: <rt-4.0.19-5499-1462892951-1574.4497-6-0@openssl.org>

Not a bug.

Closing.

Matt

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


From rt at openssl.org  Tue May 10 15:09:50 2016
From: rt at openssl.org (Matt Caswell via RT)
Date: Tue, 10 May 2016 15:09:50 +0000
Subject: [openssl-dev] [openssl.org #4499] ARM32 and "undefined reference to
	`engine_load_afalg_internal'"
In-Reply-To: <CAH8yC8=Ja2B46MigmE9SAmJBkL1ym1hw1_iH3TUBTVjwe=vkfA@mail.gmail.com>
References: <RT-Ticket-4499@openssl.org>
 <CAH8yC8=Ja2B46MigmE9SAmJBkL1ym1hw1_iH3TUBTVjwe=vkfA@mail.gmail.com>
Message-ID: <rt-4.0.19-5500-1462892990-626.4499-6-0@openssl.org>

No response from OP. Assuming fixed.

Closing.

Matt

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


From rt at openssl.org  Tue May 10 15:12:56 2016
From: rt at openssl.org (Matt Caswell via RT)
Date: Tue, 10 May 2016 15:12:56 +0000
Subject: [openssl-dev] [openssl.org #4510] SSL certificate problem: unable
	to get local issuer certificate. Bug?
In-Reply-To: <CALC5Oe=Jx82z7yN0cOrThAae9FXKRV_SngCLvjQZbFj31oP1VQ@mail.gmail.com>
References: <RT-Ticket-4510@openssl.org>
 <CALC5Oe=Jx82z7yN0cOrThAae9FXKRV_SngCLvjQZbFj31oP1VQ@mail.gmail.com>
Message-ID: <rt-4.0.19-5499-1462893176-282.4510-6-0@openssl.org>

Does not appear to be an OpenSSL bug.

Closing.

Matt

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


From rt at openssl.org  Tue May 10 15:53:42 2016
From: rt at openssl.org (Stephen Henson via RT)
Date: Tue, 10 May 2016 15:53:42 +0000
Subject: [openssl-dev] [openssl.org #4538] Possible typo on
	https://www.openssl.org/docs/manmaster/apps/x509v3_config.html
In-Reply-To: <CALbgBj_kW=TdpjX1YQfXvLtydRVMjkMJ5GRELmm0YFviS-VHgQ@mail.gmail.com>
References: <RT-Ticket-4538@openssl.org>
 <CALbgBj_kW=TdpjX1YQfXvLtydRVMjkMJ5GRELmm0YFviS-VHgQ@mail.gmail.com>
Message-ID: <rt-4.0.19-5499-1462895622-1274.4538-6-0@openssl.org>

Fixed now, 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=4538
Please log in as guest with password guest if prompted


From rt at openssl.org  Tue May 10 16:24:46 2016
From: rt at openssl.org (Michel via RT)
Date: Tue, 10 May 2016 16:24:46 +0000
Subject: [openssl-dev] [openssl.org #4173] help to check whether
	handshake negociates SRP or PSK ciphersuite
In-Reply-To: <002201d1aad8$6b07b4a0$41171de0$@sales@free.fr>
References: <RT-Ticket-4173@openssl.org>
 <003401d13104$78233ae0$6869b0a0$@sales@free.fr>
 <rt-4.0.19-5500-1462892422-809.4173-6-0@openssl.org>
 <002201d1aad8$6b07b4a0$41171de0$@sales@free.fr>
Message-ID: <rt-4.0.19-5500-1462897486-1287.4173-6-0@openssl.org>

Cool !

Many thanks  Steve.

-----Message d'origine-----
De : Stephen Henson via RT [mailto:rt at openssl.org] 
Envoy? : mardi 10 mai 2016 17:00
? : michel.sales at free.fr
Cc : openssl-dev at openssl.org
Objet : [openssl.org #4173] help to check whether handshake negociates SRP or PSK ciphersuite

This is now supported in the master branch with the SSL_CIPHER_get_auth_nid() function.

The equivalent cannot be added to 1.0.2 as we do not add new features to stable branches.

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=4173
Please log in as guest with password guest if prompted


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


From raji.kotamraju at gmail.com  Tue May 10 17:34:18 2016
From: raji.kotamraju at gmail.com (Rajeswari K)
Date: Tue, 10 May 2016 23:04:18 +0530
Subject: [openssl-dev] DTLS session resumption with DTLS_ANY_VERSION
Message-ID: <CA+mfXPFV6BaM4bTYf8oM7kHJhH3N2WRrKo0py-rbYsJEm2GJnw@mail.gmail.com>

Hello openssl-dev team,

Having query regarding DTLS session resumption when configured SSL_CTX with
DTLS_ANY_VERSION.

When we select SSL_CTX with DTLS_ANY_VERSION, method will be of
DTLS_Server_method(), which will have ssl_ctx->version as 0xFEFD to support
both the versions (i.e. DTLS1.0 and DTLS1.2).

During handshake, we landed on to version DTLS1.0.i.e. s->session->version
holds 0xFEFF.

In order to perform session resumption, we derived new SSL structure from
global ssl_ctx using SSL_new() and tried performing ssl handshake.

With the below logic,
else {
        i = ssl_get_prev_session(s, p, j, d + n);
        /*
         * Only resume if the session's version matches the negotiated
         * version.
         * RFC 5246 does not provide much useful advice on resumption
         * with a different protocol version. It doesn't forbid it but
         * the sanity of such behaviour would be questionable.
         * In practice, clients do not accept a version mismatch and
         * will abort the handshake with an error.
         */
        if (i == 1 && s->version == s->session->ssl_version) { /* previous
                                                                * session */
            s->hit = 1;
        } else if (i == -1)
            goto err;
        else {                  /* i == 0 */

            if (!ssl_get_new_session(s, 1))
                goto err;
        }

Since s->version is with 0xFEFD and s->session->ssl_version is 0xFEFF, we
always try for new session and wont land on to session resumption though
client has sent the  session_id.

Is this intended behaviour? Please clarify.

Thanks,
Rajeswari.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20160510/09588982/attachment.html>

From rt at openssl.org  Tue May 10 17:43:43 2016
From: rt at openssl.org (Rich Salz via RT)
Date: Tue, 10 May 2016 17:43:43 +0000
Subject: [openssl-dev] [openssl.org #4407] avoid double-free in callers to
	OCSP_parse_url
In-Reply-To: <D3060DC4.143C67%jbasney@illinois.edu>
References: <RT-Ticket-4407@openssl.org> <D3060DC4.143C67%jbasney@illinois.edu>
Message-ID: <rt-4.0.19-5499-1462902223-819.4407-6-0@openssl.org>

fixed in master and 1.0.2, closing. THANKS!

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


From rt at openssl.org  Tue May 10 19:37:49 2016
From: rt at openssl.org (Richard Levitte via RT)
Date: Tue, 10 May 2016 19:37:49 +0000
Subject: [openssl-dev] [openssl.org #4418] Apple configuration delay does
	not respond to Ctrl-C, proceeds with configuration
In-Reply-To: <rt-4.0.19-5499-1462890559-1061.4418-6-0@openssl.org>
References: <RT-Ticket-4418@openssl.org>
 <CAH8yC8nCUQ2hzDuJC5t9eNKXy7YON7aakUPZ=FSt2uSd=aXmrg@mail.gmail.com>
 <rt-4.0.19-5499-1462890559-1061.4418-6-0@openssl.org>
Message-ID: <rt-4.0.19-5499-1462909069-1714.4418-6-0@openssl.org>

On Tue May 10 14:29:19 2016, matt wrote:
> Ping Richard Levitte. Can this be closed?

Yes, it was fixed with commit a87c159f19e998bba660ceba9d01c5fc58bfa60b.

Closing now.

--
Richard Levitte
levitte at openssl.org

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


From rt at openssl.org  Tue May 10 19:44:33 2016
From: rt at openssl.org (Richard Levitte via RT)
Date: Tue, 10 May 2016 19:44:33 +0000
Subject: [openssl-dev] [openssl.org #4456] Fedora 1,
	i386: error: field `next_timeout` has incomplete type
In-Reply-To: <rt-4.0.19-1914-1458519077-206.4456-6-0@openssl.org>
References: <RT-Ticket-4456@openssl.org>
 <CAH8yC8nYG+fSJktLqgkKtgDyFk0Os=UiP52WmcnkYSCyxs-RSw@mail.gmail.com>
 <rt-4.0.19-1915-1458477111-1447.4456-21-0@openssl.org>
 <20160320.194548.286469873540532506.levitte@openssl.org>
 <rt-4.0.19-1914-1458499557-1787.4456-6-0@openssl.org>
 <CAH8yC8ny2RudD29h3UQwSWEfPM6wSAjDpgcAyx7d9f_AktF+4w@mail.gmail.com>
 <rt-4.0.19-1914-1458519077-206.4456-6-0@openssl.org>
Message-ID: <rt-4.0.19-5499-1462909473-488.4456-6-0@openssl.org>

On Mon Mar 21 00:11:17 2016, noloader at gmail.com wrote:
> On Sun, Mar 20, 2016 at 2:45 PM, Richard Levitte via RT
> <rt at openssl.org> wrote:
> > '#include <sys/time.h>' should be added in e_os.h rather than
> > ssl/ssl_locl.h
> >
>
> Thanks.
>
> Would it be possible to add <sys/time.h>, <sys/select.h>, and
> <strings.h>? Then all these tickets can be closed.
>
> It should also allow moving onto Android testing. Android, Cygwin and
> early Fedora seem to have similar personalities, and they often
> complain about the same headers.

Jeff, would you mind checking again with a fresh master? I *think* this should
be resolved by now, but can't tell for sure.

--
Richard Levitte
levitte at openssl.org

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


From rt at openssl.org  Tue May 10 19:54:49 2016
From: rt at openssl.org (Richard Levitte via RT)
Date: Tue, 10 May 2016 19:54:49 +0000
Subject: [openssl-dev] [openssl.org #4311] OpenSSL 1.1.0-pre3: quote
	PERL=$(PERL) in Makefiles
In-Reply-To: <rt-4.0.19-5500-1462892176-947.4311-6-0@openssl.org>
References: <RT-Ticket-4311@openssl.org> <56C36B8A.50507@kippdata.de>
 <rt-4.0.19-5500-1462886302-337.4311-6-0@openssl.org>
 <rt-4.0.19-5500-1462886957-1375.4311-6-0@openssl.org>
 <8c38ec6c-080b-9060-17ab-d1519339c2e4@kippdata.de>
 <rt-4.0.19-5500-1462892176-947.4311-6-0@openssl.org>
Message-ID: <rt-4.0.19-18545-1462910089-1637.4311-6-0@openssl.org>

On Tue May 10 14:56:16 2016, rainer.jung at kippdata.de wrote:
> Am 10.05.2016 um 15:29 schrieb Richard Levitte via RT:
> > On Tue May 10 13:18:22 2016, matt wrote:
> >> Makefile.in doesn't exist any more. Ping Richard Levitte - does
> >> anything need
> >> to be done for the new build system?
> >
> > The run_tests.pl line in Configurations/unix-Makefile.tmpl would
> > still need
> > that change...
> >
> > ... but I don't quite understand the background story. What you end
> > up with is
> > perl calls like this:
> >
> > /usr/bin/env perl ... blah ...
> >
> > and the difference between that and this is nil:
> >
> > perl ... blah ...
>
> No, this is about lines which set the PERL shell variable from the
> Makefile variable and then run a command on the same line, e.g.
>
> PERL=$(PERL) /path/to/something
>
> Now if the Makefile variable PERL is set to
>
> PERL=/usr/bin/env perl

I understand this part. What I'm questioning is the need to set PERL to
"/usr/bin/env perl" to begin with. It's practically not different at all from
setting it to just "perl", all this does is that any time the environment
variable PERL is used to run a perl script is to have an extra process between
the shell and perl itself that will simply pass along the exact environment
that it got from the shell. In effect, any time the environment variable PERL
with your assignment is used to run a script (assuming the quoting you
suggest), i.e.:

$PERL blah.pl

it would expand to this:

/usr/bin/env perl blah.pl

If it's only assigned "perl", the command would expand to this:

perl blah.pl

perl itself literally gets the exact same environment in both cases.

Mind you, I did read your reasoning around #! in scripts. Unfortunately, that
reasoning is flawed, that won't be affected by the environment variable PERL.

Cheers,
Richard

--
Richard Levitte
levitte at openssl.org

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


From rt at openssl.org  Tue May 10 20:22:07 2016
From: rt at openssl.org (Richard Levitte via RT)
Date: Tue, 10 May 2016 20:22:07 +0000
Subject: [openssl-dev] [openssl.org #4255] OpenSSL-1.1.0-pre2 failures using
	MinGW-W64
In-Reply-To: <rt-4.0.19-5499-1462892263-544.4255-6-0@openssl.org>
References: <RT-Ticket-4255@openssl.org>
 <1453060954.186021958.y9vnrjtk@frv39.fwdcdn.com>
 <rt-4.0.19-5500-1462883800-449.4255-6-0@openssl.org>
 <rt-4.0.19-5500-1462886039-340.4255-6-0@openssl.org>
 <1462891086.517874430.c1bydlty@frv39.fwdcdn.com>
 <rt-4.0.19-5499-1462892263-544.4255-6-0@openssl.org>
Message-ID: <rt-4.0.19-5499-1462911727-1073.4255-6-0@openssl.org>

On Tue May 10 14:57:43 2016, sav_ix at ukr.net wrote:
>
> Hi, Everyone
>
> Updates sources from master branch and made OpenSSL build and test
> using command:
> (./Configure --prefix="$PWD/../GCC64r" -std=gnu11 -mtune=native
> -march=native threads no-deprecated shared mingw64 >_Configure.log &&
> make -j
> $NUMBER_OF_PROCESSORS >_make.log && make -j$NUMBER_OF_PROCESSORS
> install >_install.log) 2>_stderr.log && HARNESS_VERBOSE=yes make test
> >_test.log 2>&1
>
> Logs added in attachment.
>
> On some stage of OpenSSL testsuite run, process
> C:\libOPENSSL-1.1.0-dev\src\apps\openssl.exe s_server -no_comp -rev
> -engine ossltest -accept 4443 -cert ../apps/server.pem -naccept 1
> -cipher AES128-SHA
> stop respond over 5 minutes and was terminated manually.
>
> Same repeated a bit later with processes
> C:\libOPENSSL-1.1.0-dev\src\apps\openssl.exe s_client -engine ossltest
> -connect 127.0.0.1:4453 -4
> C:\libOPENSSL-1.1.0-dev\src\apps\openssl.exe s_client -engine ossltest
> -connect [::1]:4453 -6
> After their termination OpenSSL testsuite stop execution.
>
> Could you tell, whether this errors reproduced on other Windows
> systems? (mean not using cross-compilation or Wine)

Ah, I see that it's the tests based on TLSProxy that are troublesome... we have
seen this before, and I can't remember if this was resolved.

Matt, I think this is more your department....

--
Richard Levitte
levitte at openssl.org

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


From rt at openssl.org  Tue May 10 20:29:51 2016
From: rt at openssl.org (Richard Levitte via RT)
Date: Tue, 10 May 2016 20:29:51 +0000
Subject: [openssl-dev] [openssl.org #4324] openssl-1.1.0-pre3 with
	solaris-x86-cc & solaris64-x86_64-cc make fails
In-Reply-To: <rt-4.0.19-3310-1456410990-592.4324-6-0@openssl.org>
References: <RT-Ticket-4324@openssl.org>
 <521557.3312.qm@web101212.mail.kks.yahoo.co.jp>
 <845222.20757.qm@web101214.mail.kks.yahoo.co.jp>
 <rt-4.0.19-3310-1456410990-592.4324-6-0@openssl.org>
Message-ID: <rt-4.0.19-18545-1462912191-1476.4324-6-0@openssl.org>

Hi,

Sorry for taking so long to get back to you.

Would you mind trying again with a fresh master, or with the latest beta? Quite
a lot has happened, especially in Makefile.shared and exactly around the stuff
you have reported, so I'm hopeful things will work better for you now.

Cheers,
Richard

On Thu Feb 25 14:36:30 2016, yoi_no_myoujou at yahoo.co.jp wrote:
> With the following patch,
> % ./Configure --unified solaris-x86-cc
> % make
> % make test
> passed.
>
> % ./Configure --unifiedsolaris64-x86_64-cc; make; make test
> also passed.
>
>
> This patch was written comparing to openssl-1.0.2f.
>
> It has side effect for other configurations.
> Please add some conditions.
>
>
> diff -cr ../openssl-1.1.0-pre3.orig/Makefile.shared ./Makefile.shared
> *** ../openssl-1.1.0-pre3.orig/Makefile.shared 2016-02-16
> 03:08:07.000000000 +0900
> --- ./Makefile.shared 2016-02-25 22:57:23.347187336 +0900
> ***************
> *** 398,409 ****
> ($(CC) -v 2>&1 | grep gcc) > /dev/null && MINUSZ='-Wl,-z,'; \
> SHLIB=lib$(LIBNAME).so; \
> SHLIB_SUFFIX=;\
> ! if [ $(LIBNAME) != "crypto" -a $(LIBNAME) != "ssl" ]; then \
> ALLSYMSFLAGS="$${MINUSZ}allextract"; \
> ! else \
> ! $(PERL) $(SRCDIR)/util/mkdef.pl $(LIBNAME) linux
> >$(LIBNAME).map; \
> ! ALLSYMSFLAGS="$${MINUSZ}allextract,-M,$(LIBNAME).map"; \
> ! fi; \
> NOALLSYMSFLAGS="$${MINUSZ}defaultextract"; \
> SHAREDFLAGS="$(CFLAGS) $(SHARED_LDFLAGS) -h
> $$SHLIB$$SHLIB_SOVER$$SHLIB_SUFFIX -Wl,-Bsymbolic"; \
> fi; \
> --- 398,409 ----
> ($(CC) -v 2>&1 | grep gcc) > /dev/null && MINUSZ='-Wl,-z,'; \
> SHLIB=lib$(LIBNAME).so; \
> SHLIB_SUFFIX=;\
> ! # if [ $(LIBNAME) != "crypto" -a $(LIBNAME) != "ssl" ]; then \
> ALLSYMSFLAGS="$${MINUSZ}allextract"; \
> ! # else \
> ! # $(PERL) $(SRCDIR)/util/mkdef.pl $(LIBNAME) linux
> >$(LIBNAME).map; \
> ! # ALLSYMSFLAGS="$${MINUSZ}allextract,-M,$(LIBNAME).map"; \
> ! # fi; \
> NOALLSYMSFLAGS="$${MINUSZ}defaultextract"; \
> SHAREDFLAGS="$(CFLAGS) $(SHARED_LDFLAGS) -h
> $$SHLIB$$SHLIB_SOVER$$SHLIB_SUFFIX -Wl,-Bsymbolic"; \
> fi; \


--
Richard Levitte
levitte at openssl.org

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


From rt at openssl.org  Tue May 10 20:33:47 2016
From: rt at openssl.org (Richard Levitte via RT)
Date: Tue, 10 May 2016 20:33:47 +0000
Subject: [openssl-dev] [openssl.org #4345] Bug - Cannot build
	openssl-1.1.0-pre4-dev on NetBSD 6_Stable
In-Reply-To: <4c16b2491b878e183f594c75f801f5bf.squirrel@wm.sdf.org>
References: <RT-Ticket-4345@openssl.org>
 <4c16b2491b878e183f594c75f801f5bf.squirrel@wm.sdf.org>
Message-ID: <rt-4.0.19-18545-1462912427-976.4345-6-0@openssl.org>

Hey,

would you mind trying the latest beta, or a fresh master checkout? I can't know
for sure, but it's possible you'll get better results now. If not, I'm all
ears.

Cheers,
Richard


On Thu Feb 25 13:13:41 2016, yancm at SDF.ORG wrote:
> The first parts of this report are the actual build bug I think I am
> encountering, but also, at the end, I am asking for additional help with
> enabling the crypto-mdebug and crypto-mdebug-backtrace as I am trying to
> to diagnose a compatibility issue between tor and the openssl 1.1.0_dev
> branch.
>
> config and output:
> *****Config command and output*****
> # ./config --unified --debug --api=1.1.0 no-shared
> Operating system: i686-whatever-netbsd
> Configuring for BSD-x86-elf
> Configuring OpenSSL version 1.1.0-pre4-dev (0x0x10100004L)
> no-crypto-mdebug [default] OPENSSL_NO_CRYPTO_MDEBUG (skip dir)
> no-crypto-mdebug-backtrace [forced]
> 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-heartbeats [default] OPENSSL_NO_HEARTBEATS (skip dir)
> no-md2 [default] OPENSSL_NO_MD2 (skip dir)
> no-rc5 [default] OPENSSL_NO_RC5 (skip dir)
> no-sctp [default] OPENSSL_NO_SCTP (skip dir)
> no-shared [option]
> no-ssl-trace [default] OPENSSL_NO_SSL_TRACE (skip dir)
> no-static-engine [default] OPENSSL_NO_STATIC_ENGINE (skip dir)
> no-unit-test [default] OPENSSL_NO_UNIT_TEST (skip dir)
> no-zlib [default]
> no-zlib-dynamic [forced]
> Configuring for BSD-x86-elf
> IsMK1MF =no
> CC =cc
> CFLAG = -pthread -D_THREAD_SAFE -D_REENTRANT -DL_ENDIAN -Wall -O0
> -g -DWHIRLPOOL_ASM -Wa,--noexecstack
> DEFINES =DSO_DLFCN HAVE_DLFCN_H OPENSSL_THREADS
> OPENSSL_NO_STATIC_ENGINE OPENSSL_PIC OPENSSL_BN_ASM_PART_WORDS
> OPENSSL_IA32_SSE2 OPENSSL_BN_ASM_MONT OPENSSL_BN_ASM_GF2m SHA1_ASM
> SHA256_ASM SHA512_ASM MD5_ASM RMD160_ASM AES_ASM VPAES_ASM GHASH_ASM
> ECP_NISTZ256_ASM POLY1305_ASM OPENSSL_API_COMPAT=0x10100000L
> LFLAG =
> PLIB_LFLAG =
> EX_LIBS =
> CPUID_OBJ =x86cpuid.o
> BN_ASM =bn-586.o co-586.o x86-mont.o x86-gf2m.o
> EC_ASM =ecp_nistz256.o ecp_nistz256-x86.o
> DES_ENC =des-586.o crypt586.o
> AES_ENC =aes-586.o vpaes-x86.o aesni-x86.o
> BF_ENC =bf-586.o
> CAST_ENC =c_enc.o
> RC4_ENC =rc4-586.o
> RC5_ENC =rc5-586.o
> MD5_OBJ_ASM =md5-586.o
> SHA1_OBJ_ASM =sha1-586.o sha256-586.o sha512-586.o
> RMD160_OBJ_ASM=rmd-586.o
> CMLL_ENC =cmll-x86.o
> MODES_OBJ =ghash-x86.o
> PADLOCK_OBJ =e_padlock-x86.o
> CHACHA_ENC =chacha-x86.o
> POLY1305_OBJ =poly1305-x86.o
> PROCESSOR =
> RANLIB =/usr/bin/ranlib
> ARFLAGS =
> PERL =/usr/pkg/bin/perl
>
> THIRTY_TWO_BIT mode
> BN_LLONG mode
>
> Configured for BSD-x86-elf.
> ***************************************
>
> if I gmake at the top level, the build proceeds for a while and appears to
> exit cleanly, but if I run gmake again, I get the following message:
> # gmake
> gmake: *** No rule to make target
> 'usr/include/stdio.husr/include/sys/cdefs.h', needed by 'apps/openssl'.
> Stop.
>
> ***************************************
> I have problems even if I turn off debug.
>
> I really want debug AND I think I need to enable crypto-mdebug and
> crypto-mdebug-backtrace so I can determine the calling line from tor that
> is crashing in openssl. The tor dev's think they have coded for
> compatibility with openssl 1.1.0_dev, but I cannot confirm this on my
> builds. I built tor with debug symbols, but so far, even if I set
> breakpoints at main() in tor, running tor in gdb appears to crash in
> openssl somewhere but I cannot execute a backtrace to see what line in tor
> is calling the openssl function that is failing. At the moment I cannot
> even build openssl. I've had this issue for a week or two...
>
>
>
>
>
>


--
Richard Levitte
levitte at openssl.org

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


From rt at openssl.org  Tue May 10 20:38:31 2016
From: rt at openssl.org (Richard Levitte via RT)
Date: Tue, 10 May 2016 20:38:31 +0000
Subject: [openssl-dev] [openssl.org #4399] OS X 10.8: Make clean is leaving
	build artifacts
In-Reply-To: <CAH8yC8=GoFtSVU7YSdTZxOEU2kCzs8p2qrAzLSyg2quGtmGQEw@mail.gmail.com>
References: <RT-Ticket-4399@openssl.org>
 <CAH8yC8=GoFtSVU7YSdTZxOEU2kCzs8p2qrAzLSyg2quGtmGQEw@mail.gmail.com>
Message-ID: <rt-4.0.19-18545-1462912711-50.4399-6-0@openssl.org>

On Tue Mar 08 17:41:40 2016, noloader at gmail.com wrote:
> $ KERNEL_BITS=64 ./config shared
> ...
> $ make depend && make clean && make
> ...
>
> $ make clean
> rm -f libcrypto.1.1.dylib
> rm -f libcrypto.dylib
> rm -f libssl.1.1.dylib
> rm -f libssl.dylib
> rm -f libcrypto.a libssl.a
> rm -f apps/openssl test/afalgtest test/asynctest test/bftest
> test/bntest test/casttest test/clienthellotest test/constant_time_test
> test/ct_test test/danetest test/destest test/dhtest test/dsatest
> test/dtlsv1listentest test/ecdhtest test/ecdsatest test/ectest
> test/enginetest test/evp_extra_test test/evp_test test/exptest
> test/gmdifftest test/heartbeat_test test/hmactest test/ideatest
> test/igetest test/md2test test/md4test test/md5test test/mdc2test
> test/memleaktest test/nptest test/p5_crpt2_test test/packettest
> test/pbelutest test/randtest test/rc2test test/rc4test test/rc5test
> test/rmdtest test/rsa_test test/secmemtest test/sha1test test/sha256t
> test/sha512t test/srptest test/ssltest test/threadstest
> test/v3nametest test/verify_extra_test test/wp_test
> rm -f `find . -name '*.d'`
> rm -f `find . -name '*.o'`
> rm -f ./core
> rm -f ./tags ./TAGS
> rm -f ./openssl.pc ./libcrypto.pc ./libssl.pc
> rm -f `find . -type l`
> rm -f ../openssl-1.1.0-pre4-dev.tar
>
> $ find . -name *.dylib
> ./engines/capi.dylib
> ./engines/dasync.dylib
> ./engines/ossltest.dylib
> ./engines/padlock.dylib
>
> $ make distclean
> make: *** No rule to make target 'distclean'. Stop.
> $ make dclean
> make: *** No rule to make target 'dclean'. Stop.
>

This issue was resolved with commit 4c1cf7e4400daa47fd18c6321edb78fac636a994

Closing this ticket.

--
Richard Levitte
levitte at openssl.org

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


From rt at openssl.org  Tue May 10 20:48:33 2016
From: rt at openssl.org (Richard Levitte via RT)
Date: Tue, 10 May 2016 20:48:33 +0000
Subject: [openssl-dev] [openssl.org #4415] test/certs/mkcert.sh uses "#!
	/binbash"
In-Reply-To: <CAH8yC8=tOV+Hza=fV6JsK-GCh8zdRk8XVN1g_q0-W_K_2QCYnw@mail.gmail.com>
References: <RT-Ticket-4415@openssl.org>
 <CAH8yC8=tOV+Hza=fV6JsK-GCh8zdRk8XVN1g_q0-W_K_2QCYnw@mail.gmail.com>
Message-ID: <rt-4.0.19-5499-1462913313-1948.4415-6-0@openssl.org>

On Fri Mar 11 12:05:32 2016, noloader at gmail.com wrote:
> test/certs/mkcert.sh uses:
>
> #! /binbash"
>
> It does not work as expected on some platforms, like OpenBSD and
> FreeBSD where Bash is located in, say, /usr/local/bin or
> /usr/pkg/bin/bash.
>
> Instead, I believe you should use:
>
> #! /usr/bin/env bash
>
> Another potential pain point is PERL:
>
> grep -iIR perl * | grep '#' | grep -v 'env' | wc -l
> 232

That's a large number.... if you grep for '#!' rather than '#', you get a more
accurate number

Anyhow, we have fixed the scripts that are for public use (they are generated
from a template). The rest are internal, and we adamantly call them with
explicit perl commands, like 'perl foo.pl'. In other words, this is a very low
priority.

Closing this ticket.

--
Richard Levitte
levitte at openssl.org

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


From openssl at roumenpetrov.info  Tue May 10 20:52:46 2016
From: openssl at roumenpetrov.info (Roumen Petrov)
Date: Tue, 10 May 2016 23:52:46 +0300
Subject: [openssl-dev] use of X.509 lookup methods,
 X509_OBJECT internal or opaque?
In-Reply-To: <4551491c54564abbb1adf251746867f6@usma1ex-dag1mb1.msg.corp.akamai.com>
References: <571B8D25.2030100@roumenpetrov.info>
 <0ceaba4b64d44e689f05225f480ba33f@usma1ex-dag1mb1.msg.corp.akamai.com>
 <790538e8524942339cede3107cb60d43@usma1ex-dag1mb1.msg.corp.akamai.com>
 <572DA7C0.6040706@roumenpetrov.info> <572DAB2C.1060000@roumenpetrov.info>
 <4551491c54564abbb1adf251746867f6@usma1ex-dag1mb1.msg.corp.akamai.com>
Message-ID: <57324A1E.1030200@roumenpetrov.info>

Hi Rich,

Salz, Rich wrote:
> Can you look at https://github.com/openssl/openssl/pull/1044 and see if it addresses the issues?
Yes.

May be with some definitions for backward compatibility. I mean for 
renamed pre 1.1 functions - with inserted  ..._CTX.... into name of :
- X509_STORE_get_by_subject
- X509_STOREget1_{certs|crls}

I understand idea of new function X509_STORE_CTX_get_X509_by_subject. 
X509 is misleading.
What about X509_STORE_CTX_get_obj_by_subject?

Regards,
Roumen



From rt at openssl.org  Tue May 10 20:57:57 2016
From: rt at openssl.org (Richard Levitte via RT)
Date: Tue, 10 May 2016 20:57:57 +0000
Subject: [openssl-dev] [openssl.org #4452] openssl-1.1.0-pre4: undefined
	symbol for solaris-x86-cc
In-Reply-To: <rt-4.0.19-19985-1458556925-1313.4452-6-0@openssl.org>
References: <RT-Ticket-4452@openssl.org>
 <747648.50843.qm@web101220.mail.kks.yahoo.co.jp>
 <rt-4.0.19-1915-1458424415-879.4452-6-0@openssl.org>
 <550057.6653.qm@web101214.mail.kks.yahoo.co.jp>
 <777156.81532.qm@web101215.mail.kks.yahoo.co.jp>
 <rt-4.0.19-19985-1458556925-1313.4452-6-0@openssl.org>
Message-ID: <rt-4.0.19-18545-1462913877-1156.4452-6-0@openssl.org>

Hi,

that looks like engines/asm/e_padlock_x86.o wasn't built for some reason, even
though it should.

I would like it if you gave me a full log, or in other words, send me build.log
after running this:

(set -x; ./Configure solaris-x86-cc shared; make) > build.log 2>&1

Cheers,
Richard

On Mon Mar 21 10:42:05 2016, yoi_no_myoujou at yahoo.co.jp wrote:
> % ../Configure solaris-x86-cc shared; make; make test
> also passes.
>
> Regards,
>
> --- Kiyoshi <yoi_no_myoujou at yahoo.co.jp>
>
>
>
>
>
> > Tried with openssl-SNAP-20160320,
> > but have the same result, not fixed yet.
> >
> >
> > Regards,
> >
> > --- Kiyoshi <yoi_no_myoujou at yahoo.co.jp>
> >
> >
> >
> >
> >> If you have the possibility, please try a fresh checkout of the master
> > branch
> >> and see if this is fixed.
> >>
> >> Cheers,
> >> Richard
> >>
> >> Vid Sat, 19 Mar 2016 kl. 10.55.59, skrev yoi_no_myoujou at yahoo.co.jp:
> >>> With patch for #4444,
> >>>
> >>> % mkdir build_solaris-x86-cc
> >>> % cd build_solaris-x86-cc
> >>> % ../Configure solaris-x86-cc
> >>> % make
> >>> :
> >>> Undefined first referenced
> >>> symbol in file
> >>> padlock_xstore ./libcrypto.a(e_padlock.o)
> >>> padlock_capability ./libcrypto.a(e_padlock.o)
> >>> padlock_reload_key ./libcrypto.a(e_padlock.o)
> >>> padlock_ctr32_encrypt ./libcrypto.a(e_padlock.o)
> >>> padlock_key_bswap ./libcrypto.a(e_padlock.o)
> >>> padlock_cbc_encrypt ./libcrypto.a(e_padlock.o)
> >>> padlock_cfb_encrypt ./libcrypto.a(e_padlock.o)
> >>> padlock_ecb_encrypt ./libcrypto.a(e_padlock.o)
> >>> padlock_ofb_encrypt ./libcrypto.a(e_padlock.o)
> >>> padlock_aes_block ./libcrypto.a(e_padlock.o)
> >>> ld: fatal: symbol referencing errors. No output written to
> > apps/openssl
> >>> ../Makefile.shared:186: recipe for target 'link_app.' failed
> >>> make[1]: *** [link_app.] Error 2
> >>>
> >>>
> >>> % ../Configure solaris-x86-cc no-asm
> >>>
> >>> % make
> >>> % make test
> >>> passes.
> >>>
> >>>
> >>> OS: Solaris10 x86/x64
> >>> cc: /opt/solarisstudio12.4/bin/cc
> >>>
> >>>
> >>> Best Regards,
> >>>
> >>> --- Kiyoshi <yoi_no_myoujou at yahoo.co.jp>
> >>>
> >>>
> >>
> >>
> >> --
> >> Richard Levitte
> >> levitte at openssl.org
> >>
> >> --
> >> Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4452
> >> Please log in as guest with password guest if prompted
> >>
> >
>


--
Richard Levitte
levitte at openssl.org

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


From rt at openssl.org  Tue May 10 21:01:49 2016
From: rt at openssl.org (Richard Levitte via RT)
Date: Tue, 10 May 2016 21:01:49 +0000
Subject: [openssl-dev] [openssl.org #4453] openssl-1.1.0-pre4: make fails
	with 'wrong ELF class: ELFCLASS64' on solaris64-x86_64-cc
In-Reply-To: <173729.2988.qm@web101210.mail.kks.yahoo.co.jp>
References: <RT-Ticket-4453@openssl.org>
 <173729.2988.qm@web101210.mail.kks.yahoo.co.jp>
Message-ID: <rt-4.0.19-5499-1462914109-1337.4453-6-0@openssl.org>

Hi,

would you mind checking again with the latest beta or a fresh master checkout?
It looks to me like this issue is fixed, but I want to make sure.

Cheers,
Richard

On Sat Mar 19 10:56:00 2016, yoi_no_myoujou at yahoo.co.jp wrote:
> Hello,
>
> Tested with patch for #4444, and removing gcc from path.
>
> % ./config
> Operating system: i86pc-whatever-solaris2
> Configuring for solaris64-x86_64-cc
> Configuring OpenSSL version 1.1.0-pre4 (0x0x10100004L)
> no-crypto-mdebug [default] OPENSSL_NO_CRYPTO_MDEBUG (skip dir)
> no-crypto-mdebug-backtrace [forced]
> OPENSSL_NO_CRYPTO_MDEBUG_BACKTRACE (skip dir)
> no-dynamic-engine [forced]
> 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-heartbeats [default] OPENSSL_NO_HEARTBEATS (skip dir)
> no-md2 [default] OPENSSL_NO_MD2 (skip dir)
> no-rc5 [default] OPENSSL_NO_RC5 (skip dir)
> no-sctp [default] OPENSSL_NO_SCTP (skip dir)
> no-shared [default]
> 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-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 solaris64-x86_64-cc
> IsMK1MF =no
> CC =cc
> CFLAG =-xarch=generic64 -xstrconst -Xa -DL_ENDIAN -xO5
> -xdepend -xbuiltin -D_REENTRANT -DFILIO_H
> SHARED_CFLAG =-KPIC
> DEFINES =DSO_DLFCN HAVE_DLFCN_H OPENSSL_THREADS
> OPENSSL_NO_DYNAMIC_ENGINE OPENSSL_PIC OPENSSL_IA32_SSE2
> OPENSSL_BN_ASM_MONT OPENSSL_BN_ASM_MONT5 OPENSSL_BN_ASM_GF2m SHA1_ASM
> SHA256_ASM SHA512_ASM MD5_ASM AES_ASM VPAES_ASM BSAES_ASM GHASH_ASM
> ECP_NISTZ256_ASM POLY1305_ASM
> LFLAG =-mt
> PLIB_LFLAG =
> EX_LIBS =-lresolv -lsocket -lnsl -ldl -lpthread
> APPS_OBJ =
> CPUID_OBJ =x86_64cpuid.o
> UPLINK_OBJ =
> BN_ASM =asm/x86_64-gcc.o x86_64-mont.o x86_64-mont5.o x86_64-
> gf2m.o rsaz_exp.o rsaz-x86_64.o rsaz-avx2.o
> EC_ASM =ecp_nistz256.o ecp_nistz256-x86_64.o
> DES_ENC =des_enc.o fcrypt_b.o
> AES_ENC =aes-x86_64.o vpaes-x86_64.o bsaes-x86_64.o aesni-
> x86_64.o aesni-sha1-x86_64.o aesni-sha256-x86_64.o aesni-mb-x86_64.o
> BF_ENC =bf_enc.o
> CAST_ENC =c_enc.o
> RC4_ENC =rc4-x86_64.o rc4-md5-x86_64.o
> RC5_ENC =rc5_enc.o
> MD5_OBJ_ASM =md5-x86_64.o
> SHA1_OBJ_ASM =sha1-x86_64.o sha256-x86_64.o sha512-x86_64.o sha1-mb-
> x86_64.o sha256-mb-x86_64.o
> RMD160_OBJ_ASM=
> CMLL_ENC =cmll-x86_64.o cmll_misc.o
> MODES_OBJ =ghash-x86_64.o aesni-gcm-x86_64.o
> PADLOCK_OBJ =e_padlock-x86_64.o
> CHACHA_ENC =chacha-x86_64.o
> POLY1305_OBJ =poly1305-x86_64.o
> BLAKE2_OBJ =
> PROCESSOR =
> RANLIB =/usr/ccs/bin/ranlib
> ARFLAGS =
> PERL =/opt/perl5/bin/perl
>
> SIXTY_FOUR_BIT_LONG mode
>
> Configured for solaris64-x86_64-cc.
>
>
>
> % make
> :
> make[1]: Entering directory '/tmp/openssl-1.1.0-pre4'
> ( :; LIBDEPS="${LIBDEPS:--L. -lssl -L. -lcrypto -lresolv -lsocket
> -lnsl -ldl -lpthread }"; LDCMD="${LDCMD:-cc}"; LDFLAGS="${LDFLAGS:--
> DDSO_DLFCN -DHAVE_DLFCN_H -DOPENSSL_THREADS
> -DOPENSSL_NO_DYNAMIC_ENGINE -DOPENSSL_PIC -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 -DGHASH_ASM -DECP_NISTZ256_ASM -DPOLY1305_ASM
> -DOPENSSLDIR="\"/usr/local/ssl\""
> -DENGINESDIR="\"/usr/local/lib/engines\"" -xarch=generic64 -xstrconst
> -Xa -DL_ENDIAN -xO5 -xdepend -xbuiltin -D_REENTRANT -DFILIO_H -mt}";
> LIBPATH=`for x in $LIBDEPS; do echo $x; done | sed -e 's/^ *-L//;t' -e
> d | uniq`; LIBPATH=`echo $LIBPATH | sed -e 's/ /:/g'`; echo
> LD_LIBRARY_PATH=$LIBPATH:$LD_LIBRARY_PATH ${LDCMD} ${LDFLAGS} -o
> ${APPNAME:=apps/openssl} apps/app_rand.o apps/apps.o apps/asn1pars.o
> apps/ca.o apps/ciphers.o apps/cms.o apps/crl.o apps/crl2p7.o
> apps/dgst.o apps/dhparam.o
> apps/dsa.o apps/dsaparam.o apps/ec.o apps/ecparam.o apps/enc.o
> apps/engine.o apps/errstr.o apps/gendsa.o apps/genpkey.o apps/genrsa.o
> apps/nseq.o apps/ocsp.o apps/openssl.o apps/opt.o apps/passwd.o
> apps/pkcs12.o apps/pkcs7.o apps/pkcs8.o apps/pkey.o apps/pkeyparam.o
> apps/pkeyutl.o apps/prime.o apps/rand.o apps/rehash.o apps/req.o
> apps/rsa.o apps/rsautl.o apps/s_cb.o apps/s_client.o apps/s_server.o
> apps/s_socket.o apps/s_time.o apps/sess_id.o apps/smime.o apps/speed.o
> apps/spkac.o apps/srp.o apps/ts.o apps/verify.o apps/version.o
> apps/x509.o ${LIBDEPS}; LD_LIBRARY_PATH=$LIBPATH:$LD_LIBRARY_PATH
> ${LDCMD} ${LDFLAGS} -o ${APPNAME:=apps/openssl} apps/app_rand.o
> apps/apps.o apps/asn1pars.o apps/ca.o apps/ciphers.o apps/cms.o
> apps/crl.o apps/crl2p7.o apps/dgst.o apps/dhparam.o apps/dsa.o
> apps/dsaparam.o apps/ec.o apps/ecparam.o apps/enc.o apps/engine.o
> apps/errstr.o apps/gendsa.o apps/genpkey.o apps/genrsa.o apps/nseq.o
> apps/ocsp.o apps/openssl.o apps/opt.o
> apps/passwd.o apps/pkcs12.o apps/pkcs7.o apps/pkcs8.o apps/pkey.o
> apps/pkeyparam.o apps/pkeyutl.o apps/prime.o apps/rand.o apps/rehash.o
> apps/req.o apps/rsa.o apps/rsautl.o apps/s_cb.o apps/s_client.o
> apps/s_server.o apps/s_socket.o apps/s_time.o apps/sess_id.o
> apps/smime.o apps/speed.o apps/spkac.o apps/srp.o apps/ts.o
> apps/verify.o apps/version.o apps/x509.o ${LIBDEPS} )
>
LD_LIBRARY_PATH=.:/opt/openssl/lib:/opt/local/lib:/usr/local/lib:/opt/local/locale/lib:/opt/SUNWspro/lib:/usr/jdk/latest/lib:/opt/netpbm/lib:/usr/sfw/lib:/usr/lib:/usr/lib/iconv:/usr/lib/locale/ja:/opt/sfw/lib:/opt/sfw/netpbm/link:/usr/openwin/lib/locale/ja:/usr/openwin/lib/locale/common:/usr/openwin/lib:/usr/java/lib:/opt/coreutils/libexec/coreutils
> cc -mt -o apps/openssl apps/app_rand.o apps/apps.o apps/asn1pars.o
> apps/ca.o apps/ciphers.o apps/cms.o apps/crl.o apps/crl2p7.o
> apps/dgst.o apps/dhparam.o apps/dsa.o apps/dsaparam.o apps/ec.o
> apps/ecparam.o apps/enc.o apps/engine.o apps/errstr.o apps/gendsa.o
> apps/genpkey.o apps/genrsa.o apps/nseq.o apps/ocsp.o apps/openssl.o
> apps/opt.o apps/passwd.o apps/pkcs12.o apps/pkcs7.o apps/pkcs8.o
> apps/pkey.o apps/pkeyparam.o apps/pkeyutl.o apps/prime.o apps/rand.o
> apps/rehash.o apps/req.o apps/rsa.o apps/rsautl.o apps/s_cb.o
> apps/s_client.o apps/s_server.o apps/s_socket.o apps/s_time.o
> apps/sess_id.o apps/smime.o
> apps/speed.o apps/spkac.o apps/srp.o apps/ts.o apps/verify.o
> apps/version.o apps/x509.o -L. -lssl -L. -lcrypto -lresolv -lsocket
> -lnsl -ldl -lpthread
> ld: fatal: file apps/app_rand.o: wrong ELF class: ELFCLASS64
> ld: fatal: file processing errors. No output written to apps/openssl
> Makefile.shared:186: recipe for target 'link_app.' failed
> make[1]: *** [link_app.] Error 2
> make[1]: Leaving directory '/tmp/openssl-1.1.0-pre4'
> Makefile:8687: recipe for target 'apps/openssl' failed
> make: *** [apps/openssl] Error 2
>
>
> Patch for this:
> diff ../openssl-1.1.0-pre4.orig/Configurations/10-main.conf
> Configurations/10-main.conf
> 196c196
> < lflags => add(threads("-mt")),
> ---
> > lflags => add(threads("-mt -m64")),
>
>
> It seems to be better to change '-xarch=generic64' to '-m64' in line
> 196 & 201 of the same file, too.
>
>
> Best Regards,
>
> --- Kiyoshi <yoi_no_myoujou at yahoo.co.jp>


--
Richard Levitte
levitte at openssl.org

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


From rsalz at akamai.com  Tue May 10 21:05:29 2016
From: rsalz at akamai.com (Salz, Rich)
Date: Tue, 10 May 2016 21:05:29 +0000
Subject: [openssl-dev] use of X.509 lookup methods,
 X509_OBJECT internal or opaque?
In-Reply-To: <57324A1E.1030200@roumenpetrov.info>
References: <571B8D25.2030100@roumenpetrov.info>
 <0ceaba4b64d44e689f05225f480ba33f@usma1ex-dag1mb1.msg.corp.akamai.com>
 <790538e8524942339cede3107cb60d43@usma1ex-dag1mb1.msg.corp.akamai.com>
 <572DA7C0.6040706@roumenpetrov.info> <572DAB2C.1060000@roumenpetrov.info>
 <4551491c54564abbb1adf251746867f6@usma1ex-dag1mb1.msg.corp.akamai.com>
 <57324A1E.1030200@roumenpetrov.info>
Message-ID: <88325fac26054ff4bb1d7aaaf42b3210@usma1ex-dag1mb1.msg.corp.akamai.com>

> > Can you look at https://github.com/openssl/openssl/pull/1044 and see if it
> addresses the issues?
> Yes.

Great, thanks!
 
> May be with some definitions for backward compatibility. I mean for
> renamed pre 1.1 functions - with inserted  ..._CTX.... into name of :
> - X509_STORE_get_by_subject
> - X509_STOREget1_{certs|crls}

Added #define's for the old names.

> I understand idea of new function X509_STORE_CTX_get_X509_by_subject.
> X509 is misleading.
> What about X509_STORE_CTX_get_obj_by_subject?

That's better.

I pushed a new version that adds your feedback.

From rt at openssl.org  Tue May 10 21:06:55 2016
From: rt at openssl.org (Richard Levitte via RT)
Date: Tue, 10 May 2016 21:06:55 +0000
Subject: [openssl-dev] [openssl.org #4490] "nmake install" fails
	"Destination must be a directory at .\util\copy.pl line 39"
	on Windows with short pathname (no spaces)
In-Reply-To: <CAH8yC8m5OwQiwbPxBLiW5SSizKJqVpiDQ+dc=2hZuiYotbgLZA@mail.gmail.com>
References: <RT-Ticket-4490@openssl.org>
 <CAH8yC8m5OwQiwbPxBLiW5SSizKJqVpiDQ+dc=2hZuiYotbgLZA@mail.gmail.com>
Message-ID: <rt-4.0.19-18545-1462914415-1060.4490-6-0@openssl.org>

Fixed in commit 1697a81bafcc9a65012b62ba01c1661bf40e5edb

Closing ticket.

On Mon Mar 28 09:41:25 2016, noloader at gmail.com wrote:
> Working from Master at c5c7700c9a1c1daa.
>
> Strawberry PERL 5.22
> Windows XP x64 (as fully patched as it can be)
> Visual Studio 2005 (as fully patched as it can be)
> Source directory: C:\openssl-src
> Install directory: C:\OpenSSL
>
> **********
>
> C:\openssl-src>nmake install
>
> Microsoft (R) Program Maintenance Utility Version 8.00.50727.762
> Copyright (C) Microsoft Corporation. All rights reserved.
>
> *** Installing development files
> created directory `C:/Program Files/OpenSSL'
> created directory `C:/Program Files/OpenSSL/include'
> created directory `C:/Program Files/OpenSSL/include/openssl'
> Destination must be a directory at .\util\copy.pl line 39.
> NMAKE : fatal error U1077: 'perl' : return code '0x2'
> Stop.
>
> **********
>
> C:\openssl-src>perl Configure VC-WIN64A no-async
> --openssldir="C:\OpenSSL"
> Configuring OpenSSL version 1.1.0-pre5-dev (0x0x10100005L)
> no-async [option] OPENSSL_NO_ASYNC
> no-crypto-mdebug [default] OPENSSL_NO_CRYPTO_MDEBUG (skip dir)
> no-crypto-mdebug-backtrace [forced]
> OPENSSL_NO_CRYPTO_MDEBUG_BACKTRACE (sk
> ip dir)
> no-dynamic-engine [forced]
> 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-heartbeats [default] OPENSSL_NO_HEARTBEATS (skip dir)
> no-md2 [default] OPENSSL_NO_MD2 (skip dir)
> no-rc5 [default] OPENSSL_NO_RC5 (skip dir)
> no-sctp [default] OPENSSL_NO_SCTP (skip dir)
> no-shared [default]
> 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-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 VC-WIN64A
> CC =cl
> CFLAG =-W3 -wd4090 -Gs0 -GF -Gy -nologo -DOPENSSL_SYS_WIN32
> -DWIN32_LEAN
> _AND_MEAN -DL_ENDIAN -D_CRT_SECURE_NO_DEPRECATE -DUNICODE -D_UNICODE
> /MT /Ox /O2
> /Ob2
> SHARED_CFLAG =-D_WINDLL
> DEFINES =DSO_WIN32 OPENSSL_THREADS OPENSSL_NO_DYNAMIC_ENGINE
> OPENSSL_PIC O
> PENSSL_IA32_SSE2 OPENSSL_BN_ASM_MONT OPENSSL_BN_ASM_MONT5
> OPENSSL_BN_ASM_GF2m SH
> A1_ASM SHA256_ASM SHA512_ASM MD5_ASM AES_ASM VPAES_ASM BSAES_ASM
> GHASH_ASM ECP_N
> ISTZ256_ASM POLY1305_ASM
> LFLAG =/nologo /debug
> PLIB_LFLAG =
> EX_LIBS =ws2_32.lib gdi32.lib advapi32.lib crypt32.lib
> user32.lib
> APPS_OBJ =
> CPUID_OBJ =x86_64cpuid.o
> UPLINK_OBJ =
> BN_ASM =bn_asm.o x86_64-mont.o x86_64-mont5.o x86_64-gf2m.o
> rsaz_exp.o rs
> az-x86_64.o rsaz-avx2.o
> EC_ASM =ecp_nistz256.o ecp_nistz256-x86_64.o
> DES_ENC =des_enc.o fcrypt_b.o
> AES_ENC =aes-x86_64.o vpaes-x86_64.o bsaes-x86_64.o aesni-
> x86_64.o aesni-s
> ha1-x86_64.o aesni-sha256-x86_64.o aesni-mb-x86_64.o
> BF_ENC =bf_enc.o
> CAST_ENC =c_enc.o
> RC4_ENC =rc4-x86_64.o rc4-md5-x86_64.o
> RC5_ENC =rc5_enc.o
> MD5_OBJ_ASM =md5-x86_64.o
> SHA1_OBJ_ASM =sha1-x86_64.o sha256-x86_64.o sha512-x86_64.o sha1-mb-
> x86_64.o sh
> a256-mb-x86_64.o
> RMD160_OBJ_ASM=
> CMLL_ENC =cmll-x86_64.o cmll_misc.o
> MODES_OBJ =ghash-x86_64.o aesni-gcm-x86_64.o
> PADLOCK_OBJ =e_padlock-x86_64.o
> CHACHA_ENC =chacha-x86_64.o
> POLY1305_OBJ =poly1305-x86_64.o
> BLAKE2_OBJ =
> PROCESSOR =
> RANLIB =true
> ARFLAGS =/nologo
> PERL =perl
>
> SIXTY_FOUR_BIT mode
>
> Configured for VC-WIN64A.


--
Richard Levitte
levitte at openssl.org

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


From rt at openssl.org  Tue May 10 21:32:05 2016
From: rt at openssl.org (Richard Levitte via RT)
Date: Tue, 10 May 2016 21:32:05 +0000
Subject: [openssl-dev] [openssl.org #4356] 64-bit OS X on x86_64
	misidentified as i686
In-Reply-To: <CAH8yC8=AaaFN5cR1gc694Czeu863Mybcn1NQa1K63Q24mqytcg@mail.gmail.com>
References: <RT-Ticket-4356@openssl.org>
 <CAH8yC8=AaaFN5cR1gc694Czeu863Mybcn1NQa1K63Q24mqytcg@mail.gmail.com>
Message-ID: <rt-4.0.19-18545-1462915925-464.4356-6-0@openssl.org>

Hey

Would you mind having a look at https://github.com/openssl/openssl/pull/1053
and see if that makes things better?

Cheers,
Richard

On Sun Feb 28 22:11:56 2016, noloader at gmail.com wrote:
> Working from Master:
>
> $ git reset --hard HEAD && git pull
> HEAD is now at 31ba0e1 Fix mk1mf build
> Already up-to-date.
>
> MacBook Pro from 2013 (Intel, x86_64), OS X 10.8.5, fully patched:
>
> $ ./config
> Operating system: i686-apple-darwinDarwin Kernel Version 12.6.0: Wed
> Mar 18 16:23:48 PDT 2015; root:xnu-2050.48.19~1/RELEASE_X86_64
> WARNING! If you wish to build 64-bit library, then you have to
> invoke './Configure darwin64-x86_64-cc ' *manually*.
> You have about 5 seconds to press Ctrl-C to abort.
> ...
>
> This code from config seems to be responsible:
>
> Darwin:*)
> case "$MACHINE" in
> Power*)
> echo "ppc-apple-darwin${VERSION}"
> ;;
> *)
> echo "i686-apple-darwin${VERSION}"
> ;;
> esac
> exit 0
> ;;
>
> And:
>
> i?86-apple-darwin*)
> ISA64=`(sysctl -n hw.optional.x86_64) 2>/dev/null`
> if [ "$ISA64" = "1" -a -z "$KERNEL_BITS" ]; then
> echo "WARNING! If you wish to build 64-bit library, then you
> have to"
> echo " invoke '$THERE/Configure darwin64-x86_64-cc
> $options' *manually*."
> if [ "$TEST" = "false" -a -t 1 ]; then
> echo " You have about 5 seconds to press Ctrl-C to
> abort."
> # The stty technique used elsewhere doesn't work on
> # MacOS. At least, right now on this Mac.
> sleep 5
> fi
> fi
> if [ "$ISA64" = "1" -a "$KERNEL_BITS" = "64" ]; then
> OUT="darwin64-x86_64-cc"
> else
> OUT="darwin-i386-cc"
> fi ;;
>
> $MACHINE looks like it could help here:
>
> $ uname -m
> x86_64
>
> Maybe its time to add a case for x86_64. For those who really want
> 32-bit, they can 'export KERNEL_BITS=32'.


--
Richard Levitte
levitte at openssl.org

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


From rt at openssl.org  Tue May 10 21:56:47 2016
From: rt at openssl.org (Stephen Henson via RT)
Date: Tue, 10 May 2016 21:56:47 +0000
Subject: [openssl-dev] [openssl.org #4224] [PATCH] ciphers command does not
	list supported SRP suites
In-Reply-To: <000c01d14a05$b9aa9070$2cffb150$@sales@free.fr>
References: <RT-Ticket-4224@openssl.org>
 <000c01d14a05$b9aa9070$2cffb150$@sales@free.fr>
Message-ID: <rt-4.0.19-18545-1462917407-1102.4224-6-0@openssl.org>

Applied now. 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=4224
Please log in as guest with password guest if prompted


From rt at openssl.org  Tue May 10 22:27:40 2016
From: rt at openssl.org (Andy Polyakov via RT)
Date: Tue, 10 May 2016 22:27:40 +0000
Subject: [openssl-dev] [openssl.org #4196] BeagleBone Black detected as
	ARMv4
In-Reply-To: <57326056.1030402@openssl.org>
References: <RT-Ticket-4196@openssl.org>
 <CAH8yC8=CbtfwPc_WLLwpFbH2B8DV8JXuHmtUWnA5U4VAwyizNA@mail.gmail.com>
 <rt-4.0.19-9880-1450789980-363.4196-21-0@openssl.org>
 <57326056.1030402@openssl.org>
Message-ID: <rt-4.0.19-5499-1462919260-1797.4196-6-0@openssl.org>

> This seems like an odd result considering the BeagleBone Black
> processor is closer to a NEON.

Well, ./config script should add -march=armv7-a option and that is more
than enough to make it NEON-capable. In fact linux-armv4 target covers
*all* post-v4 32-bit processors, it's all about additional flags. For
those who want to distribute single software package suitable for
multiple processors it's even possible to produce "universal" binaries
(see commentary in 10-main.cf)...

> This particular BBB is running a Debian
> 8.2 based image.
> 
> I also believe CFLAGS should include hard-floats (i.e.,
> -mfloat-abi=hard).

This is something that is left to compiler vendor (by configuring
defaults) or for user/packager to decide.

> Without it, entropy estimates for some of the RAND_
> functions could produce incorrect results.

Well, can you backup this statement? Even if you could, it would be
compiler/run-time problem. If processor is not FP-capable, then it's
normally emulated in system library, but results are consistent with
FP-capable processor. Or at least if they are not, then it's a bug, and
it's a bug in system libraries, not OpenSSL.


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


From rt at openssl.org  Tue May 10 22:35:41 2016
From: rt at openssl.org (Andy Polyakov via RT)
Date: Tue, 10 May 2016 22:35:41 +0000
Subject: [openssl-dev] [openssl.org #4331] openssl-1.1.0pre3 on IRIX:
	struct timeval is undefined
In-Reply-To: <5732623D.2010905@openssl.org>
References: <RT-Ticket-4331@openssl.org>
 <201602211919.u1LJJooK024142@tezro.nonet>
 <rt-4.0.19-3784-1456115660-1297.4331-21-0@openssl.org>
 <5732623D.2010905@openssl.org>
Message-ID: <rt-4.0.19-5499-1462919741-714.4331-6-0@openssl.org>

> Building openssl-1.1.0pre3 for irix-mips3-cc fails because 
> struct timeval is undefined:

This was addressed recently. Case is being dismissed.


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


From rt at openssl.org  Tue May 10 22:37:26 2016
From: rt at openssl.org (Andy Polyakov via RT)
Date: Tue, 10 May 2016 22:37:26 +0000
Subject: [openssl-dev] [openssl.org #4332] openssl-1.1.0pre3 on IRIX:
	"Something wrong with" config --unified
In-Reply-To: <573262A5.5010100@openssl.org>
References: <RT-Ticket-4332@openssl.org>
 <201602211932.u1LJW5Mm024635@tezro.nonet>
 <rt-4.0.19-3310-1456115660-924.4332-21-0@openssl.org>
 <573262A5.5010100@openssl.org>
Message-ID: <rt-4.0.19-18545-1462919846-1984.4332-6-0@openssl.org>

> I'm trying to build openssl 1.1.0pre3 on IRIX 6.5 with the new unified
> building system using perl 5.8.9. This fails with the error message 
> below. Building without --unified works as expected. Any hints
> how to debug this or extract better logs would be appreciated.

There is minimal requirement of Perl 5.10. There is no other option, but
to update your perl. Case is being dismissed.



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


From rt at openssl.org  Tue May 10 22:41:52 2016
From: rt at openssl.org (Andy Polyakov via RT)
Date: Tue, 10 May 2016 22:41:52 +0000
Subject: [openssl-dev] [openssl.org #4333] openssl-1.1.0pre3 on IRIX:
	make test: Unrecognized escape \R passed through
In-Reply-To: <573263AF.2050601@openssl.org>
References: <RT-Ticket-4333@openssl.org>
 <201602212021.u1LKL2mh065389@tezro.nonet>
 <rt-4.0.19-3310-1456115662-1011.4333-21-0@openssl.org>
 <573263AF.2050601@openssl.org>
Message-ID: <rt-4.0.19-5499-1462920112-1243.4333-6-0@openssl.org>

> make test fails on IRIX 6.5 with perl 5.8.9 when building for irix-mips3-cc 
> and irix64-mips4-cc (the only platforms I've tried so far).

Just like with RT#4332 you've got to have at least Perl 5.10. Case is
being dismissed.


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


From rt at openssl.org  Fri May  6 00:33:47 2016
From: rt at openssl.org (SMS Conversation via RT)
Date: Fri, 06 May 2016 00:33:47 +0000
Subject: [openssl-dev] [openssl.org #4510] SSL certificate problem:
	unable to get local issuer certificate. Bug?
In-Reply-To: <CALC5Oe=Or-7=mrWX_Az7KTeqHqmvoh-Au=BYVGpeqaK-AGaY4w@mail.gmail.com>
References: <RT-Ticket-4510@openssl.org>
 <CALC5Oe=Jx82z7yN0cOrThAae9FXKRV_SngCLvjQZbFj31oP1VQ@mail.gmail.com>
 <rt-4.0.19-23551-1462461223-1977.4510-6-0@openssl.org>
 <CALC5Oe=Or-7=mrWX_Az7KTeqHqmvoh-Au=BYVGpeqaK-AGaY4w@mail.gmail.com>
Message-ID: <rt-4.0.19-2506-1462494827-146.4510-6-0@openssl.org>

Hello Steve,

I updated the openssl version to 1.0.2h and reran.  Was able to
reproduce.  *Old
pem works newer pem fails*.

See attached phpinfo for system setting.

Thanks... George

On Thu, May 5, 2016 at 8:13 AM, Stephen Henson via RT <rt at openssl.org>
wrote:

> On Tue Apr 12 13:41:51 2016, nbhfgq at gmail.com wrote:
> > On my test server running OpenSSL 1.0.2e on Windows Server 2012. The
> > "newest" cacert.pem fails with an error "SSL certificate problem: unable
> to
> > get local issuer certificate", however, the one from 2014 works. I am
> > attaching both.
> >
>
> Can you try a newer version of OpenSSL? I can't reproduce this with the
> latest
> OpenSSL 1.0.2 stable branch.
>
> 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=4510
> Please log in as guest with password guest if prompted
>
>

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: phpinfo.pdf
Type: application/pdf
Size: 313736 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20160506/8c3f7a08/attachment-0001.pdf>

From rt at openssl.org  Tue May 10 14:57:43 2016
From: rt at openssl.org (sav_ix@ukr.net via RT)
Date: Tue, 10 May 2016 14:57:43 +0000
Subject: [openssl-dev] [openssl.org #4255] OpenSSL-1.1.0-pre2 failures using
	MinGW-W64
In-Reply-To: <1462891086.517874430.c1bydlty@frv39.fwdcdn.com>
References: <RT-Ticket-4255@openssl.org>
 <1453060954.186021958.y9vnrjtk@frv39.fwdcdn.com>
 <rt-4.0.19-5500-1462883800-449.4255-6-0@openssl.org>
 <rt-4.0.19-5500-1462886039-340.4255-6-0@openssl.org>
 <1462891086.517874430.c1bydlty@frv39.fwdcdn.com>
Message-ID: <rt-4.0.19-5499-1462892263-1037.4255-6-0@openssl.org>


Hi, Everyone 

Updates sources from master branch and made OpenSSL build and test using command: 
(./Configure --prefix="$PWD/../GCC64r" -std=gnu11 -mtune=native -march=native threads no-deprecated shared mingw64 >_Configure.log && make -j 
$NUMBER_OF_PROCESSORS >_make.log && make -j$NUMBER_OF_PROCESSORS install >_install.log) 2>_stderr.log && HARNESS_VERBOSE=yes make test >_test.log 2>&1 

Logs added in attachment. 

On some stage of OpenSSL testsuite run, process 
C:\libOPENSSL-1.1.0-dev\src\apps\openssl.exe s_server -no_comp -rev -engine ossltest -accept 4443 -cert ../apps/server.pem -naccept 1 -cipher AES128-SHA 
stop respond over 5 minutes and was terminated manually. 

Same repeated a bit later with processes 
C:\libOPENSSL-1.1.0-dev\src\apps\openssl.exe s_client -engine ossltest -connect 127.0.0.1:4453 -4 
C:\libOPENSSL-1.1.0-dev\src\apps\openssl.exe s_client -engine ossltest -connect [::1]:4453 -6 
After their termination OpenSSL testsuite stop execution. 

Could you tell, whether this errors reproduced on other Windows systems? (mean not using cross-compilation or Wine) 


Regards, 
Alexander 


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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: mingw-w64_build_logs.zip
Type: application/x-zip-compressed
Size: 106352 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20160510/e06b075d/attachment-0001.bin>

From erik at efca.com  Wed May 11 03:13:57 2016
From: erik at efca.com (Erik Forsberg)
Date: Tue, 10 May 2016 20:13:57 -0700
Subject: [openssl-dev] [openssl.org #4444] [openssl-1.1.0-pre4]
	Make	fails with "recipe for target 'depend' failed" on
	solaris64-x86_64
In-Reply-To: <rt-4.0.19-1915-1458351113-1657.4444-6-0@openssl.org>
References: <RT-Ticket-4444@openssl.org>
 <rt-4.0.19-1915-1458351113-1657.4444-6-0@openssl.org>
Message-ID: <wug0FX-kjFyPNEm@srv.efca.com>

no idea where this OLD message came from.
In any case, do ignore, problem has been solved for many weeks.

>-- Original Message --
>
>
>still not working right.
>Attached a longish log file extract.
>But root cause seems to be that we try to process test dependencies
>while doing depend in crypto, way before we had done any work in
>the test subdir. That causes the find to exit with failed status aborting
>the depend.
>
>
>>-- Original Message --
>>
>>Fixup show in last message has now been merged with master, commit
>>a6adf099cbd7c3bc5c7051ad3d334636ef5e7f90
>>
>>--
>>Richard Levitte
>>levitte at openssl.org
>>
>>-- 
>>Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4444
>>Please log in as guest with password guest if prompted
>>
>>-- 
>>openssl-dev mailing list
>>To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
>
>
>-- 
>Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4444
>Please log in as guest with password guest if prompted
>
>
>Attachment: depend.log (34.6 KB)
>
>-- 
>openssl-dev mailing list
>To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev


From rt at openssl.org  Wed May 11 03:34:27 2016
From: rt at openssl.org (Erik Forsberg via RT)
Date: Wed, 11 May 2016 03:34:27 +0000
Subject: [openssl-dev] [openssl.org #4444] [openssl-1.1.0-pre4] Make
	fails with "recipe for target 'depend' failed" on solaris64-x86_64
In-Reply-To: <wug0FX-kjFyPNEm@srv.efca.com>
References: <RT-Ticket-4444@openssl.org>
 <rt-4.0.19-1915-1458351113-1657.4444-6-0@openssl.org>
 <wug0FX-kjFyPNEm@srv.efca.com>
Message-ID: <rt-4.0.19-18545-1462937667-1938.4444-6-0@openssl.org>

no idea where this OLD message came from.
In any case, do ignore, problem has been solved for many weeks.

>-- Original Message --
>
>
>still not working right.
>Attached a longish log file extract.
>But root cause seems to be that we try to process test dependencies
>while doing depend in crypto, way before we had done any work in
>the test subdir. That causes the find to exit with failed status aborting
>the depend.
>
>
>>-- Original Message --
>>
>>Fixup show in last message has now been merged with master, commit
>>a6adf099cbd7c3bc5c7051ad3d334636ef5e7f90
>>
>>--
>>Richard Levitte
>>levitte at openssl.org
>>
>>-- 
>>Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4444
>>Please log in as guest with password guest if prompted
>>
>>-- 
>>openssl-dev mailing list
>>To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
>
>
>-- 
>Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4444
>Please log in as guest with password guest if prompted
>
>
>Attachment: depend.log (34.6 KB)
>
>-- 
>openssl-dev mailing list
>To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev


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


From ca+ssl-dev at esmtp.org  Wed May 11 03:45:01 2016
From: ca+ssl-dev at esmtp.org (Claus Assmann)
Date: Tue, 10 May 2016 20:45:01 -0700
Subject: [openssl-dev] 1.0.1t: CMS => PKCS#7 compatibility tests: signed
 content DER format, RSA key: verify error
Message-ID: <20160511034501.GA14975@x2.esmtp.org>

make test fails on OpenBSD and FreeBSD (8.4):

CMS => PKCS#7 compatibility tests
signed content DER format, RSA key: verify error
*** Error 1 in test (Makefile:330 'test_cms')

more cms.err
Verification failure
34371851688:error:21075075:PKCS7 routines:PKCS7_verify:certificate verify error:pk7_smime.c:328:Verify error:certificate has expired

Is that a known problem?  If it isn't specific to my setup, maybe
it can be fixed for the next release?

From openssl-users at dukhovni.org  Wed May 11 03:58:08 2016
From: openssl-users at dukhovni.org (Viktor Dukhovni)
Date: Tue, 10 May 2016 23:58:08 -0400
Subject: [openssl-dev] 1.0.1t: CMS => PKCS#7 compatibility tests: signed
	content DER format, RSA key: verify error
In-Reply-To: <20160511034501.GA14975@x2.esmtp.org>
References: <20160511034501.GA14975@x2.esmtp.org>
Message-ID: <94A48783-8CD1-450F-BCC1-72B964362776@dukhovni.org>


> On May 10, 2016, at 11:45 PM, Claus Assmann <ca+ssl-dev at esmtp.org> wrote:
> 
> make test fails on OpenBSD and FreeBSD (8.4):
> 
> CMS => PKCS#7 compatibility tests
> signed content DER format, RSA key: verify error
> *** Error 1 in test (Makefile:330 'test_cms')
> 
> more cms.err
> Verification failure
> 34371851688:error:21075075:PKCS7 routines:PKCS7_verify:certificate verify error:pk7_smime.c:328:Verify error:certificate has expired
> 
> Is that a known problem?  If it isn't specific to my setup, maybe
> it can be fixed for the next release?

Some of the certs in the 1.0.x test suite are getting old, and it looks
like some have expired.  In "master", I generated new certificates for
various tests with a 100-year lifetime.  Though some of the tests may
still be using older certs there too.  We'll flush these out as we find
them.  Thanks for the report.

-- 
	Viktor.


From rt at openssl.org  Wed May 11 06:04:25 2016
From: rt at openssl.org (Richard Levitte via RT)
Date: Wed, 11 May 2016 06:04:25 +0000
Subject: [openssl-dev] [openssl.org #4444] [openssl-1.1.0-pre4] Make fails
	with "recipe for target 'depend' failed" on solaris64-x86_64
In-Reply-To: <rt-4.0.19-18545-1462937666-1951.4444-6-0@openssl.org>
References: <RT-Ticket-4444@openssl.org>
 <rt-4.0.19-1915-1458351113-1657.4444-6-0@openssl.org>
 <wug0FX-kjFyPNEm@srv.efca.com>
 <rt-4.0.19-18545-1462937666-1951.4444-6-0@openssl.org>
Message-ID: <rt-4.0.19-18545-1462946665-1987.4444-6-0@openssl.org>

Thanks. re-closing.

On Wed May 11 03:34:26 2016, erik at efca.com wrote:
> no idea where this OLD message came from.
> In any case, do ignore, problem has been solved for many weeks.
>
> >-- Original Message --
> >
> >
> >still not working right.
> >Attached a longish log file extract.
> >But root cause seems to be that we try to process test dependencies
> >while doing depend in crypto, way before we had done any work in
> >the test subdir. That causes the find to exit with failed status aborting
> >the depend.
> >
> >
> >>-- Original Message --
> >>
> >>Fixup show in last message has now been merged with master, commit
> >>a6adf099cbd7c3bc5c7051ad3d334636ef5e7f90
> >>
> >>--
> >>Richard Levitte
> >>levitte at openssl.org
> >>
> >>--
> >>Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4444
> >>Please log in as guest with password guest if prompted
> >>
> >>--
> >>openssl-dev mailing list
> >>To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
> >
> >
> >--
> >Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4444
> >Please log in as guest with password guest if prompted
> >
> >
> >Attachment: depend.log (34.6 KB)
> >
> >--
> >openssl-dev mailing list
> >To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
>


--
Richard Levitte
levitte at openssl.org

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


From levitte at openssl.org  Wed May 11 07:09:55 2016
From: levitte at openssl.org (Richard Levitte)
Date: Wed, 11 May 2016 09:09:55 +0200 (CEST)
Subject: [openssl-dev] Packager material in our source...
Message-ID: <20160511.090955.97786788517023184.levitte@openssl.org>

Hi,

I've been wondering, why do we have an openssl.spec in the OpenSSL
source?  Why would we have packager material in there at all, and if
we should have such things, why only for RPMs, why not Debian, why not
stuff to build Windows .msis, why not stuff to build PCSI files (for
VMS)?

This is to say, I'm going to make a move to remove openssl.spec from
our source, and thought a fair warning was waranted.

Cheers,
Richard

-- 
Richard Levitte         levitte at openssl.org
OpenSSL Project         http://www.openssl.org/~levitte/

From xoloki at gmail.com  Wed May 11 08:09:53 2016
From: xoloki at gmail.com (Joey Yandle)
Date: Wed, 11 May 2016 01:09:53 -0700
Subject: [openssl-dev] Packager material in our source...
In-Reply-To: <20160511.090955.97786788517023184.levitte@openssl.org>
References: <20160511.090955.97786788517023184.levitte@openssl.org>
Message-ID: <5732E8D1.2070909@gmail.com>

Though I don't use RedHat or it's derivatives, it's packaging file is at 
least mercifully self-contained.  Also, spec files can be used to 
generate packaging files for other formats.

I'd advocate for leaving it in... just not very forcefully.

On 5/11/2016 12:09 AM, Richard Levitte wrote:
> Hi,
>
> I've been wondering, why do we have an openssl.spec in the OpenSSL
> source?  Why would we have packager material in there at all, and if
> we should have such things, why only for RPMs, why not Debian, why not
> stuff to build Windows .msis, why not stuff to build PCSI files (for
> VMS)?
>
> This is to say, I'm going to make a move to remove openssl.spec from
> our source, and thought a fair warning was waranted.
>
> Cheers,
> Richard
>

From rt at openssl.org  Wed May 11 09:21:04 2016
From: rt at openssl.org (Andy Polyakov via RT)
Date: Wed, 11 May 2016 09:21:04 +0000
Subject: [openssl-dev] [openssl.org #4523] Failure - make test
In-Reply-To: <5732F97A.8040102@openssl.org>
References: <RT-Ticket-4523@openssl.org>
 <D368120842644E438A175B140D0C165973FF177D@AGDEHENSEX03.bechtle.net>
 <rt-4.0.19-21242-1461969616-1839.4523-21-0@openssl.org>
 <5732F97A.8040102@openssl.org>
Message-ID: <rt-4.0.19-18545-1462958464-1593.4523-6-0@openssl.org>

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


From matt at openssl.org  Wed May 11 09:26:52 2016
From: matt at openssl.org (Matt Caswell)
Date: Wed, 11 May 2016 10:26:52 +0100
Subject: [openssl-dev] DTLS session resumption with DTLS_ANY_VERSION
In-Reply-To: <CA+mfXPFV6BaM4bTYf8oM7kHJhH3N2WRrKo0py-rbYsJEm2GJnw@mail.gmail.com>
References: <CA+mfXPFV6BaM4bTYf8oM7kHJhH3N2WRrKo0py-rbYsJEm2GJnw@mail.gmail.com>
Message-ID: <5732FADC.6010804@openssl.org>



On 10/05/16 18:34, Rajeswari K wrote:
> Hello openssl-dev team,
> 
> Having query regarding DTLS session resumption when configured SSL_CTX
> with DTLS_ANY_VERSION. 
> 
> When we select SSL_CTX with DTLS_ANY_VERSION, method will be of
> DTLS_Server_method(), which will have ssl_ctx->version as 0xFEFD to
> support both the versions (i.e. DTLS1.0 and DTLS1.2).
> 
> During handshake, we landed on to version DTLS1.0.i.e.
> s->session->version holds 0xFEFF. 
> 
> In order to perform session resumption, we derived new SSL structure
> from global ssl_ctx using SSL_new() and tried performing ssl handshake.
> 
> With the below logic, 
> else {
>         i = ssl_get_prev_session(s, p, j, d + n);
>         /*
>          * Only resume if the session's version matches the negotiated
>          * version.
>          * RFC 5246 does not provide much useful advice on resumption
>          * with a different protocol version. It doesn't forbid it but
>          * the sanity of such behaviour would be questionable.
>          * In practice, clients do not accept a version mismatch and
>          * will abort the handshake with an error.
>          */
>         if (i == 1 && s->version == s->session->ssl_version) { /* previous
>                                                                 * session */
>             s->hit = 1;
>         } else if (i == -1)
>             goto err;
>         else {                  /* i == 0 */
> 
>             if (!ssl_get_new_session(s, 1))
>                 goto err;
>         }
> 
> Since s->version is with 0xFEFD and s->session->ssl_version is 0xFEFF,
> we always try for new session and wont land on to session resumption
> though client has sent the  session_id. 
> 
> Is this intended behaviour? Please clarify.


No. This appears to be a bug introduced by commit 03d14f588734 in
November 2014.

The real problem though is that the DTLS version negotiation is
happening too late - after session resumption. Interestingly this only
seems to be a problem in 1.0.2. In 1.1.0 this is working correctly (the
version negotiation logic has been substantially rewritten in the new
version).

Please could you try out the attached patch? Let me know how you get on.

Thanks

Matt
-------------- next part --------------
A non-text attachment was scrubbed...
Name: dtls-ver-before-sess.patch
Type: text/x-patch
Size: 3303 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20160511/b4592642/attachment-0001.bin>

From meissner at suse.de  Wed May 11 09:34:36 2016
From: meissner at suse.de (Marcus Meissner)
Date: Wed, 11 May 2016 11:34:36 +0200
Subject: [openssl-dev] cms-test.pl failing - expired certs
In-Reply-To: <20160511092400.GB32650@suse.de>
References: <20160511092400.GB32650@suse.de>
Message-ID: <20160511093435.GD32650@suse.de>

On Wed, May 11, 2016 at 11:24:00AM +0200, Marcus Meissner wrote:
> Hi,
> 
> tests/cms-test.pl is failing, as the smime-certs/ expired yesterday / expire today.
> 
> Can someone please generate correct new certs?

Hups. I only looked at 1.0.1 branch. The certs are refreshed in 1.0.2 and master.

Sorry for the noise.

Ciao, Marcus

From meissner at suse.de  Wed May 11 09:24:01 2016
From: meissner at suse.de (Marcus Meissner)
Date: Wed, 11 May 2016 11:24:01 +0200
Subject: [openssl-dev] cms-test.pl failing - expired certs
Message-ID: <20160511092400.GB32650@suse.de>

Hi,

tests/cms-test.pl is failing, as the smime-certs/ expired yesterday / expire today.

Can someone please generate correct new certs?

Ciao, Marcus

From rt at openssl.org  Wed May 11 10:24:31 2016
From: rt at openssl.org (Matt Caswell via RT)
Date: Wed, 11 May 2016 10:24:31 +0000
Subject: [openssl-dev] [openssl.org #4379] "arch/async_posix.h:67:24: error:
	ucontext.h: No such file or directory" under OpenBSD 5.7/64-bit
In-Reply-To: <CAH8yC8k=3OzYiZD3FZ=DpaLB2iLt3SFGRxhR1=ed2_Sw2OthhQ@mail.gmail.com>
References: <RT-Ticket-4379@openssl.org>
 <CAH8yC8k=3OzYiZD3FZ=DpaLB2iLt3SFGRxhR1=ed2_Sw2OthhQ@mail.gmail.com>
Message-ID: <rt-4.0.19-5499-1462962271-609.4379-6-0@openssl.org>

On Sat Mar 05 02:22:00 2016, noloader at gmail.com wrote:
> cc -I.. -I../.. -I../modes -I../include -I../../include -DDSO_DLFCN
> -DHAVE_DLFCN_H -DOPENSSL_THREADS -DOPENSSL_NO_STATIC_ENGINE
> -DOPENSSL_PIC -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 -DGHASH_ASM
> -DECP_NISTZ256_ASM -DPOLY1305_ASM -DOPENSSLDIR="\"/usr/local/ssl\""
> -DENGINESDIR="\"/usr/local/lib/engines\"" -DL_ENDIAN -Wall -O3
> -pthread -D_THREAD_SAFE -D_REENTRANT -Wa,--noexecstack -fPIC -c
> async.c -o async.o
> In file included from async_locl.h:69,
> from async.c:62:
> arch/async_posix.h:67:24: error: ucontext.h: No such file or directory
> In file included from async_locl.h:69,
> from async.c:62:
> arch/async_posix.h: In function 'async_fibre_swapcontext':
> arch/async_posix.h:85: warning: implicit declaration of function
> 'setcontext'
> *** Error 1 in crypto/async (Makefile:65 'async.o')
> *** Error 1 in crypto (Makefile:91 'subdirs')
> *** Error 1 in /home/jwalton/openssl (Makefile:291 'build_crypto')

Hi Jeff

Please could you try the attached patch?

Thanks

Matt

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: no-openbsd-ucontext.patch
Type: text/x-patch
Size: 1039 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20160511/d8752834/attachment.bin>

From rainer.jung at kippdata.de  Wed May 11 10:51:33 2016
From: rainer.jung at kippdata.de (Rainer Jung)
Date: Wed, 11 May 2016 12:51:33 +0200
Subject: [openssl-dev] [openssl.org #4311] OpenSSL 1.1.0-pre3: quote
 PERL=$(PERL) in Makefiles
In-Reply-To: <rt-4.0.19-18545-1462910089-1637.4311-6-0@openssl.org>
References: <RT-Ticket-4311@openssl.org> <56C36B8A.50507@kippdata.de>
 <rt-4.0.19-5500-1462886302-337.4311-6-0@openssl.org>
 <rt-4.0.19-5500-1462886957-1375.4311-6-0@openssl.org>
 <8c38ec6c-080b-9060-17ab-d1519339c2e4@kippdata.de>
 <rt-4.0.19-5500-1462892176-947.4311-6-0@openssl.org>
 <rt-4.0.19-18545-1462910089-1637.4311-6-0@openssl.org>
Message-ID: <634a5843-2ad4-c5b5-8882-2964b9798bde@kippdata.de>

Am 10.05.2016 um 21:54 schrieb Richard Levitte via RT:
> I understand this part. What I'm questioning is the need to set PERL to
> "/usr/bin/env perl" to begin with. It's practically not different at all from
> setting it to just "perl", all this does is that any time the environment
> variable PERL is used to run a perl script is to have an extra process between
> the shell and perl itself that will simply pass along the exact environment
> that it got from the shell. In effect, any time the environment variable PERL
> with your assignment is used to run a script (assuming the quoting you
> suggest), i.e.:
>
> $PERL blah.pl
>
> it would expand to this:
>
> /usr/bin/env perl blah.pl
>
> If it's only assigned "perl", the command would expand to this:
>
> perl blah.pl
>
> perl itself literally gets the exact same environment in both cases.

I agree.

> Mind you, I did read your reasoning around #! in scripts. Unfortunately, that
> reasoning is flawed, that won't be affected by the environment variable PERL.

I had to rad my ticket again, and actually this is the only reason for 
the ticket: the following perl scripts are generated from .in files 
during building OpenSSL and get installed and executed later in another 
environment:

- c_rehash
- CA.pl
- tsget

All of them contain in the .in file the magic header:

#!{- $config{perl} -}

IMHO $config{perl} - detected and set during config and Configure from 
the PERL env var and as a fallback from the PATH - is used as the perl 
during build time and also put into the scripts for use on the target 
system.

But those two perl paths should be defined independently from each other.

You say the reasoning is flawed, but to me it looks like:

- config checks whether the PERL env var is set. If not it searches for 
a perl in the path and sets the PERL env var to that one.

- config calls Configure

- Configure sets $config{perl} from the PERL env var

- the scripts c_rehash, CA.pl and tsget are generated from their .in 
files and their first line

#!{- $config{perl} -}

is replaced by #!$PERL (with $PERL resolved).

I'd love if I were wrong and there would already be a way to set the 
perl for those scripts independently from the one used for the build 
process. If you think that demand is too specific, I can live with 
patching the scripts myself. But IMHO it would be nice not to enforce 
the same restrictions on the build procedure perl to the runtime perl 
for those simple scripts. For the build procedure it should be the 
required 5.10 with modules etc. For the three scripts typically the 
platform perl would suffice.

Regards,

Rainer

From rt at openssl.org  Wed May 11 10:51:46 2016
From: rt at openssl.org (Rainer Jung via RT)
Date: Wed, 11 May 2016 10:51:46 +0000
Subject: [openssl-dev] [openssl.org #4311] OpenSSL 1.1.0-pre3: quote
	PERL=$(PERL) in Makefiles
In-Reply-To: <634a5843-2ad4-c5b5-8882-2964b9798bde@kippdata.de>
References: <RT-Ticket-4311@openssl.org> <56C36B8A.50507@kippdata.de>
 <rt-4.0.19-5500-1462886302-337.4311-6-0@openssl.org>
 <rt-4.0.19-5500-1462886957-1375.4311-6-0@openssl.org>
 <8c38ec6c-080b-9060-17ab-d1519339c2e4@kippdata.de>
 <rt-4.0.19-5500-1462892176-947.4311-6-0@openssl.org>
 <rt-4.0.19-18545-1462910089-1637.4311-6-0@openssl.org>
 <634a5843-2ad4-c5b5-8882-2964b9798bde@kippdata.de>
Message-ID: <rt-4.0.19-5499-1462963906-1853.4311-6-0@openssl.org>

Am 10.05.2016 um 21:54 schrieb Richard Levitte via RT:
> I understand this part. What I'm questioning is the need to set PERL to
> "/usr/bin/env perl" to begin with. It's practically not different at all from
> setting it to just "perl", all this does is that any time the environment
> variable PERL is used to run a perl script is to have an extra process between
> the shell and perl itself that will simply pass along the exact environment
> that it got from the shell. In effect, any time the environment variable PERL
> with your assignment is used to run a script (assuming the quoting you
> suggest), i.e.:
>
> $PERL blah.pl
>
> it would expand to this:
>
> /usr/bin/env perl blah.pl
>
> If it's only assigned "perl", the command would expand to this:
>
> perl blah.pl
>
> perl itself literally gets the exact same environment in both cases.

I agree.

> Mind you, I did read your reasoning around #! in scripts. Unfortunately, that
> reasoning is flawed, that won't be affected by the environment variable PERL.

I had to rad my ticket again, and actually this is the only reason for 
the ticket: the following perl scripts are generated from .in files 
during building OpenSSL and get installed and executed later in another 
environment:

- c_rehash
- CA.pl
- tsget

All of them contain in the .in file the magic header:

#!{- $config{perl} -}

IMHO $config{perl} - detected and set during config and Configure from 
the PERL env var and as a fallback from the PATH - is used as the perl 
during build time and also put into the scripts for use on the target 
system.

But those two perl paths should be defined independently from each other.

You say the reasoning is flawed, but to me it looks like:

- config checks whether the PERL env var is set. If not it searches for 
a perl in the path and sets the PERL env var to that one.

- config calls Configure

- Configure sets $config{perl} from the PERL env var

- the scripts c_rehash, CA.pl and tsget are generated from their .in 
files and their first line

#!{- $config{perl} -}

is replaced by #!$PERL (with $PERL resolved).

I'd love if I were wrong and there would already be a way to set the 
perl for those scripts independently from the one used for the build 
process. If you think that demand is too specific, I can live with 
patching the scripts myself. But IMHO it would be nice not to enforce 
the same restrictions on the build procedure perl to the runtime perl 
for those simple scripts. For the build procedure it should be the 
required 5.10 with modules etc. For the three scripts typically the 
platform perl would suffice.

Regards,

Rainer


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


From rt at openssl.org  Wed May 11 12:46:36 2016
From: rt at openssl.org (Matt Caswell via RT)
Date: Wed, 11 May 2016 12:46:36 +0000
Subject: [openssl-dev] [openssl.org #4387] [PATCH] Fix V2ClientHello handling
In-Reply-To: <CAF8qwaDkjz3kH+BUoUBqMvukKfTC+B7u+m__OKMxSZ4UO72+kQ@mail.gmail.com>
References: <RT-Ticket-4387@openssl.org>
 <CAF8qwaDkjz3kH+BUoUBqMvukKfTC+B7u+m__OKMxSZ4UO72+kQ@mail.gmail.com>
Message-ID: <rt-4.0.19-18545-1462970796-169.4387-6-0@openssl.org>

Patch applied in cb21df322.

Thanks.

Matt

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


From rt at openssl.org  Wed May 11 14:57:09 2016
From: rt at openssl.org (Kiyoshi KANAZAWA via RT)
Date: Wed, 11 May 2016 14:57:09 +0000
Subject: [openssl-dev] [openssl.org #4452] openssl-1.1.0-pre4: undefined
	symbol for solaris-x86-cc
In-Reply-To: <936104.55478.qm@web101209.mail.kks.yahoo.co.jp>
References: <RT-Ticket-4452@openssl.org>
 <747648.50843.qm@web101220.mail.kks.yahoo.co.jp>
 <rt-4.0.19-1915-1458424415-879.4452-6-0@openssl.org>
 <550057.6653.qm@web101214.mail.kks.yahoo.co.jp>
 <777156.81532.qm@web101215.mail.kks.yahoo.co.jp>
 <rt-4.0.19-19985-1458556925-1313.4452-6-0@openssl.org>
 <rt-4.0.19-18545-1462913877-1156.4452-6-0@openssl.org>
 <936104.55478.qm@web101209.mail.kks.yahoo.co.jp>
Message-ID: <rt-4.0.19-18545-1462978629-1478.4452-6-0@openssl.org>

Hello,

It is fixed in openssl-1.1.0-pre5.

Thanks,

--- Kiyoshi <yoi_no_myoujou at yahoo.co.jp>




----- Original Message -----
>From: Richard Levitte via RT <rt at openssl.org>
>To: yoi_no_myoujou at yahoo.co.jp 
>Cc: openssl-dev at openssl.org
>Date: 2016/5/11, Wed 05:57
>Subject: [openssl.org #4452] openssl-1.1.0-pre4: undefined symbol for solaris-x86-cc
> 
>Hi,
>
>that looks like engines/asm/e_padlock_x86.o wasn't built for some reason, even
>though it should.
>
>I would like it if you gave me a full log, or in other words, send me build.log
>after running this:
>
>(set -x; ./Configure solaris-x86-cc shared; make) > build.log 2>&1
>
>Cheers,
>Richard
>
>On Mon Mar 21 10:42:05 2016, yoi_no_myoujou at yahoo.co.jp wrote:
>> % ../Configure solaris-x86-cc shared; make; make test
>> also passes.
>>
>> Regards,
>>
>> --- Kiyoshi <yoi_no_myoujou at yahoo.co.jp>
>>
>>
>>
>>
>>
>> > Tried with openssl-SNAP-20160320,
>> > but have the same result, not fixed yet.
>> >
>> >
>> > Regards,
>> >
>> > --- Kiyoshi <yoi_no_myoujou at yahoo.co.jp>
>> >
>> >
>> >
>> >
>> >> If you have the possibility, please try a fresh checkout of the master
>> > branch
>> >> and see if this is fixed.
>> >>
>> >> Cheers,
>> >> Richard
>> >>
>> >> Vid Sat, 19 Mar 2016 kl. 10.55.59, skrev yoi_no_myoujou at yahoo.co.jp:
>> >>> With patch for #4444,
>> >>>
>> >>> % mkdir build_solaris-x86-cc
>> >>> % cd build_solaris-x86-cc
>> >>> % ../Configure solaris-x86-cc
>> >>> % make
>> >>> :
>> >>> Undefined first referenced
>> >>> symbol in file
>> >>> padlock_xstore ./libcrypto.a(e_padlock.o)
>> >>> padlock_capability ./libcrypto.a(e_padlock.o)
>> >>> padlock_reload_key ./libcrypto.a(e_padlock.o)
>> >>> padlock_ctr32_encrypt ./libcrypto.a(e_padlock.o)
>> >>> padlock_key_bswap ./libcrypto.a(e_padlock.o)
>> >>> padlock_cbc_encrypt ./libcrypto.a(e_padlock.o)
>> >>> padlock_cfb_encrypt ./libcrypto.a(e_padlock.o)
>> >>> padlock_ecb_encrypt ./libcrypto.a(e_padlock.o)
>> >>> padlock_ofb_encrypt ./libcrypto.a(e_padlock.o)
>> >>> padlock_aes_block ./libcrypto.a(e_padlock.o)
>> >>> ld: fatal: symbol referencing errors. No output written to
>> > apps/openssl
>> >>> ../Makefile.shared:186: recipe for target 'link_app.' failed
>> >>> make[1]: *** [link_app.] Error 2
>> >>>
>> >>>
>> >>> % ../Configure solaris-x86-cc no-asm
>> >>>
>> >>> % make
>> >>> % make test
>> >>> passes.
>> >>>
>> >>>
>> >>> OS: Solaris10 x86/x64
>> >>> cc: /opt/solarisstudio12.4/bin/cc
>> >>>
>> >>>
>> >>> Best Regards,
>> >>>
>> >>> --- Kiyoshi <yoi_no_myoujou at yahoo.co.jp>
>> >>>
>> >>>
>> >>
>> >>
>> >> --
>> >> Richard Levitte
>> >> levitte at openssl.org
>> >>
>> >> --
>> >> Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4452
>> >> Please log in as guest with password guest if prompted
>> >>
>> >
>>
>
>
>--
>Richard Levitte
>levitte at openssl.org
>
>-- 
>Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4452
>Please log in as guest with password guest if prompted
>
>
>
>


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


From rt at openssl.org  Wed May 11 15:01:08 2016
From: rt at openssl.org (Kiyoshi KANAZAWA via RT)
Date: Wed, 11 May 2016 15:01:08 +0000
Subject: [openssl-dev] [openssl.org #4324] openssl-1.1.0-pre3 with
	solaris-x86-cc & solaris64-x86_64-cc make fails
In-Reply-To: <69551.59647.qm@web101207.mail.kks.yahoo.co.jp>
References: <RT-Ticket-4324@openssl.org>
 <521557.3312.qm@web101212.mail.kks.yahoo.co.jp>
 <845222.20757.qm@web101214.mail.kks.yahoo.co.jp>
 <rt-4.0.19-3310-1456410990-592.4324-6-0@openssl.org>
 <rt-4.0.19-18545-1462912191-1476.4324-6-0@openssl.org>
 <69551.59647.qm@web101207.mail.kks.yahoo.co.jp>
Message-ID: <rt-4.0.19-5499-1462978868-1757.4324-6-0@openssl.org>

Hello,

They are fixed in openssl-1.1.0-pre5.

Regards,


--- Kiyoshi <yoi_no_myoujou at yahoo.co.jp>




----- Original Message -----
> From: Richard Levitte via RT <rt at openssl.org>
> To: yoi_no_myoujou at yahoo.co.jp
> Cc: openssl-dev at openssl.org
> Date: 2016/5/11, Wed 05:29
> Subject: [openssl.org #4324] openssl-1.1.0-pre3 with solaris-x86-cc & solaris64-x86_64-cc make fails
> 
> Hi,
> 
> Sorry for taking so long to get back to you.
> 
> Would you mind trying again with a fresh master, or with the latest beta? Quite
> a lot has happened, especially in Makefile.shared and exactly around the stuff
> you have reported, so I'm hopeful things will work better for you now.
> 
> Cheers,
> Richard
> 
> On Thu Feb 25 14:36:30 2016, yoi_no_myoujou at yahoo.co.jp wrote:
>>  With the following patch,
>>  % ./Configure --unified solaris-x86-cc
>>  % make
>>  % make test
>>  passed.
>> 
>>  % ./Configure --unifiedsolaris64-x86_64-cc; make; make test
>>  also passed.
>> 
>> 
>>  This patch was written comparing to openssl-1.0.2f.
>> 
>>  It has side effect for other configurations.
>>  Please add some conditions.
>> 
>> 
>>  diff -cr ../openssl-1.1.0-pre3.orig/Makefile.shared ./Makefile.shared
>>  *** ../openssl-1.1.0-pre3.orig/Makefile.shared 2016-02-16
>>  03:08:07.000000000 +0900
>>  --- ./Makefile.shared 2016-02-25 22:57:23.347187336 +0900
>>  ***************
>>  *** 398,409 ****
>>  ($(CC) -v 2>&1 | grep gcc) > /dev/null && 
> MINUSZ='-Wl,-z,'; \
>>  SHLIB=lib$(LIBNAME).so; \
>>  SHLIB_SUFFIX=;\
>>  ! if [ $(LIBNAME) != "crypto" -a $(LIBNAME) != "ssl" ]; 
> then \
>>  ALLSYMSFLAGS="$${MINUSZ}allextract"; \
>>  ! else \
>>  ! $(PERL) $(SRCDIR)/util/mkdef.pl $(LIBNAME) linux
>>  >$(LIBNAME).map; \
>>  ! ALLSYMSFLAGS="$${MINUSZ}allextract,-M,$(LIBNAME).map"; \
>>  ! fi; \
>>  NOALLSYMSFLAGS="$${MINUSZ}defaultextract"; \
>>  SHAREDFLAGS="$(CFLAGS) $(SHARED_LDFLAGS) -h
>>  $$SHLIB$$SHLIB_SOVER$$SHLIB_SUFFIX -Wl,-Bsymbolic"; \
>>  fi; \
>>  --- 398,409 ----
>>  ($(CC) -v 2>&1 | grep gcc) > /dev/null && 
> MINUSZ='-Wl,-z,'; \
>>  SHLIB=lib$(LIBNAME).so; \
>>  SHLIB_SUFFIX=;\
>>  ! # if [ $(LIBNAME) != "crypto" -a $(LIBNAME) != "ssl" 
> ]; then \
>>  ALLSYMSFLAGS="$${MINUSZ}allextract"; \
>>  ! # else \
>>  ! # $(PERL) $(SRCDIR)/util/mkdef.pl $(LIBNAME) linux
>>  >$(LIBNAME).map; \
>>  ! # ALLSYMSFLAGS="$${MINUSZ}allextract,-M,$(LIBNAME).map"; \
>>  ! # fi; \
>>  NOALLSYMSFLAGS="$${MINUSZ}defaultextract"; \
>>  SHAREDFLAGS="$(CFLAGS) $(SHARED_LDFLAGS) -h
>>  $$SHLIB$$SHLIB_SOVER$$SHLIB_SUFFIX -Wl,-Bsymbolic"; \
>>  fi; \
> 
> 
> --
> Richard Levitte
> levitte at openssl.org
> 
> -- 
> Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4324
> Please log in as guest with password guest if prompted
>


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


From rt at openssl.org  Wed May 11 15:15:49 2016
From: rt at openssl.org (Kiyoshi KANAZAWA via RT)
Date: Wed, 11 May 2016 15:15:49 +0000
Subject: [openssl-dev] [openssl.org #4453] openssl-1.1.0-pre4: make
	fails with 'wrong ELF class: ELFCLASS64' on solaris64-x86_64-cc
In-Reply-To: <632791.48237.qm@web101205.mail.kks.yahoo.co.jp>
References: <RT-Ticket-4453@openssl.org>
 <173729.2988.qm@web101210.mail.kks.yahoo.co.jp>
 <rt-4.0.19-5499-1462914109-1337.4453-6-0@openssl.org>
 <632791.48237.qm@web101205.mail.kks.yahoo.co.jp>
Message-ID: <rt-4.0.19-5499-1462979749-1434.4453-6-0@openssl.org>

Hi,

Checked with openssl-1.1.0-pre5,
and confirmed it is fixed.

Thanks,

--- Kiyoshi <yoi_no_myoujou at yahoo.co.jp>




----- Original Message -----
> From: Richard Levitte via RT <rt at openssl.org>
> To: yoi_no_myoujou at yahoo.co.jp
> Cc: openssl-dev at openssl.org
> Date: 2016/5/11, Wed 06:01
> Subject: [openssl.org #4453] openssl-1.1.0-pre4: make fails with 'wrong ELF class: ELFCLASS64' on solaris64-x86_64-cc
> 
> Hi,
> 
> would you mind checking again with the latest beta or a fresh master checkout?
> It looks to me like this issue is fixed, but I want to make sure.
> 
> Cheers,
> Richard
> 
> On Sat Mar 19 10:56:00 2016, yoi_no_myoujou at yahoo.co.jp wrote:
>>  Hello,
>> 
>>  Tested with patch for #4444, and removing gcc from path.
>> 
>>  % ./config
>>  Operating system: i86pc-whatever-solaris2
>>  Configuring for solaris64-x86_64-cc
>>  Configuring OpenSSL version 1.1.0-pre4 (0x0x10100004L)
>>  no-crypto-mdebug [default] OPENSSL_NO_CRYPTO_MDEBUG (skip dir)
>>  no-crypto-mdebug-backtrace [forced]
>>  OPENSSL_NO_CRYPTO_MDEBUG_BACKTRACE (skip dir)
>>  no-dynamic-engine [forced]
>>  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-heartbeats [default] OPENSSL_NO_HEARTBEATS (skip dir)
>>  no-md2 [default] OPENSSL_NO_MD2 (skip dir)
>>  no-rc5 [default] OPENSSL_NO_RC5 (skip dir)
>>  no-sctp [default] OPENSSL_NO_SCTP (skip dir)
>>  no-shared [default]
>>  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-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 solaris64-x86_64-cc
>>  IsMK1MF =no
>>  CC =cc
>>  CFLAG =-xarch=generic64 -xstrconst -Xa -DL_ENDIAN -xO5
>>  -xdepend -xbuiltin -D_REENTRANT -DFILIO_H
>>  SHARED_CFLAG =-KPIC
>>  DEFINES =DSO_DLFCN HAVE_DLFCN_H OPENSSL_THREADS
>>  OPENSSL_NO_DYNAMIC_ENGINE OPENSSL_PIC OPENSSL_IA32_SSE2
>>  OPENSSL_BN_ASM_MONT OPENSSL_BN_ASM_MONT5 OPENSSL_BN_ASM_GF2m SHA1_ASM
>>  SHA256_ASM SHA512_ASM MD5_ASM AES_ASM VPAES_ASM BSAES_ASM GHASH_ASM
>>  ECP_NISTZ256_ASM POLY1305_ASM
>>  LFLAG =-mt
>>  PLIB_LFLAG =
>>  EX_LIBS =-lresolv -lsocket -lnsl -ldl -lpthread
>>  APPS_OBJ =
>>  CPUID_OBJ =x86_64cpuid.o
>>  UPLINK_OBJ =
>>  BN_ASM =asm/x86_64-gcc.o x86_64-mont.o x86_64-mont5.o x86_64-
>>  gf2m.o rsaz_exp.o rsaz-x86_64.o rsaz-avx2.o
>>  EC_ASM =ecp_nistz256.o ecp_nistz256-x86_64.o
>>  DES_ENC =des_enc.o fcrypt_b.o
>>  AES_ENC =aes-x86_64.o vpaes-x86_64.o bsaes-x86_64.o aesni-
>>  x86_64.o aesni-sha1-x86_64.o aesni-sha256-x86_64.o aesni-mb-x86_64.o
>>  BF_ENC =bf_enc.o
>>  CAST_ENC =c_enc.o
>>  RC4_ENC =rc4-x86_64.o rc4-md5-x86_64.o
>>  RC5_ENC =rc5_enc.o
>>  MD5_OBJ_ASM =md5-x86_64.o
>>  SHA1_OBJ_ASM =sha1-x86_64.o sha256-x86_64.o sha512-x86_64.o sha1-mb-
>>  x86_64.o sha256-mb-x86_64.o
>>  RMD160_OBJ_ASM=
>>  CMLL_ENC =cmll-x86_64.o cmll_misc.o
>>  MODES_OBJ =ghash-x86_64.o aesni-gcm-x86_64.o
>>  PADLOCK_OBJ =e_padlock-x86_64.o
>>  CHACHA_ENC =chacha-x86_64.o
>>  POLY1305_OBJ =poly1305-x86_64.o
>>  BLAKE2_OBJ =
>>  PROCESSOR =
>>  RANLIB =/usr/ccs/bin/ranlib
>>  ARFLAGS =
>>  PERL =/opt/perl5/bin/perl
>> 
>>  SIXTY_FOUR_BIT_LONG mode
>> 
>>  Configured for solaris64-x86_64-cc.
>> 
>> 
>> 
>>  % make
>>  :
>>  make[1]: Entering directory '/tmp/openssl-1.1.0-pre4'
>>  ( :; LIBDEPS="${LIBDEPS:--L. -lssl -L. -lcrypto -lresolv -lsocket
>>  -lnsl -ldl -lpthread }"; LDCMD="${LDCMD:-cc}"; 
> LDFLAGS="${LDFLAGS:--
>>  DDSO_DLFCN -DHAVE_DLFCN_H -DOPENSSL_THREADS
>>  -DOPENSSL_NO_DYNAMIC_ENGINE -DOPENSSL_PIC -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 -DGHASH_ASM -DECP_NISTZ256_ASM -DPOLY1305_ASM
>>  -DOPENSSLDIR="\"/usr/local/ssl\""
>>  -DENGINESDIR="\"/usr/local/lib/engines\"" 
> -xarch=generic64 -xstrconst
>>  -Xa -DL_ENDIAN -xO5 -xdepend -xbuiltin -D_REENTRANT -DFILIO_H -mt}";
>>  LIBPATH=`for x in $LIBDEPS; do echo $x; done | sed -e 's/^ *-L//;t' 
> -e
>>  d | uniq`; LIBPATH=`echo $LIBPATH | sed -e 's/ /:/g'`; echo
>>  LD_LIBRARY_PATH=$LIBPATH:$LD_LIBRARY_PATH ${LDCMD} ${LDFLAGS} -o
>>  ${APPNAME:=apps/openssl} apps/app_rand.o apps/apps.o apps/asn1pars.o
>>  apps/ca.o apps/ciphers.o apps/cms.o apps/crl.o apps/crl2p7.o
>>  apps/dgst.o apps/dhparam.o
>>  apps/dsa.o apps/dsaparam.o apps/ec.o apps/ecparam.o apps/enc.o
>>  apps/engine.o apps/errstr.o apps/gendsa.o apps/genpkey.o apps/genrsa.o
>>  apps/nseq.o apps/ocsp.o apps/openssl.o apps/opt.o apps/passwd.o
>>  apps/pkcs12.o apps/pkcs7.o apps/pkcs8.o apps/pkey.o apps/pkeyparam.o
>>  apps/pkeyutl.o apps/prime.o apps/rand.o apps/rehash.o apps/req.o
>>  apps/rsa.o apps/rsautl.o apps/s_cb.o apps/s_client.o apps/s_server.o
>>  apps/s_socket.o apps/s_time.o apps/sess_id.o apps/smime.o apps/speed.o
>>  apps/spkac.o apps/srp.o apps/ts.o apps/verify.o apps/version.o
>>  apps/x509.o ${LIBDEPS}; LD_LIBRARY_PATH=$LIBPATH:$LD_LIBRARY_PATH
>>  ${LDCMD} ${LDFLAGS} -o ${APPNAME:=apps/openssl} apps/app_rand.o
>>  apps/apps.o apps/asn1pars.o apps/ca.o apps/ciphers.o apps/cms.o
>>  apps/crl.o apps/crl2p7.o apps/dgst.o apps/dhparam.o apps/dsa.o
>>  apps/dsaparam.o apps/ec.o apps/ecparam.o apps/enc.o apps/engine.o
>>  apps/errstr.o apps/gendsa.o apps/genpkey.o apps/genrsa.o apps/nseq.o
>>  apps/ocsp.o apps/openssl.o apps/opt.o
>>  apps/passwd.o apps/pkcs12.o apps/pkcs7.o apps/pkcs8.o apps/pkey.o
>>  apps/pkeyparam.o apps/pkeyutl.o apps/prime.o apps/rand.o apps/rehash.o
>>  apps/req.o apps/rsa.o apps/rsautl.o apps/s_cb.o apps/s_client.o
>>  apps/s_server.o apps/s_socket.o apps/s_time.o apps/sess_id.o
>>  apps/smime.o apps/speed.o apps/spkac.o apps/srp.o apps/ts.o
>>  apps/verify.o apps/version.o apps/x509.o ${LIBDEPS} )
>> 
> LD_LIBRARY_PATH=.:/opt/openssl/lib:/opt/local/lib:/usr/local/lib:/opt/local/locale/lib:/opt/SUNWspro/lib:/usr/jdk/latest/lib:/opt/netpbm/lib:/usr/sfw/lib:/usr/lib:/usr/lib/iconv:/usr/lib/locale/ja:/opt/sfw/lib:/opt/sfw/netpbm/link:/usr/openwin/lib/locale/ja:/usr/openwin/lib/locale/common:/usr/openwin/lib:/usr/java/lib:/opt/coreutils/libexec/coreutils
>>  cc -mt -o apps/openssl apps/app_rand.o apps/apps.o apps/asn1pars.o
>>  apps/ca.o apps/ciphers.o apps/cms.o apps/crl.o apps/crl2p7.o
>>  apps/dgst.o apps/dhparam.o apps/dsa.o apps/dsaparam.o apps/ec.o
>>  apps/ecparam.o apps/enc.o apps/engine.o apps/errstr.o apps/gendsa.o
>>  apps/genpkey.o apps/genrsa.o apps/nseq.o apps/ocsp.o apps/openssl.o
>>  apps/opt.o apps/passwd.o apps/pkcs12.o apps/pkcs7.o apps/pkcs8.o
>>  apps/pkey.o apps/pkeyparam.o apps/pkeyutl.o apps/prime.o apps/rand.o
>>  apps/rehash.o apps/req.o apps/rsa.o apps/rsautl.o apps/s_cb.o
>>  apps/s_client.o apps/s_server.o apps/s_socket.o apps/s_time.o
>>  apps/sess_id.o apps/smime.o
>>  apps/speed.o apps/spkac.o apps/srp.o apps/ts.o apps/verify.o
>>  apps/version.o apps/x509.o -L. -lssl -L. -lcrypto -lresolv -lsocket
>>  -lnsl -ldl -lpthread
>>  ld: fatal: file apps/app_rand.o: wrong ELF class: ELFCLASS64
>>  ld: fatal: file processing errors. No output written to apps/openssl
>>  Makefile.shared:186: recipe for target 'link_app.' failed
>>  make[1]: *** [link_app.] Error 2
>>  make[1]: Leaving directory '/tmp/openssl-1.1.0-pre4'
>>  Makefile:8687: recipe for target 'apps/openssl' failed
>>  make: *** [apps/openssl] Error 2
>> 
>> 
>>  Patch for this:
>>  diff ../openssl-1.1.0-pre4.orig/Configurations/10-main.conf
>>  Configurations/10-main.conf
>>  196c196
>>  < lflags => add(threads("-mt")),
>>  ---
>>  > lflags => add(threads("-mt -m64")),
>> 
>> 
>>  It seems to be better to change '-xarch=generic64' to 
> '-m64' in line
>>  196 & 201 of the same file, too.
>> 
>> 
>>  Best Regards,
>> 
>>  --- Kiyoshi <yoi_no_myoujou at yahoo.co.jp>
> 
> 
> --
> Richard Levitte
> levitte at openssl.org
> 
> -- 
> Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4453
> Please log in as guest with password guest if prompted
>


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


From rt at openssl.org  Wed May 11 15:58:27 2016
From: rt at openssl.org (Stephen Henson via RT)
Date: Wed, 11 May 2016 15:58:27 +0000
Subject: [openssl-dev] [openssl.org #4236] SSL_connect() crash with CRL
In-Reply-To: <alpine.DEB.2.20.1601141800240.15657@tvnag.unkk.fr>
References: <RT-Ticket-4236@openssl.org>
 <alpine.DEB.2.20.1601141800240.15657@tvnag.unkk.fr>
Message-ID: <rt-4.0.19-18545-1462982307-498.4236-6-0@openssl.org>

On Thu Jan 14 17:08:13 2016, daniel at haxx.se wrote:
> Hey
>
> I've had this crash for a while with current openssl git master. It is
> perfectly reproducable using curl test 313 and I have an openssl build
> here
> with debug symbols so I can provide more info to help someone diagnose
> this,
> just let me know.
>

I've pulled the latest curl using git and OpenSSL master. I had to make one
minor change to curl to get it to compile. I can't reproduce the problem with
test 313: it seems to work fine. I've tried it using the verify utility and
s_serrver/s_client too and all work.

Can you give more details of your setup and how you're compiling OpenSSL/curl?
Can you reproduce the problem using verify or s_client/s_server?

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=4236
Please log in as guest with password guest if prompted


From rt at openssl.org  Wed May 11 16:08:10 2016
From: rt at openssl.org (Thomas, Marc via RT)
Date: Wed, 11 May 2016 16:08:10 +0000
Subject: [openssl-dev] [openssl.org #4539] Documentation - Cipher names
	changed between 1.0.2 & 1.1.0-pre
In-Reply-To: <8DC50C7F6B759747ADDC8B292F116D7C22537B64@MX102CL02.corp.emc.com>
References: <RT-Ticket-4539@openssl.org>
 <8DC50C7F6B759747ADDC8B292F116D7C22537B64@MX102CL02.corp.emc.com>
Message-ID: <rt-4.0.19-5499-1462982890-1319.4539-21-0@openssl.org>

Hello Folks,

I'd like to suggest the "ciphers" documentation in 1.1.0 be updated to include the old EDH names for ciphers which were renamed to DHE between 1.0.2 & 1.1.0-pre.
I think there are only two affected which are still available: EDH-RSA-DES-CBC3-SHA & EDH-DSS-DES-CBC3-SHA.

https://www.openssl.org/docs/manmaster/apps/ciphers.html

So, for example:

SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA    DHE-DSS-DES-CBC3-SHA (OpenSSL 1.1.0 onwards, ignored by earlier versions)
SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA    EDH-DSS-DES-CBC3-SHA (pre OpenSSL 1.1.0, accepted as an alias by OpenSSL 1.1.0)
SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA    DHE-RSA-DES-CBC3-SHA (OpenSSL 1.1.0 onwards, ignored by earlier versions)
SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA    EDH-RSA-DES-CBC3-SHA (pre OpenSSL 1.1.0, accepted as an alias by OpenSSL 1.1.0)

TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA    DHE-DSS-DES-CBC3-SHA (OpenSSL 1.1.0 onwards, ignored by earlier versions)
TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA    EDH-DSS-DES-CBC3-SHA (pre OpenSSL 1.1.0, accepted as an alias by OpenSSL 1.1.0)
TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA    DHE-RSA-DES-CBC3-SHA (OpenSSL 1.1.0 onwards, ignored by earlier versions)
TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA    EDH-RSA-DES-CBC3-SHA (pre OpenSSL 1.1.0, accepted as an alias by OpenSSL 1.1.0)


The reason for asking is the old names are preferable for backwards compatibility with earlier versions of OpenSSL.

Thanks & Kind Regards,

Marc Thomas
Field Support Specialist, Customer Service

EMC Computer Systems (UK) Limited
Business Address: EMC Tower, Great West Road, Brentford, TW8 9AN

[CS Email Signature - LATEST]

EMC Computer Systems (UK) Limited
Registered in England No. 2051360  Registered office address: Level 1, Exchange House, Primrose Street, London EC2A 2EG.
The information contained in this e-mail message and any files transmitted with it are confidential. It is intended only for the addressee and others authorised to receive it. If you are not the intended recipient or the person responsible for delivering the message to the intended recipient, you are advised that you have received the e-mail in error; please delete it and notify the sender immediately. You should not retain the message or disclose its contents to anyone. Any disclosure, copying, distribution or action taken in reliance on the contents of the e-mail and its attachments is strictly prohibited.


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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.jpg
Type: image/jpeg
Size: 31111 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20160511/6dbb5af6/attachment-0001.jpg>

From viktor.kolodrevskiy at gmail.com  Wed May 11 16:19:59 2016
From: viktor.kolodrevskiy at gmail.com (Viktor Kolodrevskiy)
Date: Wed, 11 May 2016 19:19:59 +0300
Subject: [openssl-dev] smime-certs certificates are expired in 1.0.1 sources
Message-ID: <CAMjfUZnHAPzOBaRTBuSDoGJv=-r0-ofjuZAxM8MFx=K8J0xibQ@mail.gmail.com>

Cert files under
openssl-1.0.1t/test/smime-certs are expired on May 11 2016.
This makes cms-test.pl test to fail while running "make test".
Reproduced on Linux.
I think they should be updated since when cms-test.pl is failing it?s
not quite clear why it fails.
Had to go inside that test and understand what it?s doing. I think
many users will start to post this issue.
What do you think?

-- 
Thanks,
Viktor

From ca+ssl-dev at esmtp.org  Wed May 11 16:23:53 2016
From: ca+ssl-dev at esmtp.org (Claus Assmann)
Date: Wed, 11 May 2016 09:23:53 -0700
Subject: [openssl-dev] 1.0.1t: test fails due to expired cert
In-Reply-To: <94A48783-8CD1-450F-BCC1-72B964362776@dukhovni.org>
References: <20160511034501.GA14975@x2.esmtp.org>
 <94A48783-8CD1-450F-BCC1-72B964362776@dukhovni.org>
Message-ID: <20160511162353.GA22092@x2.esmtp.org>

On Tue, May 10, 2016, Viktor Dukhovni wrote:

[looks like there are at least three different threads now?
hence I made the Subject a bit more generic.]

> > 34371851688:error:21075075:PKCS7 routines:PKCS7_verify:certificate verify error:pk7_smime.c:328:Verify error:certificate has expired

> Some of the certs in the 1.0.x test suite are getting old, and it looks
> like some have expired.  In "master", I generated new certificates for

For my software I run a script before release which ensures that
the included (test) certificates are valid for "some time". Maybe
such a test should be included in the release build process (or
maybe run the tests before release with a date several months into
the future)?

From rt at openssl.org  Wed May 11 16:26:35 2016
From: rt at openssl.org (Kaduk, Ben via RT)
Date: Wed, 11 May 2016 16:26:35 +0000
Subject: [openssl-dev] [openssl.org #3723] Patch to add short name "Email"
	to "emailAddress" object
In-Reply-To: <57335D38.1020103@akamai.com>
References: <RT-Ticket-3723@openssl.org> <57335D38.1020103@akamai.com>
Message-ID: <rt-4.0.19-18545-1462983995-681.3723-6-0@openssl.org>

As a bit of follow-up here, it looks like the behavior changed from
using "Email" as a shortname for this attribute to just using the long
form "emailAddress" in commit  30911232c17f309f947156959fcbbf504c1b66fe
back in 2002.  The commit message there was pretty sparse, "Some more
OID enhancements", and there does not seem to be any particular
justification for that change.

However, we've been through a few release series since then, so perhaps
the current behavior is sufficiently "well-established" that it's not
worth reverting back to the historical behavior.

If that's the case, this ticket should probably be closed; if not, we
should be able to come up with a patch that applies cleanly to current
master.

-Ben


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


From rt at openssl.org  Wed May 11 18:04:49 2016
From: rt at openssl.org (Stephen Henson via RT)
Date: Wed, 11 May 2016 18:04:49 +0000
Subject: [openssl-dev] [openssl.org #4363] [PATCH] Adding missing
	BN_CTX_(start/end) in crypto/ec/ec_key.c
In-Reply-To: <CANduzxBYuhrQQ7X_fnXdFwXEfnqqZP7psdjj8bEZ7tGrK0PRRg@mail.gmail.com>
References: <RT-Ticket-4363@openssl.org>
 <CANduzxBYuhrQQ7X_fnXdFwXEfnqqZP7psdjj8bEZ7tGrK0PRRg@mail.gmail.com>
Message-ID: <rt-4.0.19-18545-1462989889-1257.4363-6-0@openssl.org>

Applied, 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=4363
Please log in as guest with password guest if prompted


From rt at openssl.org  Wed May 11 19:52:04 2016
From: rt at openssl.org (Stephen Henson via RT)
Date: Wed, 11 May 2016 19:52:04 +0000
Subject: [openssl-dev] [openssl.org #4442] PATCH: fix typo in AF_ALG engine
	name
In-Reply-To: <CAH8yC8nN9EmsDggwvekyOxne4P0FKD18hO33Ck_o5z8ANOm0Ag@mail.gmail.com>
References: <RT-Ticket-4442@openssl.org>
 <CAH8yC8nN9EmsDggwvekyOxne4P0FKD18hO33Ck_o5z8ANOm0Ag@mail.gmail.com>
Message-ID: <rt-4.0.19-18545-1462996324-1340.4442-6-0@openssl.org>

Thanks, applied.

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=4442
Please log in as guest with password guest if prompted


From rt at openssl.org  Wed May 11 19:53:14 2016
From: rt at openssl.org (Richard Levitte via RT)
Date: Wed, 11 May 2016 19:53:14 +0000
Subject: [openssl-dev] [openssl.org #4452] openssl-1.1.0-pre4: undefined
	symbol for solaris-x86-cc
In-Reply-To: <rt-4.0.19-18545-1462978629-983.4452-6-0@openssl.org>
References: <RT-Ticket-4452@openssl.org>
 <747648.50843.qm@web101220.mail.kks.yahoo.co.jp>
 <rt-4.0.19-1915-1458424415-879.4452-6-0@openssl.org>
 <550057.6653.qm@web101214.mail.kks.yahoo.co.jp>
 <777156.81532.qm@web101215.mail.kks.yahoo.co.jp>
 <rt-4.0.19-19985-1458556925-1313.4452-6-0@openssl.org>
 <rt-4.0.19-18545-1462913877-1156.4452-6-0@openssl.org>
 <936104.55478.qm@web101209.mail.kks.yahoo.co.jp>
 <rt-4.0.19-18545-1462978629-983.4452-6-0@openssl.org>
Message-ID: <rt-4.0.19-18545-1462996394-1662.4452-6-0@openssl.org>

Thank you. Closing this ticket.

On Wed May 11 14:57:09 2016, yoi_no_myoujou at yahoo.co.jp wrote:
> Hello,
>
> It is fixed in openssl-1.1.0-pre5.
>
> Thanks,
>
> --- Kiyoshi <yoi_no_myoujou at yahoo.co.jp>
>
>
>
>
> ----- Original Message -----
> > From: Richard Levitte via RT <rt at openssl.org>
> > To: yoi_no_myoujou at yahoo.co.jp
> > Cc: openssl-dev at openssl.org
> > Date: 2016/5/11, Wed 05:57
> > Subject: [openssl.org #4452] openssl-1.1.0-pre4: undefined symbol for
> > solaris-x86-cc
> >
> > Hi,
> >
> > that looks like engines/asm/e_padlock_x86.o wasn't built for some
> > reason, even
> > though it should.
> >
> > I would like it if you gave me a full log, or in other words, send me
> > build.log
> > after running this:
> >
> > (set -x; ./Configure solaris-x86-cc shared; make) > build.log 2>&1
> >
> > Cheers,
> > Richard
> >
> > On Mon Mar 21 10:42:05 2016, yoi_no_myoujou at yahoo.co.jp wrote:
> >> % ../Configure solaris-x86-cc shared; make; make test
> >> also passes.
> >>
> >> Regards,
> >>
> >> --- Kiyoshi <yoi_no_myoujou at yahoo.co.jp>
> >>
> >>
> >>
> >>
> >>
> >> > Tried with openssl-SNAP-20160320,
> >> > but have the same result, not fixed yet.
> >> >
> >> >
> >> > Regards,
> >> >
> >> > --- Kiyoshi <yoi_no_myoujou at yahoo.co.jp>
> >> >
> >> >
> >> >
> >> >
> >> >> If you have the possibility, please try a fresh checkout of the
> >> >> master
> >> > branch
> >> >> and see if this is fixed.
> >> >>
> >> >> Cheers,
> >> >> Richard
> >> >>
> >> >> Vid Sat, 19 Mar 2016 kl. 10.55.59, skrev
> >> >> yoi_no_myoujou at yahoo.co.jp:
> >> >>> With patch for #4444,
> >> >>>
> >> >>> % mkdir build_solaris-x86-cc
> >> >>> % cd build_solaris-x86-cc
> >> >>> % ../Configure solaris-x86-cc
> >> >>> % make
> >> >>> :
> >> >>> Undefined first referenced
> >> >>> symbol in file
> >> >>> padlock_xstore ./libcrypto.a(e_padlock.o)
> >> >>> padlock_capability ./libcrypto.a(e_padlock.o)
> >> >>> padlock_reload_key ./libcrypto.a(e_padlock.o)
> >> >>> padlock_ctr32_encrypt ./libcrypto.a(e_padlock.o)
> >> >>> padlock_key_bswap ./libcrypto.a(e_padlock.o)
> >> >>> padlock_cbc_encrypt ./libcrypto.a(e_padlock.o)
> >> >>> padlock_cfb_encrypt ./libcrypto.a(e_padlock.o)
> >> >>> padlock_ecb_encrypt ./libcrypto.a(e_padlock.o)
> >> >>> padlock_ofb_encrypt ./libcrypto.a(e_padlock.o)
> >> >>> padlock_aes_block ./libcrypto.a(e_padlock.o)
> >> >>> ld: fatal: symbol referencing errors. No output written to
> >> > apps/openssl
> >> >>> ../Makefile.shared:186: recipe for target 'link_app.' failed
> >> >>> make[1]: *** [link_app.] Error 2
> >> >>>
> >> >>>
> >> >>> % ../Configure solaris-x86-cc no-asm
> >> >>>
> >> >>> % make
> >> >>> % make test
> >> >>> passes.
> >> >>>
> >> >>>
> >> >>> OS: Solaris10 x86/x64
> >> >>> cc: /opt/solarisstudio12.4/bin/cc
> >> >>>
> >> >>>
> >> >>> Best Regards,
> >> >>>
> >> >>> --- Kiyoshi <yoi_no_myoujou at yahoo.co.jp>
> >> >>>
> >> >>>
> >> >>
> >> >>
> >> >> --
> >> >> Richard Levitte
> >> >> levitte at openssl.org
> >> >>
> >> >> --
> >> >> Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4452
> >> >> Please log in as guest with password guest if prompted
> >> >>
> >> >
> >>
> >
> >
> > --
> > Richard Levitte
> > levitte at openssl.org
> >
> > --
> > Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4452
> > Please log in as guest with password guest if prompted
> >
> >
> >
> >


--
Richard Levitte
levitte at openssl.org

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


From rt at openssl.org  Wed May 11 19:53:39 2016
From: rt at openssl.org (Richard Levitte via RT)
Date: Wed, 11 May 2016 19:53:39 +0000
Subject: [openssl-dev] [openssl.org #4453] openssl-1.1.0-pre4: make fails
	with 'wrong ELF class: ELFCLASS64' on solaris64-x86_64-cc
In-Reply-To: <rt-4.0.19-5499-1462979749-1143.4453-6-0@openssl.org>
References: <RT-Ticket-4453@openssl.org>
 <173729.2988.qm@web101210.mail.kks.yahoo.co.jp>
 <rt-4.0.19-5499-1462914109-1337.4453-6-0@openssl.org>
 <632791.48237.qm@web101205.mail.kks.yahoo.co.jp>
 <rt-4.0.19-5499-1462979749-1143.4453-6-0@openssl.org>
Message-ID: <rt-4.0.19-5499-1462996419-1967.4453-6-0@openssl.org>

Thank you. Closing this ticket.

On Wed May 11 15:15:49 2016, yoi_no_myoujou at yahoo.co.jp wrote:
> Hi,
>
> Checked with openssl-1.1.0-pre5,
> and confirmed it is fixed.
>
> Thanks,
>
> --- Kiyoshi <yoi_no_myoujou at yahoo.co.jp>
>
>
>
>
> ----- Original Message -----
> > From: Richard Levitte via RT <rt at openssl.org>
> > To: yoi_no_myoujou at yahoo.co.jp
> > Cc: openssl-dev at openssl.org
> > Date: 2016/5/11, Wed 06:01
> > Subject: [openssl.org #4453] openssl-1.1.0-pre4: make fails with
> > 'wrong ELF class: ELFCLASS64' on solaris64-x86_64-cc
> >
> > Hi,
> >
> > would you mind checking again with the latest beta or a fresh master
> > checkout?
> > It looks to me like this issue is fixed, but I want to make sure.
> >
> > Cheers,
> > Richard
> >
> > On Sat Mar 19 10:56:00 2016, yoi_no_myoujou at yahoo.co.jp wrote:
> >> Hello,
> >>
> >> Tested with patch for #4444, and removing gcc from path.
> >>
> >> % ./config
> >> Operating system: i86pc-whatever-solaris2
> >> Configuring for solaris64-x86_64-cc
> >> Configuring OpenSSL version 1.1.0-pre4 (0x0x10100004L)
> >> no-crypto-mdebug [default] OPENSSL_NO_CRYPTO_MDEBUG (skip dir)
> >> no-crypto-mdebug-backtrace [forced]
> >> OPENSSL_NO_CRYPTO_MDEBUG_BACKTRACE (skip dir)
> >> no-dynamic-engine [forced]
> >> 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-heartbeats [default] OPENSSL_NO_HEARTBEATS (skip dir)
> >> no-md2 [default] OPENSSL_NO_MD2 (skip dir)
> >> no-rc5 [default] OPENSSL_NO_RC5 (skip dir)
> >> no-sctp [default] OPENSSL_NO_SCTP (skip dir)
> >> no-shared [default]
> >> 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-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 solaris64-x86_64-cc
> >> IsMK1MF =no
> >> CC =cc
> >> CFLAG =-xarch=generic64 -xstrconst -Xa -DL_ENDIAN -xO5
> >> -xdepend -xbuiltin -D_REENTRANT -DFILIO_H
> >> SHARED_CFLAG =-KPIC
> >> DEFINES =DSO_DLFCN HAVE_DLFCN_H OPENSSL_THREADS
> >> OPENSSL_NO_DYNAMIC_ENGINE OPENSSL_PIC OPENSSL_IA32_SSE2
> >> OPENSSL_BN_ASM_MONT OPENSSL_BN_ASM_MONT5 OPENSSL_BN_ASM_GF2m
> >> SHA1_ASM
> >> SHA256_ASM SHA512_ASM MD5_ASM AES_ASM VPAES_ASM BSAES_ASM GHASH_ASM
> >> ECP_NISTZ256_ASM POLY1305_ASM
> >> LFLAG =-mt
> >> PLIB_LFLAG =
> >> EX_LIBS =-lresolv -lsocket -lnsl -ldl -lpthread
> >> APPS_OBJ =
> >> CPUID_OBJ =x86_64cpuid.o
> >> UPLINK_OBJ =
> >> BN_ASM =asm/x86_64-gcc.o x86_64-mont.o x86_64-mont5.o x86_64-
> >> gf2m.o rsaz_exp.o rsaz-x86_64.o rsaz-avx2.o
> >> EC_ASM =ecp_nistz256.o ecp_nistz256-x86_64.o
> >> DES_ENC =des_enc.o fcrypt_b.o
> >> AES_ENC =aes-x86_64.o vpaes-x86_64.o bsaes-x86_64.o aesni-
> >> x86_64.o aesni-sha1-x86_64.o aesni-sha256-x86_64.o aesni-mb-x86_64.o
> >> BF_ENC =bf_enc.o
> >> CAST_ENC =c_enc.o
> >> RC4_ENC =rc4-x86_64.o rc4-md5-x86_64.o
> >> RC5_ENC =rc5_enc.o
> >> MD5_OBJ_ASM =md5-x86_64.o
> >> SHA1_OBJ_ASM =sha1-x86_64.o sha256-x86_64.o sha512-x86_64.o sha1-mb-
> >> x86_64.o sha256-mb-x86_64.o
> >> RMD160_OBJ_ASM=
> >> CMLL_ENC =cmll-x86_64.o cmll_misc.o
> >> MODES_OBJ =ghash-x86_64.o aesni-gcm-x86_64.o
> >> PADLOCK_OBJ =e_padlock-x86_64.o
> >> CHACHA_ENC =chacha-x86_64.o
> >> POLY1305_OBJ =poly1305-x86_64.o
> >> BLAKE2_OBJ =
> >> PROCESSOR =
> >> RANLIB =/usr/ccs/bin/ranlib
> >> ARFLAGS =
> >> PERL =/opt/perl5/bin/perl
> >>
> >> SIXTY_FOUR_BIT_LONG mode
> >>
> >> Configured for solaris64-x86_64-cc.
> >>
> >>
> >>
> >> % make
> >> :
> >> make[1]: Entering directory '/tmp/openssl-1.1.0-pre4'
> >> ( :; LIBDEPS="${LIBDEPS:--L. -lssl -L. -lcrypto -lresolv -lsocket
> >> -lnsl -ldl -lpthread }"; LDCMD="${LDCMD:-cc}";
> > LDFLAGS="${LDFLAGS:--
> >> DDSO_DLFCN -DHAVE_DLFCN_H -DOPENSSL_THREADS
> >> -DOPENSSL_NO_DYNAMIC_ENGINE -DOPENSSL_PIC -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 -DGHASH_ASM -DECP_NISTZ256_ASM -DPOLY1305_ASM
> >> -DOPENSSLDIR="\"/usr/local/ssl\""
> >> -DENGINESDIR="\"/usr/local/lib/engines\""
> > -xarch=generic64 -xstrconst
> >> -Xa -DL_ENDIAN -xO5 -xdepend -xbuiltin -D_REENTRANT -DFILIO_H -mt}";
> >> LIBPATH=`for x in $LIBDEPS; do echo $x; done | sed -e 's/^ *-L//;t'
> > -e
> >> d | uniq`; LIBPATH=`echo $LIBPATH | sed -e 's/ /:/g'`; echo
> >> LD_LIBRARY_PATH=$LIBPATH:$LD_LIBRARY_PATH ${LDCMD} ${LDFLAGS} -o
> >> ${APPNAME:=apps/openssl} apps/app_rand.o apps/apps.o apps/asn1pars.o
> >> apps/ca.o apps/ciphers.o apps/cms.o apps/crl.o apps/crl2p7.o
> >> apps/dgst.o apps/dhparam.o
> >> apps/dsa.o apps/dsaparam.o apps/ec.o apps/ecparam.o apps/enc.o
> >> apps/engine.o apps/errstr.o apps/gendsa.o apps/genpkey.o
> >> apps/genrsa.o
> >> apps/nseq.o apps/ocsp.o apps/openssl.o apps/opt.o apps/passwd.o
> >> apps/pkcs12.o apps/pkcs7.o apps/pkcs8.o apps/pkey.o apps/pkeyparam.o
> >> apps/pkeyutl.o apps/prime.o apps/rand.o apps/rehash.o apps/req.o
> >> apps/rsa.o apps/rsautl.o apps/s_cb.o apps/s_client.o apps/s_server.o
> >> apps/s_socket.o apps/s_time.o apps/sess_id.o apps/smime.o
> >> apps/speed.o
> >> apps/spkac.o apps/srp.o apps/ts.o apps/verify.o apps/version.o
> >> apps/x509.o ${LIBDEPS}; LD_LIBRARY_PATH=$LIBPATH:$LD_LIBRARY_PATH
> >> ${LDCMD} ${LDFLAGS} -o ${APPNAME:=apps/openssl} apps/app_rand.o
> >> apps/apps.o apps/asn1pars.o apps/ca.o apps/ciphers.o apps/cms.o
> >> apps/crl.o apps/crl2p7.o apps/dgst.o apps/dhparam.o apps/dsa.o
> >> apps/dsaparam.o apps/ec.o apps/ecparam.o apps/enc.o apps/engine.o
> >> apps/errstr.o apps/gendsa.o apps/genpkey.o apps/genrsa.o apps/nseq.o
> >> apps/ocsp.o apps/openssl.o apps/opt.o
> >> apps/passwd.o apps/pkcs12.o apps/pkcs7.o apps/pkcs8.o apps/pkey.o
> >> apps/pkeyparam.o apps/pkeyutl.o apps/prime.o apps/rand.o
> >> apps/rehash.o
> >> apps/req.o apps/rsa.o apps/rsautl.o apps/s_cb.o apps/s_client.o
> >> apps/s_server.o apps/s_socket.o apps/s_time.o apps/sess_id.o
> >> apps/smime.o apps/speed.o apps/spkac.o apps/srp.o apps/ts.o
> >> apps/verify.o apps/version.o apps/x509.o ${LIBDEPS} )
> >>
> >
LD_LIBRARY_PATH=.:/opt/openssl/lib:/opt/local/lib:/usr/local/lib:/opt/local/locale/lib:/opt/SUNWspro/lib:/usr/jdk/latest/lib:/opt/netpbm/lib:/usr/sfw/lib:/usr/lib:/usr/lib/iconv:/usr/lib/locale/ja:/opt/sfw/lib:/opt/sfw/netpbm/link:/usr/openwin/lib/locale/ja:/usr/openwin/lib/locale/common:/usr/openwin/lib:/usr/java/lib:/opt/coreutils/libexec/coreutils
> >> cc -mt -o apps/openssl apps/app_rand.o apps/apps.o apps/asn1pars.o
> >> apps/ca.o apps/ciphers.o apps/cms.o apps/crl.o apps/crl2p7.o
> >> apps/dgst.o apps/dhparam.o apps/dsa.o apps/dsaparam.o apps/ec.o
> >> apps/ecparam.o apps/enc.o apps/engine.o apps/errstr.o apps/gendsa.o
> >> apps/genpkey.o apps/genrsa.o apps/nseq.o apps/ocsp.o apps/openssl.o
> >> apps/opt.o apps/passwd.o apps/pkcs12.o apps/pkcs7.o apps/pkcs8.o
> >> apps/pkey.o apps/pkeyparam.o apps/pkeyutl.o apps/prime.o apps/rand.o
> >> apps/rehash.o apps/req.o apps/rsa.o apps/rsautl.o apps/s_cb.o
> >> apps/s_client.o apps/s_server.o apps/s_socket.o apps/s_time.o
> >> apps/sess_id.o apps/smime.o
> >> apps/speed.o apps/spkac.o apps/srp.o apps/ts.o apps/verify.o
> >> apps/version.o apps/x509.o -L. -lssl -L. -lcrypto -lresolv -lsocket
> >> -lnsl -ldl -lpthread
> >> ld: fatal: file apps/app_rand.o: wrong ELF class: ELFCLASS64
> >> ld: fatal: file processing errors. No output written to apps/openssl
> >> Makefile.shared:186: recipe for target 'link_app.' failed
> >> make[1]: *** [link_app.] Error 2
> >> make[1]: Leaving directory '/tmp/openssl-1.1.0-pre4'
> >> Makefile:8687: recipe for target 'apps/openssl' failed
> >> make: *** [apps/openssl] Error 2
> >>
> >>
> >> Patch for this:
> >> diff ../openssl-1.1.0-pre4.orig/Configurations/10-main.conf
> >> Configurations/10-main.conf
> >> 196c196
> >> < lflags => add(threads("-mt")),
> >> ---
> >> > lflags => add(threads("-mt -m64")),
> >>
> >>
> >> It seems to be better to change '-xarch=generic64' to
> > '-m64' in line
> >> 196 & 201 of the same file, too.
> >>
> >>
> >> Best Regards,
> >>
> >> --- Kiyoshi <yoi_no_myoujou at yahoo.co.jp>
> >
> >
> > --
> > Richard Levitte
> > levitte at openssl.org
> >
> > --
> > Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4453
> > Please log in as guest with password guest if prompted
> >


--
Richard Levitte
levitte at openssl.org

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


From rt at openssl.org  Wed May 11 20:03:58 2016
From: rt at openssl.org (Richard Levitte via RT)
Date: Wed, 11 May 2016 20:03:58 +0000
Subject: [openssl-dev] [openssl.org #4324] openssl-1.1.0-pre3 with
	solaris-x86-cc & solaris64-x86_64-cc make fails
In-Reply-To: <rt-4.0.19-5499-1462978867-1059.4324-6-0@openssl.org>
References: <RT-Ticket-4324@openssl.org>
 <521557.3312.qm@web101212.mail.kks.yahoo.co.jp>
 <845222.20757.qm@web101214.mail.kks.yahoo.co.jp>
 <rt-4.0.19-3310-1456410990-592.4324-6-0@openssl.org>
 <rt-4.0.19-18545-1462912191-1476.4324-6-0@openssl.org>
 <69551.59647.qm@web101207.mail.kks.yahoo.co.jp>
 <rt-4.0.19-5499-1462978867-1059.4324-6-0@openssl.org>
Message-ID: <rt-4.0.19-18545-1462997038-1903.4324-6-0@openssl.org>

Thank you. Closing this ticket.

On Wed May 11 15:01:07 2016, yoi_no_myoujou at yahoo.co.jp wrote:
> Hello,
>
> They are fixed in openssl-1.1.0-pre5.
>
> Regards,
>
>
> --- Kiyoshi <yoi_no_myoujou at yahoo.co.jp>
>
>
>
>
> ----- Original Message -----
> > From: Richard Levitte via RT <rt at openssl.org>
> > To: yoi_no_myoujou at yahoo.co.jp
> > Cc: openssl-dev at openssl.org
> > Date: 2016/5/11, Wed 05:29
> > Subject: [openssl.org #4324] openssl-1.1.0-pre3 with solaris-x86-cc &
> > solaris64-x86_64-cc make fails
> >
> > Hi,
> >
> > Sorry for taking so long to get back to you.
> >
> > Would you mind trying again with a fresh master, or with the latest
> > beta? Quite
> > a lot has happened, especially in Makefile.shared and exactly around
> > the stuff
> > you have reported, so I'm hopeful things will work better for you
> > now.
> >
> > Cheers,
> > Richard
> >
> > On Thu Feb 25 14:36:30 2016, yoi_no_myoujou at yahoo.co.jp wrote:
> >> With the following patch,
> >> % ./Configure --unified solaris-x86-cc
> >> % make
> >> % make test
> >> passed.
> >>
> >> % ./Configure --unifiedsolaris64-x86_64-cc; make; make test
> >> also passed.
> >>
> >>
> >> This patch was written comparing to openssl-1.0.2f.
> >>
> >> It has side effect for other configurations.
> >> Please add some conditions.
> >>
> >>
> >> diff -cr ../openssl-1.1.0-pre3.orig/Makefile.shared
> >> ./Makefile.shared
> >> *** ../openssl-1.1.0-pre3.orig/Makefile.shared 2016-02-16
> >> 03:08:07.000000000 +0900
> >> --- ./Makefile.shared 2016-02-25 22:57:23.347187336 +0900
> >> ***************
> >> *** 398,409 ****
> >> ($(CC) -v 2>&1 | grep gcc) > /dev/null &&
> > MINUSZ='-Wl,-z,'; \
> >> SHLIB=lib$(LIBNAME).so; \
> >> SHLIB_SUFFIX=;\
> >> ! if [ $(LIBNAME) != "crypto" -a $(LIBNAME) != "ssl" ];
> > then \
> >> ALLSYMSFLAGS="$${MINUSZ}allextract"; \
> >> ! else \
> >> ! $(PERL) $(SRCDIR)/util/mkdef.pl $(LIBNAME) linux
> >> > $(LIBNAME).map; \
> >> ! ALLSYMSFLAGS="$${MINUSZ}allextract,-M,$(LIBNAME).map"; \
> >> ! fi; \
> >> NOALLSYMSFLAGS="$${MINUSZ}defaultextract"; \
> >> SHAREDFLAGS="$(CFLAGS) $(SHARED_LDFLAGS) -h
> >> $$SHLIB$$SHLIB_SOVER$$SHLIB_SUFFIX -Wl,-Bsymbolic"; \
> >> fi; \
> >> --- 398,409 ----
> >> ($(CC) -v 2>&1 | grep gcc) > /dev/null &&
> > MINUSZ='-Wl,-z,'; \
> >> SHLIB=lib$(LIBNAME).so; \
> >> SHLIB_SUFFIX=;\
> >> ! # if [ $(LIBNAME) != "crypto" -a $(LIBNAME) != "ssl"
> > ]; then \
> >> ALLSYMSFLAGS="$${MINUSZ}allextract"; \
> >> ! # else \
> >> ! # $(PERL) $(SRCDIR)/util/mkdef.pl $(LIBNAME) linux
> >> > $(LIBNAME).map; \
> >> ! # ALLSYMSFLAGS="$${MINUSZ}allextract,-M,$(LIBNAME).map"; \
> >> ! # fi; \
> >> NOALLSYMSFLAGS="$${MINUSZ}defaultextract"; \
> >> SHAREDFLAGS="$(CFLAGS) $(SHARED_LDFLAGS) -h
> >> $$SHLIB$$SHLIB_SOVER$$SHLIB_SUFFIX -Wl,-Bsymbolic"; \
> >> fi; \
> >
> >
> > --
> > Richard Levitte
> > levitte at openssl.org
> >
> > --
> > Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4324
> > Please log in as guest with password guest if prompted
> >


--
Richard Levitte
levitte at openssl.org

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


From rsalz at akamai.com  Wed May 11 20:59:45 2016
From: rsalz at akamai.com (Salz, Rich)
Date: Wed, 11 May 2016 20:59:45 +0000
Subject: [openssl-dev] How to contribute patches has changed
Message-ID: <e0710c072a454aaa93d923f9c2d480cd@usma1ex-dag1mb1.msg.corp.akamai.com>

We've updated our preferred way to submit patches.  Please see the CONTRIBUTING file, which you can find here (among other places):
   https://github.com/openssl/openssl/blob/master/CONTRIBUTING

The summary could be phrase as "just open a GitHub PR, no need to deal with RT"

We hope this will make community involvement easier on everyone.

Thanks!

--
Senior Architect, Akamai Technologies
IM: richsalz at jabber.at Twitter: RichSalz

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20160511/1e9a1be6/attachment.html>

From xoloki at gmail.com  Wed May 11 21:02:48 2016
From: xoloki at gmail.com (Joey Yandle)
Date: Wed, 11 May 2016 14:02:48 -0700
Subject: [openssl-dev] How to contribute patches has changed
In-Reply-To: <e0710c072a454aaa93d923f9c2d480cd@usma1ex-dag1mb1.msg.corp.akamai.com>
References: <e0710c072a454aaa93d923f9c2d480cd@usma1ex-dag1mb1.msg.corp.akamai.com>
Message-ID: <57339DF8.9040301@gmail.com>

> The summary could be phrase as ?just open a GitHub PR, no need to deal
> with RT?

I haven't been keeping my PR #512 up to date since the 1.1 code freeze, 
is now a good time to start again?

cheers,

Joey

From rsalz at akamai.com  Wed May 11 21:03:58 2016
From: rsalz at akamai.com (Salz, Rich)
Date: Wed, 11 May 2016 21:03:58 +0000
Subject: [openssl-dev] How to contribute patches has changed
In-Reply-To: <57339DF8.9040301@gmail.com>
References: <e0710c072a454aaa93d923f9c2d480cd@usma1ex-dag1mb1.msg.corp.akamai.com>
 <57339DF8.9040301@gmail.com>
Message-ID: <8377e3b2831346c79bd6214b653b97e5@usma1ex-dag1mb1.msg.corp.akamai.com>

> I haven't been keeping my PR #512 up to date since the 1.1 code freeze, is
> now a good time to start again?

If it's a feature, wait until after 1.1 and then rebase.  If it's a bug or doc fix or similar, please update now and ping.

From xoloki at gmail.com  Wed May 11 21:16:28 2016
From: xoloki at gmail.com (Joey Yandle)
Date: Wed, 11 May 2016 14:16:28 -0700
Subject: [openssl-dev] How to contribute patches has changed
In-Reply-To: <8377e3b2831346c79bd6214b653b97e5@usma1ex-dag1mb1.msg.corp.akamai.com>
References: <e0710c072a454aaa93d923f9c2d480cd@usma1ex-dag1mb1.msg.corp.akamai.com>
 <57339DF8.9040301@gmail.com>
 <8377e3b2831346c79bd6214b653b97e5@usma1ex-dag1mb1.msg.corp.akamai.com>
Message-ID: <5733A12C.8010306@gmail.com>

> If it's a feature, wait until after 1.1 and then rebase.  If it's a bug or doc fix or similar, please update now and ping.
>

It's the windows RNG fix/cleanup.  Just updated and now no conflicts on PR.

   https://github.com/openssl/openssl/pull/512

Thanks!

Joey

From housley at vigilsec.com  Wed May 11 21:03:55 2016
From: housley at vigilsec.com (Russ Housley)
Date: Wed, 11 May 2016 17:03:55 -0400
Subject: [openssl-dev] Signing Internet-Drafts and RFCs
In-Reply-To: <534D6D0E.90904@drh-consultancy.co.uk>
References: <ACDB9333-BB9F-4B6F-9A50-1AC360CEA17E@vigilsec.com>
 <534D6D0E.90904@drh-consultancy.co.uk>
Message-ID: <87F088D8-B0E6-407B-90CD-BCA14A5F77BD@vigilsec.com>

Today, the IETF uses OpenSSL to digitally sign Internet-Drafts.  If you care about the details, please see RFC 5485.

We are looking to expand Internet-Draft signing, and start signing RFCs as well.  Someone has suggested that we support RFC 5126, "CMS Advanced Electronic Signatures (CAdES)?.  This would mean including some signed attributes that we do not currently use.

A CAdES Basic Electronic Signature (CAdES-BES) must include these signed attributes:

- Content-type ? I know OpenSSL supports this one.
- Message-digest ? I know OpenSSL supports this one.
- ESS signing-certificate-v2 ? I cannot tell if this is supported.

The ESS signing-certificate-v2 attribute is defined in RFC 5035.  I am interested in using it with SHA-256.  Is it supported?  If not, what would need to happen to get it supported?

Russ


From rt at openssl.org  Wed May 11 22:16:00 2016
From: rt at openssl.org (Daniel Stenberg via RT)
Date: Wed, 11 May 2016 22:16:00 +0000
Subject: [openssl-dev] [openssl.org #4236] SSL_connect() crash with CRL
In-Reply-To: <alpine.DEB.2.20.1605120009150.11284@tvnag.unkk.fr>
References: <RT-Ticket-4236@openssl.org>
 <alpine.DEB.2.20.1601141800240.15657@tvnag.unkk.fr>
 <rt-4.0.19-18545-1462982307-498.4236-6-0@openssl.org>
 <alpine.DEB.2.20.1605120009150.11284@tvnag.unkk.fr>
Message-ID: <rt-4.0.19-24780-1463004960-640.4236-6-0@openssl.org>

On Wed, 11 May 2016, Stephen Henson via RT wrote:

> I've pulled the latest curl using git and OpenSSL master. I had to make one 
> minor change to curl to get it to compile. I can't reproduce the problem 
> with test 313: it seems to work fine. I've tried it using the verify utility 
> and s_serrver/s_client too and all work.

Sorry, that problem was fixed at some later point and I've not seen it trigger 
recently. I forgot to mark it as such in the bug.

-- 

  / daniel.haxx.se


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


From rt at openssl.org  Thu May 12 03:13:16 2016
From: rt at openssl.org (Stephen Henson via RT)
Date: Thu, 12 May 2016 03:13:16 +0000
Subject: [openssl-dev] [openssl.org #4236] SSL_connect() crash with CRL
In-Reply-To: <rt-4.0.19-24780-1463004960-1001.4236-6-0@openssl.org>
References: <RT-Ticket-4236@openssl.org>
 <alpine.DEB.2.20.1601141800240.15657@tvnag.unkk.fr>
 <rt-4.0.19-18545-1462982307-498.4236-6-0@openssl.org>
 <alpine.DEB.2.20.1605120009150.11284@tvnag.unkk.fr>
 <rt-4.0.19-24780-1463004960-1001.4236-6-0@openssl.org>
Message-ID: <rt-4.0.19-24780-1463022796-1367.4236-6-0@openssl.org>

On Wed May 11 22:16:00 2016, daniel at haxx.se wrote:
>
>
> Sorry, that problem was fixed at some later point and I've not seen it
> trigger
> recently. I forgot to mark it as such in the bug.

OK, thanks for the update. Ticket closed.

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=4236
Please log in as guest with password guest if prompted


From matt at openssl.org  Thu May 12 08:27:55 2016
From: matt at openssl.org (Matt Caswell)
Date: Thu, 12 May 2016 09:27:55 +0100
Subject: [openssl-dev] Signing Internet-Drafts and RFCs
In-Reply-To: <87F088D8-B0E6-407B-90CD-BCA14A5F77BD@vigilsec.com>
References: <ACDB9333-BB9F-4B6F-9A50-1AC360CEA17E@vigilsec.com>
 <534D6D0E.90904@drh-consultancy.co.uk>
 <87F088D8-B0E6-407B-90CD-BCA14A5F77BD@vigilsec.com>
Message-ID: <57343E8B.7000407@openssl.org>



On 11/05/16 22:03, Russ Housley wrote:
> Today, the IETF uses OpenSSL to digitally sign Internet-Drafts.  If
> you care about the details, please see RFC 5485.
> 
> We are looking to expand Internet-Draft signing, and start signing
> RFCs as well.  Someone has suggested that we support RFC 5126, "CMS
> Advanced Electronic Signatures (CAdES)?.  This would mean including
> some signed attributes that we do not currently use.
> 
> A CAdES Basic Electronic Signature (CAdES-BES) must include these
> signed attributes:
> 
> - Content-type ? I know OpenSSL supports this one. - Message-digest ?
> I know OpenSSL supports this one. - ESS signing-certificate-v2 ? I
> cannot tell if this is supported.
> 
> The ESS signing-certificate-v2 attribute is defined in RFC 5035.  I
> am interested in using it with SHA-256.  Is it supported?  If not,
> what would need to happen to get it supported?

With the caveat that I know nothing about CAdES and haven't reviewed the
PR in question, you might want to look at this:

https://github.com/openssl/openssl/pull/206

If this PR were to be merged it would be a new feature and therefore
would not get incorporated until after the up-coming 1.1.0 release.

Matt


From rt at openssl.org  Thu May 12 10:05:40 2016
From: rt at openssl.org (Matt Caswell via RT)
Date: Thu, 12 May 2016 10:05:40 +0000
Subject: [openssl-dev] [openssl.org #3994] make clean leaves extra files
In-Reply-To: <CADqLbzL0bZ6ED9Gzi7w6e5TD+c1PnKpQJhV=BDDzde+6osgfTg@mail.gmail.com>
References: <RT-Ticket-3994@openssl.org>
 <CADqLbzL0bZ6ED9Gzi7w6e5TD+c1PnKpQJhV=BDDzde+6osgfTg@mail.gmail.com>
Message-ID: <rt-4.0.19-24780-1463047540-745.3994-6-0@openssl.org>

Dmitry reports this as fixed. Closing ticket.

Matt

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


From rt at openssl.org  Thu May 12 11:08:37 2016
From: rt at openssl.org (Stephen Henson via RT)
Date: Thu, 12 May 2016 11:08:37 +0000
Subject: [openssl-dev] [openssl.org #4104] A bug in the crl2pkc7 command in
	master
In-Reply-To: <CADqLbzLG+YgsKa7A0+cZrjZFrydPrrzNJpXxpu8Qhm5wKgJ--g@mail.gmail.com>
References: <RT-Ticket-4104@openssl.org>
 <CADqLbzLG+YgsKa7A0+cZrjZFrydPrrzNJpXxpu8Qhm5wKgJ--g@mail.gmail.com>
Message-ID: <rt-4.0.19-18545-1463051317-754.4104-6-0@openssl.org>

On Wed Oct 21 19:41:57 2015, beldmit at gmail.com wrote:
> Hello,
>
> I've found a bug in the crl2pkc7 command in the master branch.
>
> openssl crl2pkcs7 -in test.crl -certfile cert.pem -out p7.pem
>
> Output:
>
> error opening the file, -in
> error loading certificates
> 140737354073768:error:02001002:system library:fopen:No such file or
> directory:bss_file.c:175:fopen('-in','r')
> 140737354073768:error:2006D080:BIO routines:BIO_new_file:no such
> file:bss_file.c:178:
>
> The patch I attach fixes it.
>

This is already fixed in master with commit a465ca78414095224199

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=4104
Please log in as guest with password guest if prompted


From steve at openssl.org  Thu May 12 11:44:10 2016
From: steve at openssl.org (Dr. Stephen Henson)
Date: Thu, 12 May 2016 11:44:10 +0000
Subject: [openssl-dev] Signing Internet-Drafts and RFCs
In-Reply-To: <57343E8B.7000407@openssl.org>
References: <ACDB9333-BB9F-4B6F-9A50-1AC360CEA17E@vigilsec.com>
 <534D6D0E.90904@drh-consultancy.co.uk>
 <87F088D8-B0E6-407B-90CD-BCA14A5F77BD@vigilsec.com>
 <57343E8B.7000407@openssl.org>
Message-ID: <20160512114410.GA19510@openssl.org>

On Thu, May 12, 2016, Matt Caswell wrote:

> 
> 
> On 11/05/16 22:03, Russ Housley wrote:
> > Today, the IETF uses OpenSSL to digitally sign Internet-Drafts.  If
> > you care about the details, please see RFC 5485.
> > 
> > We are looking to expand Internet-Draft signing, and start signing
> > RFCs as well.  Someone has suggested that we support RFC 5126, "CMS
> > Advanced Electronic Signatures (CAdES)?.  This would mean including
> > some signed attributes that we do not currently use.
> > 
> > A CAdES Basic Electronic Signature (CAdES-BES) must include these
> > signed attributes:
> > 
> > - Content-type ? I know OpenSSL supports this one. - Message-digest ?
> > I know OpenSSL supports this one. - ESS signing-certificate-v2 ? I
> > cannot tell if this is supported.
> > 
> > The ESS signing-certificate-v2 attribute is defined in RFC 5035.  I
> > am interested in using it with SHA-256.  Is it supported?  If not,
> > what would need to happen to get it supported?
> 
> With the caveat that I know nothing about CAdES and haven't reviewed the
> PR in question, you might want to look at this:
> 
> https://github.com/openssl/openssl/pull/206
> 
> If this PR were to be merged it would be a new feature and therefore
> would not get incorporated until after the up-coming 1.1.0 release.
> 

Note that that PR (which IMHO needs quite a bit of work before we should
consider merging it) applies to the timestamping protocol. Something more
suited to CMS would be better with command line support and automatic
processing in CMS_verify et al.

I'll look into that after 1.1.0 release.

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

From rsalz at akamai.com  Thu May 12 13:16:43 2016
From: rsalz at akamai.com (Salz, Rich)
Date: Thu, 12 May 2016 13:16:43 +0000
Subject: [openssl-dev] Signing Internet-Drafts and RFCs
In-Reply-To: <87F088D8-B0E6-407B-90CD-BCA14A5F77BD@vigilsec.com>
References: <ACDB9333-BB9F-4B6F-9A50-1AC360CEA17E@vigilsec.com>
 <534D6D0E.90904@drh-consultancy.co.uk>
 <87F088D8-B0E6-407B-90CD-BCA14A5F77BD@vigilsec.com>
Message-ID: <a753ff7ee74b42ca9d4a7878e005ebd8@usma1ex-dag1mb1.msg.corp.akamai.com>

So Matt already mentioned that it's too late for our upcoming 1.1 release.  But do you think there'd be interest in adding this at an IETF hackathon?  I can be there FWIW.  Keeping a separate ietf-openssl branch that has the changes, for example, shouldn't be onerous. 

--  
Senior Architect, Akamai Technologies
IM: richsalz at jabber.at Twitter: RichSalz


From rt at openssl.org  Thu May 12 13:51:52 2016
From: rt at openssl.org (Stephen Henson via RT)
Date: Thu, 12 May 2016 13:51:52 +0000
Subject: [openssl-dev] [openssl.org #4438] GOST ciphersuites and DTLS
In-Reply-To: <CADqLbzL470JHDUm3OcOy3ohnedMe=zP9Cm5zR74FQvWTTMBUyQ@mail.gmail.com>
References: <RT-Ticket-4438@openssl.org>
 <CADqLbzL470JHDUm3OcOy3ohnedMe=zP9Cm5zR74FQvWTTMBUyQ@mail.gmail.com>
Message-ID: <rt-4.0.19-24780-1463061112-1155.4438-6-0@openssl.org>

Fixed now, 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=4438
Please log in as guest with password guest if prompted


From rt at openssl.org  Thu May 12 13:53:28 2016
From: rt at openssl.org (Stephen Henson via RT)
Date: Thu, 12 May 2016 13:53:28 +0000
Subject: [openssl-dev] [openssl.org #4246] OpenSSL-1.1-pre2 openssl req
	fails to use engine
In-Reply-To: <56996C4C.5090303@gmail.com>
References: <RT-Ticket-4246@openssl.org> <56996C4C.5090303@gmail.com>
Message-ID: <rt-4.0.19-18545-1463061208-1634.4246-6-0@openssl.org>

Fixed now, 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=4246
Please log in as guest with password guest if prompted


From rt at openssl.org  Thu May 12 13:56:13 2016
From: rt at openssl.org (Stephen Henson via RT)
Date: Thu, 12 May 2016 13:56:13 +0000
Subject: [openssl-dev] [openssl.org #4403] [PATCH] prevent OPENSSL_realloc()
	from clobbering old pointer value on failure in OpenSSL-1.1 pre-4
In-Reply-To: <CAFrbyQyewz=1g5GJ3RVz4_dDf1XjgQFp09rzq+gw9cBpszG77g@mail.gmail.com>
References: <RT-Ticket-4403@openssl.org>
 <CAFrbyQyewz=1g5GJ3RVz4_dDf1XjgQFp09rzq+gw9cBpszG77g@mail.gmail.com>
Message-ID: <rt-4.0.19-24780-1463061373-769.4403-6-0@openssl.org>

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


From rt at openssl.org  Thu May 12 13:57:34 2016
From: rt at openssl.org (Stephen Henson via RT)
Date: Thu, 12 May 2016 13:57:34 +0000
Subject: [openssl-dev] [openssl.org #4207] engine key format in 1.1
In-Reply-To: <5682A73C.70305@roumenpetrov.info>
References: <RT-Ticket-4207@openssl.org> <5682A73C.70305@roumenpetrov.info>
Message-ID: <rt-4.0.19-18545-1463061454-925.4207-6-0@openssl.org>

The remaining cases should be fixed now by commit d18ba3cc36d5fed032d.

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=4207
Please log in as guest with password guest if prompted


From jaroslav.imrich at gmail.com  Thu May 12 13:58:12 2016
From: jaroslav.imrich at gmail.com (Jaroslav Imrich)
Date: Thu, 12 May 2016 15:58:12 +0200
Subject: [openssl-dev] Signing Internet-Drafts and RFCs
In-Reply-To: <20160512114410.GA19510@openssl.org>
References: <ACDB9333-BB9F-4B6F-9A50-1AC360CEA17E@vigilsec.com>
 <534D6D0E.90904@drh-consultancy.co.uk>
 <87F088D8-B0E6-407B-90CD-BCA14A5F77BD@vigilsec.com>
 <57343E8B.7000407@openssl.org> <20160512114410.GA19510@openssl.org>
Message-ID: <CAB6OCMvJw-qX7GhN29xswKqNyNCSa1j033ARkLOJiwLP+X4cog@mail.gmail.com>

On 12 May 2016 at 13:44, Dr. Stephen Henson <steve at openssl.org> wrote:

> On Thu, May 12, 2016, Matt Caswell wrote:
>
> >
> >
> > On 11/05/16 22:03, Russ Housley wrote:
> > > Today, the IETF uses OpenSSL to digitally sign Internet-Drafts.  If
> > > you care about the details, please see RFC 5485.
> > >
> > > We are looking to expand Internet-Draft signing, and start signing
> > > RFCs as well.  Someone has suggested that we support RFC 5126, "CMS
> > > Advanced Electronic Signatures (CAdES)?.  This would mean including
> > > some signed attributes that we do not currently use.
> > >
> > > A CAdES Basic Electronic Signature (CAdES-BES) must include these
> > > signed attributes:
> > >
> > > - Content-type ? I know OpenSSL supports this one. - Message-digest ?
> > > I know OpenSSL supports this one. - ESS signing-certificate-v2 ? I
> > > cannot tell if this is supported.
> > >
> > > The ESS signing-certificate-v2 attribute is defined in RFC 5035.  I
> > > am interested in using it with SHA-256.  Is it supported?  If not,
> > > what would need to happen to get it supported?
> >
> > With the caveat that I know nothing about CAdES and haven't reviewed the
> > PR in question, you might want to look at this:
> >
> > https://github.com/openssl/openssl/pull/206
> >
> > If this PR were to be merged it would be a new feature and therefore
> > would not get incorporated until after the up-coming 1.1.0 release.
> >
>
> Note that that PR (which IMHO needs quite a bit of work before we should
> consider merging it) applies to the timestamping protocol. Something more
> suited to CMS would be better with command line support and automatic
> processing in CMS_verify et al.
>

SigningCertificate(v1) attribute is currently defined in TS module too,
thus it seems logical that people are adding SigningCertificateV2 support
there.
Similar (but IMO much better) patch adding support for SigningCertificateV2
attribute almost got merged in PR#771 -
https://github.com/openssl/openssl/pull/771
Maybe it is time to consider a freeze exception? :)

Regards, Jaroslav
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20160512/234ea881/attachment-0001.html>

From housley at vigilsec.com  Thu May 12 14:46:38 2016
From: housley at vigilsec.com (Russ Housley)
Date: Thu, 12 May 2016 10:46:38 -0400
Subject: [openssl-dev] Signing Internet-Drafts and RFCs
In-Reply-To: <a753ff7ee74b42ca9d4a7878e005ebd8@usma1ex-dag1mb1.msg.corp.akamai.com>
References: <ACDB9333-BB9F-4B6F-9A50-1AC360CEA17E@vigilsec.com>
 <534D6D0E.90904@drh-consultancy.co.uk>
 <87F088D8-B0E6-407B-90CD-BCA14A5F77BD@vigilsec.com>
 <a753ff7ee74b42ca9d4a7878e005ebd8@usma1ex-dag1mb1.msg.corp.akamai.com>
Message-ID: <235B23B4-682A-430E-8823-2F917A5C6A7F@vigilsec.com>

Three points:

(1) There may be people willing to work on code at the hackathon.  I have not looked around too much, but I could do that depending on the response to the second point.

(2) We need to validate signatures on I-Ds and RFCs with the standard release.  I?m okay with needing 1.1 or later, but I?m not okay with users having to fetch a special version.

(3) We are signing I-Ds now; we just are not including the signing-certificate-v2 attribute.  These older signature need to continue to validate, which should not be a problem since you should just hash unknown attributes that are included by the signer.

Russ


On May 12, 2016, at 9:16 AM, Salz, Rich <rsalz at akamai.com> wrote:

> So Matt already mentioned that it's too late for our upcoming 1.1 release.  But do you think there'd be interest in adding this at an IETF hackathon?  I can be there FWIW.  Keeping a separate ietf-openssl branch that has the changes, for example, shouldn't be onerous. 
> 
> --  
> Senior Architect, Akamai Technologies
> IM: richsalz at jabber.at Twitter: RichSalz
> 


From rsalz at akamai.com  Thu May 12 14:52:26 2016
From: rsalz at akamai.com (Salz, Rich)
Date: Thu, 12 May 2016 14:52:26 +0000
Subject: [openssl-dev] Signing Internet-Drafts and RFCs
In-Reply-To: <235B23B4-682A-430E-8823-2F917A5C6A7F@vigilsec.com>
References: <ACDB9333-BB9F-4B6F-9A50-1AC360CEA17E@vigilsec.com>
 <534D6D0E.90904@drh-consultancy.co.uk>
 <87F088D8-B0E6-407B-90CD-BCA14A5F77BD@vigilsec.com>
 <a753ff7ee74b42ca9d4a7878e005ebd8@usma1ex-dag1mb1.msg.corp.akamai.com>
 <235B23B4-682A-430E-8823-2F917A5C6A7F@vigilsec.com>
Message-ID: <0aa661415e4147539c5c85f9f8c17b3f@usma1ex-dag1mb1.msg.corp.akamai.com>


> (2) We need to validate signatures on I-Ds and RFCs with the standard
> release.  I?m okay with needing 1.1 or later, but I?m not okay with users
> having to fetch a special version.

It would show up a release after 1.1, but it would be in a regular release.
 


From housley at vigilsec.com  Thu May 12 15:04:49 2016
From: housley at vigilsec.com (Russ Housley)
Date: Thu, 12 May 2016 11:04:49 -0400
Subject: [openssl-dev] Signing Internet-Drafts and RFCs
In-Reply-To: <0aa661415e4147539c5c85f9f8c17b3f@usma1ex-dag1mb1.msg.corp.akamai.com>
References: <ACDB9333-BB9F-4B6F-9A50-1AC360CEA17E@vigilsec.com>
 <534D6D0E.90904@drh-consultancy.co.uk>
 <87F088D8-B0E6-407B-90CD-BCA14A5F77BD@vigilsec.com>
 <a753ff7ee74b42ca9d4a7878e005ebd8@usma1ex-dag1mb1.msg.corp.akamai.com>
 <235B23B4-682A-430E-8823-2F917A5C6A7F@vigilsec.com>
 <0aa661415e4147539c5c85f9f8c17b3f@usma1ex-dag1mb1.msg.corp.akamai.com>
Message-ID: <456FA470-90C5-4D25-88C1-AA243B76F6CB@vigilsec.com>


On May 12, 2016, at 10:52 AM, Salz, Rich <rsalz at akamai.com> wrote:

> 
>> (2) We need to validate signatures on I-Ds and RFCs with the standard
>> release.  I?m okay with needing 1.1 or later, but I?m not okay with users
>> having to fetch a special version.
> 
> It would show up a release after 1.1, but it would be in a regular release.

s/1.1/1.2/




From rt at openssl.org  Thu May 12 15:21:18 2016
From: rt at openssl.org (Richard Levitte via RT)
Date: Thu, 12 May 2016 15:21:18 +0000
Subject: [openssl-dev] [openssl.org #4522] Update to openssl.spec supplied
	with 1.0.1s
In-Reply-To: <rt-4.0.19-23551-1462541163-1067.4522-6-0@openssl.org>
References: <RT-Ticket-4522@openssl.org>
 <CF59E2BB6EB04C4AB71CBCF5716C635666F8C43A@MTB0120CP3XF04.ds.irsnet.gov>
 <rt-4.0.19-21242-1461969594-1031.4522-21-0@openssl.org>
 <be448272154a482bac463dcffe98a7ab@usma1ex-dag1mb1.msg.corp.akamai.com>
 <rt-4.0.19-23551-1462456667-147.4522-6-0@openssl.org>
 <rt-4.0.19-25938-1462540369-31.4522-6-0@openssl.org>
 <CF59E2BB6EB04C4AB71CBCF5716C635666F9467A@MTB0120CP3XF04.ds.irsnet.gov>
 <rt-4.0.19-23551-1462541163-1067.4522-6-0@openssl.org>
Message-ID: <rt-4.0.19-24780-1463066478-90.4522-6-0@openssl.org>

Ok.

FYI, we decided to remove openssl.spec from master (i.e. upcoming 1.1.0), as it
really belongs with the packagers rather than with us.
The 1.0.1 series will not be fixed, as it's at its last year before EOL, and we
only do security fixes on it.
The 1.0.2 series is a viable target, though, and I'll gladly apply your changes
there (with some mods)...

Cheers,
Richard On Fri May 06 13:26:03 2016, John.Withers at irs.gov wrote:
> (Replying to you instead of to the list as I can't ...)
>
> That was an oversight on my part. As part of the porting process, I
> was removing as many potential variables as possible. I neglected to
> reinstate that code before posting the file.
>
> I apologize for any confusion.
>
> John Withers
> Enterprise Operations
> Directory Services Branch - OS:CTO:EO:ISD:DSB:PKI
> Champaign, Illinois
>
> Phone: (217) 974-7736
>
> -----Original Message-----
> From: Richard Levitte via RT [mailto:rt at openssl.org]
> Sent: Friday, May 06, 2016 8:13 AM
> To: Withers John Z
> Cc: openssl-dev at openssl.org
> Subject: [openssl.org #4522] Update to openssl.spec supplied with
> 1.0.1s
>
> Vid Thu, 05 May 2016 kl. 13.57.47, skrev rsalz at akamai.com:
> >
> >
> > 1.0.1 is at end-of life and is only getting security fixes for the
> > rest of the year.
> > 1.0.2 is LTS and maybe this needs to be ported there (and master) as
> > well?
>
> master, without a doubt. I think 1.0.2 as well.
>
> There's one think I must question though... the attached openssl.spec
> removes
> all the architecture variants. Why?
>
> Cheers,
> Richard
>
> --
> Richard Levitte
> levitte at openssl.org
>
> --
> Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4522
> Please log in as guest with password guest if prompted
>


--
Richard Levitte
levitte at openssl.org

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


From rt at openssl.org  Thu May 12 15:27:44 2016
From: rt at openssl.org (Richard Levitte via RT)
Date: Thu, 12 May 2016 15:27:44 +0000
Subject: [openssl-dev] [openssl.org #4522] Update to openssl.spec supplied
	with 1.0.1s
In-Reply-To: <rt-4.0.19-24780-1463066477-14.4522-6-0@openssl.org>
References: <RT-Ticket-4522@openssl.org>
 <CF59E2BB6EB04C4AB71CBCF5716C635666F8C43A@MTB0120CP3XF04.ds.irsnet.gov>
 <rt-4.0.19-21242-1461969594-1031.4522-21-0@openssl.org>
 <be448272154a482bac463dcffe98a7ab@usma1ex-dag1mb1.msg.corp.akamai.com>
 <rt-4.0.19-23551-1462456667-147.4522-6-0@openssl.org>
 <rt-4.0.19-25938-1462540369-31.4522-6-0@openssl.org>
 <CF59E2BB6EB04C4AB71CBCF5716C635666F9467A@MTB0120CP3XF04.ds.irsnet.gov>
 <rt-4.0.19-23551-1462541163-1067.4522-6-0@openssl.org>
 <rt-4.0.19-24780-1463066477-14.4522-6-0@openssl.org>
Message-ID: <rt-4.0.19-24780-1463066864-1368.4522-6-0@openssl.org>

If you want to make a quick test, the changes are found on github, in this pull
request:
https://github.com/openssl/openssl/pull/1058

On Thu May 12 15:21:17 2016, levitte wrote:
> Ok.
>
> FYI, we decided to remove openssl.spec from master (i.e. upcoming
> 1.1.0), as it
> really belongs with the packagers rather than with us.
> The 1.0.1 series will not be fixed, as it's at its last year before
> EOL, and we
> only do security fixes on it.
> The 1.0.2 series is a viable target, though, and I'll gladly apply
> your changes
> there (with some mods)...
>
> Cheers,
> Richard On Fri May 06 13:26:03 2016, John.Withers at irs.gov wrote:
> > (Replying to you instead of to the list as I can't ...)
> >
> > That was an oversight on my part. As part of the porting process, I
> > was removing as many potential variables as possible. I neglected to
> > reinstate that code before posting the file.
> >
> > I apologize for any confusion.
> >
> > John Withers
> > Enterprise Operations
> > Directory Services Branch - OS:CTO:EO:ISD:DSB:PKI
> > Champaign, Illinois
> >
> > Phone: (217) 974-7736
> >
> > -----Original Message-----
> > From: Richard Levitte via RT [mailto:rt at openssl.org]
> > Sent: Friday, May 06, 2016 8:13 AM
> > To: Withers John Z
> > Cc: openssl-dev at openssl.org
> > Subject: [openssl.org #4522] Update to openssl.spec supplied with
> > 1.0.1s
> >
> > Vid Thu, 05 May 2016 kl. 13.57.47, skrev rsalz at akamai.com:
> > >
> > >
> > > 1.0.1 is at end-of life and is only getting security fixes for the
> > > rest of the year.
> > > 1.0.2 is LTS and maybe this needs to be ported there (and master)
> > > as
> > > well?
> >
> > master, without a doubt. I think 1.0.2 as well.
> >
> > There's one think I must question though... the attached openssl.spec
> > removes
> > all the architecture variants. Why?
> >
> > Cheers,
> > Richard
> >
> > --
> > Richard Levitte
> > levitte at openssl.org
> >
> > --
> > Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4522
> > Please log in as guest with password guest if prompted
> >
>
>
> --
> Richard Levitte
> levitte at openssl.org


--
Richard Levitte
levitte at openssl.org

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


From rt at openssl.org  Thu May 12 15:35:12 2016
From: rt at openssl.org (Hubert Kario via RT)
Date: Thu, 12 May 2016 15:35:12 +0000
Subject: [openssl-dev] [openssl.org #1298] OpenSSL bug in
	libcrypto.so:RAND_poll() crashes apache2 @ startup
In-Reply-To: <8712967.qzBgEPKk4D@pintsize.usersys.redhat.com>
References: <RT-Ticket-1298@openssl.org>
 <c85add41e1d4492da4f8c5921b8d791c@usma1ex-dag1mb1.msg.corp.akamai.com>
 <rt-4.0.19-5499-1462806332-1325.1298-6-0@openssl.org>
 <8712967.qzBgEPKk4D@pintsize.usersys.redhat.com>
Message-ID: <rt-4.0.19-24780-1463067312-1707.1298-6-0@openssl.org>

On Monday 09 May 2016 15:05:32 Salz, Rich via RT wrote:
> It's probably not an issue because the number of file descriptors has
> increased on the native O/S's.  But "file descriptor exhaustion" is
> still an issue for RNG's (google it) and we should keep it in mind
> for the future.  What's the best way to do that?

until getrandom()/getentropy()[1] is added to glibc, there's little that 
openssl can do

 1 - https://sourceware.org/bugzilla/show_bug.cgi?id=17252
-- 
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purky?ova 99/71, 612 45, Brno, Czech Republic
-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=1298
Please log in as guest with password guest if prompted

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20160512/b20792de/attachment.sig>

From rsalz at akamai.com  Thu May 12 15:35:18 2016
From: rsalz at akamai.com (Salz, Rich)
Date: Thu, 12 May 2016 15:35:18 +0000
Subject: [openssl-dev] Signing Internet-Drafts and RFCs
In-Reply-To: <456FA470-90C5-4D25-88C1-AA243B76F6CB@vigilsec.com>
References: <ACDB9333-BB9F-4B6F-9A50-1AC360CEA17E@vigilsec.com>
 <534D6D0E.90904@drh-consultancy.co.uk>
 <87F088D8-B0E6-407B-90CD-BCA14A5F77BD@vigilsec.com>
 <a753ff7ee74b42ca9d4a7878e005ebd8@usma1ex-dag1mb1.msg.corp.akamai.com>
 <235B23B4-682A-430E-8823-2F917A5C6A7F@vigilsec.com>
 <0aa661415e4147539c5c85f9f8c17b3f@usma1ex-dag1mb1.msg.corp.akamai.com>
 <456FA470-90C5-4D25-88C1-AA243B76F6CB@vigilsec.com>
Message-ID: <7ddab16425de457395f320581454522e@usma1ex-dag1mb1.msg.corp.akamai.com>


> > It would show up a release after 1.1, but it would be in a regular release.
> 
> s/1.1/1.2/

No, it would be in a release after 1.1 :)  Maybe that's 1.1.1 or maybe that's 1.2, we haven't figured it out yet.

From rt at openssl.org  Thu May 12 15:45:13 2016
From: rt at openssl.org (Richard Levitte via RT)
Date: Thu, 12 May 2016 15:45:13 +0000
Subject: [openssl-dev] [openssl.org #4522] Update to openssl.spec supplied
	with 1.0.1s
In-Reply-To: <rt-4.0.19-24780-1463066864-1504.4522-6-0@openssl.org>
References: <RT-Ticket-4522@openssl.org>
 <CF59E2BB6EB04C4AB71CBCF5716C635666F8C43A@MTB0120CP3XF04.ds.irsnet.gov>
 <rt-4.0.19-21242-1461969594-1031.4522-21-0@openssl.org>
 <be448272154a482bac463dcffe98a7ab@usma1ex-dag1mb1.msg.corp.akamai.com>
 <rt-4.0.19-23551-1462456667-147.4522-6-0@openssl.org>
 <rt-4.0.19-25938-1462540369-31.4522-6-0@openssl.org>
 <CF59E2BB6EB04C4AB71CBCF5716C635666F9467A@MTB0120CP3XF04.ds.irsnet.gov>
 <rt-4.0.19-23551-1462541163-1067.4522-6-0@openssl.org>
 <rt-4.0.19-24780-1463066477-14.4522-6-0@openssl.org>
 <rt-4.0.19-24780-1463066864-1504.4522-6-0@openssl.org>
Message-ID: <rt-4.0.19-18545-1463067913-422.4522-6-0@openssl.org>

It just got merged into the 1.0.2 branch.

Closing this ticket.

Cheers,
Richard

On Thu May 12 15:27:44 2016, levitte wrote:
> If you want to make a quick test, the changes are found on github, in
> this pull
> request:
> https://github.com/openssl/openssl/pull/1058
>
> On Thu May 12 15:21:17 2016, levitte wrote:
> > Ok.
> >
> > FYI, we decided to remove openssl.spec from master (i.e. upcoming
> > 1.1.0), as it
> > really belongs with the packagers rather than with us.
> > The 1.0.1 series will not be fixed, as it's at its last year before
> > EOL, and we
> > only do security fixes on it.
> > The 1.0.2 series is a viable target, though, and I'll gladly apply
> > your changes
> > there (with some mods)...
> >
> > Cheers,
> > Richard On Fri May 06 13:26:03 2016, John.Withers at irs.gov wrote:
> > > (Replying to you instead of to the list as I can't ...)
> > >
> > > That was an oversight on my part. As part of the porting process, I
> > > was removing as many potential variables as possible. I neglected
> > > to
> > > reinstate that code before posting the file.
> > >
> > > I apologize for any confusion.
> > >
> > > John Withers
> > > Enterprise Operations
> > > Directory Services Branch - OS:CTO:EO:ISD:DSB:PKI
> > > Champaign, Illinois
> > >
> > > Phone: (217) 974-7736
> > >
> > > -----Original Message-----
> > > From: Richard Levitte via RT [mailto:rt at openssl.org]
> > > Sent: Friday, May 06, 2016 8:13 AM
> > > To: Withers John Z
> > > Cc: openssl-dev at openssl.org
> > > Subject: [openssl.org #4522] Update to openssl.spec supplied with
> > > 1.0.1s
> > >
> > > Vid Thu, 05 May 2016 kl. 13.57.47, skrev rsalz at akamai.com:
> > > >
> > > >
> > > > 1.0.1 is at end-of life and is only getting security fixes for
> > > > the
> > > > rest of the year.
> > > > 1.0.2 is LTS and maybe this needs to be ported there (and master)
> > > > as
> > > > well?
> > >
> > > master, without a doubt. I think 1.0.2 as well.
> > >
> > > There's one think I must question though... the attached
> > > openssl.spec
> > > removes
> > > all the architecture variants. Why?
> > >
> > > Cheers,
> > > Richard
> > >
> > > --
> > > Richard Levitte
> > > levitte at openssl.org
> > >
> > > --
> > > Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4522
> > > Please log in as guest with password guest if prompted
> > >
> >
> >
> > --
> > Richard Levitte
> > levitte at openssl.org
>
>
> --
> Richard Levitte
> levitte at openssl.org


--
Richard Levitte
levitte at openssl.org

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


From rt at openssl.org  Thu May 12 19:44:04 2016
From: rt at openssl.org (Juan Manuel Guerrero via RT)
Date: Thu, 12 May 2016 19:44:04 +0000
Subject: [openssl-dev] [openssl.org #4217] Fixing DJGPP port of openssl
	master branch.
In-Reply-To: <5734DBC5.7000703@gmx.de>
References: <RT-Ticket-4217@openssl.org> <568A77AE.8090801@gmx.de>
 <rt-4.0.19-11137-1451936568-1413.4217-21-0@openssl.org>
 <20160104.212201.300039170238726481.levitte@openssl.org>
 <568B25A2.8000705@gmx.de>
 <rt-4.0.19-11679-1451963145-1881.4217-6-0@openssl.org>
 <568DA30C.6060109@gmx.de>
 <rt-4.0.19-11679-1452126320-995.4217-6-0@openssl.org>
 <rt-4.0.19-5499-1462884709-440.4217-6-0@openssl.org>
 <5734DBC5.7000703@gmx.de>
Message-ID: <rt-4.0.19-18545-1463082244-973.4217-6-0@openssl.org>

Am 10.05.2016 14:51, schrieb Richard Levitte via RT:
> Hi Juan,
>
> sorry that I lost track of this, and thank you Matt for the ping.
>
> I've made this a github PR, here: https://github.com/openssl/openssl/pull/1050
>
> Could you verify that it still works correctly? Or anyone else that's
> interested?
> (we will proceed anyway if we haven't heard from you by the end of the week,
> but it would be nice having things verified)
>
> Cheers,
> Richard
>
> On Thu Jan 07 00:25:20 2016, juan.guerrero at gmx.de wrote:
>> Am 05.01.2016 04:05, schrieb Juan Manuel Guerrero via RT:
>>> Am 04.01.2016 21:22, schrieb Richard Levitte via RT:
>>>> Hi Juan, and thanks.
>>>>
>>>> I'm looking at your fix, and have a couple of questions:
>> [snip]
>>
>> This is the last and final patch to fix the DJGPP port. The only
>> difference
>> compared with the initial patch is that it checks mow all file names
>> for LFN
>> validity. The dirname part and the basename part of the file name are
>> now
>> checked for ilicit initial dots in the case that no LFN support is
>> provided
>> by the file system. I have attached the patch as gzip'ed file too.
>>
>> Similar patches are also provided for the openssl 1.0.1 branch and the
>> openssl 1.0.2 branch too.
>>
>>
>> Regards,
>> Juan M. Guerrero
>>
>>
>>
>>
>>
>>
>> 2016-01-06 Juan Manuel Guerrero<juan.guerrero at gmx.de>
>>
>> * Configure: Replaced -DTERMIO by -DTERMIOS in CFLAGS.
>>
>> * crypto/bio/bss_dgram.c [WATT32]: Remove obsolete redefinition of
>> function names: sock_write, sock_read and sock_puts.
>>
>> * crypto/bio/bss_sock.c [WATT32]: For Watt-32 2.2.11 sock_write,
>> sock_read and sock_puts are redefined to their private names so their
>> names must be undefined first before they can be redefined again.
>>
>> * crypto/bio/bss_file.c (file_fopen) [OPENSSL_SYS_MSDOS]: Call
>> dosify_filename to replace leading dot if file system does not support
>> it.
>> (dosify_filename): Replace leading dot in passed file name if file
>> system does not support LFN. Replace all leading dots in the dirname
>> part and the basname part of the file name.
>>
>> * e_os.h [__DJGPP__]: Undefine macro DEVRANDOM_EGD. Neither MS-DOS
>> nor FreeDOS provide 'egd' sockets.
>> New macro HAS_LFN_SUPPORT checks if underlying file system supports
>> long file names or not.
>> Include sys/un.h.
>> Define WATT32_NO_OLDIES.
>>
>> * INSTALL.DJGPP: Update URL of WATT-32 library.
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> diff --git a/Configurations/10-main.conf b/Configurations/10-main.conf
>> index a82b95d..fad57a9 100644
>> --- a/Configurations/10-main.conf
>> +++ b/Configurations/10-main.conf
>> @@ -1299,7 +1299,7 @@
>> "DJGPP" =>  {
>> inherit_from =>  [ asm("x86_asm") ],
>> cc =>  "gcc",
>> - cflags =>  "-I/dev/env/WATT_ROOT/inc -DTERMIO
>> -DL_ENDIAN -fomit-frame-pointer -O2 -Wall",
>> + cflags =>  "-I/dev/env/WATT_ROOT/inc -DTERMIOS
>> -DL_ENDIAN -fomit-frame-pointer -O2 -Wall",
>> sys_id =>  "MSDOS",
>> lflags =>  "-L/dev/env/WATT_ROOT/lib -lwatt",
>> bn_ops =>  "BN_LLONG ${x86_gcc_des}
>> ${x86_gcc_opts}",
>> diff --git a/INSTALL.DJGPP b/INSTALL.DJGPP
>> index 1047ec9..23aed6a 100644
>> --- a/INSTALL.DJGPP
>> +++ b/INSTALL.DJGPP
>> @@ -18,7 +18,7 @@
>> files to download, see the DJGPP "ZIP PICKER" page at
>> "http://www.delorie.com/djgpp/zip-picker.html". You also need to
>> have
>> the WATT-32 networking package installed before you try to compile
>> - OpenSSL. This can be obtained from "http://www.bgnett.no/~giva/".
>> + OpenSSL. This can be obtained from "http://www.watt-32.net/".
>> The Makefile assumes that the WATT-32 code is in the directory
>> specified by the environment variable WATT_ROOT. If you have watt-
>> 32
>> in directory "watt32" under your main DJGPP directory, specify
>> diff --git a/crypto/bio/bss_dgram.c b/crypto/bio/bss_dgram.c
>> index 5e934ce..ca318cf 100644
>> --- a/crypto/bio/bss_dgram.c
>> +++ b/crypto/bio/bss_dgram.c
>> @@ -97,12 +97,6 @@
>> ((a)->s6_addr32[2] == htonl(0x0000ffff)))
>> # endif
>>
>> -# ifdef WATT32
>> -# define sock_write SockWrite /* Watt-32 uses same names */
>> -# define sock_read SockRead
>> -# define sock_puts SockPuts
>> -# endif
>> -
>> static int dgram_write(BIO *h, const char *buf, int num);
>> static int dgram_read(BIO *h, char *buf, int size);
>> static int dgram_puts(BIO *h, const char *str);
>> diff --git a/crypto/bio/bss_file.c b/crypto/bio/bss_file.c
>> index c09a9a9..f34161c 100644
>> --- a/crypto/bio/bss_file.c
>> +++ b/crypto/bio/bss_file.c
>> @@ -95,6 +95,10 @@
>>
>> # if !defined(OPENSSL_NO_STDIO)
>>
>> +#ifdef OPENSSL_SYS_MSDOS
>> +# include<libc/unconst.h>
>> +static void dosify_filename(const char *filename);
>> +#endif
>> static int file_write(BIO *h, const char *buf, int num);
>> static int file_read(BIO *h, char *buf, int size);
>> static int file_puts(BIO *h, const char *str);
>> @@ -161,6 +165,9 @@ static FILE *file_fopen(const char *filename,
>> const char *mode)
>> file = fopen(filename, mode);
>> }
>> # else
>> +# ifdef OPENSSL_SYS_MSDOS
>> + dosify_filename(filename);
>> +# endif
>> file = fopen(filename, mode);
>> # endif
>> return (file);
>> @@ -467,6 +474,23 @@ static int file_puts(BIO *bp, const char *str)
>> return (ret);
>> }
>>
>> +#ifdef OPENSSL_SYS_MSDOS
>> +static void dosify_filename(const char *filename)
>> +{
>> + if (filename&&  *filename&&  !HAS_LFN_SUPPORT(filename)) {
>> + char *namestart = unconst(filename, char *);
>> +
>> + do {
>> + if (namestart[0] == '/'&&  namestart[2] != '.'&&
>> namestart[2] != '/') {
>> +
>> + /* Leading dot not allowed on plain DOS. */
>> + if (namestart[1] == '.')
>> + *++namestart = '_';
>> + }
>> + } while (*++namestart);
>> + }
>> +}
>> +#endif
>> #else
>>
>> static int file_write(BIO *b, const char *in, int inl)
>> diff --git a/crypto/bio/bss_sock.c b/crypto/bio/bss_sock.c
>> index 1673b32..5cef4f3 100644
>> --- a/crypto/bio/bss_sock.c
>> +++ b/crypto/bio/bss_sock.c
>> @@ -66,7 +66,11 @@
>> # include<openssl/bio.h>
>>
>> # ifdef WATT32
>> -# define sock_write SockWrite /* Watt-32 uses same names */
>> +/* Watt-32 uses same names */
>> +# undef sock_write
>> +# undef sock_read
>> +# undef sock_puts
>> +# define sock_write SockWrite
>> # define sock_read SockRead
>> # define sock_puts SockPuts
>> # endif
>> diff --git a/e_os.h b/e_os.h
>> index 5ab4c89..6d52f13 100644
>> --- a/e_os.h
>> +++ b/e_os.h
>> @@ -141,6 +141,7 @@ extern "C" {
>> # define writesocket(s,b,n) send((s),(b),(n),0)
>> # elif defined(__DJGPP__)
>> # define WATT32
>> +# define WATT32_NO_OLDIES
>> # define get_last_socket_error() errno
>> # define clear_socket_error() errno=0
>> # define closesocket(s) close_s(s)
>> @@ -194,11 +195,14 @@ extern "C" {
>> # include<unistd.h>
>> # include<sys/stat.h>
>> # include<sys/socket.h>
>> +# include<sys/un.h>
>> # include<tcp.h>
>> # include<netdb.h>
>> # define _setmode setmode
>> # define _O_TEXT O_TEXT
>> # define _O_BINARY O_BINARY
>> +# define HAS_LFN_SUPPORT(name) (pathconf((name), _PC_NAME_MAX)>
>> 12)
>> +# undef DEVRANDOM_EGD /* Neither MS-DOS nor FreeDOS provide 'egd'
>> sockets. */
>> # undef DEVRANDOM
>> # define DEVRANDOM "/dev/urandom\x24"
>> # endif /* __DJGPP__ */
>
>
> --
> Richard Levitte
> levitte at openssl.org
>

Hello Richard,

I have verified that every thing works flawlessly.  Please feel free to go ahead
and merge the DJGPP specific changes.

Kind regards,
Juan


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


From openssl at roumenpetrov.info  Thu May 12 20:02:34 2016
From: openssl at roumenpetrov.info (Roumen Petrov)
Date: Thu, 12 May 2016 23:02:34 +0300
Subject: [openssl-dev] use of X.509 lookup methods,
 X509_OBJECT internal or opaque?
In-Reply-To: <88325fac26054ff4bb1d7aaaf42b3210@usma1ex-dag1mb1.msg.corp.akamai.com>
References: <571B8D25.2030100@roumenpetrov.info>
 <0ceaba4b64d44e689f05225f480ba33f@usma1ex-dag1mb1.msg.corp.akamai.com>
 <790538e8524942339cede3107cb60d43@usma1ex-dag1mb1.msg.corp.akamai.com>
 <572DA7C0.6040706@roumenpetrov.info> <572DAB2C.1060000@roumenpetrov.info>
 <4551491c54564abbb1adf251746867f6@usma1ex-dag1mb1.msg.corp.akamai.com>
 <57324A1E.1030200@roumenpetrov.info>
 <88325fac26054ff4bb1d7aaaf42b3210@usma1ex-dag1mb1.msg.corp.akamai.com>
Message-ID: <5734E15A.8010306@roumenpetrov.info>

Salz, Rich wrote:
>>> Can you look at https://github.com/openssl/openssl/pull/1044 [SNIP ....]
>>> I pushed a new version that adds your feedback.
10x, it's fine by me.

Roumen

From rt at openssl.org  Thu May 12 20:07:27 2016
From: rt at openssl.org (Rich Salz via RT)
Date: Thu, 12 May 2016 20:07:27 +0000
Subject: [openssl-dev] [openssl.org #4320] [Patch] OpenSSL 1.1.0-pre3:
	"unable to load Key" error in PEM_get_EVP_CIPHER_INFO()
In-Reply-To: <56C4BA0E.7090603@kippdata.de>
References: <RT-Ticket-4320@openssl.org> <56C4BA0E.7090603@kippdata.de>
Message-ID: <rt-4.0.19-24780-1463083647-192.4320-6-0@openssl.org>

closing per OP; we fixed the bug.

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


From rt at openssl.org  Thu May 12 20:12:47 2016
From: rt at openssl.org (Richard Levitte via RT)
Date: Thu, 12 May 2016 20:12:47 +0000
Subject: [openssl-dev] [openssl.org #4217] Fixing DJGPP port of openssl
	master branch.
In-Reply-To: <rt-4.0.19-18545-1463082244-1001.4217-6-0@openssl.org>
References: <RT-Ticket-4217@openssl.org>
 <rt-4.0.19-11137-1451938935-1890.4217-6-0@openssl.org>
 <568B25A2.8000705@gmx.de>
Message-ID: <rt-4.0.19-24780-1463083967-315.4217-6-0@openssl.org>

On Thu May 12 19:44:04 2016, juan.guerrero at gmx.de wrote:
> Hello Richard,
>
> I have verified that every thing works flawlessly. Please feel free
> to go ahead
> and merge the DJGPP specific changes.

Flawlessly, I like the sound of that! Thank you for confirming, it's now been
merged into master.

Closing this ticket.

Cheers,
Richard

--
Richard Levitte
levitte at openssl.org

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


From rt at openssl.org  Thu May 12 20:15:00 2016
From: rt at openssl.org (Richard Levitte via RT)
Date: Thu, 12 May 2016 20:15:00 +0000
Subject: [openssl-dev] [openssl.org #4356] 64-bit OS X on x86_64
	misidentified as i686
In-Reply-To: <rt-4.0.19-18545-1462915925-999.4356-6-0@openssl.org>
References: <RT-Ticket-4356@openssl.org>
 <CAH8yC8=AaaFN5cR1gc694Czeu863Mybcn1NQa1K63Q24mqytcg@mail.gmail.com>
 <rt-4.0.19-18545-1462915925-999.4356-6-0@openssl.org>
Message-ID: <rt-4.0.19-18545-1463084100-75.4356-6-0@openssl.org>

Hi,

FYI, the changes were merged into master earlier today. I'm closing this ticket
now, please open a new one should there be any new problems.

Cheers,
Richard

On Tue May 10 21:32:05 2016, levitte wrote:
> Hey
>
> Would you mind having a look at https://github.com/openssl/openssl/pull/1053
> and see if that makes things better?
>
> Cheers,
> Richard
>
> On Sun Feb 28 22:11:56 2016, noloader at gmail.com wrote:
> > Working from Master:
> >
> > $ git reset --hard HEAD && git pull
> > HEAD is now at 31ba0e1 Fix mk1mf build
> > Already up-to-date.
> >
> > MacBook Pro from 2013 (Intel, x86_64), OS X 10.8.5, fully patched:
> >
> > $ ./config
> > Operating system: i686-apple-darwinDarwin Kernel Version 12.6.0: Wed
> > Mar 18 16:23:48 PDT 2015; root:xnu-2050.48.19~1/RELEASE_X86_64
> > WARNING! If you wish to build 64-bit library, then you have to
> > invoke './Configure darwin64-x86_64-cc ' *manually*.
> > You have about 5 seconds to press Ctrl-C to abort.
> > ...
> >
> > This code from config seems to be responsible:
> >
> > Darwin:*)
> > case "$MACHINE" in
> > Power*)
> > echo "ppc-apple-darwin${VERSION}"
> > ;;
> > *)
> > echo "i686-apple-darwin${VERSION}"
> > ;;
> > esac
> > exit 0
> > ;;
> >
> > And:
> >
> > i?86-apple-darwin*)
> > ISA64=`(sysctl -n hw.optional.x86_64) 2>/dev/null`
> > if [ "$ISA64" = "1" -a -z "$KERNEL_BITS" ]; then
> > echo "WARNING! If you wish to build 64-bit library, then you
> > have to"
> > echo " invoke '$THERE/Configure darwin64-x86_64-cc
> > $options' *manually*."
> > if [ "$TEST" = "false" -a -t 1 ]; then
> > echo " You have about 5 seconds to press Ctrl-C to
> > abort."
> > # The stty technique used elsewhere doesn't work on
> > # MacOS. At least, right now on this Mac.
> > sleep 5
> > fi
> > fi
> > if [ "$ISA64" = "1" -a "$KERNEL_BITS" = "64" ]; then
> > OUT="darwin64-x86_64-cc"
> > else
> > OUT="darwin-i386-cc"
> > fi ;;
> >
> > $MACHINE looks like it could help here:
> >
> > $ uname -m
> > x86_64
> >
> > Maybe its time to add a case for x86_64. For those who really want
> > 32-bit, they can 'export KERNEL_BITS=32'.
>
>
> --
> Richard Levitte
> levitte at openssl.org


--
Richard Levitte
levitte at openssl.org

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


From rt at openssl.org  Wed May 11 16:35:49 2016
From: rt at openssl.org (Michael French via RT)
Date: Wed, 11 May 2016 16:35:49 +0000
Subject: [openssl-dev] [openssl.org #4540] openssl make test
In-Reply-To: <9aaed159615144e9b52e73fed13e4a25@CT-EXCHG13.cleartrack.com>
References: <RT-Ticket-4540@openssl.org>
 <9aaed159615144e9b52e73fed13e4a25@CT-EXCHG13.cleartrack.com>
Message-ID: <rt-4.0.19-5499-1462984549-1865.4540-21-0@openssl.org>

Hi,

I was trying to build openssl 1.0.1t on a CentOS 6.7 system.  I'm seeing failures when performing a make test, including the below at the end of the test.  I've included the maketest.log

CMS => PKCS#7 compatibility tests
signed content DER format, RSA key: verify error
make[2]: *** [test_cms] Error 1
make[2]: Leaving directory `/root/openssl-1.0.1t/test'
make[1]: *** [tests] Error 2
make[1]: Leaving directory `/root/openssl-1.0.1t'

I was wondering if you had any suggestions?

Thanks!

Mike

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: maketest.log
Type: application/octet-stream
Size: 353780 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20160511/27307c4c/attachment-0001.obj>

From rt at openssl.org  Thu May 12 21:58:25 2016
From: rt at openssl.org (Stephen Henson via RT)
Date: Thu, 12 May 2016 21:58:25 +0000
Subject: [openssl-dev] [openssl.org #4540] openssl make test
In-Reply-To: <9aaed159615144e9b52e73fed13e4a25@CT-EXCHG13.cleartrack.com>
References: <RT-Ticket-4540@openssl.org>
 <9aaed159615144e9b52e73fed13e4a25@CT-EXCHG13.cleartrack.com>
Message-ID: <rt-4.0.19-24780-1463090305-1733.4540-6-0@openssl.org>

It's caused by the S/MIME test certificates expiring. This is fixed in commit
24762dee178bace3c3 either apply that, use a recent snapshot or just copy the
test/smime-certs directory from a recent snapshot.

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=4540
Please log in as guest with password guest if prompted


From openssl-users at dukhovni.org  Thu May 12 22:34:17 2016
From: openssl-users at dukhovni.org (Viktor Dukhovni)
Date: Thu, 12 May 2016 22:34:17 +0000
Subject: [openssl-dev] [openssl.org #4540] openssl make test
In-Reply-To: <rt-4.0.19-24780-1463090305-1733.4540-6-0@openssl.org>
References: <RT-Ticket-4540@openssl.org>
 <9aaed159615144e9b52e73fed13e4a25@CT-EXCHG13.cleartrack.com>
 <rt-4.0.19-24780-1463090305-1733.4540-6-0@openssl.org>
Message-ID: <20160512223417.GA3300@mournblade.imrryr.org>

On Thu, May 12, 2016 at 09:58:25PM +0000, Stephen Henson via RT wrote:

> It's caused by the S/MIME test certificates expiring. This is fixed in commit
> 24762dee178bace3c3 either apply that, use a recent snapshot or just copy the
> test/smime-certs directory from a recent snapshot.

It might make sense to create an updated source tarball.  Same
underlying OpenSSL patch level (since it is just the tests, not
the resulting code that's changing).  Don't know whether we've
any process in place for doing that...

-- 
	Viktor.

From viktor.kolodrevskiy at gmail.com  Thu May 12 23:08:35 2016
From: viktor.kolodrevskiy at gmail.com (Viktor Kolodrevskiy)
Date: Fri, 13 May 2016 02:08:35 +0300
Subject: [openssl-dev] [openssl.org #4540] openssl make test
In-Reply-To: <20160512223417.GA3300@mournblade.imrryr.org>
References: <RT-Ticket-4540@openssl.org>
 <9aaed159615144e9b52e73fed13e4a25@CT-EXCHG13.cleartrack.com>
 <rt-4.0.19-24780-1463090305-1733.4540-6-0@openssl.org>
 <20160512223417.GA3300@mournblade.imrryr.org>
Message-ID: <817402B9-470C-42EC-BA2A-8331FDF8705F@gmail.com>

Would be great to have updated source tarball.


> On May 13, 2016, at 01:34, Viktor Dukhovni <openssl-users at dukhovni.org> wrote:
> 
> On Thu, May 12, 2016 at 09:58:25PM +0000, Stephen Henson via RT wrote:
> 
>> It's caused by the S/MIME test certificates expiring. This is fixed in commit
>> 24762dee178bace3c3 either apply that, use a recent snapshot or just copy the
>> test/smime-certs directory from a recent snapshot.
> 
> It might make sense to create an updated source tarball.  Same
> underlying OpenSSL patch level (since it is just the tests, not
> the resulting code that's changing).  Don't know whether we've
> any process in place for doing that...
> 
> -- 
> 	Viktor.
> -- 
> openssl-dev mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev


From rt at openssl.org  Fri May 13 11:07:30 2016
From: rt at openssl.org (Stephen Henson via RT)
Date: Fri, 13 May 2016 11:07:30 +0000
Subject: [openssl-dev] [openssl.org #4302] Documentation error in
	apps/x509.html: -[digest] option
In-Reply-To: <56BDFD76.8060706@ts.fujitsu.com>
References: <RT-Ticket-4302@openssl.org> <56BDFD76.8060706@ts.fujitsu.com>
Message-ID: <rt-4.0.19-24780-1463137650-1152.4302-6-0@openssl.org>

Fixed in commit 0b2d4755d67eece48d1

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=4302
Please log in as guest with password guest if prompted


From rt at openssl.org  Fri May 13 11:41:55 2016
From: rt at openssl.org (Stephen Henson via RT)
Date: Fri, 13 May 2016 11:41:55 +0000
Subject: [openssl-dev] [openssl.org #4215] Results of regression for some
	apps
In-Reply-To: <CADqLbzKx583zFh-aj1RLTD+a4M2sTOW_H2uXHLWOQ_OkcSfFJw@mail.gmail.com>
References: <RT-Ticket-4215@openssl.org>
 <CADqLbzKx583zFh-aj1RLTD+a4M2sTOW_H2uXHLWOQ_OkcSfFJw@mail.gmail.com>
Message-ID: <rt-4.0.19-18545-1463139715-1098.4215-6-0@openssl.org>

On Mon Jan 04 14:07:23 2016, beldmit at gmail.com wrote:
> Hello!
>
> I found the following problems running my cipher suite with openssl 1.1.0
>
> 1. Some apps try to load the default config file twice. In case when we
> load an engine via the config file and the engine prevents itself from
> loading more than once, it causes errors.
>
> The attached patch contains fixes for the 'req' and 'ts' utilities, but may
> be there are some more utilities with specific config files.
>
> 2. The 'smime' utility erroneously regards the '-signer' option to be the
> name of input file. It's wrong when the utility uses this option in -verify
> mode. So the attached patch makes this option to be processed as string,
> not as input.
>
> 3. The 'cms' and 'smime' utilities do not accept the '-inform smime'
> options. It may be a bug or not a bug (files in SMIME format are accepted)
> but it is definitely an incompatibility.
>

Can you indicate if #1 is still a problem and if so give some details on how to
reproduce it?

#2 and #3 should be addressed now.

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=4215
Please log in as guest with password guest if prompted


From viktor.kolodrevskiy at gmail.com  Fri May 13 11:54:30 2016
From: viktor.kolodrevskiy at gmail.com (Viktor Kolodrevskiy)
Date: Fri, 13 May 2016 14:54:30 +0300
Subject: [openssl-dev] [openssl.org #4540] openssl make test
In-Reply-To: <rt-4.0.19-5499-1462984549-1865.4540-21-0@openssl.org>
References: <RT-Ticket-4540@openssl.org>
 <9aaed159615144e9b52e73fed13e4a25@CT-EXCHG13.cleartrack.com>
 <rt-4.0.19-5499-1462984549-1865.4540-21-0@openssl.org>
Message-ID: <59922F3B-EC64-4359-B748-6C0C81DB05E7@gmail.com>

It?s a known issue.
It's caused by the S/MIME test certificates expiring.


> On May 11, 2016, at 19:35, Michael French via RT <rt at openssl.org> wrote:
> 
> Hi,
> 
> I was trying to build openssl 1.0.1t on a CentOS 6.7 system.  I'm seeing failures when performing a make test, including the below at the end of the test.  I've included the maketest.log
> 
> CMS => PKCS#7 compatibility tests
> signed content DER format, RSA key: verify error
> make[2]: *** [test_cms] Error 1
> make[2]: Leaving directory `/root/openssl-1.0.1t/test'
> make[1]: *** [tests] Error 2
> make[1]: Leaving directory `/root/openssl-1.0.1t'
> 
> I was wondering if you had any suggestions?
> 
> Thanks!
> 
> Mike
> 
> -- 
> Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4540
> Please log in as guest with password guest if prompted
> 
> <maketest.log>-- 
> openssl-dev mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev


From rt at openssl.org  Fri May 13 12:03:09 2016
From: rt at openssl.org (Stephen Henson via RT)
Date: Fri, 13 May 2016 12:03:09 +0000
Subject: [openssl-dev] [openssl.org #4471] 1.1.0-pre4 safestack.h
	compilation errors with -Wcast-qual
In-Reply-To: <558C903B-A05C-4B2C-A29E-065E918D5F56@xbill.org>
References: <RT-Ticket-4471@openssl.org>
 <558C903B-A05C-4B2C-A29E-065E918D5F56@xbill.org>
Message-ID: <rt-4.0.19-18545-1463140989-1400.4471-6-0@openssl.org>

Fixed in commit afdd82fb567db

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=4471
Please log in as guest with password guest if prompted


From rt at openssl.org  Fri May 13 12:08:51 2016
From: rt at openssl.org (Matt Caswell via RT)
Date: Fri, 13 May 2016 12:08:51 +0000
Subject: [openssl-dev] [openssl.org #4389] [PATCH] The NewSessionTicket
	message is not optional.
In-Reply-To: <CAF8qwaBe0DNX_rbrv674VShBavk7_YfaXs9Gc5o0cSjXNZe5HQ@mail.gmail.com>
References: <RT-Ticket-4389@openssl.org>
 <CAF8qwaBe0DNX_rbrv674VShBavk7_YfaXs9Gc5o0cSjXNZe5HQ@mail.gmail.com>
Message-ID: <rt-4.0.19-18545-1463141331-583.4389-6-0@openssl.org>

Patch applied in c45d6b2b0, and a test for this added in 5f7267598.

Thanks

Matt

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


From raji.kotamraju at gmail.com  Fri May 13 17:33:19 2016
From: raji.kotamraju at gmail.com (Rajeswari K)
Date: Fri, 13 May 2016 23:03:19 +0530
Subject: [openssl-dev] DTLS session resumption with DTLS_ANY_VERSION
In-Reply-To: <5732FADC.6010804@openssl.org>
References: <CA+mfXPFV6BaM4bTYf8oM7kHJhH3N2WRrKo0py-rbYsJEm2GJnw@mail.gmail.com>
 <5732FADC.6010804@openssl.org>
Message-ID: <CA+mfXPF4_QbskeeRj54h9pTnAQwr5yDGLOzn8r2xYmbZqSvA8A@mail.gmail.com>

Hi Matt,

Thanks for the response.

But, this fix doesn't perform session resumption.

Thanks,
Rajeswari.

On Wed, May 11, 2016 at 2:56 PM, Matt Caswell <matt at openssl.org> wrote:

>
>
> On 10/05/16 18:34, Rajeswari K wrote:
> > Hello openssl-dev team,
> >
> > Having query regarding DTLS session resumption when configured SSL_CTX
> > with DTLS_ANY_VERSION.
> >
> > When we select SSL_CTX with DTLS_ANY_VERSION, method will be of
> > DTLS_Server_method(), which will have ssl_ctx->version as 0xFEFD to
> > support both the versions (i.e. DTLS1.0 and DTLS1.2).
> >
> > During handshake, we landed on to version DTLS1.0.i.e.
> > s->session->version holds 0xFEFF.
> >
> > In order to perform session resumption, we derived new SSL structure
> > from global ssl_ctx using SSL_new() and tried performing ssl handshake.
> >
> > With the below logic,
> > else {
> >         i = ssl_get_prev_session(s, p, j, d + n);
> >         /*
> >          * Only resume if the session's version matches the negotiated
> >          * version.
> >          * RFC 5246 does not provide much useful advice on resumption
> >          * with a different protocol version. It doesn't forbid it but
> >          * the sanity of such behaviour would be questionable.
> >          * In practice, clients do not accept a version mismatch and
> >          * will abort the handshake with an error.
> >          */
> >         if (i == 1 && s->version == s->session->ssl_version) { /*
> previous
> >                                                                 *
> session */
> >             s->hit = 1;
> >         } else if (i == -1)
> >             goto err;
> >         else {                  /* i == 0 */
> >
> >             if (!ssl_get_new_session(s, 1))
> >                 goto err;
> >         }
> >
> > Since s->version is with 0xFEFD and s->session->ssl_version is 0xFEFF,
> > we always try for new session and wont land on to session resumption
> > though client has sent the  session_id.
> >
> > Is this intended behaviour? Please clarify.
>
>
> No. This appears to be a bug introduced by commit 03d14f588734 in
> November 2014.
>
> The real problem though is that the DTLS version negotiation is
> happening too late - after session resumption. Interestingly this only
> seems to be a problem in 1.0.2. In 1.1.0 this is working correctly (the
> version negotiation logic has been substantially rewritten in the new
> version).
>
> Please could you try out the attached patch? Let me know how you get on.
>
> Thanks
>
> Matt
>
> --
> openssl-dev mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20160513/aa9ab192/attachment-0001.html>

From matt at openssl.org  Fri May 13 17:46:14 2016
From: matt at openssl.org (Matt Caswell)
Date: Fri, 13 May 2016 18:46:14 +0100
Subject: [openssl-dev] DTLS session resumption with DTLS_ANY_VERSION
In-Reply-To: <CA+mfXPF4_QbskeeRj54h9pTnAQwr5yDGLOzn8r2xYmbZqSvA8A@mail.gmail.com>
References: <CA+mfXPFV6BaM4bTYf8oM7kHJhH3N2WRrKo0py-rbYsJEm2GJnw@mail.gmail.com>
 <5732FADC.6010804@openssl.org>
 <CA+mfXPF4_QbskeeRj54h9pTnAQwr5yDGLOzn8r2xYmbZqSvA8A@mail.gmail.com>
Message-ID: <573612E6.8060608@openssl.org>



On 13/05/16 18:33, Rajeswari K wrote:
> Hi Matt,
> 
> Thanks for the response. 
> 
> But, this fix doesn't perform session resumption. 

Did you try the patch?

As you pointed out we hit the following line:

        if (i == 1 && s->version == s->session->ssl_version) { /* previous
                                                                * session */

The version from the SSL object and the version from the session do not
match and that is why session resumption does not take place.

The reason that the versions do not match is because version negotiation
takes place *after* this check. So at this point s->version equals
DTLS_ANY_VERSION. My patch moves the version negotiation to before the
above test so that s->version should now be equal to DTLSv1, and
therefore should be the same as in s->session->ssl_version, and session
resumption should be successful.

Matt



> 
> Thanks,
> Rajeswari.
> 
> On Wed, May 11, 2016 at 2:56 PM, Matt Caswell <matt at openssl.org
> <mailto:matt at openssl.org>> wrote:
> 
> 
> 
>     On 10/05/16 18:34, Rajeswari K wrote:
>     > Hello openssl-dev team,
>     >
>     > Having query regarding DTLS session resumption when configured SSL_CTX
>     > with DTLS_ANY_VERSION.
>     >
>     > When we select SSL_CTX with DTLS_ANY_VERSION, method will be of
>     > DTLS_Server_method(), which will have ssl_ctx->version as 0xFEFD to
>     > support both the versions (i.e. DTLS1.0 and DTLS1.2).
>     >
>     > During handshake, we landed on to version DTLS1.0.i.e.
>     > s->session->version holds 0xFEFF.
>     >
>     > In order to perform session resumption, we derived new SSL structure
>     > from global ssl_ctx using SSL_new() and tried performing ssl
>     handshake.
>     >
>     > With the below logic,
>     > else {
>     >         i = ssl_get_prev_session(s, p, j, d + n);
>     >         /*
>     >          * Only resume if the session's version matches the negotiated
>     >          * version.
>     >          * RFC 5246 does not provide much useful advice on resumption
>     >          * with a different protocol version. It doesn't forbid it but
>     >          * the sanity of such behaviour would be questionable.
>     >          * In practice, clients do not accept a version mismatch and
>     >          * will abort the handshake with an error.
>     >          */
>     >         if (i == 1 && s->version == s->session->ssl_version) { /*
>     previous
>     >                                                                 *
>     session */
>     >             s->hit = 1;
>     >         } else if (i == -1)
>     >             goto err;
>     >         else {                  /* i == 0 */
>     >
>     >             if (!ssl_get_new_session(s, 1))
>     >                 goto err;
>     >         }
>     >
>     > Since s->version is with 0xFEFD and s->session->ssl_version is 0xFEFF,
>     > we always try for new session and wont land on to session resumption
>     > though client has sent the  session_id.
>     >
>     > Is this intended behaviour? Please clarify.
> 
> 
>     No. This appears to be a bug introduced by commit 03d14f588734 in
>     November 2014.
> 
>     The real problem though is that the DTLS version negotiation is
>     happening too late - after session resumption. Interestingly this only
>     seems to be a problem in 1.0.2. In 1.1.0 this is working correctly (the
>     version negotiation logic has been substantially rewritten in the new
>     version).
> 
>     Please could you try out the attached patch? Let me know how you get on.
> 
>     Thanks
> 
>     Matt
> 
>     --
>     openssl-dev mailing list
>     To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
> 
> 
> 
> 

From myles.borins at gmail.com  Fri May 13 20:57:56 2016
From: myles.borins at gmail.com (Myles Borins)
Date: Fri, 13 May 2016 13:57:56 -0700
Subject: [openssl-dev] Backport of ccae4a1582efcad311d095a8e6832b2b67d5ed05
Message-ID: <00B4B577-B413-4763-9AA8-3D551886A166@gmail.com>

Hey All,

I'm a collaborator on the Node.js project. Another collaborator sent a fix that has landed upstream to allow different protocol versions when reusing sessions.

https://github.com/openssl/openssl/pull/852 <https://github.com/openssl/openssl/pull/852>

We are currently experiencing problems with Node.js interacting with dynamoDB for people trying to use Lamda on AWS. Lamda is running on node v4, which is using openssl 1.0.2.

A pull request has been made to back port the change, and we are currently waiting for review. While we do float some patch?s on our openssl, we do not float anything that has not received review from the team.

https://github.com/openssl/openssl/pull/918 <https://github.com/openssl/openssl/pull/918>

I was curious if there is anything we can do to help expedite the process, you can see in this issue <https://github.com/aws/aws-sdk-js/issues/862> that there are numerous individuals affected by this problem, and some of the work arounds are? less than ideal.

Thank you for your time and all the hard work you do on the project!

Best,

Myles Borins
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20160513/e59342a5/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 455 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20160513/e59342a5/attachment.sig>

From rt at openssl.org  Sat May 14 11:56:37 2016
From: rt at openssl.org (Rich Salz via RT)
Date: Sat, 14 May 2016 11:56:37 +0000
Subject: [openssl-dev] [openssl.org #4063] Client Hello longer than 2^14
	bytes are rejected
In-Reply-To: <2666857.mJb7Wub1ca@pintsize.usersys.redhat.com>
References: <RT-Ticket-4063@openssl.org>
 <2666857.mJb7Wub1ca@pintsize.usersys.redhat.com>
Message-ID: <rt-4.0.19-18545-1463226997-827.4063-6-0@openssl.org>

Whew, *finally* we got around to putting this into master. Thanks! :)

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


From beldmit at gmail.com  Sat May 14 21:42:50 2016
From: beldmit at gmail.com (Dmitry Belyavsky)
Date: Sun, 15 May 2016 00:42:50 +0300
Subject: [openssl-dev] [openssl.org #4215] Results of regression for
	some apps
In-Reply-To: <rt-4.0.19-18545-1463139715-1098.4215-6-0@openssl.org>
References: <RT-Ticket-4215@openssl.org>
 <CADqLbzKx583zFh-aj1RLTD+a4M2sTOW_H2uXHLWOQ_OkcSfFJw@mail.gmail.com>
 <rt-4.0.19-18545-1463139715-1098.4215-6-0@openssl.org>
Message-ID: <CADqLbz+mCKcyPo4Ask6q8HXv9-eQPEiMMVoyBmqN_oUjzQLHmA@mail.gmail.com>

Dear Stephen,


On Fri, May 13, 2016 at 2:41 PM, Stephen Henson via RT <rt at openssl.org>
wrote:

> On Mon Jan 04 14:07:23 2016, beldmit at gmail.com wrote:
> > Hello!
> >
> > I found the following problems running my cipher suite with openssl 1.1.0
> >
> > 1. Some apps try to load the default config file twice. In case when we
> > load an engine via the config file and the engine prevents itself from
> > loading more than once, it causes errors.
> >
> > The attached patch contains fixes for the 'req' and 'ts' utilities, but
> may
> > be there are some more utilities with specific config files.
> >
> > 2. The 'smime' utility erroneously regards the '-signer' option to be the
> > name of input file. It's wrong when the utility uses this option in
> -verify
> > mode. So the attached patch makes this option to be processed as string,
> > not as input.
> >
> > 3. The 'cms' and 'smime' utilities do not accept the '-inform smime'
> > options. It may be a bug or not a bug (files in SMIME format are
> accepted)
> > but it is definitely an incompatibility.
> >
>
> Can you indicate if #1 is still a problem and if so give some details on
> how to
> reproduce it?
>

Yes. The bug is still reproducable with the req command.

To reproduce it, you need to specify the OPENSSL_CONF variable.
(You have to load the engine via config to enable the algorithms on startup
of the openssl).
The engine you load through the config must return an error on loading 2nd
time (as ccgost engine does).

So using the req command like this:

OPENSSL_CONF=openssl.conf openssl req -new -key mykey.pem

Will cause an error like this:

140444282672896:error:26078067:engine routines:engine_list_add:conflicting
engine id:crypto/engine/eng_list.c:116:
140444282672896:error:2606906E:engine routines:ENGINE_add:internal list
error:crypto/engine/eng_list.c:268:
140444282672896:error:260B6067:engine routines:dynamic_load:conflicting
engine id:crypto/engine/eng_dyn.c:544:
140444282672896:error:260BC066:engine routines:int_engine_configure:engine
configuration error:crypto/engine/eng_cnf.c:190:section=cryptocom_section,
name=dynamic_path, value=/path/to/libengine.so
140444282672896:error:0E07606D:configuration file
routines:module_run:module initialization
error:crypto/conf/conf_mod.c:221:module=engines, value=engine_section,
retcode=-1

To prevent it, it seems to me that it's necessary to check
whether the value of the variable 'template' does not match the variable
'default_config_file'
as the config file specified in the default_config_file variable is already
loaded.



>
> #2 and #3 should be addressed now.
>
> Thank you!


-- 
SY, Dmitry Belyavsky
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20160515/16114203/attachment.html>

From rt at openssl.org  Sat May 14 21:43:05 2016
From: rt at openssl.org (Dmitry Belyavsky via RT)
Date: Sat, 14 May 2016 21:43:05 +0000
Subject: [openssl-dev] [openssl.org #4215] Results of regression for
	some apps
In-Reply-To: <CADqLbz+mCKcyPo4Ask6q8HXv9-eQPEiMMVoyBmqN_oUjzQLHmA@mail.gmail.com>
References: <RT-Ticket-4215@openssl.org>
 <CADqLbzKx583zFh-aj1RLTD+a4M2sTOW_H2uXHLWOQ_OkcSfFJw@mail.gmail.com>
 <rt-4.0.19-18545-1463139715-1098.4215-6-0@openssl.org>
 <CADqLbz+mCKcyPo4Ask6q8HXv9-eQPEiMMVoyBmqN_oUjzQLHmA@mail.gmail.com>
Message-ID: <rt-4.0.19-1432-1463262185-417.4215-6-0@openssl.org>

Dear Stephen,


On Fri, May 13, 2016 at 2:41 PM, Stephen Henson via RT <rt at openssl.org>
wrote:

> On Mon Jan 04 14:07:23 2016, beldmit at gmail.com wrote:
> > Hello!
> >
> > I found the following problems running my cipher suite with openssl 1.1.0
> >
> > 1. Some apps try to load the default config file twice. In case when we
> > load an engine via the config file and the engine prevents itself from
> > loading more than once, it causes errors.
> >
> > The attached patch contains fixes for the 'req' and 'ts' utilities, but
> may
> > be there are some more utilities with specific config files.
> >
> > 2. The 'smime' utility erroneously regards the '-signer' option to be the
> > name of input file. It's wrong when the utility uses this option in
> -verify
> > mode. So the attached patch makes this option to be processed as string,
> > not as input.
> >
> > 3. The 'cms' and 'smime' utilities do not accept the '-inform smime'
> > options. It may be a bug or not a bug (files in SMIME format are
> accepted)
> > but it is definitely an incompatibility.
> >
>
> Can you indicate if #1 is still a problem and if so give some details on
> how to
> reproduce it?
>

Yes. The bug is still reproducable with the req command.

To reproduce it, you need to specify the OPENSSL_CONF variable.
(You have to load the engine via config to enable the algorithms on startup
of the openssl).
The engine you load through the config must return an error on loading 2nd
time (as ccgost engine does).

So using the req command like this:

OPENSSL_CONF=openssl.conf openssl req -new -key mykey.pem

Will cause an error like this:

140444282672896:error:26078067:engine routines:engine_list_add:conflicting
engine id:crypto/engine/eng_list.c:116:
140444282672896:error:2606906E:engine routines:ENGINE_add:internal list
error:crypto/engine/eng_list.c:268:
140444282672896:error:260B6067:engine routines:dynamic_load:conflicting
engine id:crypto/engine/eng_dyn.c:544:
140444282672896:error:260BC066:engine routines:int_engine_configure:engine
configuration error:crypto/engine/eng_cnf.c:190:section=cryptocom_section,
name=dynamic_path, value=/path/to/libengine.so
140444282672896:error:0E07606D:configuration file
routines:module_run:module initialization
error:crypto/conf/conf_mod.c:221:module=engines, value=engine_section,
retcode=-1

To prevent it, it seems to me that it's necessary to check
whether the value of the variable 'template' does not match the variable
'default_config_file'
as the config file specified in the default_config_file variable is already
loaded.



>
> #2 and #3 should be addressed now.
>
> Thank you!


-- 
SY, Dmitry Belyavsky

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


From rt at openssl.org  Sat May 14 23:38:20 2016
From: rt at openssl.org (yancm via RT)
Date: Sat, 14 May 2016 23:38:20 +0000
Subject: [openssl-dev] [openssl.org #4345] Bug - Cannot build
	openssl-1.1.0-pre4-dev on NetBSD 6_Stable
In-Reply-To: <db857ebb5197804a6ce23f5d7cbfb17c.squirrel@wm.sdf.org>
References: <RT-Ticket-4345@openssl.org>
 <4c16b2491b878e183f594c75f801f5bf.squirrel@wm.sdf.org>
 <rt-4.0.19-18545-1462912427-976.4345-6-0@openssl.org>
 <db857ebb5197804a6ce23f5d7cbfb17c.squirrel@wm.sdf.org>
Message-ID: <rt-4.0.19-18545-1463269100-1024.4345-6-0@openssl.org>

Richard,
OpenSSL 1.1.0-pre6-dev compiled, tested and installed fine with
"no-shared" config flag
Shared mode compiled and tested fine, but openssl executable could not
find it's libraries once installed...

I suggest to close this ticket...

thanks,
gene

> Hey,
>
> would you mind trying the latest beta, or a fresh master checkout? I can't
> know
> for sure, but it's possible you'll get better results now. If not, I'm all
> ears.
>
> Cheers,
> Richard
>
>
> On Thu Feb 25 13:13:41 2016, yancm at SDF.ORG wrote:
>> The first parts of this report are the actual build bug I think I am
>> encountering, but also, at the end, I am asking for additional help with
>> enabling the crypto-mdebug and crypto-mdebug-backtrace as I am trying to
>> to diagnose a compatibility issue between tor and the openssl 1.1.0_dev
>> branch.
>>
>> config and output:
>> *****Config command and output*****
>> # ./config --unified --debug --api=1.1.0 no-shared
>> Operating system: i686-whatever-netbsd
>> Configuring for BSD-x86-elf
>> Configuring OpenSSL version 1.1.0-pre4-dev (0x0x10100004L)
>> no-crypto-mdebug [default] OPENSSL_NO_CRYPTO_MDEBUG (skip dir)
>> no-crypto-mdebug-backtrace [forced]
>> 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-heartbeats [default] OPENSSL_NO_HEARTBEATS (skip dir)
>> no-md2 [default] OPENSSL_NO_MD2 (skip dir)
>> no-rc5 [default] OPENSSL_NO_RC5 (skip dir)
>> no-sctp [default] OPENSSL_NO_SCTP (skip dir)
>> no-shared [option]
>> no-ssl-trace [default] OPENSSL_NO_SSL_TRACE (skip dir)
>> no-static-engine [default] OPENSSL_NO_STATIC_ENGINE (skip dir)
>> no-unit-test [default] OPENSSL_NO_UNIT_TEST (skip dir)
>> no-zlib [default]
>> no-zlib-dynamic [forced]
>> Configuring for BSD-x86-elf
>> IsMK1MF =no
>> CC =cc
>> CFLAG = -pthread -D_THREAD_SAFE -D_REENTRANT -DL_ENDIAN -Wall -O0
>> -g -DWHIRLPOOL_ASM -Wa,--noexecstack
>> DEFINES =DSO_DLFCN HAVE_DLFCN_H OPENSSL_THREADS
>> OPENSSL_NO_STATIC_ENGINE OPENSSL_PIC OPENSSL_BN_ASM_PART_WORDS
>> OPENSSL_IA32_SSE2 OPENSSL_BN_ASM_MONT OPENSSL_BN_ASM_GF2m SHA1_ASM
>> SHA256_ASM SHA512_ASM MD5_ASM RMD160_ASM AES_ASM VPAES_ASM GHASH_ASM
>> ECP_NISTZ256_ASM POLY1305_ASM OPENSSL_API_COMPAT=0x10100000L
>> LFLAG =
>> PLIB_LFLAG =
>> EX_LIBS =
>> CPUID_OBJ =x86cpuid.o
>> BN_ASM =bn-586.o co-586.o x86-mont.o x86-gf2m.o
>> EC_ASM =ecp_nistz256.o ecp_nistz256-x86.o
>> DES_ENC =des-586.o crypt586.o
>> AES_ENC =aes-586.o vpaes-x86.o aesni-x86.o
>> BF_ENC =bf-586.o
>> CAST_ENC =c_enc.o
>> RC4_ENC =rc4-586.o
>> RC5_ENC =rc5-586.o
>> MD5_OBJ_ASM =md5-586.o
>> SHA1_OBJ_ASM =sha1-586.o sha256-586.o sha512-586.o
>> RMD160_OBJ_ASM=rmd-586.o
>> CMLL_ENC =cmll-x86.o
>> MODES_OBJ =ghash-x86.o
>> PADLOCK_OBJ =e_padlock-x86.o
>> CHACHA_ENC =chacha-x86.o
>> POLY1305_OBJ =poly1305-x86.o
>> PROCESSOR =
>> RANLIB =/usr/bin/ranlib
>> ARFLAGS =
>> PERL =/usr/pkg/bin/perl
>>
>> THIRTY_TWO_BIT mode
>> BN_LLONG mode
>>
>> Configured for BSD-x86-elf.
>> ***************************************
>>
>> if I gmake at the top level, the build proceeds for a while and appears
>> to
>> exit cleanly, but if I run gmake again, I get the following message:
>> # gmake
>> gmake: *** No rule to make target
>> 'usr/include/stdio.husr/include/sys/cdefs.h', needed by 'apps/openssl'.
>> Stop.
>>
>> ***************************************
>> I have problems even if I turn off debug.
>>
>> I really want debug AND I think I need to enable crypto-mdebug and
>> crypto-mdebug-backtrace so I can determine the calling line from tor
>> that
>> is crashing in openssl. The tor dev's think they have coded for
>> compatibility with openssl 1.1.0_dev, but I cannot confirm this on my
>> builds. I built tor with debug symbols, but so far, even if I set
>> breakpoints at main() in tor, running tor in gdb appears to crash in
>> openssl somewhere but I cannot execute a backtrace to see what line in
>> tor
>> is calling the openssl function that is failing. At the moment I cannot
>> even build openssl. I've had this issue for a week or two...
>>
>>
>>
>>
>>
>>
>
>
> --
> Richard Levitte
> levitte at openssl.org
>
> --
> Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4345
> Please log in as guest with password guest if prompted
>
>



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


From rt at openssl.org  Sun May 15 11:15:38 2016
From: rt at openssl.org (Richard Levitte via RT)
Date: Sun, 15 May 2016 11:15:38 +0000
Subject: [openssl-dev] [openssl.org #4345] Bug - Cannot build
	openssl-1.1.0-pre4-dev on NetBSD 6_Stable
In-Reply-To: <rt-4.0.19-18545-1463269100-1261.4345-6-0@openssl.org>
References: <RT-Ticket-4345@openssl.org>
 <4c16b2491b878e183f594c75f801f5bf.squirrel@wm.sdf.org>
 <rt-4.0.19-18545-1462912427-976.4345-6-0@openssl.org>
 <db857ebb5197804a6ce23f5d7cbfb17c.squirrel@wm.sdf.org>
 <rt-4.0.19-18545-1463269100-1261.4345-6-0@openssl.org>
Message-ID: <rt-4.0.19-1432-1463310938-1171.4345-6-0@openssl.org>

Closing ticket on request. You might want to take a closer look at the
installation problem and open a new ticket once you've figured it out.

Cheers,
Richard

On Sat May 14 23:38:20 2016, yancm at SDF.ORG wrote:
> Richard,
> OpenSSL 1.1.0-pre6-dev compiled, tested and installed fine with
> "no-shared" config flag
> Shared mode compiled and tested fine, but openssl executable could not
> find it's libraries once installed...
>
> I suggest to close this ticket...
>
> thanks,
> gene
>
> > Hey,
> >
> > would you mind trying the latest beta, or a fresh master checkout? I can't
> > know
> > for sure, but it's possible you'll get better results now. If not, I'm all
> > ears.
> >
> > Cheers,
> > Richard
> >
> >
> > On Thu Feb 25 13:13:41 2016, yancm at SDF.ORG wrote:
> >> The first parts of this report are the actual build bug I think I am
> >> encountering, but also, at the end, I am asking for additional help with
> >> enabling the crypto-mdebug and crypto-mdebug-backtrace as I am trying to
> >> to diagnose a compatibility issue between tor and the openssl 1.1.0_dev
> >> branch.
> >>
> >> config and output:
> >> *****Config command and output*****
> >> # ./config --unified --debug --api=1.1.0 no-shared
> >> Operating system: i686-whatever-netbsd
> >> Configuring for BSD-x86-elf
> >> Configuring OpenSSL version 1.1.0-pre4-dev (0x0x10100004L)
> >> no-crypto-mdebug [default] OPENSSL_NO_CRYPTO_MDEBUG (skip dir)
> >> no-crypto-mdebug-backtrace [forced]
> >> 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-heartbeats [default] OPENSSL_NO_HEARTBEATS (skip dir)
> >> no-md2 [default] OPENSSL_NO_MD2 (skip dir)
> >> no-rc5 [default] OPENSSL_NO_RC5 (skip dir)
> >> no-sctp [default] OPENSSL_NO_SCTP (skip dir)
> >> no-shared [option]
> >> no-ssl-trace [default] OPENSSL_NO_SSL_TRACE (skip dir)
> >> no-static-engine [default] OPENSSL_NO_STATIC_ENGINE (skip dir)
> >> no-unit-test [default] OPENSSL_NO_UNIT_TEST (skip dir)
> >> no-zlib [default]
> >> no-zlib-dynamic [forced]
> >> Configuring for BSD-x86-elf
> >> IsMK1MF =no
> >> CC =cc
> >> CFLAG = -pthread -D_THREAD_SAFE -D_REENTRANT -DL_ENDIAN -Wall -O0
> >> -g -DWHIRLPOOL_ASM -Wa,--noexecstack
> >> DEFINES =DSO_DLFCN HAVE_DLFCN_H OPENSSL_THREADS
> >> OPENSSL_NO_STATIC_ENGINE OPENSSL_PIC OPENSSL_BN_ASM_PART_WORDS
> >> OPENSSL_IA32_SSE2 OPENSSL_BN_ASM_MONT OPENSSL_BN_ASM_GF2m SHA1_ASM
> >> SHA256_ASM SHA512_ASM MD5_ASM RMD160_ASM AES_ASM VPAES_ASM GHASH_ASM
> >> ECP_NISTZ256_ASM POLY1305_ASM OPENSSL_API_COMPAT=0x10100000L
> >> LFLAG =
> >> PLIB_LFLAG =
> >> EX_LIBS =
> >> CPUID_OBJ =x86cpuid.o
> >> BN_ASM =bn-586.o co-586.o x86-mont.o x86-gf2m.o
> >> EC_ASM =ecp_nistz256.o ecp_nistz256-x86.o
> >> DES_ENC =des-586.o crypt586.o
> >> AES_ENC =aes-586.o vpaes-x86.o aesni-x86.o
> >> BF_ENC =bf-586.o
> >> CAST_ENC =c_enc.o
> >> RC4_ENC =rc4-586.o
> >> RC5_ENC =rc5-586.o
> >> MD5_OBJ_ASM =md5-586.o
> >> SHA1_OBJ_ASM =sha1-586.o sha256-586.o sha512-586.o
> >> RMD160_OBJ_ASM=rmd-586.o
> >> CMLL_ENC =cmll-x86.o
> >> MODES_OBJ =ghash-x86.o
> >> PADLOCK_OBJ =e_padlock-x86.o
> >> CHACHA_ENC =chacha-x86.o
> >> POLY1305_OBJ =poly1305-x86.o
> >> PROCESSOR =
> >> RANLIB =/usr/bin/ranlib
> >> ARFLAGS =
> >> PERL =/usr/pkg/bin/perl
> >>
> >> THIRTY_TWO_BIT mode
> >> BN_LLONG mode
> >>
> >> Configured for BSD-x86-elf.
> >> ***************************************
> >>
> >> if I gmake at the top level, the build proceeds for a while and appears
> >> to
> >> exit cleanly, but if I run gmake again, I get the following message:
> >> # gmake
> >> gmake: *** No rule to make target
> >> 'usr/include/stdio.husr/include/sys/cdefs.h', needed by 'apps/openssl'.
> >> Stop.
> >>
> >> ***************************************
> >> I have problems even if I turn off debug.
> >>
> >> I really want debug AND I think I need to enable crypto-mdebug and
> >> crypto-mdebug-backtrace so I can determine the calling line from tor
> >> that
> >> is crashing in openssl. The tor dev's think they have coded for
> >> compatibility with openssl 1.1.0_dev, but I cannot confirm this on my
> >> builds. I built tor with debug symbols, but so far, even if I set
> >> breakpoints at main() in tor, running tor in gdb appears to crash in
> >> openssl somewhere but I cannot execute a backtrace to see what line in
> >> tor
> >> is calling the openssl function that is failing. At the moment I cannot
> >> even build openssl. I've had this issue for a week or two...
> >>
> >>
> >>
> >>
> >>
> >>
> >
> >
> > --
> > Richard Levitte
> > levitte at openssl.org
> >
> > --
> > Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4345
> > Please log in as guest with password guest if prompted
> >
> >
>
>


--
Richard Levitte
levitte at openssl.org

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


From raji.kotamraju at gmail.com  Mon May 16 05:50:29 2016
From: raji.kotamraju at gmail.com (Rajeswari K)
Date: Mon, 16 May 2016 11:20:29 +0530
Subject: [openssl-dev] DTLS session resumption with DTLS_ANY_VERSION
In-Reply-To: <573612E6.8060608@openssl.org>
References: <CA+mfXPFV6BaM4bTYf8oM7kHJhH3N2WRrKo0py-rbYsJEm2GJnw@mail.gmail.com>
 <5732FADC.6010804@openssl.org>
 <CA+mfXPF4_QbskeeRj54h9pTnAQwr5yDGLOzn8r2xYmbZqSvA8A@mail.gmail.com>
 <573612E6.8060608@openssl.org>
Message-ID: <CA+mfXPHnjWD=8qcpJ4u7S8if0dFmURwgDo7-iZ7ee_t7b5aKsA@mail.gmail.com>

Hi Matt,

Yes, i tested with your patch. Honestly, before writing to openssl-dev
team, i tried session resumption with moving the version just like what you
gave as patch. But, still session resumption didn't work for me. Am
debugging same at openssl front.

Just to confirm on the issue, i tried hardcoding s->version and s->method
with DTLSv1 just after calling SSL_new() followed by SSL_clear(). Then
Session resumption worked as expected.

So, updation of s->version during handshake and updation of
s->session->version has some relation which am trying to find out.

I was looking at updation of s->session->version during handshake when the
version is DTLS_ANY_VERSION. Will check and update you on my findings if
any.

Thanks,
Rajeswari.


On Fri, May 13, 2016 at 11:16 PM, Matt Caswell <matt at openssl.org> wrote:

>
>
> On 13/05/16 18:33, Rajeswari K wrote:
> > Hi Matt,
> >
> > Thanks for the response.
> >
> > But, this fix doesn't perform session resumption.
>
> Did you try the patch?
>
> As you pointed out we hit the following line:
>
>         if (i == 1 && s->version == s->session->ssl_version) { /* previous
>                                                                 * session
> */
>
> The version from the SSL object and the version from the session do not
> match and that is why session resumption does not take place.
>
> The reason that the versions do not match is because version negotiation
> takes place *after* this check. So at this point s->version equals
> DTLS_ANY_VERSION. My patch moves the version negotiation to before the
> above test so that s->version should now be equal to DTLSv1, and
> therefore should be the same as in s->session->ssl_version, and session
> resumption should be successful.
>
> Matt
>
>
>
> >
> > Thanks,
> > Rajeswari.
> >
> > On Wed, May 11, 2016 at 2:56 PM, Matt Caswell <matt at openssl.org
> > <mailto:matt at openssl.org>> wrote:
> >
> >
> >
> >     On 10/05/16 18:34, Rajeswari K wrote:
> >     > Hello openssl-dev team,
> >     >
> >     > Having query regarding DTLS session resumption when configured
> SSL_CTX
> >     > with DTLS_ANY_VERSION.
> >     >
> >     > When we select SSL_CTX with DTLS_ANY_VERSION, method will be of
> >     > DTLS_Server_method(), which will have ssl_ctx->version as 0xFEFD to
> >     > support both the versions (i.e. DTLS1.0 and DTLS1.2).
> >     >
> >     > During handshake, we landed on to version DTLS1.0.i.e.
> >     > s->session->version holds 0xFEFF.
> >     >
> >     > In order to perform session resumption, we derived new SSL
> structure
> >     > from global ssl_ctx using SSL_new() and tried performing ssl
> >     handshake.
> >     >
> >     > With the below logic,
> >     > else {
> >     >         i = ssl_get_prev_session(s, p, j, d + n);
> >     >         /*
> >     >          * Only resume if the session's version matches the
> negotiated
> >     >          * version.
> >     >          * RFC 5246 does not provide much useful advice on
> resumption
> >     >          * with a different protocol version. It doesn't forbid it
> but
> >     >          * the sanity of such behaviour would be questionable.
> >     >          * In practice, clients do not accept a version mismatch
> and
> >     >          * will abort the handshake with an error.
> >     >          */
> >     >         if (i == 1 && s->version == s->session->ssl_version) { /*
> >     previous
> >     >                                                                 *
> >     session */
> >     >             s->hit = 1;
> >     >         } else if (i == -1)
> >     >             goto err;
> >     >         else {                  /* i == 0 */
> >     >
> >     >             if (!ssl_get_new_session(s, 1))
> >     >                 goto err;
> >     >         }
> >     >
> >     > Since s->version is with 0xFEFD and s->session->ssl_version is
> 0xFEFF,
> >     > we always try for new session and wont land on to session
> resumption
> >     > though client has sent the  session_id.
> >     >
> >     > Is this intended behaviour? Please clarify.
> >
> >
> >     No. This appears to be a bug introduced by commit 03d14f588734 in
> >     November 2014.
> >
> >     The real problem though is that the DTLS version negotiation is
> >     happening too late - after session resumption. Interestingly this
> only
> >     seems to be a problem in 1.0.2. In 1.1.0 this is working correctly
> (the
> >     version negotiation logic has been substantially rewritten in the new
> >     version).
> >
> >     Please could you try out the attached patch? Let me know how you get
> on.
> >
> >     Thanks
> >
> >     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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20160516/1a89e788/attachment-0001.html>

From rt at openssl.org  Mon May 16 13:42:16 2016
From: rt at openssl.org (Richard Levitte via RT)
Date: Mon, 16 May 2016 13:42:16 +0000
Subject: [openssl-dev] [openssl.org #2622] Buffer overflow using
	UI_add_input_string
In-Reply-To: <ogtobxlvzx2.fsf@mitre.org>
References: <RT-Ticket-2622@openssl.org> <ogtobxlvzx2.fsf@mitre.org>
Message-ID: <rt-4.0.19-841-1463406136-982.2622-6-0@openssl.org>

Fixing old ticket.

https://github.com/openssl/openssl/pull/1077

On Fri Oct 14 18:14:51 2011, ramsdell at mitre.org wrote:
> TrouSerS is an open-source TCG Software Stack by IBM. It uses OpenSSL
> to read passwords. The code in ssl_ui.c of the trousers library has a
> buffer overflow. I suspect many other applications may have the same
> problem because the documentation is not clear about how
> UI_add_input_string handles terminating null bytes. Here is the nub
> of the issue.
>
> People declare the buffer used by UI_add_input_string as:
>
> char pin_buf[UI_MAX_SECRET_STRING_LENGTH];
>
> and then call UI_add_input_string as:
>
> if (!UI_add_input_string(ui, "Enter PIN:", 0, pin_buf,
> 1, UI_MAX_SECRET_STRING_LENGTH))
>
> The documentation should tell them to use
>
> char pin_buf[UI_MAX_SECRET_STRING_LENGTH + 1];
>
> because there is a buffer overflow as demonstrated by the enclosed C
> program.
>
> $ make LDLIBS=-lcrypto ui
> cc ui.c -lcrypto -o ui
> $ ./ui
> pin_buf[UI_MAX_SECRET_STRING_LENGTH] = 1
> Enter PIN:ab
>
> strlen(pin_buf) = 2
> pin_buf = ab
> pin_buf[UI_MAX_SECRET_STRING_LENGTH] = 0
> $
>
> John
>


--
Richard Levitte
levitte at openssl.org

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


From rt at openssl.org  Mon May 16 13:55:12 2016
From: rt at openssl.org (Richard Levitte via RT)
Date: Mon, 16 May 2016 13:55:12 +0000
Subject: [openssl-dev] [openssl.org #2612] Segfault protection in X509v3
	extension API - PATCH
In-Reply-To: <rt-3.4.5-17788-1316768933-1807.2612-6-0@openssl.org>
References: <RT-Ticket-2612@openssl.org>
 <A0791806BB7A1A45AADDD832832C979CB77BD323BB@GBTWK10E001.Technology.local>
 <rt-3.4.5-52550-1316768620-164.2612-3-0@openssl.org>
 <A0791806BB7A1A45AADDD832832C979CB77BD323BC@GBTWK10E001.Technology.local>
 <rt-3.4.5-17788-1316768933-1807.2612-6-0@openssl.org>
Message-ID: <rt-4.0.19-841-1463406912-320.2612-6-0@openssl.org>

Old ticket, rejecting it. Those extension must be programmed correctly.

On Fri Sep 23 09:08:53 2011, nick.lewis at usa.g4s.com wrote:
> Please find attached below a revised patch that provides further
> protection against segmentation faults in the X509v3 extension API
>
> Best Regards
> Nick
>
> --------------------
>
> diff --git a/crypto/x509v3/v3_prn.c b/crypto/x509v3/v3_prn.c
> index 3146218..094861e 100755
> --- a/crypto/x509v3/v3_prn.c
> +++ b/crypto/x509v3/v3_prn.c
> @@ -118,7 +118,7 @@ int X509V3_EXT_print(BIO *out, X509_EXTENSION
> *ext, unsigned long flag, int inde
> return unknown_ext_print(out, ext, flag, indent, 0);
> p = ext->value->data;
> if(method->it) ext_str = ASN1_item_d2i(NULL, &p, ext->value-
> >length, ASN1_ITEM_ptr(method->it));
> - else ext_str = method->d2i(NULL, &p, ext->value->length);
> + else if(method->d2i) ext_str = method->d2i(NULL, &p, ext-
> >value->length);
>
> if(!ext_str) return unknown_ext_print(out, ext, flag, indent, 1);
>
> @@ -158,7 +158,7 @@ int X509V3_EXT_print(BIO *out, X509_EXTENSION
> *ext, unsigned long flag, int inde
> sk_CONF_VALUE_pop_free(nval, X509V3_conf_free);
> if(value) OPENSSL_free(value);
> if(method->it) ASN1_item_free(ext_str,
> ASN1_ITEM_ptr(method->it));
> - else method->ext_free(ext_str);
> + else if (method->ext_free) method->ext_free(ext_str);
> return ok;
> }
>
>
>
>
>
> The details of this company are as follows:
> G4S Technology Limited, Registered Office: Challenge House,
> International Drive, Tewkesbury, Gloucestershire GL20 8UQ, Registered
> in England No. 2382338.
>
> This communication may contain information which is confidential,
> personal and/or privileged.
>
> It is for the exclusive use of the intended recipient(s).
> If you are not the intended recipient(s), please note that any
> distribution, forwarding, copying or use of this communication or the
> information in it is strictly prohibited.
>
> Any personal views expressed in this e-mail are those of the
> individual sender and the company does not endorse or accept
> responsibility for them.
>
> Prior to taking any action based upon this e-mail message, you should
> seek appropriate confirmation of its authenticity.
>
> This e-mail has been scanned for all viruses by MessageLabs.


--
Richard Levitte
levitte at openssl.org

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


From rt at openssl.org  Mon May 16 13:56:26 2016
From: rt at openssl.org (Richard Levitte via RT)
Date: Mon, 16 May 2016 13:56:26 +0000
Subject: [openssl-dev] [openssl.org #2611] [PATCH] Support of TLSv1 in s_time
In-Reply-To: <m3d3eu5ui8.fsf@neo.luffy.cx>
References: <RT-Ticket-2611@openssl.org> <m3d3eu5ui8.fsf@neo.luffy.cx>
Message-ID: <rt-4.0.19-841-1463406986-1443.2611-6-0@openssl.org>

Removing outdated ticket.

On Fri Sep 23 09:03:13 2011, bernat at luffy.cx wrote:
> Hi!
>
> When OpenSSL is compiled with SSLv2 disabled, s_time is not able to use
> TLSv1 any more because it uses SSLv3_client_method(). This patch just
> adds a "-tls1" switch to s_time, like s_client, to enable TLSv1.
>
> I think a better way would be tu use SSLv23_client_method() even when
> SSLv2 is disabled at compile time because in this case,
> SSLv23_client_method() will use SSLv3 or TLSv1. However, since s_client
> also uses SSLv3_client_method() by default when SSLv2 is disabled at
> compile time, I have kept this semantic.
>


--
Richard Levitte
levitte at openssl.org

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


From rt at openssl.org  Mon May 16 14:02:41 2016
From: rt at openssl.org (Richard Levitte via RT)
Date: Mon, 16 May 2016 14:02:41 +0000
Subject: [openssl-dev] [openssl.org #2590] change commonName entry for
	default openssl config file
In-Reply-To: <CALcaFhQwcf04XjasK9Ec441k1BV4=LP2p0zASbzoc9v=omNZyw@mail.gmail.com>
References: <RT-Ticket-2590@openssl.org>
 <CALcaFhQwcf04XjasK9Ec441k1BV4=LP2p0zASbzoc9v=omNZyw@mail.gmail.com>
Message-ID: <rt-4.0.19-840-1463407361-1511.2590-6-0@openssl.org>

There's no *requirement* in X.509 to have the host name in the CN. As a matter
of fact, there are X.509v3 extensions that are better suited for this purpose.

Closing ticket.

On Wed Aug 31 07:03:17 2011, dtauerbach at gmail.com wrote:
> Hi,
>
> This is just a minor thing that always bugs me whenever I install openssl;
> by default the openssl configuration file (/etc/ssl/openssl.cnf) has the
> following line:
>
> "commonName = Common Name (eg, YOUR name)"
>
> Sometimes when I'm installing a certificate I accidentally forget to write
> my host name given this prompt (as I just did a few minutes ago). I'd
> suggest
>
> "commonName = Common Name (your host name)"
>
> since the X.509 format of course requires the CN to be the host. I suspect
> this default configuration file is being copied from apps/openssl.cnf,
> though I confess this is just based on a diff without looking too closely.
> This is of course very minor, but an easy change so I hope you'll consider
> it to save lots of future idiots like me 30 seconds.
>
> (I am running Ubuntu 10.04 (old!) at the moment, and peeked at the source
> code from the openssl-fips-1.2.3.tar.gz tarball.)
>
> Thanks,
> Dan


--
Richard Levitte
levitte at openssl.org

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


From tshort at akamai.com  Mon May 16 14:49:55 2016
From: tshort at akamai.com (Short, Todd)
Date: Mon, 16 May 2016 14:49:55 +0000
Subject: [openssl-dev] master failing unit tests inconsistently?
Message-ID: <F6B1C6A0-31A1-4DEA-98BE-D25C95D9D3A3@akamai.com>

Hi openssl-dev:

I?ve been running the master branch and have been noticing inconsistant unit tests results. It is failing on a number of tests, and has been for several days. I?m using clang-3.6 (3.6.0-2ubuntu1~trust1) or gcc (4.84-2ubuntu1~14.04.01) on Linux 3.13-0-85-generic #129-Ubuntu.

This is one sample:

../test/recipes/70-test_sslcertstatus.t .... Failed 1/1 subtests
../test/recipes/70-test_sslextension.t ..... Failed 2/3 subtests
../test/recipes/70-test_sslsessiontick.t ... Failed 9/10 subtests
../test/recipes/70-test_sslskewith0p.t ..... (hangs)

OR

Test Summary Report
-------------------
../test/recipes/70-test_sslextension.t   (Wstat: 13 Tests: 2 Failed: 0)
  Non-zero wait status: 13
  Parse errors: Bad plan.  You planned 3 tests but ran 2.
../test/recipes/70-test_sslsessiontick.t (Wstat: 13 Tests: 1 Failed: 0)
  Non-zero wait status: 13
  Parse errors: Bad plan.  You planned 8 tests but ran 1.
../test/recipes/70-test_sslvertol.t      (Wstat: 13 Tests: 0 Failed: 0)
  Non-zero wait status: 13
  Parse errors: Bad plan.  You planned 2 tests but ran 0.
../test/recipes/70-test_tlsextms.t       (Wstat: 13 Tests: 1 Failed: 0)
  Non-zero wait status: 13
  Parse errors: Bad plan.  You planned 9 tests but ran 1.
Files=78, Tests=417, 107 wallclock secs ( 0.65 usr  0.08 sys + 93.02 cusr 14.76 csys = 108.51 CPU)
Result: FAIL
Failed 4/78 test programs. 0/417 subtests failed.
make: *** [tests] Error 255

Is anyone else seeing this?

It seems related to https://github.com/openssl/openssl/commit/7ad5fb6267e9da1634998bf2eccaa753f443fa83

--
-Todd Short
// tshort at akamai.com<mailto:tshort at akamai.com>
// "One if by land, two if by sea, three if by the Internet."

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20160516/41fc039d/attachment.html>

From matt at openssl.org  Mon May 16 14:57:44 2016
From: matt at openssl.org (Matt Caswell)
Date: Mon, 16 May 2016 15:57:44 +0100
Subject: [openssl-dev] master failing unit tests inconsistently?
In-Reply-To: <F6B1C6A0-31A1-4DEA-98BE-D25C95D9D3A3@akamai.com>
References: <F6B1C6A0-31A1-4DEA-98BE-D25C95D9D3A3@akamai.com>
Message-ID: <5739DFE8.8020509@openssl.org>

Yes, its a known issue. No fix as yet.

Matt

On 16/05/16 15:49, Short, Todd wrote:
> Hi openssl-dev:
> 
> I?ve been running the master branch and have been noticing inconsistant
> unit tests results. It is failing on a number of tests, and has been for
> several days. I?m using clang-3.6 (3.6.0-2ubuntu1~trust1) or gcc
> (4.84-2ubuntu1~14.04.01) on Linux 3.13-0-85-generic #129-Ubuntu.
> 
> This is one sample:
> 
> ../test/recipes/70-test_sslcertstatus.t .... Failed 1/1 subtests 
> ../test/recipes/70-test_sslextension.t ..... Failed 2/3 subtests 
> ../test/recipes/70-test_sslsessiontick.t ... Failed 9/10 subtests 
> ../test/recipes/70-test_sslskewith0p.t ..... (hangs)
> 
> OR
> 
> Test Summary Report
> -------------------
> ../test/recipes/70-test_sslextension.t   (Wstat: 13 Tests: 2 Failed: 0)
>   Non-zero wait status: 13
>   Parse errors: Bad plan.  You planned 3 tests but ran 2.
> ../test/recipes/70-test_sslsessiontick.t (Wstat: 13 Tests: 1 Failed: 0)
>   Non-zero wait status: 13
>   Parse errors: Bad plan.  You planned 8 tests but ran 1.
> ../test/recipes/70-test_sslvertol.t      (Wstat: 13 Tests: 0 Failed: 0)
>   Non-zero wait status: 13
>   Parse errors: Bad plan.  You planned 2 tests but ran 0.
> ../test/recipes/70-test_tlsextms.t       (Wstat: 13 Tests: 1 Failed: 0)
>   Non-zero wait status: 13
>   Parse errors: Bad plan.  You planned 9 tests but ran 1.
> Files=78, Tests=417, 107 wallclock secs ( 0.65 usr  0.08 sys + 93.02
> cusr 14.76 csys = 108.51 CPU)
> Result: FAIL
> Failed 4/78 test programs. 0/417 subtests failed.
> make: *** [tests] Error 255
> 
> Is anyone else seeing this?
> 
> It seems related
> to https://github.com/openssl/openssl/commit/7ad5fb6267e9da1634998bf2eccaa753f443fa83
> 
> --
> -Todd Short
> // tshort at akamai.com <mailto:tshort at akamai.com>
> // "One if by land, two if by sea, three if by the Internet."
> 
> 
> 

From raveendra.padasalagi at broadcom.com  Mon May 16 15:25:03 2016
From: raveendra.padasalagi at broadcom.com (Raveendra Padasalagi)
Date: Mon, 16 May 2016 20:55:03 +0530
Subject: [openssl-dev] Need info on offloading TLS to hardware crypto
	accelerator
Message-ID: <9e9720ec83a6a403a71f858fe9548975@mail.gmail.com>

Hi,

We have a HW IP block which implements TLS protocols cipher/hash
offloading for TLS AEAD and TLS cipher's.
Linux kernel doesn't support TLS in the kernel and hence can't access the
HW IP block using linux kernel crypto framework.

Any suggestions or information on implementing TLS offloading using
hardware crypto acceleration with 'openssl' is appreciated.

Regards,
Raveendra

From matt at openssl.org  Mon May 16 16:22:21 2016
From: matt at openssl.org (Matt Caswell)
Date: Mon, 16 May 2016 17:22:21 +0100
Subject: [openssl-dev] master failing unit tests inconsistently?
In-Reply-To: <5739DFE8.8020509@openssl.org>
References: <F6B1C6A0-31A1-4DEA-98BE-D25C95D9D3A3@akamai.com>
 <5739DFE8.8020509@openssl.org>
Message-ID: <5739F3BD.60105@openssl.org>



On 16/05/16 15:57, Matt Caswell wrote:
> Yes, its a known issue. No fix as yet.

Hopefully 6ae5452481 has fixed the issue.

Matt


> 
> Matt
> 
> On 16/05/16 15:49, Short, Todd wrote:
>> Hi openssl-dev:
>>
>> I?ve been running the master branch and have been noticing inconsistant
>> unit tests results. It is failing on a number of tests, and has been for
>> several days. I?m using clang-3.6 (3.6.0-2ubuntu1~trust1) or gcc
>> (4.84-2ubuntu1~14.04.01) on Linux 3.13-0-85-generic #129-Ubuntu.
>>
>> This is one sample:
>>
>> ../test/recipes/70-test_sslcertstatus.t .... Failed 1/1 subtests 
>> ../test/recipes/70-test_sslextension.t ..... Failed 2/3 subtests 
>> ../test/recipes/70-test_sslsessiontick.t ... Failed 9/10 subtests 
>> ../test/recipes/70-test_sslskewith0p.t ..... (hangs)
>>
>> OR
>>
>> Test Summary Report
>> -------------------
>> ../test/recipes/70-test_sslextension.t   (Wstat: 13 Tests: 2 Failed: 0)
>>   Non-zero wait status: 13
>>   Parse errors: Bad plan.  You planned 3 tests but ran 2.
>> ../test/recipes/70-test_sslsessiontick.t (Wstat: 13 Tests: 1 Failed: 0)
>>   Non-zero wait status: 13
>>   Parse errors: Bad plan.  You planned 8 tests but ran 1.
>> ../test/recipes/70-test_sslvertol.t      (Wstat: 13 Tests: 0 Failed: 0)
>>   Non-zero wait status: 13
>>   Parse errors: Bad plan.  You planned 2 tests but ran 0.
>> ../test/recipes/70-test_tlsextms.t       (Wstat: 13 Tests: 1 Failed: 0)
>>   Non-zero wait status: 13
>>   Parse errors: Bad plan.  You planned 9 tests but ran 1.
>> Files=78, Tests=417, 107 wallclock secs ( 0.65 usr  0.08 sys + 93.02
>> cusr 14.76 csys = 108.51 CPU)
>> Result: FAIL
>> Failed 4/78 test programs. 0/417 subtests failed.
>> make: *** [tests] Error 255
>>
>> Is anyone else seeing this?
>>
>> It seems related
>> to https://github.com/openssl/openssl/commit/7ad5fb6267e9da1634998bf2eccaa753f443fa83
>>
>> --
>> -Todd Short
>> // tshort at akamai.com <mailto:tshort at akamai.com>
>> // "One if by land, two if by sea, three if by the Internet."
>>
>>
>>

From rt at openssl.org  Mon May 16 16:36:18 2016
From: rt at openssl.org (Richard Levitte via RT)
Date: Mon, 16 May 2016 16:36:18 +0000
Subject: [openssl-dev] [openssl.org #2622] Buffer overflow using
	UI_add_input_string
In-Reply-To: <rt-4.0.19-841-1463406136-1522.2622-6-0@openssl.org>
References: <RT-Ticket-2622@openssl.org> <ogtobxlvzx2.fsf@mitre.org>
 <rt-4.0.19-841-1463406136-1522.2622-6-0@openssl.org>
Message-ID: <rt-4.0.19-840-1463416578-1150.2622-6-0@openssl.org>

Fixed, both for upcoming 1.1.0 and for 1.0.2.

On Mon May 16 13:42:16 2016, levitte wrote:
> Fixing old ticket.
>
> https://github.com/openssl/openssl/pull/1077
>
> On Fri Oct 14 18:14:51 2011, ramsdell at mitre.org wrote:
> > TrouSerS is an open-source TCG Software Stack by IBM. It uses OpenSSL
> > to read passwords. The code in ssl_ui.c of the trousers library has a
> > buffer overflow. I suspect many other applications may have the same
> > problem because the documentation is not clear about how
> > UI_add_input_string handles terminating null bytes. Here is the nub
> > of the issue.
> >
> > People declare the buffer used by UI_add_input_string as:
> >
> > char pin_buf[UI_MAX_SECRET_STRING_LENGTH];
> >
> > and then call UI_add_input_string as:
> >
> > if (!UI_add_input_string(ui, "Enter PIN:", 0, pin_buf,
> > 1, UI_MAX_SECRET_STRING_LENGTH))
> >
> > The documentation should tell them to use
> >
> > char pin_buf[UI_MAX_SECRET_STRING_LENGTH + 1];
> >
> > because there is a buffer overflow as demonstrated by the enclosed C
> > program.
> >
> > $ make LDLIBS=-lcrypto ui
> > cc ui.c -lcrypto -o ui
> > $ ./ui
> > pin_buf[UI_MAX_SECRET_STRING_LENGTH] = 1
> > Enter PIN:ab
> >
> > strlen(pin_buf) = 2
> > pin_buf = ab
> > pin_buf[UI_MAX_SECRET_STRING_LENGTH] = 0
> > $
> >
> > John
> >
>
>
> --
> Richard Levitte
> levitte at openssl.org


--
Richard Levitte
levitte at openssl.org

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


From rt at openssl.org  Mon May 16 16:43:19 2016
From: rt at openssl.org (Matt Caswell via RT)
Date: Mon, 16 May 2016 16:43:19 +0000
Subject: [openssl-dev] [openssl.org #2459] ecdsa_method declaration prevents
	use in implementing a dynamic engine
In-Reply-To: <AANLkTi=USC3R18Vtcw4cmhSgmVHF_nL7sVhggz+nLUtn@mail.gmail.com>
References: <RT-Ticket-2459@openssl.org>
 <AANLkTi=USC3R18Vtcw4cmhSgmVHF_nL7sVhggz+nLUtn@mail.gmail.com>
Message-ID: <rt-4.0.19-840-1463416999-922.2459-6-0@openssl.org>

This has been fixed in 1.1.0.

Matt

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


From rt at openssl.org  Mon May 16 17:33:29 2016
From: rt at openssl.org (Stephen Henson via RT)
Date: Mon, 16 May 2016 17:33:29 +0000
Subject: [openssl-dev] [openssl.org #4215] Results of regression for some
	apps
In-Reply-To: <rt-4.0.19-1432-1463262185-1952.4215-6-0@openssl.org>
References: <RT-Ticket-4215@openssl.org>
 <CADqLbzKx583zFh-aj1RLTD+a4M2sTOW_H2uXHLWOQ_OkcSfFJw@mail.gmail.com>
 <rt-4.0.19-18545-1463139715-1098.4215-6-0@openssl.org>
 <CADqLbz+mCKcyPo4Ask6q8HXv9-eQPEiMMVoyBmqN_oUjzQLHmA@mail.gmail.com>
 <rt-4.0.19-1432-1463262185-1952.4215-6-0@openssl.org>
Message-ID: <rt-4.0.19-841-1463420009-358.4215-6-0@openssl.org>

On Sat May 14 21:43:05 2016, beldmit at gmail.com wrote:
>
> Yes. The bug is still reproducable with the req command.
>
> To reproduce it, you need to specify the OPENSSL_CONF variable.
> (You have to load the engine via config to enable the algorithms on
> startup
> of the openssl).
> The engine you load through the config must return an error on loading
> 2nd
> time (as ccgost engine does).
>
> So using the req command like this:
>
> OPENSSL_CONF=openssl.conf openssl req -new -key mykey.pem
>
> Will cause an error like this:
>
> 140444282672896:error:26078067:engine
> routines:engine_list_add:conflicting
> engine id:crypto/engine/eng_list.c:116:
> 140444282672896:error:2606906E:engine routines:ENGINE_add:internal
> list
> error:crypto/engine/eng_list.c:268:
> 140444282672896:error:260B6067:engine
> routines:dynamic_load:conflicting
> engine id:crypto/engine/eng_dyn.c:544:
> 140444282672896:error:260BC066:engine
> routines:int_engine_configure:engine
> configuration
> error:crypto/engine/eng_cnf.c:190:section=cryptocom_section,
> name=dynamic_path, value=/path/to/libengine.so
> 140444282672896:error:0E07606D:configuration file
> routines:module_run:module initialization
> error:crypto/conf/conf_mod.c:221:module=engines, value=engine_section,
> retcode=-1
>

Fixed now in commit c821defc3f728a491856b7

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=4215
Please log in as guest with password guest if prompted


From rt at openssl.org  Mon May 16 18:32:13 2016
From: rt at openssl.org (Brian Wellington via RT)
Date: Mon, 16 May 2016 18:32:13 +0000
Subject: [openssl-dev] [openssl.org #4471] 1.1.0-pre4 safestack.h
	compilation errors with -Wcast-qual
In-Reply-To: <03C288C2-39FD-466F-8DC0-C27BECB57077@xbill.org>
References: <RT-Ticket-4471@openssl.org>
 <558C903B-A05C-4B2C-A29E-065E918D5F56@xbill.org>
 <rt-4.0.19-18545-1463140989-1400.4471-6-0@openssl.org>
 <03C288C2-39FD-466F-8DC0-C27BECB57077@xbill.org>
Message-ID: <rt-4.0.19-840-1463423533-738.4471-6-0@openssl.org>

This is fixed, but there are similar problems that still exist, for example:

?
#include <openssl/err.h>
#include <openssl/ssl.h>

int
main(int argc, char **argv) {
    return 0;
}
?

clang -Wcast-qual -o foo.o foo.c -I openssl-SNAP-20160516/include/
In file included from foo.c:1:
In file included from openssl-SNAP-20160516/include/openssl/err.h:123:
openssl-SNAP-20160516/include/openssl/lhash.h:265:1: warning: cast from 'const
      struct lhash_st_OPENSSL_STRING *' to 'struct lhash_st *' drops const
      qualifier [-Wcast-qual]
DEFINE_LHASH_OF(OPENSSL_STRING);
^
openssl-SNAP-20160516/include/openssl/lhash.h:217:37: note: expanded from macro
      'DEFINE_LHASH_OF'
        lh_node_stats_bio((_LHASH *)lh, out); \
                                    ^
openssl-SNAP-20160516/include/openssl/lhash.h:265:1: warning: cast from 'const
      struct lhash_st_OPENSSL_STRING *' to 'struct lhash_st *' drops const
      qualifier [-Wcast-qual]
openssl-SNAP-20160516/include/openssl/lhash.h:221:43: note: expanded from macro
      'DEFINE_LHASH_OF'
        lh_node_usage_stats_bio((_LHASH *)lh, out); \
                                          ^
openssl-SNAP-20160516/include/openssl/lhash.h:265:1: warning: cast from 'const
      struct lhash_st_OPENSSL_STRING *' to 'struct lhash_st *' drops const
      qualifier [-Wcast-qual]
openssl-SNAP-20160516/include/openssl/lhash.h:225:32: note: expanded from macro
      'DEFINE_LHASH_OF'
        lh_stats_bio((_LHASH *)lh, out); \
                               ^
openssl-SNAP-20160516/include/openssl/lhash.h:266:1: warning: cast from 'const
      struct lhash_st_OPENSSL_CSTRING *' to 'struct lhash_st *' drops const
      qualifier [-Wcast-qual]
DEFINE_LHASH_OF(OPENSSL_CSTRING);
^
openssl-SNAP-20160516/include/openssl/lhash.h:217:37: note: expanded from macro
      'DEFINE_LHASH_OF'
        lh_node_stats_bio((_LHASH *)lh, out); \
                                    ^
openssl-SNAP-20160516/include/openssl/lhash.h:266:1: warning: cast from 'const
      struct lhash_st_OPENSSL_CSTRING *' to 'struct lhash_st *' drops const
      qualifier [-Wcast-qual]
openssl-SNAP-20160516/include/openssl/lhash.h:221:43: note: expanded from macro
      'DEFINE_LHASH_OF'
        lh_node_usage_stats_bio((_LHASH *)lh, out); \
                                          ^
openssl-SNAP-20160516/include/openssl/lhash.h:266:1: warning: cast from 'const
      struct lhash_st_OPENSSL_CSTRING *' to 'struct lhash_st *' drops const
      qualifier [-Wcast-qual]
openssl-SNAP-20160516/include/openssl/lhash.h:225:32: note: expanded from macro
      'DEFINE_LHASH_OF'
        lh_stats_bio((_LHASH *)lh, out); \
                               ^
In file included from foo.c:1:
openssl-SNAP-20160516/include/openssl/err.h:321:1: warning: cast from 'const
      struct lhash_st_ERR_STRING_DATA *' to 'struct lhash_st *' drops const
      qualifier [-Wcast-qual]
DEFINE_LHASH_OF(ERR_STRING_DATA);
^
openssl-SNAP-20160516/include/openssl/lhash.h:217:37: note: expanded from macro
      'DEFINE_LHASH_OF'
        lh_node_stats_bio((_LHASH *)lh, out); \
                                    ^
In file included from foo.c:1:
openssl-SNAP-20160516/include/openssl/err.h:321:1: warning: cast from 'const
      struct lhash_st_ERR_STRING_DATA *' to 'struct lhash_st *' drops const
      qualifier [-Wcast-qual]
openssl-SNAP-20160516/include/openssl/lhash.h:221:43: note: expanded from macro
      'DEFINE_LHASH_OF'
        lh_node_usage_stats_bio((_LHASH *)lh, out); \
                                          ^
In file included from foo.c:1:
openssl-SNAP-20160516/include/openssl/err.h:321:1: warning: cast from 'const
      struct lhash_st_ERR_STRING_DATA *' to 'struct lhash_st *' drops const
      qualifier [-Wcast-qual]
openssl-SNAP-20160516/include/openssl/lhash.h:225:32: note: expanded from macro
      'DEFINE_LHASH_OF'
        lh_stats_bio((_LHASH *)lh, out); \
                               ^
In file included from foo.c:2:
openssl-SNAP-20160516/include/openssl/ssl.h:918:1: warning: cast from 'const
      struct ssl_cipher_st *' to 'void *' drops const qualifier [-Wcast-qual]
DEFINE_STACK_OF_CONST(SSL_CIPHER)
^
openssl-SNAP-20160516/include/openssl/safestack.h:188:35: note: expanded from
      macro 'DEFINE_STACK_OF_CONST'
# define DEFINE_STACK_OF_CONST(t) SKM_DEFINE_STACK_OF(t, const t, t)
                                  ^
openssl-SNAP-20160516/include/openssl/safestack.h:123:58: note: expanded from
      macro 'SKM_DEFINE_STACK_OF'
        return (t2 *)sk_delete_ptr((_STACK *)sk, (void *)ptr); \
                                                         ^
In file included from foo.c:2:
openssl-SNAP-20160516/include/openssl/ssl.h:918:1: warning: cast from 'const
      struct ssl_cipher_st *' to 'void *' drops const qualifier [-Wcast-qual]
openssl-SNAP-20160516/include/openssl/safestack.h:188:35: note: expanded from
      macro 'DEFINE_STACK_OF_CONST'
# define DEFINE_STACK_OF_CONST(t) SKM_DEFINE_STACK_OF(t, const t, t)
                                  ^
openssl-SNAP-20160516/include/openssl/safestack.h:127:46: note: expanded from
      macro 'SKM_DEFINE_STACK_OF'
        return sk_push((_STACK *)sk, (void *)ptr); \
                                             ^
In file included from foo.c:2:
openssl-SNAP-20160516/include/openssl/ssl.h:918:1: warning: cast from 'const
      struct ssl_cipher_st *' to 'void *' drops const qualifier [-Wcast-qual]
openssl-SNAP-20160516/include/openssl/safestack.h:188:35: note: expanded from
      macro 'DEFINE_STACK_OF_CONST'
# define DEFINE_STACK_OF_CONST(t) SKM_DEFINE_STACK_OF(t, const t, t)
                                  ^
openssl-SNAP-20160516/include/openssl/safestack.h:131:49: note: expanded from
      macro 'SKM_DEFINE_STACK_OF'
        return sk_unshift((_STACK *)sk, (void *)ptr); \
                                                ^
In file included from foo.c:2:
openssl-SNAP-20160516/include/openssl/ssl.h:918:1: warning: cast from 'const
      struct ssl_cipher_st *' to 'void *' drops const qualifier [-Wcast-qual]
openssl-SNAP-20160516/include/openssl/safestack.h:188:35: note: expanded from
      macro 'DEFINE_STACK_OF_CONST'
# define DEFINE_STACK_OF_CONST(t) SKM_DEFINE_STACK_OF(t, const t, t)
                                  ^
openssl-SNAP-20160516/include/openssl/safestack.h:147:48: note: expanded from
      macro 'SKM_DEFINE_STACK_OF'
        return sk_insert((_STACK *)sk, (void *)ptr, idx); \
                                               ^
In file included from foo.c:2:
openssl-SNAP-20160516/include/openssl/ssl.h:918:1: warning: cast from 'const
      struct ssl_cipher_st *' to 'void *' drops const qualifier [-Wcast-qual]
openssl-SNAP-20160516/include/openssl/safestack.h:188:35: note: expanded from
      macro 'DEFINE_STACK_OF_CONST'
# define DEFINE_STACK_OF_CONST(t) SKM_DEFINE_STACK_OF(t, const t, t)
                                  ^
openssl-SNAP-20160516/include/openssl/safestack.h:151:56: note: expanded from
      macro 'SKM_DEFINE_STACK_OF'
        return (t2 *)sk_set((_STACK *)sk, idx, (void *)ptr); \
                                                       ^
In file included from foo.c:2:
openssl-SNAP-20160516/include/openssl/ssl.h:918:1: warning: cast from 'const
      struct ssl_cipher_st *' to 'void *' drops const qualifier [-Wcast-qual]
openssl-SNAP-20160516/include/openssl/safestack.h:188:35: note: expanded from
      macro 'DEFINE_STACK_OF_CONST'
# define DEFINE_STACK_OF_CONST(t) SKM_DEFINE_STACK_OF(t, const t, t)
                                  ^
openssl-SNAP-20160516/include/openssl/safestack.h:155:46: note: expanded from
      macro 'SKM_DEFINE_STACK_OF'
        return sk_find((_STACK *)sk, (void *)ptr); \
                                             ^
In file included from foo.c:2:
openssl-SNAP-20160516/include/openssl/ssl.h:918:1: warning: cast from 'const
      struct ssl_cipher_st *' to 'void *' drops const qualifier [-Wcast-qual]
openssl-SNAP-20160516/include/openssl/safestack.h:188:35: note: expanded from
      macro 'DEFINE_STACK_OF_CONST'
# define DEFINE_STACK_OF_CONST(t) SKM_DEFINE_STACK_OF(t, const t, t)
                                  ^
openssl-SNAP-20160516/include/openssl/safestack.h:159:49: note: expanded from
      macro 'SKM_DEFINE_STACK_OF'
        return sk_find_ex((_STACK *)sk, (void *)ptr); \
                                                ^
16 warnings generated.
wavelet:~/Work/Software: 


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


From rt at openssl.org  Mon May 16 19:04:35 2016
From: rt at openssl.org (Matt Caswell via RT)
Date: Mon, 16 May 2016 19:04:35 +0000
Subject: [openssl-dev] [openssl.org #2485] Heap walking in RAND_poll causes
	deadlock in process on Windows Server 2008 R2 (x64) that uses
	libCurl, OpenSSL and ADO
In-Reply-To: <C110171C67AE58439FFF933B4958A59A10079D29@DUB2XCHCLUPIN03.enterprise.veritas.com>
References: <RT-Ticket-2485@openssl.org>
 <C110171C67AE58439FFF933B4958A59A10079D29@DUB2XCHCLUPIN03.enterprise.veritas.com>
Message-ID: <rt-4.0.19-841-1463425475-374.2485-6-0@openssl.org>

Closing this ticket in favour of:
https://github.com/openssl/openssl/pull/1079

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


From xoloki at gmail.com  Mon May 16 20:44:06 2016
From: xoloki at gmail.com (Joey Yandle)
Date: Mon, 16 May 2016 13:44:06 -0700
Subject: [openssl-dev] [openssl.org #2485] Heap walking in RAND_poll
 causes deadlock in process on Windows Server 2008 R2 (x64) that uses
 libCurl, OpenSSL and ADO
In-Reply-To: <rt-4.0.19-841-1463425475-374.2485-6-0@openssl.org>
References: <RT-Ticket-2485@openssl.org>
 <C110171C67AE58439FFF933B4958A59A10079D29@DUB2XCHCLUPIN03.enterprise.veritas.com>
 <rt-4.0.19-841-1463425475-374.2485-6-0@openssl.org>
Message-ID: <573A3116.2080707@gmail.com>

Thanks @mattcaswell for the review.

Can I get another team member to look at pr-1079?


On 5/16/2016 12:04 PM, Matt Caswell via RT wrote:
> Closing this ticket in favour of:
> https://github.com/openssl/openssl/pull/1079
>

From rt at openssl.org  Mon May 16 22:17:57 2016
From: rt at openssl.org (Dmitry Belyavsky via RT)
Date: Mon, 16 May 2016 22:17:57 +0000
Subject: [openssl-dev] [openssl.org #4215] Resolved: Results of
	regression for some apps
In-Reply-To: <CADqLbz+GP=75Qv-3i47CW8Wej-nds3CNecG57roN8+Re8yKp_A@mail.gmail.com>
References: <RT-Ticket-4215@openssl.org>
 <rt-4.0.19-841-1463420009-1272.4215-10-0@openssl.org>
 <CADqLbz+GP=75Qv-3i47CW8Wej-nds3CNecG57roN8+Re8yKp_A@mail.gmail.com>
Message-ID: <rt-4.0.19-840-1463437077-1438.4215-6-0@openssl.org>

Dear Stephen,

There was one more bugreport merged to this ticket regarding the OCSP
(#4216).
Could you take a look at it?

Thank you!

On Mon, May 16, 2016 at 8:33 PM, Stephen Henson via RT <rt at openssl.org>
wrote:

> According to our records, your request has been resolved. If you have any
> further questions or concerns, please respond to this message.
>
> --
> Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4215
> Please log in as guest with password guest if prompted
>
>


-- 
SY, Dmitry Belyavsky

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


From rt at openssl.org  Tue May 17 00:26:09 2016
From: rt at openssl.org (Stephen Henson via RT)
Date: Tue, 17 May 2016 00:26:09 +0000
Subject: [openssl-dev] [openssl.org #4215] Results of regression for some
	apps
In-Reply-To: <rt-4.0.19-840-1463437077-657.4215-6-0@openssl.org>
References: <RT-Ticket-4215@openssl.org>
 <rt-4.0.19-841-1463420009-1272.4215-10-0@openssl.org>
 <CADqLbz+GP=75Qv-3i47CW8Wej-nds3CNecG57roN8+Re8yKp_A@mail.gmail.com>
 <rt-4.0.19-840-1463437077-657.4215-6-0@openssl.org>
Message-ID: <rt-4.0.19-841-1463444769-348.4215-6-0@openssl.org>

On Mon May 16 22:17:57 2016, beldmit at gmail.com wrote:
> Dear Stephen,
>
> There was one more bugreport merged to this ticket regarding the OCSP
> (#4216).
> Could you take a look at it?
>

That should be fixed by commit 6302bbd21a79bd2ed

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=4215
Please log in as guest with password guest if prompted


From R.Falck at comforte.com  Tue May 17 05:23:17 2016
From: R.Falck at comforte.com (Rod Falck)
Date: Tue, 17 May 2016 05:23:17 +0000
Subject: [openssl-dev] Question on private_AES_set_decrypt_key "invert the
 order of the round keys"
Message-ID: <2E4E24F6E6E47843B01089BF753792289E76794F@cf-mail.comforte.local>

Hi,

In the function private_AES_set_decrypt_key, in aes_core.c, it inverts the order of the round keys before applying the MixColumn transform from low to high (excluding low and high, order doesn't really matter as each transformation is dependent only on the item in question). Then AES_decrypt applies the round keys from low to high on the input.

It seems to me that you will get the same result if you do away with the inversion of the round keys, apply the MixColumn transform (excluding low and high) and then AES_decrypt applies the round keys from high to low on the input.

Using this method would therefore save the amount (pretty small) of cpu time used to invert the round keys, with no apparent penalty, assuming looping backwards costs the same as looping forwards.

Is there something functionally wrong with my hypothesis? If not, is there something wrong security-wise, e.g. will the different cpu time cause a vulnerability (it seems that currently one can theoretically tell the difference between an encryption and a decryption based on cpu usage, but I don't know if that is a real problem)?

Rod.
--
Rod Falck. Software Architect. comForte Pty Ltd.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20160517/d72416b6/attachment.html>

From beldmit at gmail.com  Tue May 17 05:46:57 2016
From: beldmit at gmail.com (Dmitry Belyavsky)
Date: Tue, 17 May 2016 08:46:57 +0300
Subject: [openssl-dev] [openssl.org #4215] Results of regression for
	some apps
In-Reply-To: <rt-4.0.19-841-1463444769-348.4215-6-0@openssl.org>
References: <RT-Ticket-4215@openssl.org>
 <rt-4.0.19-841-1463420009-1272.4215-10-0@openssl.org>
 <CADqLbz+GP=75Qv-3i47CW8Wej-nds3CNecG57roN8+Re8yKp_A@mail.gmail.com>
 <rt-4.0.19-840-1463437077-657.4215-6-0@openssl.org>
 <rt-4.0.19-841-1463444769-348.4215-6-0@openssl.org>
Message-ID: <CADqLbzJMa-0+igSw5zHT9nym2NCvCd0J7ZwhTqqUdANhuAT4cA@mail.gmail.com>

Dear Stephen,

On Tue, May 17, 2016 at 3:26 AM, Stephen Henson via RT <rt at openssl.org>
wrote:

> On Mon May 16 22:17:57 2016, beldmit at gmail.com wrote:
> > Dear Stephen,
> >
> > There was one more bugreport merged to this ticket regarding the OCSP
> > (#4216).
> > Could you take a look at it?
> >
>
> That should be fixed by commit 6302bbd21a79bd2ed
>
> 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=4215
> Please log in as guest with password guest if prompted
>
>
Thank you for clarification!



-- 
SY, Dmitry Belyavsky
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20160517/64010324/attachment.html>

From rt at openssl.org  Tue May 17 05:47:09 2016
From: rt at openssl.org (Dmitry Belyavsky via RT)
Date: Tue, 17 May 2016 05:47:09 +0000
Subject: [openssl-dev] [openssl.org #4215] Results of regression for
	some apps
In-Reply-To: <CADqLbzJMa-0+igSw5zHT9nym2NCvCd0J7ZwhTqqUdANhuAT4cA@mail.gmail.com>
References: <RT-Ticket-4215@openssl.org>
 <rt-4.0.19-841-1463420009-1272.4215-10-0@openssl.org>
 <CADqLbz+GP=75Qv-3i47CW8Wej-nds3CNecG57roN8+Re8yKp_A@mail.gmail.com>
 <rt-4.0.19-840-1463437077-657.4215-6-0@openssl.org>
 <rt-4.0.19-841-1463444769-348.4215-6-0@openssl.org>
 <CADqLbzJMa-0+igSw5zHT9nym2NCvCd0J7ZwhTqqUdANhuAT4cA@mail.gmail.com>
Message-ID: <rt-4.0.19-841-1463464029-366.4215-6-0@openssl.org>

Dear Stephen,

On Tue, May 17, 2016 at 3:26 AM, Stephen Henson via RT <rt at openssl.org>
wrote:

> On Mon May 16 22:17:57 2016, beldmit at gmail.com wrote:
> > Dear Stephen,
> >
> > There was one more bugreport merged to this ticket regarding the OCSP
> > (#4216).
> > Could you take a look at it?
> >
>
> That should be fixed by commit 6302bbd21a79bd2ed
>
> 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=4215
> Please log in as guest with password guest if prompted
>
>
Thank you for clarification!



-- 
SY, Dmitry Belyavsky

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


From rt at openssl.org  Tue May 17 15:20:05 2016
From: rt at openssl.org (Richard Levitte via RT)
Date: Tue, 17 May 2016 15:20:05 +0000
Subject: [openssl-dev] [openssl.org #2558] [patch] make windres controllable
	via build env var settings
In-Reply-To: <201107112344.13383.vapier@gentoo.org>
References: <RT-Ticket-2558@openssl.org> <201107112344.13383.vapier@gentoo.org>
Message-ID: <rt-4.0.19-841-1463498405-1460.2558-6-0@openssl.org>

Done, both in master branch and the 1.0.2 branch.

Thank you.

On Wed Jul 13 18:43:19 2011, vapier at gentoo.org wrote:
> atm, the windres code in openssl is only usable via the cross-compile
> prefix
> option unlike all the other build tools. so add support for the
> standard $RC
> / $WINDRES env vars as well.
> -mike


--
Richard Levitte
levitte at openssl.org

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


From rt at openssl.org  Tue May 17 15:20:46 2016
From: rt at openssl.org (Richard Levitte via RT)
Date: Tue, 17 May 2016 15:20:46 +0000
Subject: [openssl-dev] [openssl.org #2616] Missing initialization in the
	CHIL engine
In-Reply-To: <1317071567.6414.294.camel@vespa.frost.loc>
References: <RT-Ticket-2616@openssl.org>
 <1317071567.6414.294.camel@vespa.frost.loc>
Message-ID: <rt-4.0.19-841-1463498446-939.2616-6-0@openssl.org>

Fixed in master and 1.0.2 branches

Thank you

On Tue Sep 27 07:24:41 2011, tmraz at redhat.com wrote:
> There is a missing initialization of a variable in the CHIL engine. In
> case the uninitialized value of the variable answer is 'C' and there is
> no prompt, the engine startup will erroneously fail.
> The attached patch fixes this.


--
Richard Levitte
levitte at openssl.org

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


From rt at openssl.org  Tue May 17 15:21:20 2016
From: rt at openssl.org (Richard Levitte via RT)
Date: Tue, 17 May 2016 15:21:20 +0000
Subject: [openssl-dev] [openssl.org #2534] Hardcoded MIN_LEN prevents using
	VALID passphrase from stdin
In-Reply-To: <4DDF170A.5070302@neurodiverse.org>
References: <RT-Ticket-2534@openssl.org> <4DDF170A.5070302@neurodiverse.org>
Message-ID: <rt-4.0.19-840-1463498480-735.2534-6-0@openssl.org>

Fixed in master and 1.0.2 branches

Thank you

On Fri May 27 07:38:24 2011, saschaefer at neurodiverse.org wrote:
> Affects OpenSSL since at least v 0.9.8g.
> Originally reported as Debian Bug # 533365
> Problem Cause: Hardcoded "MIN_LEN=4" in source file
> crypto/pem/pem_lib.c
>
> One can generate keys with 'too short' passphrase; e.g.
>
> $ openssl genrsa -des3 -passout pass:1 -out mykey.pem 1024
> or, alternatively:
> $ echo 1> psw
> $ openssl genrsa -des3 -passout file:./psw -out mykey.pem 1024
>
> One can then "use" the key, even for operations which require
> passphrasse; e.g.:
> $ openssl rsa -passin pass:1 -in mykey.pem -out outkey.pem
> or
> $ openssl rsa -passin file:./psw -in mykey.pem -out outkey.pem
>
> However, a passphrase shorter with length< 4 cannot be entered from
> stdin:
>
> $ openssl rsa -in mykey.pem -out outkey.pem
> Enter pass phrase for mykey.pem:
> 17325:error:28069065:lib(40):UI_set_result:result too
> small:ui_lib.c:850:You must type in 4 to 8191 characters
>
>
> -- Original Report -------
> I have got an RSA key which is encrypted (Proc-Type: 4,ENCRYPTED)
> using a password of only one character.
> Unfortunately, OpenSSL is not able to remove the Password with the
> standard
>
> openssl rsa -in my.key -out my.key.insecure
>
> Error:
> 29913:error:28069065:lib(40):UI_set_result:result too
> small:ui_lib.c:849:You must type in 4 to 8191 characters
>
> A forced check like this is questionable, and in the case of not
> generating, but just *using* (e.g. decrypting) a password it is
> totally unacceptable.
> OpenSSL renders my private key unusable.
>
> Proposal for fixing this issue: remove password size/quality checks
> for decrypting operations.


--
Richard Levitte
levitte at openssl.org

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


From rt at openssl.org  Tue May 17 16:21:01 2016
From: rt at openssl.org (Tim Culhane via RT)
Date: Tue, 17 May 2016 16:21:01 +0000
Subject: [openssl-dev] [openssl.org #4541] Re: [PATCH] Fix Uninitialized
	Values in OpenSSL 1.0.1o
In-Reply-To: <CO1PR07MB32905B108EC48030EC39B60E0480@CO1PR07MB329.namprd07.prod.outlook.com>
References: <RT-Ticket-4541@openssl.org>
 <CO1PR07MB32905B108EC48030EC39B60E0480@CO1PR07MB329.namprd07.prod.outlook.com>
Message-ID: <rt-4.0.19-840-1463502061-360.4541-21-0@openssl.org>

	Hi Michael,

Apologies for contacting you directly, but I had a query about a patch you submitted to OpenSSL recently.

I recently upgraded the version of OpenSSL we are using in our mail server to 1.0.2g.  I then noticed  valgrind errors like the below, which seem similar to a patch you submitted for 1.0.1o at:


https://mta.openssl.org/pipermail/openssl-bugs-mod/2015-June/000023.html



==00:00:00:29.159 26520==  Uninitialised value was created by a heap allocation
==00:00:00:29.159 26520==    at 0x4A069EE: malloc (vg_replace_malloc.c:270)
==00:00:00:29.159 26520==    by 0x828977: CRYPTO_malloc (in /opt/automation/rg-572/remote/10_128_19_9/razorgate-HEAD/install/mira/opt/criticalpath/global/bin/smtpd)
==00:00:00:29.159 26520==    by 0x85AE76: EVP_DigestInit_ex (in /opt/automation/rg-572/remote/10_128_19_9/razorgate-HEAD/install/mira/opt/criticalpath/global/bin/smtpd)
==00:00:00:29.159 26520==    by 0x83BCB5: HMAC_Init_ex (in /opt/automation/rg-572/remote/10_128_19_9/razorgate-HEAD/install/mira/opt/criticalpath/global/bin/smtpd)
==00:00:00:29.159 26520==    by 0x8BB608: pkey_hmac_ctrl (in /opt/automation/rg-572/remote/10_128_19_9/razorgate-HEAD/install/mira/opt/criticalpath/global/bin/smtpd)
==00:00:00:29.159 26520==    by 0x869119: EVP_PKEY_CTX_ctrl (in /opt/automation/rg-572/remote/10_128_19_9/razorgate-HEAD/install/mira/opt/criticalpath/global/bin/smtpd)
==00:00:00:29.159 26520==    by 0x85AE13: EVP_DigestInit_ex (in /opt/automation/rg-572/remote/10_128_19_9/razorgate-HEAD/install/mira/opt/criticalpath/global/bin/smtpd)
==00:00:00:29.159 26520==    by 0x86A6C5: EVP_DigestSignInit (in /opt/automation/rg-572/remote/10_128_19_9/razorgate-HEAD/install/mira/opt/criticalpath/global/bin/smtpd)
==00:00:00:29.159 26520==    by 0x7F2812: tls1_P_hash.constprop.3 (in /opt/automation/rg-572/remote/10_128_19_9/razorgate-HEAD/install/mira/opt/criticalpath/global/bin/smtpd)
==00:00:00:29.159 26520==    by 0x7F2F20: tls1_PRF.constprop.2 (in /opt/automation/rg-572/remote/10_128_19_9/razorgate-HEAD/install/mira/opt/criticalpath/global/bin/smtpd)
==00:00:00:29.159 26520==    by 0x7F3C52: tls1_setup_key_block (in /opt/automation/rg-572/remote/10_128_19_9/razorgate-HEAD/install/mira/opt/criticalpath/global/bin/smtpd)
==00:00:00:29.159 26520==    by 0x819D4F: ssl3_do_change_cipher_spec (in /opt/automation/rg-572/remote/10_128_19_9/razorgate-HEAD/install/mira/opt/criticalpath/global/bin/smtpd)
==00:00:00:29.159 26520==    by 0x81AAF2: ssl3_read_bytes (in /opt/automation/rg-572/remote/10_128_19_9/razorgate-HEAD/install/mira/opt/criticalpath/global/bin/smtpd)
==00:00:00:29.159 26520==    by 0x81BE7C: ssl3_get_message (in /opt/automation/rg-572/remote/10_128_19_9/razorgate-HEAD/install/mira/opt/criticalpath/global/bin/smtpd)
==00:00:00:29.159 26520==    by 0x81B99F: ssl3_get_finished (in /opt/automation/rg-572/remote/10_128_19_9/razorgate-HEAD/install/mira/opt/criticalpath/global/bin/smtpd)
==00:00:00:29.159 26520==    by 0x80DF18: ssl3_accept (in /opt/automation/rg-572/remote/10_128_19_9/razorgate-HEAD/install/mira/opt/criticalpath/global/bin/smtpd)
==00:00:00:29.159 26520==    by 0x7EB3D3: ssl23_accept (in /opt/automation/rg-572/remote/10_128_19_9/razorgate-HEAD/install/mira/opt/criticalpath/global/bin/smtpd)
==00:00:00:29.159 26520==    by 0x783209: tls_negotiation (ssl_openssl.c:1878)
==00:00:00:29.159 26520==    by 0x5D889C: process_starttls_command (receiver.c:2086)
==00:00:00:29.159 26520==    by 0x5D7B12: run_smtp_server (receiver.c:1765)
==00:00:00:29.159 26520==    by 0x5D32B1: smtp_recv_thread (receiver.c:318)

I looked at the relevant files  in the 1.0.2g version of OpenSSL, but didn't see the new calls to memset() added.

Would you happen to know the status of this patch?

Do you expect it to be added to the master version of OpenSSL any time soon?

Many thanks,

Tim

---------------

Tim Culhane
Senior Software Engineer

Synchronoss Technologies Inc.
First Floor, Simmonscourt House
Simmonscourt Road
Ballsbridge
Dublin 4

Phone: +353 1 241 5107
www.synchronoss.com




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


From raji.kotamraju at gmail.com  Tue May 17 16:43:57 2016
From: raji.kotamraju at gmail.com (Rajeswari K)
Date: Tue, 17 May 2016 22:13:57 +0530
Subject: [openssl-dev] DTLS session resumption with DTLS_ANY_VERSION
In-Reply-To: <CA+mfXPHnjWD=8qcpJ4u7S8if0dFmURwgDo7-iZ7ee_t7b5aKsA@mail.gmail.com>
References: <CA+mfXPFV6BaM4bTYf8oM7kHJhH3N2WRrKo0py-rbYsJEm2GJnw@mail.gmail.com>
 <5732FADC.6010804@openssl.org>
 <CA+mfXPF4_QbskeeRj54h9pTnAQwr5yDGLOzn8r2xYmbZqSvA8A@mail.gmail.com>
 <573612E6.8060608@openssl.org>
 <CA+mfXPHnjWD=8qcpJ4u7S8if0dFmURwgDo7-iZ7ee_t7b5aKsA@mail.gmail.com>
Message-ID: <CA+mfXPHA4yDdaH41U0bouUcLzrwrWT78VbhN7h1NLa4+pDbNCg@mail.gmail.com>

Hi Matt,

Can you share s3_srvr.c file which is based on 1.1.0 release where DTLS
session resumption works? I tried downloading 1.1.0-pre5 but i didnt see
any file related with s3_srvr.c.

Thanks,
Rajeswari.

On Mon, May 16, 2016 at 11:20 AM, Rajeswari K <raji.kotamraju at gmail.com>
wrote:

> Hi Matt,
>
> Yes, i tested with your patch. Honestly, before writing to openssl-dev
> team, i tried session resumption with moving the version just like what you
> gave as patch. But, still session resumption didn't work for me. Am
> debugging same at openssl front.
>
> Just to confirm on the issue, i tried hardcoding s->version and s->method
> with DTLSv1 just after calling SSL_new() followed by SSL_clear(). Then
> Session resumption worked as expected.
>
> So, updation of s->version during handshake and updation of
> s->session->version has some relation which am trying to find out.
>
> I was looking at updation of s->session->version during handshake when the
> version is DTLS_ANY_VERSION. Will check and update you on my findings if
> any.
>
> Thanks,
> Rajeswari.
>
>
> On Fri, May 13, 2016 at 11:16 PM, Matt Caswell <matt at openssl.org> wrote:
>
>>
>>
>> On 13/05/16 18:33, Rajeswari K wrote:
>> > Hi Matt,
>> >
>> > Thanks for the response.
>> >
>> > But, this fix doesn't perform session resumption.
>>
>> Did you try the patch?
>>
>> As you pointed out we hit the following line:
>>
>>         if (i == 1 && s->version == s->session->ssl_version) { /* previous
>>                                                                 * session
>> */
>>
>> The version from the SSL object and the version from the session do not
>> match and that is why session resumption does not take place.
>>
>> The reason that the versions do not match is because version negotiation
>> takes place *after* this check. So at this point s->version equals
>> DTLS_ANY_VERSION. My patch moves the version negotiation to before the
>> above test so that s->version should now be equal to DTLSv1, and
>> therefore should be the same as in s->session->ssl_version, and session
>> resumption should be successful.
>>
>> Matt
>>
>>
>>
>> >
>> > Thanks,
>> > Rajeswari.
>> >
>> > On Wed, May 11, 2016 at 2:56 PM, Matt Caswell <matt at openssl.org
>> > <mailto:matt at openssl.org>> wrote:
>> >
>> >
>> >
>> >     On 10/05/16 18:34, Rajeswari K wrote:
>> >     > Hello openssl-dev team,
>> >     >
>> >     > Having query regarding DTLS session resumption when configured
>> SSL_CTX
>> >     > with DTLS_ANY_VERSION.
>> >     >
>> >     > When we select SSL_CTX with DTLS_ANY_VERSION, method will be of
>> >     > DTLS_Server_method(), which will have ssl_ctx->version as 0xFEFD
>> to
>> >     > support both the versions (i.e. DTLS1.0 and DTLS1.2).
>> >     >
>> >     > During handshake, we landed on to version DTLS1.0.i.e.
>> >     > s->session->version holds 0xFEFF.
>> >     >
>> >     > In order to perform session resumption, we derived new SSL
>> structure
>> >     > from global ssl_ctx using SSL_new() and tried performing ssl
>> >     handshake.
>> >     >
>> >     > With the below logic,
>> >     > else {
>> >     >         i = ssl_get_prev_session(s, p, j, d + n);
>> >     >         /*
>> >     >          * Only resume if the session's version matches the
>> negotiated
>> >     >          * version.
>> >     >          * RFC 5246 does not provide much useful advice on
>> resumption
>> >     >          * with a different protocol version. It doesn't forbid
>> it but
>> >     >          * the sanity of such behaviour would be questionable.
>> >     >          * In practice, clients do not accept a version mismatch
>> and
>> >     >          * will abort the handshake with an error.
>> >     >          */
>> >     >         if (i == 1 && s->version == s->session->ssl_version) { /*
>> >     previous
>> >     >                                                                 *
>> >     session */
>> >     >             s->hit = 1;
>> >     >         } else if (i == -1)
>> >     >             goto err;
>> >     >         else {                  /* i == 0 */
>> >     >
>> >     >             if (!ssl_get_new_session(s, 1))
>> >     >                 goto err;
>> >     >         }
>> >     >
>> >     > Since s->version is with 0xFEFD and s->session->ssl_version is
>> 0xFEFF,
>> >     > we always try for new session and wont land on to session
>> resumption
>> >     > though client has sent the  session_id.
>> >     >
>> >     > Is this intended behaviour? Please clarify.
>> >
>> >
>> >     No. This appears to be a bug introduced by commit 03d14f588734 in
>> >     November 2014.
>> >
>> >     The real problem though is that the DTLS version negotiation is
>> >     happening too late - after session resumption. Interestingly this
>> only
>> >     seems to be a problem in 1.0.2. In 1.1.0 this is working correctly
>> (the
>> >     version negotiation logic has been substantially rewritten in the
>> new
>> >     version).
>> >
>> >     Please could you try out the attached patch? Let me know how you
>> get on.
>> >
>> >     Thanks
>> >
>> >     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
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20160517/8809f7e4/attachment.html>

From matt at openssl.org  Tue May 17 16:57:24 2016
From: matt at openssl.org (Matt Caswell)
Date: Tue, 17 May 2016 17:57:24 +0100
Subject: [openssl-dev] DTLS session resumption with DTLS_ANY_VERSION
In-Reply-To: <CA+mfXPHA4yDdaH41U0bouUcLzrwrWT78VbhN7h1NLa4+pDbNCg@mail.gmail.com>
References: <CA+mfXPFV6BaM4bTYf8oM7kHJhH3N2WRrKo0py-rbYsJEm2GJnw@mail.gmail.com>
 <5732FADC.6010804@openssl.org>
 <CA+mfXPF4_QbskeeRj54h9pTnAQwr5yDGLOzn8r2xYmbZqSvA8A@mail.gmail.com>
 <573612E6.8060608@openssl.org>
 <CA+mfXPHnjWD=8qcpJ4u7S8if0dFmURwgDo7-iZ7ee_t7b5aKsA@mail.gmail.com>
 <CA+mfXPHA4yDdaH41U0bouUcLzrwrWT78VbhN7h1NLa4+pDbNCg@mail.gmail.com>
Message-ID: <573B4D74.5040400@openssl.org>



On 17/05/16 17:43, Rajeswari K wrote:
> Hi Matt,
> 
> Can you share s3_srvr.c file which is based on 1.1.0 release where DTLS
> session resumption works? I tried downloading 1.1.0-pre5 but i didnt see
> any file related with s3_srvr.c. 

See the tls_process_client_hello() function in ssl/statem/statem_srvr.c,
around line 1240.

Matt


> 
> Thanks,
> Rajeswari.
> 
> On Mon, May 16, 2016 at 11:20 AM, Rajeswari K <raji.kotamraju at gmail.com
> <mailto:raji.kotamraju at gmail.com>> wrote:
> 
>     Hi Matt,
> 
>     Yes, i tested with your patch. Honestly, before writing to
>     openssl-dev team, i tried session resumption with moving the version
>     just like what you gave as patch. But, still session resumption
>     didn't work for me. Am debugging same at openssl front. 
> 
>     Just to confirm on the issue, i tried hardcoding s->version and
>     s->method with DTLSv1 just after calling SSL_new() followed by
>     SSL_clear(). Then Session resumption worked as expected. 
> 
>     So, updation of s->version during handshake and updation of
>     s->session->version has some relation which am trying to find out. 
> 
>     I was looking at updation of s->session->version during handshake
>     when the version is DTLS_ANY_VERSION. Will check and update you on
>     my findings if any. 
> 
>     Thanks,
>     Rajeswari.
> 
> 
>     On Fri, May 13, 2016 at 11:16 PM, Matt Caswell <matt at openssl.org
>     <mailto:matt at openssl.org>> wrote:
> 
> 
> 
>         On 13/05/16 18:33, Rajeswari K wrote:
>         > Hi Matt,
>         >
>         > Thanks for the response.
>         >
>         > But, this fix doesn't perform session resumption.
> 
>         Did you try the patch?
> 
>         As you pointed out we hit the following line:
> 
>                 if (i == 1 && s->version == s->session->ssl_version) {
>         /* previous
>                                                                        
>         * session */
> 
>         The version from the SSL object and the version from the session
>         do not
>         match and that is why session resumption does not take place.
> 
>         The reason that the versions do not match is because version
>         negotiation
>         takes place *after* this check. So at this point s->version equals
>         DTLS_ANY_VERSION. My patch moves the version negotiation to
>         before the
>         above test so that s->version should now be equal to DTLSv1, and
>         therefore should be the same as in s->session->ssl_version, and
>         session
>         resumption should be successful.
> 
>         Matt
> 
> 
> 
>         >
>         > Thanks,
>         > Rajeswari.
>         >
>         > On Wed, May 11, 2016 at 2:56 PM, Matt Caswell <matt at openssl.org <mailto:matt at openssl.org>
>         > <mailto:matt at openssl.org <mailto:matt at openssl.org>>> wrote:
>         >
>         >
>         >
>         >     On 10/05/16 18:34, Rajeswari K wrote:
>         >     > Hello openssl-dev team,
>         >     >
>         >     > Having query regarding DTLS session resumption when
>         configured SSL_CTX
>         >     > with DTLS_ANY_VERSION.
>         >     >
>         >     > When we select SSL_CTX with DTLS_ANY_VERSION, method
>         will be of
>         >     > DTLS_Server_method(), which will have ssl_ctx->version
>         as 0xFEFD to
>         >     > support both the versions (i.e. DTLS1.0 and DTLS1.2).
>         >     >
>         >     > During handshake, we landed on to version DTLS1.0.i.e.
>         >     > s->session->version holds 0xFEFF.
>         >     >
>         >     > In order to perform session resumption, we derived new
>         SSL structure
>         >     > from global ssl_ctx using SSL_new() and tried performing ssl
>         >     handshake.
>         >     >
>         >     > With the below logic,
>         >     > else {
>         >     >         i = ssl_get_prev_session(s, p, j, d + n);
>         >     >         /*
>         >     >          * Only resume if the session's version matches
>         the negotiated
>         >     >          * version.
>         >     >          * RFC 5246 does not provide much useful advice
>         on resumption
>         >     >          * with a different protocol version. It doesn't
>         forbid it but
>         >     >          * the sanity of such behaviour would be
>         questionable.
>         >     >          * In practice, clients do not accept a version
>         mismatch and
>         >     >          * will abort the handshake with an error.
>         >     >          */
>         >     >         if (i == 1 && s->version ==
>         s->session->ssl_version) { /*
>         >     previous
>         >     >                                                         
>                *
>         >     session */
>         >     >             s->hit = 1;
>         >     >         } else if (i == -1)
>         >     >             goto err;
>         >     >         else {                  /* i == 0 */
>         >     >
>         >     >             if (!ssl_get_new_session(s, 1))
>         >     >                 goto err;
>         >     >         }
>         >     >
>         >     > Since s->version is with 0xFEFD and
>         s->session->ssl_version is 0xFEFF,
>         >     > we always try for new session and wont land on to
>         session resumption
>         >     > though client has sent the  session_id.
>         >     >
>         >     > Is this intended behaviour? Please clarify.
>         >
>         >
>         >     No. This appears to be a bug introduced by commit
>         03d14f588734 in
>         >     November 2014.
>         >
>         >     The real problem though is that the DTLS version
>         negotiation is
>         >     happening too late - after session resumption.
>         Interestingly this only
>         >     seems to be a problem in 1.0.2. In 1.1.0 this is working
>         correctly (the
>         >     version negotiation logic has been substantially rewritten
>         in the new
>         >     version).
>         >
>         >     Please could you try out the attached patch? Let me know
>         how you get on.
>         >
>         >     Thanks
>         >
>         >     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
> 
> 
> 
> 
> 

From cyriacjoseph at gmail.com  Wed May 18 05:30:15 2016
From: cyriacjoseph at gmail.com (cyriac)
Date: Tue, 17 May 2016 22:30:15 -0700 (MST)
Subject: [openssl-dev] OpenSSL support of SHA 512/256 and SHA 512/224?
Message-ID: <1463549415108-66190.post@n7.nabble.com>

I would like to know if OpenSSL  and FIPS new versions (like OpenSSL 1.0.2g,
FIPS 2.0.12 etc.) support the *truncated versions of SHA 512 namely SHA
512/224 or SHA 512/256*. (Acknowledging that OpenSSL does support SHA 512)

I do not know the technical difference between SHA 512 and SHA 512/256
(except a vague conceptual overview that the initialisation vector would be
different for the truncated SHA 512/256 as compared to SHA 512 and that the
real hash length will be only 256 for SHA 512/256).

Or.... could it be assumed that an SHA 512 implementation has innate support
for the truncated version like SHA 512/256 ? And so, it does hold good for
OpenSSL too?

Thanks, 
Cyriac



--
View this message in context: http://openssl.6102.n7.nabble.com/OpenSSL-support-of-SHA-512-256-and-SHA-512-224-tp66190.html
Sent from the OpenSSL - Dev mailing list archive at Nabble.com.

From rt at openssl.org  Wed May 18 09:08:14 2016
From: rt at openssl.org (Matt Caswell via RT)
Date: Wed, 18 May 2016 09:08:14 +0000
Subject: [openssl-dev] [openssl.org #2363] bug: memory allocated by DH_new()
	may never be free()ed
In-Reply-To: <Pine.SOC.4.64.1010211654380.16441@rejewski>
References: <RT-Ticket-2363@openssl.org>
 <Pine.SOC.4.64.1010211654380.16441@rejewski>
Message-ID: <rt-4.0.19-841-1463562494-1661.2363-6-0@openssl.org>

This appears to be a usage problem where the library is not being de-inited
properly. This should be resolved anyway in 1.1.0 with auto-deinit.

Closing ticket.

Matt

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


From matt.hart at hotmail.co.uk  Wed May 18 08:46:16 2016
From: matt.hart at hotmail.co.uk (Matt Hart)
Date: Wed, 18 May 2016 01:46:16 -0700 (MST)
Subject: [openssl-dev] CNG support for OpenSSL CAPI Engine
Message-ID: <1463561176095-66193.post@n7.nabble.com>

Hi, 

We have successfully been using the CAPI engine to provide OpenSSL client
cert authentication in environments where Windows Cryptographic Service
Providers (CSP) are used for private key storage. 

But we also have a few environments that have migrated from CSP to a Windows
Key Storage Provider and CNG based encryption algorithms. 

Looking at top-of-tree for OpenSSL, I see there's currently only code for
Windows CryptAcquireContext() and hence CSPs, not for the CNG APIs
(NCryptOpenStorageProvider, BCryptOpenAlgorithmProvider et al). 

Are there plans or work in progress, for the OpenSSL CAPI engine to support
environments where CNG is in use? 

thanks 

Matt



--
View this message in context: http://openssl.6102.n7.nabble.com/CNG-support-for-OpenSSL-CAPI-Engine-tp66193.html
Sent from the OpenSSL - Dev mailing list archive at Nabble.com.

From rt at openssl.org  Wed May 18 10:22:40 2016
From: rt at openssl.org (Matt Caswell via RT)
Date: Wed, 18 May 2016 10:22:40 +0000
Subject: [openssl-dev] [openssl.org #1919] Bug in buffer_ctrl in
	BIO_f_buffer?
In-Reply-To: <295291241593189@webmail51.yandex.ru>
References: <RT-Ticket-1919@openssl.org> <295291241593189@webmail51.yandex.ru>
Message-ID: <rt-4.0.19-840-1463566960-468.1919-6-0@openssl.org>

This seems to have been fixed at some point. Closing.

Matt

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


From rt at openssl.org  Wed May 18 10:31:55 2016
From: rt at openssl.org (Matt Caswell via RT)
Date: Wed, 18 May 2016 10:31:55 +0000
Subject: [openssl-dev] [openssl.org #1518] [PATCH] Securing private RSA keys
In-Reply-To: <12b5f1ef0704091005m39ea980cn9373e48426715dca@mail.gmail.com>
References: <RT-Ticket-1518@openssl.org>
 <12b5f1ef0703222340w5c0a49a9m2ad4ac4338e4e61d@mail.gmail.com>
 <12b5f1ef0704091005m39ea980cn9373e48426715dca@mail.gmail.com>
Message-ID: <rt-4.0.19-841-1463567515-1250.1518-6-0@openssl.org>

After 9 years looks like there is no support for this patch (and it will not
apply now anyway). I'd suggest if anyone does support this then a new patch be
submitted via GitHub.

Closing this ticket.

Matt

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


From rt at openssl.org  Wed May 18 10:45:44 2016
From: rt at openssl.org (Matt Caswell via RT)
Date: Wed, 18 May 2016 10:45:44 +0000
Subject: [openssl-dev] [openssl.org #2037] GENERAL_NAME IPv6 parsing bug....
In-Reply-To: <c31a56900909081520k3790a374m79311f35acccb51d@mail.gmail.com>
References: <RT-Ticket-2037@openssl.org>
 <c31a56900909081520k3790a374m79311f35acccb51d@mail.gmail.com>
Message-ID: <rt-4.0.19-840-1463568344-133.2037-6-0@openssl.org>

I can't reproduce this, and it looks like Steve couldn't either at the time.

Closing.

Matt

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


From rt at openssl.org  Wed May 18 10:47:39 2016
From: rt at openssl.org (Matt Caswell via RT)
Date: Wed, 18 May 2016 10:47:39 +0000
Subject: [openssl-dev] [openssl.org #2146] [Fwd: Re: unexpected message
	during renegotiate attempt]
In-Reply-To: <1263918874.3832.9.camel@localhost.localdomain>
References: <RT-Ticket-2146@openssl.org>
 <1263918874.3832.9.camel@localhost.localdomain>
Message-ID: <rt-4.0.19-840-1463568459-146.2146-6-0@openssl.org>

This issue has been discussed a number of times, but will not be fixed at this
time.

Closing

Matt

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


From rt at openssl.org  Wed May 18 10:50:57 2016
From: rt at openssl.org (Matt Caswell via RT)
Date: Wed, 18 May 2016 10:50:57 +0000
Subject: [openssl-dev] [openssl.org #2291] [PATCH 3/3] engine/padlock:
	implement sha1/sha224/sha256 acceleration
In-Reply-To: <1276077246-17849-3-git-send-email-timo.teras@iki.fi>
References: <RT-Ticket-2291@openssl.org>
 <1276077246-17849-1-git-send-email-timo.teras@iki.fi>
 <1276077246-17849-3-git-send-email-timo.teras@iki.fi>
Message-ID: <rt-4.0.19-841-1463568657-729.2291-6-0@openssl.org>

Looks like padlock has this. Closing

Matt

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


From rt at openssl.org  Wed May 18 12:05:07 2016
From: rt at openssl.org (Matt Caswell via RT)
Date: Wed, 18 May 2016 12:05:07 +0000
Subject: [openssl-dev] [openssl.org #4179] fix a bug in
	ssl_next_proto_validate (ssl/t1_lib.c) [GitHub PR #506]
In-Reply-To: <566C473C.2050304@rhe.jp>
References: <RT-Ticket-4179@openssl.org> <566C473C.2050304@rhe.jp>
Message-ID: <rt-4.0.19-841-1463573107-791.4179-6-0@openssl.org>

The associated github PR was merged so closing this ticket.

Matt

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


From rt at openssl.org  Wed May 18 12:11:12 2016
From: rt at openssl.org (Matt Caswell via RT)
Date: Wed, 18 May 2016 12:11:12 +0000
Subject: [openssl-dev] [openssl.org #4352] Failed test 'Duplicate
	ClientHello extension' when testing under Clang undefined
	behavior sanitizer
In-Reply-To: <CAH8yC8nVvMhDkc27KatPEC8e2O1PhbXPGRWDY4U51hW-9gPM3w@mail.gmail.com>
References: <RT-Ticket-4352@openssl.org>
 <CAH8yC8nVvMhDkc27KatPEC8e2O1PhbXPGRWDY4U51hW-9gPM3w@mail.gmail.com>
Message-ID: <rt-4.0.19-841-1463573472-1090.4352-6-0@openssl.org>

I can't reproduce this on latest master, so I am assuming it has been fixed.

Closing ticket.

Matt

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


From rt at openssl.org  Wed May 18 12:26:42 2016
From: rt at openssl.org (Rich Salz via RT)
Date: Wed, 18 May 2016 12:26:42 +0000
Subject: [openssl-dev] [openssl.org #1518] [PATCH] Securing private RSA keys
In-Reply-To: <12b5f1ef0704091005m39ea980cn9373e48426715dca@mail.gmail.com>
References: <RT-Ticket-1518@openssl.org>
 <12b5f1ef0703222340w5c0a49a9m2ad4ac4338e4e61d@mail.gmail.com>
 <12b5f1ef0704091005m39ea980cn9373e48426715dca@mail.gmail.com>
Message-ID: <rt-4.0.19-840-1463574402-1701.1518-6-0@openssl.org>

keeping open, for non-technical reasons.

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


From rt at openssl.org  Wed May 18 13:20:03 2016
From: rt at openssl.org (Stephen Henson via RT)
Date: Wed, 18 May 2016 13:20:03 +0000
Subject: [openssl-dev] [openssl.org #1797] re: unable to verify timestamps
	sgined with a certificate that is now expired
In-Reply-To: <79766o$ckti8o@outbound.icp-qv1-irony-out1.iinet.net.au>
References: <RT-Ticket-1797@openssl.org>
 <79766o$ckti8o@outbound.icp-qv1-irony-out1.iinet.net.au>
Message-ID: <rt-4.0.19-841-1463577603-1495.1797-6-0@openssl.org>

The master version of the ts utility now supports the full set of verification
options including the -attime option which can set the verification time.

Ticket resolved.

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=1797
Please log in as guest with password guest if prompted


From rt at openssl.org  Wed May 18 14:58:12 2016
From: rt at openssl.org (amit.chaudhuri@bt.com via RT)
Date: Wed, 18 May 2016 14:58:12 +0000
Subject: [openssl-dev] [openssl.org #4542] bug: smime-certs shipped with
	openssl-1.0.1t/tests have expired leading to test failures in
	cms_test
In-Reply-To: <1463580123318.59191@bt.com>
References: <RT-Ticket-4542@openssl.org> <1463580123318.59191@bt.com>
Message-ID: <rt-4.0.19-840-1463583492-1736.4542-21-0@openssl.org>

Hi,


when running "make test_cms" on linux x86_64 I get test failures early in the process:


The contents of cms.err conclude with the phrase: "Verify error: certificate has expired".


Checking smroot.pem with openssl x509 -in smroot.pem -dates I get:


notBefore=Feb 22 .... 2008 GMT

notAtfer=May 10 ...2016 GMT


I get a similar result for all the .pems in that dir.


If I cross check the certificate file smroot.pem with the versions shipped with 1.0.1p (using sha1sum) I get the same checksum.  Looks like a simple case of the test data expiring shortly after the release date.


I've not looked at how the tests work so am unclear whether I can simply generate certificates with valid dates and substitute them in to get a valid test pass.


Regards,


Amit

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


From uri at ll.mit.edu  Wed May 18 15:35:53 2016
From: uri at ll.mit.edu (Blumenthal, Uri - 0553 - MITLL)
Date: Wed, 18 May 2016 15:35:53 +0000
Subject: [openssl-dev] [openssl.org #1518] [PATCH] Securing private RSA
 keys
In-Reply-To: <rt-4.0.19-841-1463567515-1250.1518-6-0@openssl.org>
References: <RT-Ticket-1518@openssl.org>
 <12b5f1ef0703222340w5c0a49a9m2ad4ac4338e4e61d@mail.gmail.com>
 <12b5f1ef0704091005m39ea980cn9373e48426715dca@mail.gmail.com>
 <rt-4.0.19-841-1463567515-1250.1518-6-0@openssl.org>
Message-ID: <D36203B1.2C200%uri@ll.mit.edu>

I think the goal of this ticket can be better addressed by using a
hardware token (that cost ballpark $40 retail) and libp11 (aka pkcs11
engine). Similar results with much better security.
-- 
Regards,
Uri Blumenthal





On 5/18/16, 6:31 , "openssl-dev on behalf of Matt Caswell via RT"
<openssl-dev-bounces at openssl.org on behalf of rt at openssl.org> wrote:

>After 9 years looks like there is no support for this patch (and it will
>not
>apply now anyway). I'd suggest if anyone does support this then a new
>patch be
>submitted via GitHub.
>
>Closing this ticket.
>
>Matt
>
>-- 
>Ticket here: http://rt.openssl.org/Ticket/Display.html?id=1518
>Please log in as guest with password guest if prompted
>
>-- 
>openssl-dev mailing list
>To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4324 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20160518/fc86ec99/attachment.bin>

From rt at openssl.org  Wed May 18 15:46:38 2016
From: rt at openssl.org (Rich Salz via RT)
Date: Wed, 18 May 2016 15:46:38 +0000
Subject: [openssl-dev] [openssl.org #4542] bug: smime-certs shipped with
	openssl-1.0.1t/tests have expired leading to test failures in
	cms_test
In-Reply-To: <1463580123318.59191@bt.com>
References: <RT-Ticket-4542@openssl.org> <1463580123318.59191@bt.com>
Message-ID: <rt-4.0.19-841-1463586398-809.4542-6-0@openssl.org>

pull the latest version from the snapshot. fixed in next release by shipping
new certs.

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


From rt at openssl.org  Wed May 18 16:40:20 2016
From: rt at openssl.org (Richard Levitte via RT)
Date: Wed, 18 May 2016 16:40:20 +0000
Subject: [openssl-dev] [openssl.org #1466] X.509 name's printing
In-Reply-To: <rt-3.4.5-93805-1173742290-573.1466-6-0@openssl.org>
References: <RT-Ticket-1466@openssl.org>
 <rt-1466-7512.0.364011588276583@openssl.org>
 <45F5DD32.2040107@roumenpetrov.info>
 <rt-3.4.5-93805-1173742290-573.1466-6-0@openssl.org>
Message-ID: <rt-4.0.19-840-1463589620-805.1466-6-0@openssl.org>

This has now been added to the master and 1.0.2 branches.

Thank you.

Closing ticket

On Mon Mar 12 23:31:30 2007, openssl at roumenpetrov.info wrote:
> RFC 2254 : The String Representation of LDAP Search Filters
>
> This patch add support for rfc2254 escaping.
>
> With patched source method
> ASN1_STRING_print_ex(BIO *out, ASN1_STRING *str, unsigned long flags);
> , where flags are
> XN_FLAG_RFC2253|ASN1_STRFLGS_ESC_2254
> can be used in generation of "LDAP search filter".
>
> Roumen
>


--
Richard Levitte
levitte at openssl.org

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


From rt at openssl.org  Wed May 18 19:17:10 2016
From: rt at openssl.org (Richard Levitte via RT)
Date: Wed, 18 May 2016 19:17:10 +0000
Subject: [openssl-dev] [openssl.org #1520] request for checking if -in and
	-out files are same
In-Reply-To: <rt-4.0.19-31751-1434262187-1290.1520-6-0@openssl.org>
References: <RT-Ticket-1520@openssl.org> <46271FE7.4050201@gmail.com>
 <rt-4.0.19-31900-1434250505-1190.1520-6-0@openssl.org>
 <557D1A98.9000001@gmail.com>
 <rt-4.0.19-31751-1434262187-1290.1520-6-0@openssl.org>
Message-ID: <rt-4.0.19-840-1463599029-435.1520-6-0@openssl.org>

Considering we've now solved all the binary vs non-binary issues and know how
to do that at open(2) level where it's relevant, adding O_EXCL shouldn't be
much of a problem any more. This should, however, not be done on file systems
that support file generations (VMS, and...?)

Cheers,
Richard

On Sun Jun 14 06:09:47 2015, aaronmdjones at gmail.com wrote:
> On 14/06/15 02:55, Rich Salz via RT wrote:
> > One possiblity is open in exclusive mode. The problem is that O_EXCL
> > is only
> > part of open(2), not fopen(3). And we have to use fopen() because we
> > need the
> > "b" mode for binary output on platforms that require it. So I don't
> > think that
> > will work, either.
>
> Do those platforms not have fdopen(3) with the same "b" semantics?
>
> I note fdopen(3) is a POSIX thing, and "b" has no effect on POSIX
> systems, so perhaps not. Worth a look though?
>
> Failing that, you could fstat(3) the 2 open files and compare their
> st_ino and st_dev fields for equality before writing anything to
> either
> of them.


--
Richard Levitte
levitte at openssl.org

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


From msteve at columbus.rr.com  Thu May 19 03:25:12 2016
From: msteve at columbus.rr.com (Michael Steve)
Date: Wed, 18 May 2016 23:25:12 -0400
Subject: [openssl-dev] 1.1.0 Build requirement for OpenVMS
Message-ID: <17A8F299EFD84F899C35E7D0DF885A3A@Unimatrix1>

I want to better understand the rationale behind requiring MMS and Perl for the 1.1.0 builds by the VMS community. If multiple ?someones? from this community can explain this to me, it would be most appreciated.

Michael Steve
Software Developer
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20160518/fe0579f8/attachment.html>

From levitte at openssl.org  Thu May 19 04:04:53 2016
From: levitte at openssl.org (Richard Levitte)
Date: Thu, 19 May 2016 06:04:53 +0200 (CEST)
Subject: [openssl-dev] 1.1.0 Build requirement for OpenVMS
In-Reply-To: <17A8F299EFD84F899C35E7D0DF885A3A@Unimatrix1>
References: <17A8F299EFD84F899C35E7D0DF885A3A@Unimatrix1>
Message-ID: <20160519.060453.244847054992092850.levitte@openssl.org>

In message <17A8F299EFD84F899C35E7D0DF885A3A at Unimatrix1> on Wed, 18 May 2016 23:25:12 -0400, "Michael Steve" <msteve at columbus.rr.com> said:

msteve> I want to better understand the rationale behind requiring MMS and
msteve> Perl for the 1.1.0 builds by the VMS community. If multiple ?someones?
msteve> from this community can explain this to me, it would be most
msteve> appreciated.

Sure.  The rationale is first of all to have a common build database
and set of scripts (as much as possible) for all platforms we support.
In previous OpenSSL version, we have one set of scripts and a Makefile
for Unix, one set of scripts and completely different makefile for
Windows, and a sub-functional set of DCL scripts for VMS (1).  This
was a mess to maintain.

Perl was chosen as a script language because it's one of the, not to
say *the*, most well supported interpreters on all our target
platforms (including VMS).

MMS was chosen because it is a well supported make implementation on
VMS.  However, if MMS isn't accessible for you, MMK is a free fully
functional replacement.

Cheers,
Richard

(1) and for the VMS case, it felt like the DCL scripts were constantly
    lagging behind, and with all the changes happening in the 1.1.0
    development, it became too much of a burden.  For a while there, I
    was seriously considering giving up VMS support entirely.

-- 
Richard Levitte         levitte at openssl.org
OpenSSL Project         http://www.openssl.org/~levitte/

From cyriacjoseph at gmail.com  Thu May 19 06:45:19 2016
From: cyriacjoseph at gmail.com (cyriac)
Date: Wed, 18 May 2016 23:45:19 -0700 (MST)
Subject: [openssl-dev] OpenSSL support of SHA 512/256 and SHA 512/224?
In-Reply-To: <1463549415108-66190.post@n7.nabble.com>
References: <1463549415108-66190.post@n7.nabble.com>
Message-ID: <1463640319892-66223.post@n7.nabble.com>

I could not find a concrete answer about this in the archives.
Kindly excuse if it was a repeat question... 
-Cyriac



--
View this message in context: http://openssl.6102.n7.nabble.com/OpenSSL-support-of-SHA-512-256-and-SHA-512-224-tp66190p66223.html
Sent from the OpenSSL - Dev mailing list archive at Nabble.com.

From rt at openssl.org  Thu May 19 10:07:46 2016
From: rt at openssl.org (Matt Caswell via RT)
Date: Thu, 19 May 2016 10:07:46 +0000
Subject: [openssl-dev] [openssl.org #1979] Add uClibc support
In-Reply-To: <4A4D15C2.9020404@redfish-solutions.com>
References: <RT-Ticket-1979@openssl.org>
 <4A4D15C2.9020404@redfish-solutions.com>
Message-ID: <rt-4.0.19-1993-1463652466-1985.1979-6-0@openssl.org>

Reclosing this.

Matt

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


From doctor at doctor.nl2k.ab.ca  Thu May 19 10:24:05 2016
From: doctor at doctor.nl2k.ab.ca (The Doctor)
Date: Thu, 19 May 2016 04:24:05 -0600
Subject: [openssl-dev] NO 20160519 SNAPSHOTS
Message-ID: <20160519102404.GA1809@doctor.nl2k.ab.ca>

What happened?
-- 
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
Abuse a man unjustly, and you will make friends for him.  -Edgar Watson Howe

From rsalz at akamai.com  Thu May 19 12:24:20 2016
From: rsalz at akamai.com (Salz, Rich)
Date: Thu, 19 May 2016 12:24:20 +0000
Subject: [openssl-dev] OpenSSL support of SHA 512/256 and SHA 512/224?
In-Reply-To: <1463640319892-66223.post@n7.nabble.com>
References: <1463549415108-66190.post@n7.nabble.com>
 <1463640319892-66223.post@n7.nabble.com>
Message-ID: <ab1448829b5c4f798527433167511eaf@usma1ex-dag1mb1.msg.corp.akamai.com>

Not currently supported.

From levitte at openssl.org  Thu May 19 12:50:13 2016
From: levitte at openssl.org (Richard Levitte)
Date: Thu, 19 May 2016 14:50:13 +0200 (CEST)
Subject: [openssl-dev] NO 20160519 SNAPSHOTS
In-Reply-To: <20160519102404.GA1809@doctor.nl2k.ab.ca>
References: <20160519102404.GA1809@doctor.nl2k.ab.ca>
Message-ID: <20160519.145013.509563384360069794.levitte@openssl.org>

In message <20160519102404.GA1809 at doctor.nl2k.ab.ca> on Thu, 19 May 2016 04:24:05 -0600, The Doctor <doctor at doctor.nl2k.ab.ca> said:

doctor> What happened?

A reboot for a kernel upgrade at the wrong time.  My apologies.
New snapshot will appear again tomorrow.

Cheers,
Richard

-- 
Richard Levitte         levitte at openssl.org
OpenSSL Project         http://www.openssl.org/~levitte/

From rt at openssl.org  Thu May 19 23:05:30 2016
From: rt at openssl.org (Stephen Henson via RT)
Date: Thu, 19 May 2016 23:05:30 +0000
Subject: [openssl-dev] [openssl.org #1817] smime does not add CRs
In-Reply-To: <m33afpupj4.fsf@scarff.id.au>
References: <RT-Ticket-1817@openssl.org> <m33afpupj4.fsf@scarff.id.au>
Message-ID: <rt-4.0.19-1993-1463699130-1041.1817-6-0@openssl.org>

Now fixed for smime and cms utilities. 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=1817
Please log in as guest with password guest if prompted


From rt at openssl.org  Thu May 19 23:08:08 2016
From: rt at openssl.org (Stephen Henson via RT)
Date: Thu, 19 May 2016 23:08:08 +0000
Subject: [openssl-dev] [openssl.org #2383] OpenSSL line break bugs
In-Reply-To: <4CF39B88.2000205@donz.ru>
References: <RT-Ticket-2383@openssl.org> <4CF39B88.2000205@donz.ru>
Message-ID: <rt-4.0.19-1994-1463699288-633.2383-6-0@openssl.org>

On Tue Nov 30 11:20:30 2010, donz4all at donz.ru wrote:
> Hello.
> I use OpenSSL 1.0.0a 1 Jun 2010 version.
>
> 1)Command "openssl smime -sign ..." generates output with added headers
> and meta-data in body with '\n' as line terminator but
> http://www.faqs.org/rfcs/rfc2822.html demands using only '\r\n' as line
> terminators.
>

This has now been addressed for all headers in the smime and cms utilities.

> 2)Command "openssl smime -verify -CAfile caCert.pem -certfile cert.pem
> -in %1 -out %1plain" treats all line terminators in the body of verified
> message as \r\n (as described in rfc2822). If creator and signer of this
> message use \n terminator in the message body there is no way to get
> successful verification except manual splitting message into headers and
> body and processing verification with "-content" key.
> Logically valid verification process must not change any content during
> verification.
>

That is intentional: the content is converted to canonical form as it may end
up with EOL translation en route or the MTA may end up using LF as EOL. As
indicated in the documentation the MIME parser is rather primitive and if an
application wants something more sophisticated they should use an alternative
parser.

Resolving ticket.

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=2383
Please log in as guest with password guest if prompted


From rt at openssl.org  Fri May 20 03:30:19 2016
From: rt at openssl.org (paul.dale@oracle.com via RT)
Date: Fri, 20 May 2016 03:30:19 +0000
Subject: [openssl-dev] [openssl.org #4543] Bug & fix: building the openssl
	application with READLINE enabled failsp
In-Reply-To: <754add01-ee5d-4252-8d26-af8df816bab6@default>
References: <RT-Ticket-4543@openssl.org>
 <754add01-ee5d-4252-8d26-af8df816bab6@default>
Message-ID: <rt-4.0.19-1994-1463715019-1392.4543-21-0@openssl.org>

The openssl application fails to compile with READLINE defined.

The fix is attached.

 

-- 

Oracle

Dr Paul Dale | Cryptographer | Network Security & Encryption 

Phone +61 7 3031 7217

Oracle Australia

 

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: patch
Type: application/octet-stream
Size: 463 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20160520/7aa0bc84/attachment.obj>

From rt at openssl.org  Fri May 20 10:26:56 2016
From: rt at openssl.org (Timothy Geiser via RT)
Date: Fri, 20 May 2016 10:26:56 +0000
Subject: [openssl-dev] [openssl.org #4544] [BUG] 'openssl pkcs8' command
	doesn't work as advertised
In-Reply-To: <CAFzcGVxHGo2RWeWK1WM7B5QCbYuiFp8hfpzpjf7P7ffFaT=wPQ@mail.gmail.com>
References: <RT-Ticket-4544@openssl.org>
 <CAFzcGVxHGo2RWeWK1WM7B5QCbYuiFp8hfpzpjf7P7ffFaT=wPQ@mail.gmail.com>
Message-ID: <rt-4.0.19-1993-1463740016-318.4544-21-0@openssl.org>

Confirmed with 1.0.2h on Windows 10 64-bit and 1.0.2g-fips on Xubuntu Linux
(16.04 'Xenial Xerus')

Make new RSA key in PKCS#8 format:
  ~$ openssl genpkey -algorithm rsa -out rsa_new.key

Try an example from the man page for 'pkcs8' to convert to (old) traditional
format:
  ~$ openssl pkcs8 -in rsa_new.key -out rsa_old.key
  Error reading key
  139801503176344:error:0906D06C:PEM routines:PEM_read_bio:no start line:
  pem_lib.c:701:Expecting: ENCRYPTED PRIVATE KEY

Read docs to find switch for making pkcs8 accept unencrypted keys. Try again:
  ~$ openssl pkcs8 -nocrypt -in rsa_new.key -out rsa_old.key

Check contents of new format and old format files:
  ~$ head -n 3 rsa_new.key rsa_old.key
  ==> rsa_new.key <==
  -----BEGIN PRIVATE KEY-----
  MIICdQIBADANBgkqhkiG9w0BAQEFAASCAl8wggJbAgEAAoGBAL93XnIDaTAl3MS7
  4OluxTGCG8yjI1MCQQz1dBvVf9Q1qeiqGTekY94Cj2KaHgF1EPOjKRgSG7ag7s9J

  ==> rsa_old.key <==
  -----BEGIN PRIVATE KEY-----
  MIICdQIBADANBgkqhkiG9w0BAQEFAASCAl8wggJbAgEAAoGBAL93XnIDaTAl3MS7
  4OluxTGCG8yjI1MCQQz1dBvVf9Q1qeiqGTekY94Cj2KaHgF1EPOjKRgSG7ag7s9J

The key is untranslated. This is a direct contradiction to the documentation.
The docs even have a nearly identical example:
>Convert a private key from any PKCS#8 format to traditional format:
>
> openssl pkcs8 -in pk8.pem -out key.pem

Workaround - use 'openssl rsa':
  ~$ openssl rsa -in rsa_new.key -out rsa_old.key
  writing RSA key
  ~$ head -n 3 rsa_new.key rsa_old.key
  ==> rsa_new.key <==
  -----BEGIN PRIVATE KEY-----
  MIICdQIBADANBgkqhkiG9w0BAQEFAASCAl8wggJbAgEAAoGBAL93XnIDaTAl3MS7
  4OluxTGCG8yjI1MCQQz1dBvVf9Q1qeiqGTekY94Cj2KaHgF1EPOjKRgSG7ag7s9J

  ==> rsa_old.key <==
  -----BEGIN RSA PRIVATE KEY-----
  MIICWwIBAAKBgQC/d15yA2kwJdzEu+DpbsUxghvMoyNTAkEM9XQb1X/UNanoqhk3
  pGPeAo9imh4BdRDzoykYEhu2oO7PSYAkoqD1mj+C+yCrx6aEOqehGXm/y3rxHTH9

I'm glad I was able to get the desired result with the workaround, but the
pkcs8 command does not work as advertised. I tried it with encrypted keys and
got the same result that way as well.


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


From rt at openssl.org  Fri May 20 12:23:33 2016
From: rt at openssl.org (Richard Levitte via RT)
Date: Fri, 20 May 2016 12:23:33 +0000
Subject: [openssl-dev] [openssl.org #4543] Bug & fix: building the openssl
	application with READLINE enabled failsp
In-Reply-To: <754add01-ee5d-4252-8d26-af8df816bab6@default>
References: <RT-Ticket-4543@openssl.org>
 <754add01-ee5d-4252-8d26-af8df816bab6@default>
Message-ID: <rt-4.0.19-1993-1463747013-1888.4543-6-0@openssl.org>

Applied. Thank you!

On Fri May 20 03:30:19 2016, paul.dale at oracle.com wrote:
> The openssl application fails to compile with READLINE defined.
>
> The fix is attached.
>
>
>


--
Richard Levitte
levitte at openssl.org

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


From rt at openssl.org  Fri May 20 13:22:47 2016
From: rt at openssl.org (Matt Caswell via RT)
Date: Fri, 20 May 2016 13:22:47 +0000
Subject: [openssl-dev] [openssl.org #4391] [PATCH] Tighten up logic around
	ChangeCipherSpec.
In-Reply-To: <CAF8qwaAr2rdJ0PYHQmph826Yb+43CC4gRUY0QWgwQZXLF0UKkA@mail.gmail.com>
References: <RT-Ticket-4391@openssl.org>
 <CAF8qwaAr2rdJ0PYHQmph826Yb+43CC4gRUY0QWgwQZXLF0UKkA@mail.gmail.com>
Message-ID: <rt-4.0.19-1993-1463750567-368.4391-6-0@openssl.org>

Patch applied in 1257adecd. Thanks!

Matt

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


From rt at openssl.org  Fri May 20 13:47:15 2016
From: rt at openssl.org (Matt Caswell via RT)
Date: Fri, 20 May 2016 13:47:15 +0000
Subject: [openssl-dev] [openssl.org #4394] OpenSSL 1.1.0 state machine can't
	read handshake headers async
In-Reply-To: <CAF8qwaBwPABhu+DZHZGjprRM4sFM3Tg8NV7BsKVRVi_nogrdmw@mail.gmail.com>
References: <RT-Ticket-4394@openssl.org>
 <CAF8qwaBwPABhu+DZHZGjprRM4sFM3Tg8NV7BsKVRVi_nogrdmw@mail.gmail.com>
Message-ID: <rt-4.0.19-1993-1463752035-1489.4394-6-0@openssl.org>

Fixed in 1689e7e6. Also I added a test in d7295cd6d.

Thanks

Matt

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


From rt at openssl.org  Fri May 20 14:42:49 2016
From: rt at openssl.org (Richard Levitte via RT)
Date: Fri, 20 May 2016 14:42:49 +0000
Subject: [openssl-dev] [openssl.org #1520] request for checking if -in and
	-out files are same
In-Reply-To: <46271FE7.4050201@gmail.com>
References: <RT-Ticket-1520@openssl.org> <46271FE7.4050201@gmail.com>
Message-ID: <rt-4.0.19-1994-1463755369-553.1520-6-0@openssl.org>

On Thu Apr 19 18:01:38 2007, samjnaa at gmail.com wrote:
> Dear sirs,
>
> I have been using openssl for some personal home-use encryption, and
> recently overwrote an input file while using openssl bf accidentally
> because bash's autocompletion put in the input file's name when I
> started typing the same name (minus bf at the end) for the output and I
> carelessly hit enter.
>
> For me it was not a big issue since those files were recoverable from
> elsewhere but there are probably people using openssl for more important
> things and they might have a serious problem if such a thing happened.
>
> So I request that openssl bf and other such openssl commands must check
> whether the input and output filenames are same and in such case give
> the user a warning and ask whether the user wants the output file to
> have the same name by deleting the input file after processing.
>
> If yes, then use a temporary file name till processing is done and then
> delete the input file and do something like mv tempfile origfile.
>
> If no, then abort.
>
> Since this is not a technical problem but an interface feature request I
> did not include the make report output etc (since I am using a pre-built
> openssl from my distro).
>
> Thank you.
>
> Shriramana Sharma.

I keep revisiting this (age old, sorry about that) issue time and again, and I
think the proper response is to reject this as a usage issue rather than an
inherent bug in OpenSSL command line.

Cheers,
Richard

--
Richard Levitte
levitte at openssl.org

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


From rt at openssl.org  Fri May 20 15:49:50 2016
From: rt at openssl.org (Mick Saxton via RT)
Date: Fri, 20 May 2016 15:49:50 +0000
Subject: [openssl-dev] [openssl.org #4545] Crash in crypto/rand/md_rand.c
In-Reply-To: <DB5PR0101MB1608B2BF4FDA7D1791AD17709E4B0@DB5PR0101MB1608.eurprd01.prod.exchangelabs.com>
References: <RT-Ticket-4545@openssl.org>
 <DB5PR0101MB1608B2BF4FDA7D1791AD17709E4B0@DB5PR0101MB1608.eurprd01.prod.exchangelabs.com>
Message-ID: <rt-4.0.19-1993-1463759389-386.4545-21-0@openssl.org>

Hi

Before going any further I would like to state that I have only seen this problem when we have 10000 or more concurrent connections.

Mostly we notice it on Windows but I have seen it on linux (Ubuntu).

I first noticed it when using v1.0.2d but have seen it again since upgrading to v1.0.2h.

It can happen in one of two places and results in a call to MD_Update with a negative value.

I have come up with a temporary fix which avoids the possibility of crashing at the expense of some randomness.
The system is very highly stressed at this point so debugging further is difficult.

The fix I am using is probably not what you eventually will want to implement but it does improve stability.

273:            MD_Update(&m, &(state[st_idx]), (j - k) );
Change to
273:            MD_Update(&m, &(state[st_idx]), (j - k) > 0 ? j - k : 1);  // micks at 1e.com (j -k) must not be negative

And

495:            MD_Update(&m, &(state[st_idx]), MD_DIGEST_LENGTH / 2 - k )
Change to
495:            MD_Update(&m, &(state[st_idx]), MD_DIGEST_LENGTH / 2 - k > 0 ? MD_DIGEST_LENGTH / 2 - k : 1);  // micks at 1e.com (j -k) must not be negative


I do have a test program which can reproduce this behaviour.

If I can be of further help - please contact me by email.

Regards
Mick Saxton

________________________________


Legal Notice: This email is intended only for the person(s) to whom it is addressed. If you are not an intended recipient and have received this message in error, please notify the sender immediately by replying to this email or calling +44(0) 2083269015 (UK) or +1 866 592 4214 (USA). This email and any attachments may be privileged and/or confidential. The unauthorized use, disclosure, copying or printing of any information it contains is strictly prohibited. The opinions expressed in this email are those of the author and do not necessarily represent the views of 1E Ltd. Nothing in this email will operate to bind 1E to any order or other contract.

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: crash.log
Type: application/octet-stream
Size: 1132 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20160520/83efc891/attachment-0001.obj>

From rt at openssl.org  Sat May 21 02:00:03 2016
From: rt at openssl.org (Richard Levitte via RT)
Date: Sat, 21 May 2016 02:00:03 +0000
Subject: [openssl-dev] [openssl.org #1866] openssl verify needs better error
	reporting
In-Reply-To: <49B7B34F.2080903@sun.com>
References: <RT-Ticket-1866@openssl.org> <49B7B34F.2080903@sun.com>
Message-ID: <rt-4.0.19-1994-1463796003-765.1866-6-0@openssl.org>

Fixed in the 1.0.2 branch. The master branch has had tremendous changes around
command line parsing and error reporting that the bug most likely disappeared
automatically.

Closing ticket

Cheers,
Richard

On Wed Mar 11 14:28:50 2009, Vladimir.Kotal at Sun.COM wrote:
>
> Hello,
>
> In case the openssl verify command is not able to process input file, it
> reports the usage even if the usage is perfectly okay:
>
> $ openssl verify -CAfile /local/Saved/SMI_SSL_CA-chain.pem cert.cer
> Error loading file /local/Saved/SMI_SSL_CA-chain.pem
> usage: verify [-verbose] [-CApath path] [-CAfile file] [-purpose
> purpose] [-crl_check] [-engine e] cert1 cert2 ...
> recognized usages:
> sslclient SSL client
> sslserver SSL server
> nssslserver Netscape SSL server
> smimesign S/MIME signing
> smimeencrypt S/MIME encryption
> crlsign CRL signing
> any Any Purpose
> ocsphelper OCSP helper
> $
>
>
> This is because of the following code in verify.c:
>
>
> if (CAfile) {
> i=X509_LOOKUP_load_file(lookup,CAfile,X509_FILETYPE_PEM);
> if(!i) {
> BIO_printf(bio_err, "Error loading file %s\n", CAfile);
> ERR_print_errors(bio_err);
> goto end;
> }
>
> The goto jumps to the code which prints the usage. Similarly for other
> input files.
>
> Also, it does not report what went wrong with the input file.
>
>
> v.


--
Richard Levitte
levitte at openssl.org

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


From doctor at doctor.nl2k.ab.ca  Sat May 21 14:04:00 2016
From: doctor at doctor.nl2k.ab.ca (The Doctor)
Date: Sat, 21 May 2016 08:04:00 -0600
Subject: [openssl-dev] openssl 1.0.2 SNAPSHOT issue
Message-ID: <20160521140400.GA29244@doctor.nl2k.ab.ca>

Looks like one of the test tend to cause randomd to right high
producing a lock up like state during testing.

Please look in to this.

This did not happen with the 20160520 package.
-- 
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
Abuse a man unjustly, and you will make friends for him.  -Edgar Watson Howe

From appro at openssl.org  Sun May 22 08:32:36 2016
From: appro at openssl.org (Andy Polyakov)
Date: Sun, 22 May 2016 10:32:36 +0200
Subject: [openssl-dev] Question on private_AES_set_decrypt_key "invert
 the order of the round keys"
In-Reply-To: <2E4E24F6E6E47843B01089BF753792289E76794F@cf-mail.comforte.local>
References: <2E4E24F6E6E47843B01089BF753792289E76794F@cf-mail.comforte.local>
Message-ID: <57416EA4.4030109@openssl.org>

> In the function private_AES_set_decrypt_key, in aes_core.c, it inverts
> the order of the round keys before applying the MixColumn transform from
> low to high (excluding low and high, order doesn?t really matter as each
> transformation is dependent only on the item in question). Then
> AES_decrypt applies the round keys from low to high on the input.
> 
> It seems to me that you will get the same result if you do away with the
> inversion of the round keys, apply the MixColumn transform (excluding
> low and high) and then AES_decrypt applies the round keys from high to
> low on the input.
> 
> Using this method would therefore save the amount (pretty small) of cpu
> time used to invert the round keys, with no apparent penalty, assuming
> looping backwards costs the same as looping forwards.

Well, you'll have to calculate address of the last round key in the
schedule. This introduces dependency on load of number of rounds. I mean
contemporary processors look ahead and in this context can start pulling
key schedule elements in advance. But with the dependency pre-load will
have to be postponed and might be late, which would result in delay upon
entry into the loop. I mean there is no penalty with backward looping
per se, there is penalty with setting up backward loop. In *this*
context that is.

> Is there something functionally wrong with my hypothesis?

No, not outcome-wise.

> If not, is
> there something wrong security-wise, e.g. will the different cpu time
> cause a vulnerability (it seems that currently one can theoretically
> tell the difference between an encryption and a decryption based on cpu
> usage, but I don?t know if that is a real problem)?

There is no security value in order in which key schedule elements are
addressed.


From appro at openssl.org  Sun May 22 08:54:48 2016
From: appro at openssl.org (Andy Polyakov)
Date: Sun, 22 May 2016 10:54:48 +0200
Subject: [openssl-dev] OpenSSL support of SHA 512/256 and SHA 512/224?
In-Reply-To: <1463549415108-66190.post@n7.nabble.com>
References: <1463549415108-66190.post@n7.nabble.com>
Message-ID: <574173D8.5030203@openssl.org>

> Or.... could it be assumed that an SHA 512 implementation has innate support
> for the truncated version like SHA 512/256 ? And so, it does hold good for
> OpenSSL too?

Both yes and no. Yes in sense that given low-level interface application
is actually capable of producing desired result (you can replace initial
values prior actual hashing and truncate result), and no in sense that
there is no high-level interface and the said low-level programming
won't be considered as supported.


From doctor at doctor.nl2k.ab.ca  Sun May 22 12:34:26 2016
From: doctor at doctor.nl2k.ab.ca (The Doctor)
Date: Sun, 22 May 2016 06:34:26 -0600
Subject: [openssl-dev] openssl 1.0.2 SNAPSHOT issue that exists since
	20160521
Message-ID: <20160522123426.GA10789@doctor.nl2k.ab.ca>


when executing

../apps/openssl x509 -sha1 -CAcreateserial -in reqCA.ss -days 30 -req -out certCA.ss -signkey keyCA.ss -extfile CAss.cnf -extensions v3_ca 

during the test phase, it looks as if the test hangs.

Please look into this.

-- 
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
Abuse a man unjustly, and you will make friends for him.  -Edgar Watson Howe

From doctor at doctor.nl2k.ab.ca  Mon May 23 07:04:29 2016
From: doctor at doctor.nl2k.ab.ca (The Doctor)
Date: Mon, 23 May 2016 01:04:29 -0600
Subject: [openssl-dev] openssl 1.0.2 SNAPSHOT issue that exists since
 20160521
In-Reply-To: <20160522123426.GA10789@doctor.nl2k.ab.ca>
References: <20160522123426.GA10789@doctor.nl2k.ab.ca>
Message-ID: <20160523070428.GA17582@doctor.nl2k.ab.ca>

On Sun, May 22, 2016 at 06:34:26AM -0600, The Doctor wrote:
> 
> when executing
> 
> ../apps/openssl x509 -sha1 -CAcreateserial -in reqCA.ss -days 30 -req -out certCA.ss -signkey keyCA.ss -extfile CAss.cnf -extensions v3_ca 
> 
> during the test phase, it looks as if the test hangs.
> 
> Please look into this.
> 


This issue now exists in 20160523 .

Please look into this showstopper.

-- 
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
Abuse a man unjustly, and you will make friends for him.  -Edgar Watson Howe

From rt at openssl.org  Mon May 23 07:35:17 2016
From: rt at openssl.org (=?UTF-8?B?UmFtxatuYXMgSnVyZ2lsYXM=?= via RT)
Date: Mon, 23 May 2016 07:35:17 +0000
Subject: [openssl-dev] [openssl.org #4466] Memory leak in PKCS12_newpass
	function
In-Reply-To: <FB087A6B-E4F1-4427-9116-B31B7071217F@gmail.com>
References: <RT-Ticket-4466@openssl.org>
 <CAAwMTtXM81aE6eCyqNSJDpm2UgGfcGKFpEouR5u-8AWRRL9Y8w@mail.gmail.com>
 <rt-4.0.19-23551-1462568868-1753.4466-6-0@openssl.org>
 <FB087A6B-E4F1-4427-9116-B31B7071217F@gmail.com>
Message-ID: <rt-4.0.19-18315-1463988917-774.4466-6-0@openssl.org>

Thank you very much for the fix. 

Best regards,
Ramunas

> On May 7, 2016, at 12:07 AM, Stephen Henson via RT <rt at openssl.org> wrote:
> 
> Fixed, 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=4466
> Please log in as guest with password guest if prompted
> 


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


From levitte at openssl.org  Mon May 23 08:10:46 2016
From: levitte at openssl.org (Richard Levitte)
Date: Mon, 23 May 2016 10:10:46 +0200 (CEST)
Subject: [openssl-dev] openssl 1.0.2 SNAPSHOT issue that exists since
 20160521
In-Reply-To: <20160523070428.GA17582@doctor.nl2k.ab.ca>
References: <20160522123426.GA10789@doctor.nl2k.ab.ca>
 <20160523070428.GA17582@doctor.nl2k.ab.ca>
Message-ID: <20160523.101046.721451753715566904.levitte@openssl.org>

In message <20160523070428.GA17582 at doctor.nl2k.ab.ca> on Mon, 23 May 2016 01:04:29 -0600, The Doctor <doctor at doctor.nl2k.ab.ca> said:

doctor> On Sun, May 22, 2016 at 06:34:26AM -0600, The Doctor wrote:
doctor> > 
doctor> > when executing
doctor> > 
doctor> > ../apps/openssl x509 -sha1 -CAcreateserial -in reqCA.ss -days 30 -req -out certCA.ss -signkey keyCA.ss -extfile CAss.cnf -extensions v3_ca 
doctor> > 
doctor> > during the test phase, it looks as if the test hangs.
doctor> > 
doctor> > Please look into this.
doctor> > 
doctor> 
doctor> 
doctor> This issue now exists in 20160523 .
doctor> 
doctor> Please look into this showstopper.

Can't reproduce.  I've tried on Linux (Debian bleeding edge) and
FreeBSD (8.4-RELEASE-p14).  However, I did it with the default config
(BSD-x86_64, which is what ./config gives me automagically, and no
extra options), please remind me of yours.

Cheers,
Richard

-- 
Richard Levitte         levitte at openssl.org
OpenSSL Project         http://www.openssl.org/~levitte/

From rt at openssl.org  Mon May 23 10:23:52 2016
From: rt at openssl.org (Matt Caswell via RT)
Date: Mon, 23 May 2016 10:23:52 +0000
Subject: [openssl-dev] [openssl.org #1928] interface bug on Windows 64
In-Reply-To: <4A0A9243.5040802@acm.org>
References: <RT-Ticket-1928@openssl.org> <4A0A9243.5040802@acm.org>
Message-ID: <rt-4.0.19-23362-1463999031-781.1928-6-0@openssl.org>

Will not fix for 1.1.0...Moving to a later milestone.

Matt

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


From rt at openssl.org  Mon May 23 10:31:00 2016
From: rt at openssl.org (Matt Caswell via RT)
Date: Mon, 23 May 2016 10:31:00 +0000
Subject: [openssl-dev] [openssl.org #2530]
	crypto/dsa/dsa_gen.c::dsa_builtin_paramgen has potential
	uninitialized seed
In-Reply-To: <20110518150619.GF17574@suse.de>
References: <RT-Ticket-2530@openssl.org> <20110518150619.GF17574@suse.de>
Message-ID: <rt-4.0.19-23362-1463999460-494.2530-6-0@openssl.org>

Looks like the code has changed since this was raised and this issue has been
fixed.

Closing.

Matt

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


From rsalz at akamai.com  Mon May 23 13:15:45 2016
From: rsalz at akamai.com (Salz, Rich)
Date: Mon, 23 May 2016 13:15:45 +0000
Subject: [openssl-dev] 1.1 release being delayed
Message-ID: <a756150f2fcb4c72a521893c3787557f@usma1ex-dag1mb1.msg.corp.akamai.com>

... in case you haven't noticed :)  Our announced release date for 1.1 has come and gone.

We want to close many more bugs before we release it.  In the meantime, please test against master or a daily snapshot or the last beta release.

Thanks for your patience!


--  
Senior Architect, Akamai Technologies
IM: richsalz at jabber.at Twitter: RichSalz



From rt at openssl.org  Mon May 23 13:50:04 2016
From: rt at openssl.org (Matt Caswell via RT)
Date: Mon, 23 May 2016 13:50:04 +0000
Subject: [openssl-dev] [openssl.org #2036] bug report: TLS session
	resumption not checking for existence of client finished message
In-Reply-To: <000301ca301f$de585210$9b08f630$@goodall@g2microsystems.com>
References: <RT-Ticket-2036@openssl.org>
 <000301ca301f$de585210$9b08f630$@goodall@g2microsystems.com>
Message-ID: <rt-4.0.19-18315-1464011404-1019.2036-6-0@openssl.org>

I'm guessing this is no longer an issue due to the time elapsed and I think
there have been changes in this area since then (and definitely in master).

In any case there is insufficient information in this report to identify the
problem. If this is still a problem please open a new ticket.

Closing.

Matt

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


From rt at openssl.org  Mon May 23 13:53:17 2016
From: rt at openssl.org (Matt Caswell via RT)
Date: Mon, 23 May 2016 13:53:17 +0000
Subject: [openssl-dev] [openssl.org #2325] memory corruption after libssl is
	unloaded from memory
In-Reply-To: <Pine.SOC.4.64.1008241136020.3960@rejewski>
References: <RT-Ticket-2325@openssl.org>
 <Pine.SOC.4.64.1008241136020.3960@rejewski>
Message-ID: <rt-4.0.19-18315-1464011597-1371.2325-6-0@openssl.org>

This shouldn't be an issue any more with auto-init/auto-deinit in master.
Closing this.

Matt

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


From rt at openssl.org  Mon May 23 13:59:22 2016
From: rt at openssl.org (Matt Caswell via RT)
Date: Mon, 23 May 2016 13:59:22 +0000
Subject: [openssl-dev] [openssl.org #2274] SSL demo programs in openssl-1.0.0
In-Reply-To: <4BFAEAF3.7080103@gcom.com>
References: <RT-Ticket-2274@openssl.org> <4BFAEAF3.7080103@gcom.com>
Message-ID: <rt-4.0.19-18315-1464011962-75.2274-6-0@openssl.org>

Most of the demos have been removed from master, and the other patches no
longer apply. Please reopen new issues if any of this is still valid.

Closing.

Matt

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


From rt at openssl.org  Mon May 23 14:03:47 2016
From: rt at openssl.org (Matt Caswell via RT)
Date: Mon, 23 May 2016 14:03:47 +0000
Subject: [openssl-dev] [openssl.org #2523] Patch to use standard RFC 5054
	constants and behavior for TLS-SRP (OpenSSL 1.0.1)
In-Reply-To: <BANLkTim-EHbao49+QVWURoyH5qiK6riWvQ@mail.gmail.com>
References: <RT-Ticket-2523@openssl.org>
 <BANLkTim-EHbao49+QVWURoyH5qiK6riWvQ@mail.gmail.com>
Message-ID: <rt-4.0.19-18315-1464012226-1951.2523-6-0@openssl.org>

A lot of the stuff that this is removing already seems to have gone and the
patch no longer applies. I suspect that most of this is no longer necessary. If
any of it is, please open a new ticket.

Matt

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


From rt at openssl.org  Mon May 23 14:05:04 2016
From: rt at openssl.org (Matt Caswell via RT)
Date: Mon, 23 May 2016 14:05:04 +0000
Subject: [openssl-dev] [openssl.org #1747] capi engine and mingw
In-Reply-To: <48D94EAA.9090807@roumenpetrov.info>
References: <RT-Ticket-1747@openssl.org> <48D94EAA.9090807@roumenpetrov.info>
Message-ID: <rt-4.0.19-23362-1464012304-548.1747-6-0@openssl.org>

CAPI can now be build under mingw in master. Closing this ticket.

Matt

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


From rt at openssl.org  Mon May 23 14:20:12 2016
From: rt at openssl.org (Matt Caswell via RT)
Date: Mon, 23 May 2016 14:20:12 +0000
Subject: [openssl-dev] [openssl.org #2510] [PATCH] ebcdic issues: Bad time
	value when issuing openssl x509 -text -in
In-Reply-To: <4FEFEBD7EB29F6419167D601730B83FE274A6B3E37@MBXTIG602V1.hermes.si.socgen>
References: <RT-Ticket-2510@openssl.org>
 <4FEFEBD7EB29F6419167D601730B83FE274A6B3E37@MBXTIG602V1.hermes.si.socgen>
Message-ID: <rt-4.0.19-23362-1464013212-871.2510-6-0@openssl.org>

The supplied patch is not in an acceptable form, and the diff mentioned in the
report (sourcename.txt) does not seem to be attached. Given the length of time
since this was raised this will no longer apply anyway. Please raise a new
ticket if this is still a problem.

Matt

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


From rt at openssl.org  Mon May 23 14:43:26 2016
From: rt at openssl.org (Matt Caswell via RT)
Date: Mon, 23 May 2016 14:43:26 +0000
Subject: [openssl-dev] [openssl.org #1639] BUG in BN_mod_inverse
In-Reply-To: <9b05d93f0801310016w2808860ft35bb1c565744ec49@mail.gmail.com>
References: <RT-Ticket-1639@openssl.org>
 <9b05d93f0801310016w2808860ft35bb1c565744ec49@mail.gmail.com>
Message-ID: <rt-4.0.19-23362-1464014606-822.1639-6-0@openssl.org>

AFAIK it is valid to call BN_sub() in this way, and looking at the code I can't
see any problem with doing so. There is no reproducer of an actual issue in
this report, so closing.

Matt

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


From rt at openssl.org  Mon May 23 14:49:34 2016
From: rt at openssl.org (Matt Caswell via RT)
Date: Mon, 23 May 2016 14:49:34 +0000
Subject: [openssl-dev] [openssl.org #2497] [PATCH] Improve RSAOaep Error
	Handling
In-Reply-To: <C9C899E1.1326E%tim.jackson@citrixonline.com>
References: <RT-Ticket-2497@openssl.org>
 <C9C899E1.1326E%tim.jackson@citrixonline.com>
Message-ID: <rt-4.0.19-23362-1464014974-997.2497-6-0@openssl.org>

Looks like this was independently fixed in the time since this was raised.
Closing.

Matt

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


From doctor at doctor.nl2k.ab.ca  Mon May 23 15:34:55 2016
From: doctor at doctor.nl2k.ab.ca (The Doctor)
Date: Mon, 23 May 2016 09:34:55 -0600
Subject: [openssl-dev] openssl 1.0.2 SNAPSHOT issue that exists since
 20160521
In-Reply-To: <20160523.101046.721451753715566904.levitte@openssl.org>
References: <20160522123426.GA10789@doctor.nl2k.ab.ca>
 <20160523070428.GA17582@doctor.nl2k.ab.ca>
 <20160523.101046.721451753715566904.levitte@openssl.org>
Message-ID: <20160523153455.GA23295@doctor.nl2k.ab.ca>

On Mon, May 23, 2016 at 10:10:46AM +0200, Richard Levitte wrote:
> In message <20160523070428.GA17582 at doctor.nl2k.ab.ca> on Mon, 23 May 2016 01:04:29 -0600, The Doctor <doctor at doctor.nl2k.ab.ca> said:
> 
> doctor> On Sun, May 22, 2016 at 06:34:26AM -0600, The Doctor wrote:
> doctor> > 
> doctor> > when executing
> doctor> > 
> doctor> > ../apps/openssl x509 -sha1 -CAcreateserial -in reqCA.ss -days 30 -req -out certCA.ss -signkey keyCA.ss -extfile CAss.cnf -extensions v3_ca 
> doctor> > 
> doctor> > during the test phase, it looks as if the test hangs.
> doctor> > 
> doctor> > Please look into this.
> doctor> > 
> doctor> 
> doctor> 
> doctor> This issue now exists in 20160523 .
> doctor> 
> doctor> Please look into this showstopper.
> 
> Can't reproduce.  I've tried on Linux (Debian bleeding edge) and
> FreeBSD (8.4-RELEASE-p14).  However, I did it with the default config
> (BSD-x86_64, which is what ./config gives me automagically, and no
> extra options), please remind me of yours.
>

 
 ./Configure 386 threads shared experimental-libunbound experimental-dane  no-sse2 enable-srtp no-sctp experimental-jpake  experimental-store enable-whrlpool enable-montasm enable-capieng enable-cms enable-seed enable-tlsext enable-ssl-trace enable-camellia enable-rfc3779 enable-gmp enable-mdc2 enable-md5 enable-rc5 experimental-multiblock enable-unit-test zlib-dynamic no-ssl3 --prefix=/usr/contrib --openssldir=/usr/contrib debug-bsdi-x86-elf ; make update;make depend


"debug-bsdi-x86-elf",   "gcc3:-DPERL5 -DL_ENDIAN -DTERMIOS -fomit-frame-pointer
-O2 -Wall -g::${BSDthreads}::-lgmp -ldl -lm -lc -lz:THIRY_TWO_BIT_LONG RC4_CHUNK
 BN_LLONG ${x86_gcc_des} ${x86_gcc_opts}:${x86_elf_asm}:dlfcn:bsd-gcc-shared:-fP
IC::.so.\$(SHLIB_MAJOR).\$(SHLIB_MINOR)",

 
> Cheers,
> Richard
> 
> -- 
> Richard Levitte         levitte at openssl.org
> OpenSSL Project         http://www.openssl.org/~levitte/

-- 
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
Abuse a man unjustly, and you will make friends for him.  -Edgar Watson Howe

From doctor at doctor.nl2k.ab.ca  Mon May 23 15:43:41 2016
From: doctor at doctor.nl2k.ab.ca (The Doctor)
Date: Mon, 23 May 2016 09:43:41 -0600
Subject: [openssl-dev] [openssl-users] 1.1 release being delayed
In-Reply-To: <a756150f2fcb4c72a521893c3787557f@usma1ex-dag1mb1.msg.corp.akamai.com>
References: <a756150f2fcb4c72a521893c3787557f@usma1ex-dag1mb1.msg.corp.akamai.com>
Message-ID: <20160523154341.GB23295@doctor.nl2k.ab.ca>

On Mon, May 23, 2016 at 01:15:45PM +0000, Salz, Rich wrote:
> ... in case you haven't noticed :)  Our announced release date for 1.1 has come and gone.
> 
> We want to close many more bugs before we release it.  In the meantime, please test against master or a daily snapshot or the last beta release.
> 
> Thanks for your patience!
>

No problem and hopefully for app developers will come on board.
 
> 
> --  
> Senior Architect, Akamai Technologies
> IM: richsalz at jabber.at Twitter: RichSalz
> 
> 
> -- 
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

-- 
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
Abuse a man unjustly, and you will make friends for him.  -Edgar Watson Howe

From rt at openssl.org  Mon May 23 21:37:16 2016
From: rt at openssl.org (Stephen Henson via RT)
Date: Mon, 23 May 2016 21:37:16 +0000
Subject: [openssl-dev] [openssl.org #4544] [BUG] 'openssl pkcs8' command
	doesn't work as advertised
In-Reply-To: <CAFzcGVxHGo2RWeWK1WM7B5QCbYuiFp8hfpzpjf7P7ffFaT=wPQ@mail.gmail.com>
References: <RT-Ticket-4544@openssl.org>
 <CAFzcGVxHGo2RWeWK1WM7B5QCbYuiFp8hfpzpjf7P7ffFaT=wPQ@mail.gmail.com>
Message-ID: <rt-4.0.19-18315-1464039436-757.4544-6-0@openssl.org>

On Fri May 20 10:26:56 2016, slimshady007 at gmail.com wrote:
>
> I'm glad I was able to get the desired result with the workaround, but
> the
> pkcs8 command does not work as advertised. I tried it with encrypted
> keys and
> got the same result that way as well.

The bug is in the documentation. The pkcs8 command writes private keys with
PEM_write_bio_PrivateKey() which used to use "traditional" format. Tthat
function got updated to use the more secure PKCS#8 encrypted format but the
documentation wasn't fixed to reflect that and there was no equivalent to
PEM_write_bio_PrivateKey() which used traditional format.

The master branch has a fix for this: the pkcs8 and the pkey commands now have
a -traditional command line switch which forces traditional format.

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=4544
Please log in as guest with password guest if prompted


From rt at openssl.org  Mon May 23 22:28:36 2016
From: rt at openssl.org (Matt Caswell via RT)
Date: Mon, 23 May 2016 22:28:36 +0000
Subject: [openssl-dev] [openssl.org #2267] Thread-safety issue:
	build_SYS_str_reasons() calls strerror()
In-Reply-To: <4BF10FEC.5060807@medical-insight.com>
References: <RT-Ticket-2267@openssl.org> <4BF10FEC.5060807@medical-insight.com>
Message-ID: <rt-4.0.19-18315-1464042516-1303.2267-6-0@openssl.org>

Fixed in commit 7d37818d. Closing.

Matt

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


From rt at openssl.org  Mon May 23 23:14:46 2016
From: rt at openssl.org (Matt Caswell via RT)
Date: Mon, 23 May 2016 23:14:46 +0000
Subject: [openssl-dev] [openssl.org #2238] RE: Memory leak in
	\crypto\objects\o_names.c in method 'OBJ_NAME_add'.
In-Reply-To: <4E36CEEE18BD4FA992E3F83A8144886B@ALTENPTSL023>
References: <RT-Ticket-2238@openssl.org>
 <4E36CEEE18BD4FA992E3F83A8144886B@ALTENPTSL023>
Message-ID: <rt-4.0.19-18315-1464045286-550.2238-6-0@openssl.org>

Fixed in commit 0a618df0. Closing.

Matt

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


From doctor at doctor.nl2k.ab.ca  Tue May 24 07:09:55 2016
From: doctor at doctor.nl2k.ab.ca (The Doctor)
Date: Tue, 24 May 2016 01:09:55 -0600
Subject: [openssl-dev] openssl 1.0.2 SNAPSHOT issue that exists since
 20160521
In-Reply-To: <20160523.101046.721451753715566904.levitte@openssl.org>
References: <20160522123426.GA10789@doctor.nl2k.ab.ca>
 <20160523070428.GA17582@doctor.nl2k.ab.ca>
 <20160523.101046.721451753715566904.levitte@openssl.org>
Message-ID: <20160524070954.GA17442@doctor.nl2k.ab.ca>

On Mon, May 23, 2016 at 10:10:46AM +0200, Richard Levitte wrote:
> In message <20160523070428.GA17582 at doctor.nl2k.ab.ca> on Mon, 23 May 2016 01:04:29 -0600, The Doctor <doctor at doctor.nl2k.ab.ca> said:
> 
> doctor> On Sun, May 22, 2016 at 06:34:26AM -0600, The Doctor wrote:
> doctor> > 
> doctor> > when executing
> doctor> > 
> doctor> > ../apps/openssl x509 -sha1 -CAcreateserial -in reqCA.ss -days 30 -req -out certCA.ss -signkey keyCA.ss -extfile CAss.cnf -extensions v3_ca 
> doctor> > 
> doctor> > during the test phase, it looks as if the test hangs.
> doctor> > 
> doctor> > Please look into this.
> doctor> > 
> doctor> 
> doctor> 
> doctor> This issue now exists in 20160523 .
> doctor> 
> doctor> Please look into this showstopper.
> 
> Can't reproduce.  I've tried on Linux (Debian bleeding edge) and
> FreeBSD (8.4-RELEASE-p14).  However, I did it with the default config
> (BSD-x86_64, which is what ./config gives me automagically, and no
> extra options), please remind me of yours.
>

All right,  what changed between 20160520 and 20160521 ?

Simple question.  That is the source of the showstopper.
 
> Cheers,
> Richard
> 
> -- 
> Richard Levitte         levitte at openssl.org
> OpenSSL Project         http://www.openssl.org/~levitte/

-- 
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
Abuse a man unjustly, and you will make friends for him.  -Edgar Watson Howe

From levitte at openssl.org  Tue May 24 10:26:02 2016
From: levitte at openssl.org (Richard Levitte)
Date: Tue, 24 May 2016 12:26:02 +0200 (CEST)
Subject: [openssl-dev] openssl 1.0.2 SNAPSHOT issue that exists since
 20160521
In-Reply-To: <20160524070954.GA17442@doctor.nl2k.ab.ca>
References: <20160523070428.GA17582@doctor.nl2k.ab.ca>
 <20160523.101046.721451753715566904.levitte@openssl.org>
 <20160524070954.GA17442@doctor.nl2k.ab.ca>
Message-ID: <20160524.122602.473298129306775007.levitte@openssl.org>

In message <20160524070954.GA17442 at doctor.nl2k.ab.ca> on Tue, 24 May 2016 01:09:55 -0600, The Doctor <doctor at doctor.nl2k.ab.ca> said:

doctor> On Mon, May 23, 2016 at 10:10:46AM +0200, Richard Levitte wrote:
doctor> > In message <20160523070428.GA17582 at doctor.nl2k.ab.ca> on Mon, 23 May 2016 01:04:29 -0600, The Doctor <doctor at doctor.nl2k.ab.ca> said:
doctor> > 
doctor> > doctor> On Sun, May 22, 2016 at 06:34:26AM -0600, The Doctor wrote:
doctor> > doctor> > 
doctor> > doctor> > when executing
doctor> > doctor> > 
doctor> > doctor> > ../apps/openssl x509 -sha1 -CAcreateserial -in reqCA.ss -days 30 -req -out certCA.ss -signkey keyCA.ss -extfile CAss.cnf -extensions v3_ca 
doctor> > doctor> > 
doctor> > doctor> > during the test phase, it looks as if the test hangs.
doctor> > doctor> > 
doctor> > doctor> > Please look into this.
doctor> > doctor> > 
doctor> > doctor> 
doctor> > doctor> 
doctor> > doctor> This issue now exists in 20160523 .
doctor> > doctor> 
doctor> > doctor> Please look into this showstopper.
doctor> > 
doctor> > Can't reproduce.  I've tried on Linux (Debian bleeding edge) and
doctor> > FreeBSD (8.4-RELEASE-p14).  However, I did it with the default config
doctor> > (BSD-x86_64, which is what ./config gives me automagically, and no
doctor> > extra options), please remind me of yours.
doctor> >
doctor> 
doctor> All right,  what changed between 20160520 and 20160521 ?
doctor> 
doctor> Simple question.  That is the source of the showstopper.

I'm attaching the only change that I can think makes a difference.
Try a 'patch -R -p1 < xopen_source.patch' and see if that changes
anything.

I don't think we're going to back off from that change, so if you can
help us figure out what goes wrong with it on your system and how to
improve the change, that's be great.

Cheers,
Richard

-- 
Richard Levitte         levitte at openssl.org
OpenSSL Project         http://www.openssl.org/~levitte/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: xopen_source.patch
Type: text/x-patch
Size: 2512 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20160524/91135af8/attachment.bin>

From rt at openssl.org  Tue May 24 12:49:52 2016
From: rt at openssl.org (Stephen Henson via RT)
Date: Tue, 24 May 2016 12:49:52 +0000
Subject: [openssl-dev] [openssl.org #4471] 1.1.0-pre4 safestack.h
	compilation errors with -Wcast-qual
In-Reply-To: <rt-4.0.19-840-1463423533-1971.4471-6-0@openssl.org>
References: <RT-Ticket-4471@openssl.org>
 <558C903B-A05C-4B2C-A29E-065E918D5F56@xbill.org>
 <rt-4.0.19-18545-1463140989-1400.4471-6-0@openssl.org>
 <03C288C2-39FD-466F-8DC0-C27BECB57077@xbill.org>
 <rt-4.0.19-840-1463423533-1971.4471-6-0@openssl.org>
Message-ID: <rt-4.0.19-18315-1464094192-1242.4471-6-0@openssl.org>

On Mon May 16 18:32:13 2016, bwelling at xbill.org wrote:
> This is fixed, but there are similar problems that still exist, for
> example:
>
> ?
> #include <openssl/err.h>
> #include <openssl/ssl.h>
>

I've addresses some, but not all the warnings now. Some of them would require
signiicant changes to the way STACK works. We'll review the possibilities for
inclusion after 1.1.0.

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=4471
Please log in as guest with password guest if prompted


From rt at openssl.org  Tue May 24 13:53:07 2016
From: rt at openssl.org (Stephen Henson via RT)
Date: Tue, 24 May 2016 13:53:07 +0000
Subject: [openssl-dev] [openssl.org #4329] OpenSSL 1.1.0 pre3: internal
	error in tls_post_process_client_key_exchange during reneg
In-Reply-To: <56C9C1CC.50406@kippdata.de>
References: <RT-Ticket-4329@openssl.org> <56C9C1CC.50406@kippdata.de>
Message-ID: <rt-4.0.19-18315-1464097987-1439.4329-6-0@openssl.org>

On Sun Feb 21 13:55:35 2016, rainer.jung at kippdata.de wrote:
> Running the Apache test suite for Apache 2.4 with OpenSSL 1.1.0
> adjustments, I get
>

Can you please check to see if this issue is still present in the latest
OpenSSL 1.1.0?

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=4329
Please log in as guest with password guest if prompted


From doctor at doctor.nl2k.ab.ca  Tue May 24 14:24:12 2016
From: doctor at doctor.nl2k.ab.ca (The Doctor)
Date: Tue, 24 May 2016 08:24:12 -0600
Subject: [openssl-dev] openssl 1.0.2 SNAPSHOT issue that exists since
 20160521
In-Reply-To: <20160524.122602.473298129306775007.levitte@openssl.org>
References: <20160523070428.GA17582@doctor.nl2k.ab.ca>
 <20160523.101046.721451753715566904.levitte@openssl.org>
 <20160524070954.GA17442@doctor.nl2k.ab.ca>
 <20160524.122602.473298129306775007.levitte@openssl.org>
Message-ID: <20160524142412.GA6384@doctor.nl2k.ab.ca>

On Tue, May 24, 2016 at 12:26:02PM +0200, Richard Levitte wrote:
> In message <20160524070954.GA17442 at doctor.nl2k.ab.ca> on Tue, 24 May 2016 01:09:55 -0600, The Doctor <doctor at doctor.nl2k.ab.ca> said:
> 
> doctor> On Mon, May 23, 2016 at 10:10:46AM +0200, Richard Levitte wrote:
> doctor> > In message <20160523070428.GA17582 at doctor.nl2k.ab.ca> on Mon, 23 May 2016 01:04:29 -0600, The Doctor <doctor at doctor.nl2k.ab.ca> said:
> doctor> > 
> doctor> > doctor> On Sun, May 22, 2016 at 06:34:26AM -0600, The Doctor wrote:
> doctor> > doctor> > 
> doctor> > doctor> > when executing
> doctor> > doctor> > 
> doctor> > doctor> > ../apps/openssl x509 -sha1 -CAcreateserial -in reqCA.ss -days 30 -req -out certCA.ss -signkey keyCA.ss -extfile CAss.cnf -extensions v3_ca 
> doctor> > doctor> > 
> doctor> > doctor> > during the test phase, it looks as if the test hangs.
> doctor> > doctor> > 
> doctor> > doctor> > Please look into this.
> doctor> > doctor> > 
> doctor> > doctor> 
> doctor> > doctor> 
> doctor> > doctor> This issue now exists in 20160523 .
> doctor> > doctor> 
> doctor> > doctor> Please look into this showstopper.
> doctor> > 
> doctor> > Can't reproduce.  I've tried on Linux (Debian bleeding edge) and
> doctor> > FreeBSD (8.4-RELEASE-p14).  However, I did it with the default config
> doctor> > (BSD-x86_64, which is what ./config gives me automagically, and no
> doctor> > extra options), please remind me of yours.
> doctor> >
> doctor> 
> doctor> All right,  what changed between 20160520 and 20160521 ?
> doctor> 
> doctor> Simple question.  That is the source of the showstopper.
> 
> I'm attaching the only change that I can think makes a difference.
> Try a 'patch -R -p1 < xopen_source.patch' and see if that changes
> anything.
> 
> I don't think we're going to back off from that change, so if you can
> help us figure out what goes wrong with it on your system and how to
> improve the change, that's be great.
> 
> Cheers,
> Richard
> 
> -- 
> Richard Levitte         levitte at openssl.org
> OpenSSL Project         http://www.openssl.org/~levitte/

> commit e10b54ca32280d9fec20085f404dcdcf2217c90e
> Author: Andy Polyakov <appro at openssl.org>
> Date:   Mon May 16 16:44:33 2016 +0200
> 
>     rand/randfile.c: remove _XOPEN_SOURCE definition.
>     
>     Defintions of macros similar to _XOPEN_SOURCE belong in command line
>     or in worst case prior first #include directive in source. As for
>     macros is was allegedly controlling. One can argue that we are
>     probably better off demanding S_IS* macros but there are systems
>     that just don't comply, hence this compromise solution...
>     
>     Reviewed-by: Rich Salz <rsalz at openssl.org>
>     (cherry picked from commit 2e6d7799ffc47604d06e0465afeb84b91aff8006)
> 
> diff --git a/crypto/rand/randfile.c b/crypto/rand/randfile.c
> index 9537c56..76bdb9a 100644
> --- a/crypto/rand/randfile.c
> +++ b/crypto/rand/randfile.c
> @@ -56,11 +56,6 @@
>   * [including the GNU Public Licence.]
>   */
>  
> -/* We need to define this to get macros like S_IFBLK and S_IFCHR */
> -#if !defined(OPENSSL_SYS_VXWORKS)
> -# define _XOPEN_SOURCE 500
> -#endif
> -
>  #include <errno.h>
>  #include <stdio.h>
>  #include <stdlib.h>
> @@ -80,6 +75,29 @@
>  #ifndef OPENSSL_NO_POSIX_IO
>  # include <sys/stat.h>
>  # include <fcntl.h>
> +/*
> + * Following should not be needed, and we could have been stricter
> + * and demand S_IS*. But some systems just don't comply... Formally
> + * below macros are "anatomically incorrect", because normally they
> + * would look like ((m) & MASK == TYPE), but since MASK availability
> + * is as questionable, we settle for this poor-man fallback...
> + */
> +# if !defined(S_ISBLK)
> +#  if defined(_S_IFBLK)
> +#   define S_ISBLK(m) ((m) & _S_IFBLK)
> +#  elif defined(S_IFBLK)
> +#   define S_ISBLK(m) ((m) & S_IFBLK)
> +#  elif defined(_WIN32)
> +#   define S_ISBLK(m) 0 /* no concept of block devices on Windows */
> +#  endif
> +# endif
> +# if !defined(S_ISCHR)
> +#  if defined(_S_IFCHR)
> +#   define S_ISCHR(m) ((m) & _S_IFCHR)
> +#  elif defined(S_IFCHR)
> +#   define S_ISCHR(m) ((m) & S_IFCHR)
> +#  endif
> +# endif
>  #endif
>  
>  #ifdef _WIN32
> @@ -151,8 +169,8 @@ int RAND_load_file(const char *file, long bytes)
>  #endif
>      if (in == NULL)
>          goto err;
> -#if defined(S_IFBLK) && defined(S_IFCHR) && !defined(OPENSSL_NO_POSIX_IO)
> -    if (sb.st_mode & (S_IFBLK | S_IFCHR)) {
> +#if defined(S_ISBLK) && defined(S_ISCHR) && !defined(OPENSSL_NO_POSIX_IO)
> +    if (S_ISBLK(sb.st_mode) || S_ISCHR(sb.st_mode)) {
>          /*
>           * this file is a device. we don't want read an infinite number of
>           * bytes from a random device, nor do we want to use buffered I/O

The patch worked.  What is next?
-- 
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
Abuse a man unjustly, and you will make friends for him.  -Edgar Watson Howe

From levitte at openssl.org  Tue May 24 15:15:52 2016
From: levitte at openssl.org (Richard Levitte)
Date: Tue, 24 May 2016 17:15:52 +0200 (CEST)
Subject: [openssl-dev] openssl 1.0.2 SNAPSHOT issue that exists since
 20160521
In-Reply-To: <20160524142412.GA6384@doctor.nl2k.ab.ca>
References: <20160524070954.GA17442@doctor.nl2k.ab.ca>
 <20160524.122602.473298129306775007.levitte@openssl.org>
 <20160524142412.GA6384@doctor.nl2k.ab.ca>
Message-ID: <20160524.171552.202172377345607274.levitte@openssl.org>

In message <20160524142412.GA6384 at doctor.nl2k.ab.ca> on Tue, 24 May 2016 08:24:12 -0600, The Doctor <doctor at doctor.nl2k.ab.ca> said:

doctor> On Tue, May 24, 2016 at 12:26:02PM +0200, Richard Levitte wrote:
doctor> > In message <20160524070954.GA17442 at doctor.nl2k.ab.ca> on Tue, 24 May 2016 01:09:55 -0600, The Doctor <doctor at doctor.nl2k.ab.ca> said:
doctor> > 
doctor> > doctor> On Mon, May 23, 2016 at 10:10:46AM +0200, Richard Levitte wrote:
doctor> > doctor> > In message <20160523070428.GA17582 at doctor.nl2k.ab.ca> on Mon, 23 May 2016 01:04:29 -0600, The Doctor <doctor at doctor.nl2k.ab.ca> said:
doctor> > doctor> > 
doctor> > doctor> > doctor> On Sun, May 22, 2016 at 06:34:26AM -0600, The Doctor wrote:
doctor> > doctor> > doctor> > 
doctor> > doctor> > doctor> > when executing
doctor> > doctor> > doctor> > 
doctor> > doctor> > doctor> > ../apps/openssl x509 -sha1 -CAcreateserial -in reqCA.ss -days 30 -req -out certCA.ss -signkey keyCA.ss -extfile CAss.cnf -extensions v3_ca 
doctor> > doctor> > doctor> > 
doctor> > doctor> > doctor> > during the test phase, it looks as if the test hangs.
doctor> > doctor> > doctor> > 
doctor> > doctor> > doctor> > Please look into this.
doctor> > doctor> > doctor> > 
doctor> > doctor> > doctor> 
doctor> > doctor> > doctor> 
doctor> > doctor> > doctor> This issue now exists in 20160523 .
doctor> > doctor> > doctor> 
doctor> > doctor> > doctor> Please look into this showstopper.
doctor> > doctor> > 
doctor> > doctor> > Can't reproduce.  I've tried on Linux (Debian bleeding edge) and
doctor> > doctor> > FreeBSD (8.4-RELEASE-p14).  However, I did it with the default config
doctor> > doctor> > (BSD-x86_64, which is what ./config gives me automagically, and no
doctor> > doctor> > extra options), please remind me of yours.
doctor> > doctor> >
doctor> > doctor> 
doctor> > doctor> All right,  what changed between 20160520 and 20160521 ?
doctor> > doctor> 
doctor> > doctor> Simple question.  That is the source of the showstopper.
doctor> > 
doctor> > I'm attaching the only change that I can think makes a difference.
doctor> > Try a 'patch -R -p1 < xopen_source.patch' and see if that changes
doctor> > anything.
doctor> > 
doctor> > I don't think we're going to back off from that change, so if you can
doctor> > help us figure out what goes wrong with it on your system and how to
doctor> > improve the change, that's be great.
doctor> > 
doctor> > Cheers,
doctor> > Richard
doctor> > 
doctor> > -- 
doctor> > Richard Levitte         levitte at openssl.org
doctor> > OpenSSL Project         http://www.openssl.org/~levitte/
doctor> 
doctor> > commit e10b54ca32280d9fec20085f404dcdcf2217c90e
doctor> > Author: Andy Polyakov <appro at openssl.org>
doctor> > Date:   Mon May 16 16:44:33 2016 +0200
doctor> > 
doctor> >     rand/randfile.c: remove _XOPEN_SOURCE definition.
doctor> >     
doctor> >     Defintions of macros similar to _XOPEN_SOURCE belong in command line
doctor> >     or in worst case prior first #include directive in source. As for
doctor> >     macros is was allegedly controlling. One can argue that we are
doctor> >     probably better off demanding S_IS* macros but there are systems
doctor> >     that just don't comply, hence this compromise solution...
doctor> >     
doctor> >     Reviewed-by: Rich Salz <rsalz at openssl.org>
doctor> >     (cherry picked from commit 2e6d7799ffc47604d06e0465afeb84b91aff8006)
doctor> > 
doctor> > diff --git a/crypto/rand/randfile.c b/crypto/rand/randfile.c
doctor> > index 9537c56..76bdb9a 100644
doctor> > --- a/crypto/rand/randfile.c
doctor> > +++ b/crypto/rand/randfile.c
doctor> > @@ -56,11 +56,6 @@
doctor> >   * [including the GNU Public Licence.]
doctor> >   */
doctor> >  
doctor> > -/* We need to define this to get macros like S_IFBLK and S_IFCHR */
doctor> > -#if !defined(OPENSSL_SYS_VXWORKS)
doctor> > -# define _XOPEN_SOURCE 500
doctor> > -#endif
doctor> > -
doctor> >  #include <errno.h>
doctor> >  #include <stdio.h>
doctor> >  #include <stdlib.h>
doctor> > @@ -80,6 +75,29 @@
doctor> >  #ifndef OPENSSL_NO_POSIX_IO
doctor> >  # include <sys/stat.h>
doctor> >  # include <fcntl.h>
doctor> > +/*
doctor> > + * Following should not be needed, and we could have been stricter
doctor> > + * and demand S_IS*. But some systems just don't comply... Formally
doctor> > + * below macros are "anatomically incorrect", because normally they
doctor> > + * would look like ((m) & MASK == TYPE), but since MASK availability
doctor> > + * is as questionable, we settle for this poor-man fallback...
doctor> > + */
doctor> > +# if !defined(S_ISBLK)
doctor> > +#  if defined(_S_IFBLK)
doctor> > +#   define S_ISBLK(m) ((m) & _S_IFBLK)
doctor> > +#  elif defined(S_IFBLK)
doctor> > +#   define S_ISBLK(m) ((m) & S_IFBLK)
doctor> > +#  elif defined(_WIN32)
doctor> > +#   define S_ISBLK(m) 0 /* no concept of block devices on Windows */
doctor> > +#  endif
doctor> > +# endif
doctor> > +# if !defined(S_ISCHR)
doctor> > +#  if defined(_S_IFCHR)
doctor> > +#   define S_ISCHR(m) ((m) & _S_IFCHR)
doctor> > +#  elif defined(S_IFCHR)
doctor> > +#   define S_ISCHR(m) ((m) & S_IFCHR)
doctor> > +#  endif
doctor> > +# endif
doctor> >  #endif
doctor> >  
doctor> >  #ifdef _WIN32
doctor> > @@ -151,8 +169,8 @@ int RAND_load_file(const char *file, long bytes)
doctor> >  #endif
doctor> >      if (in == NULL)
doctor> >          goto err;
doctor> > -#if defined(S_IFBLK) && defined(S_IFCHR) && !defined(OPENSSL_NO_POSIX_IO)
doctor> > -    if (sb.st_mode & (S_IFBLK | S_IFCHR)) {
doctor> > +#if defined(S_ISBLK) && defined(S_ISCHR) && !defined(OPENSSL_NO_POSIX_IO)
doctor> > +    if (S_ISBLK(sb.st_mode) || S_ISCHR(sb.st_mode)) {
doctor> >          /*
doctor> >           * this file is a device. we don't want read an infinite number of
doctor> >           * bytes from a random device, nor do we want to use buffered I/O
doctor> 
doctor> The patch worked.  What is next?

So I understand correctly, it works when the patch is reversed (that's
what -R does), right?  Good, that gives us a point.  However, that
commit is there for a reason, so like I said, if you can help us
figure out what goes wrong on your system, everyone will be happier.

Cheers,
Richard

-- 
Richard Levitte         levitte at openssl.org
OpenSSL Project         http://www.openssl.org/~levitte/

From rt at openssl.org  Tue May 24 15:45:08 2016
From: rt at openssl.org (Richard Levitte via RT)
Date: Tue, 24 May 2016 15:45:08 +0000
Subject: [openssl-dev] [openssl.org #4492] Configure, Unix and Linux,
	and malformed command line when path includes spaces
In-Reply-To: <CAH8yC8kfiOtg75fp06doyk3E7YwmmDV6ercVzOJaL2c5+q8tUw@mail.gmail.com>
References: <RT-Ticket-4492@openssl.org>
 <CAH8yC8kfiOtg75fp06doyk3E7YwmmDV6ercVzOJaL2c5+q8tUw@mail.gmail.com>
Message-ID: <rt-4.0.19-18315-1464104708-491.4492-6-0@openssl.org>

I just pushed a pull request that I think solves this.

https://github.com/openssl/openssl/pull/1120

Care to try it?

Cheers,
Richard

On Tue Mar 29 06:53:29 2016, noloader at gmail.com wrote:
> Unix and Linux builds have problems when the path includes spaces.
> In-tree is witnessing the issue, and out-of-tree may experience the
> issue.
>
> This problem was observed on Windows due to "C:\Program Files" and
> "C:\Documents and Settings"; see Issues 4486 and 4490. Windows uses
> UAC, which means make usually does not fails and it sprays the errant
> directories onto the filesystem.
>
> Conventional wisdom is to "don't use spaces"; however, it does not
> apply to Windows so the problem may as well be completely remediated
> since it has to be fixed under Windows.
>
> To duplicate:
>
> cd /tmp
> git clone git://git.openssl.org/openssl.git "openssl workspace"
> cd "openssl workspace"
> ./config
>
> You should encounter paths like the following on the command lines.
> Notice the include options have "-I../openssl -Iworkspace/include -I.
> -Icrypto/include -Iinclude -Icrypto/bn/workspace/crypto/include".
>
> cc -DDSO_DLFCN -DHAVE_DLFCN_H -DOPENSSL_THREADS
> -DOPENSSL_NO_DYNAMIC_ENGINE -DOPENSSL_PIC -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 -DGHASH_ASM -DECP_NISTZ256_ASM -DPOLY1305_ASM
> -DOPENSSLDIR="\"/usr/local/ssl\""
> -DENGINESDIR="\"/usr/local/lib/engines\"" -O3 -D_REENTRANT -arch
> x86_64 -DL_ENDIAN -Wall -fPIC -I../openssl -Iworkspace/include -I.
> -Icrypto/include -Iinclude -Icrypto/bn/workspace/crypto/include -MMD
> -MF crypto/aes/aes-x86_64.d.tmp -MT crypto/aes/aes-x86_64.o -c -o
> crypto/aes/aes-x86_64.o crypto/aes/aes-x86_64.s
> ...
>
> ***********
>
> I see where some of the potential problems are. I just don't have the
> requisite Perl experience to remediate them and offer a patch. Some
> other places are where $bilddir, $srcdir and $args{incs} are used.
>
> openssl workspace$ grep -R "\-I" * | egrep -iv
> 'makefile|\.conf|\.h|\.c|\.txt|\.pod|//test|test\.pl'
> Configurations/descrip.mms.tmpl: staging_instdir =
> staging_instdir - "]A.;" + ".OPENSSL-INSTALL]"
> Configurations/descrip.mms.tmpl: staging_instdir =
> staging_instdir - "A.;" + "[OPENSSL-INSTALL]"
> Configurations/descrip.mms.tmpl: $(PERL) "-I." "-Mvmsconfig" {-
> sourcefile("util", "dofile.pl") -} -
> Configurations/descrip.mms.tmpl: $(PERL) "-I." "-Mvmsconfig" {-
> sourcefile("util", "dofile.pl") -} -
> Configurations/descrip.mms.tmpl: \$(PERL) "-I\$(BUILDDIR)"
> "-Mconfigdata" $dofile -
> Configure: $withargs{zlib_include}="-I$1";
> Configure: my $cmd = "$config{perl} \"-I.\" \"-Mconfigdata\"
> $dofile -o\"Configure\" \"".join("\" \"", at templates)."\" >
> \"$out.new\"";
> ...
> test/run_tests.pl:$switches = "-w \"-I$testlib\" \"-I$utillib\"";
>


--
Richard Levitte
levitte at openssl.org

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


From rt at openssl.org  Tue May 24 15:46:07 2016
From: rt at openssl.org (Richard Levitte via RT)
Date: Tue, 24 May 2016 15:46:07 +0000
Subject: [openssl-dev] [openssl.org #4486] PATCH: fix NMAKE fatal error
	U1073: "don't know how to make
	'LNAME\openssl\Configurations\windows-makefile.tmpl'"
In-Reply-To: <CAH8yC8ku7J0G4UGQ2vx=c19_XjCFpSdpUbApHm_4W2HwuDmGpg@mail.gmail.com>
References: <RT-Ticket-4486@openssl.org>
 <CAH8yC8ku7J0G4UGQ2vx=c19_XjCFpSdpUbApHm_4W2HwuDmGpg@mail.gmail.com>
Message-ID: <rt-4.0.19-23362-1464104767-869.4486-6-0@openssl.org>

I'm surprised so little is needed... Does it, combined with my fix for 4492?

Cheers,
Richard

On Sun Mar 27 13:29:37 2016, noloader at gmail.com wrote:
> Using Strawberry PERL from a typical Windows user desktop and working
> from Master at c828cd7...
>
> > cls && perl Configure VC-WIN32
> ...
>
> > nmake
> Microsoft (R) Program Maintenance Utility Version 11.00.61030.0
> Copyright (C) Microsoft Corporation. All rights reserved.
>
> NMAKE : fatal error U1073: don't know how to make
> 'LNAME\openssl\Configurations
> \windows-makefile.tmpl'
> Stop.
>
> $ git diff
> diff --git a/Configurations/windows-makefile.tmpl
> b/Configurations/windows-makefile.tmpl
> index 0b8ac72..6f97315 100644
> --- a/Configurations/windows-makefile.tmpl
> +++ b/Configurations/windows-makefile.tmpl
> @@ -218,7 +218,7 @@ uninstall_runtime:
>
> # Building targets ###################################################
>
> -configdata.pm: {- $config{build_file_template} -} $(SRCDIR)\Configure
> +configdata.pm: "{- $config{build_file_template} -}"
> $(SRCDIR)\Configure
> @echo "Detected changed: $?"
> @echo "Reconfiguring..."
> $(PERL) $(SRCDIR)\Configure reconf
>
> **********
>
> After patching:
>
> > nmake
>
> Microsoft (R) Program Maintenance Utility Version 11.00.61030.0
> Copyright (C) Microsoft Corporation. All rights reserved.
>
> nasm -f win32 -ocrypto\aes\aes-586.obj crypto\aes\aes-586.asm
> cl -DDSO_WIN32 -DOPENSSL_THREADS -DOPENSSL_NO_DYNAMIC_ENGINE
> -DOPENSSL_P
> IC -DOPENSSL_BN_ASM_PART_WORDS -DOPENSSL_IA32_SSE2
> -DOPENSSL_BN_ASM_MONT -DOPENS
> SL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM
> -DRMD160_ASM -DAES
> _ASM -DVPAES_ASM -DWHIRLPOOL_ASM -DGHASH_ASM -DECP_NISTZ256_ASM
> -DPOLY1305_ASM "
> -DENGINESDIR=\"%ProgramFiles(x86)%\\OpenSSL\\lib\\engines\"" "-
> DOPENSSLDIR=\"%Co
> mmonProgramFiles(x86)%\\SSL\"" -W3 -wd4090 -Gs0 -GF -Gy -nologo
> -DOPENSSL_SYS_WI
> N32 -DWIN32_LEAN_AND_MEAN -DL_ENDIAN -D_CRT_SECURE_NO_DEPRECATE
> -DUNICODE -D_UNI
> CODE /MT /Ox /O2 /Ob2 /Zl /Zi /Fdlib -D_WINDLL /I ..\..\Jeffrey /I
> Walton\openss
> l\include /I . /I crypto\include /I include /I
> crypto\bn\Walton\openssl\crypto\i
> nclude -c /Focrypto\aes\aes_cfb.obj crypto\aes\aes_cfb.c
> aes_cfb.c
> cl -DDSO_WIN32 -DOPENSSL_THREADS -DOPENSSL_NO_DYNAMIC_ENGINE
> -DOPENSSL_P
> IC -DOPENSSL_BN_ASM_PART_WORDS -DOPENSSL_IA32_SSE2
> -DOPENSSL_BN_ASM_MONT -DOPENS
> SL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM
> -DRMD160_ASM -DAES
> _ASM -DVPAES_ASM -DWHIRLPOOL_ASM -DGHASH_ASM -DECP_NISTZ256_ASM
> -DPOLY1305_ASM "
> -DENGINESDIR=\"%ProgramFiles(x86)%\\OpenSSL\\lib\\engines\"" "-
> DOPENSSLDIR=\"%Co
> mmonProgramFiles(x86)%\\SSL\"" -W3 -wd4090 -Gs0 -GF -Gy -nologo
> -DOPENSSL_SYS_WI
> N32 -DWIN32_LEAN_AND_MEAN -DL_ENDIAN -D_CRT_SECURE_NO_DEPRECATE
> -DUNICODE -D_UNI
> CODE /MT /Ox /O2 /Ob2 /Zl /Zi /Fdlib -D_WINDLL /I ..\..\Jeffrey /I
> Walton\openss
> l\include /I . /I crypto\include /I include /I
> crypto\bn\Walton\openssl\crypto\i
> nclude -c /Focrypto\aes\aes_ecb.obj crypto\aes\aes_ecb.c
> aes_ecb.c
>
> ...


--
Richard Levitte
levitte at openssl.org

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


From doctor at doctor.nl2k.ab.ca  Tue May 24 15:44:57 2016
From: doctor at doctor.nl2k.ab.ca (The Doctor)
Date: Tue, 24 May 2016 09:44:57 -0600
Subject: [openssl-dev] openssl 1.0.2 SNAPSHOT issue that exists since
 20160521
In-Reply-To: <20160524.171552.202172377345607274.levitte@openssl.org>
References: <20160524070954.GA17442@doctor.nl2k.ab.ca>
 <20160524.122602.473298129306775007.levitte@openssl.org>
 <20160524142412.GA6384@doctor.nl2k.ab.ca>
 <20160524.171552.202172377345607274.levitte@openssl.org>
Message-ID: <20160524154456.GA23031@doctor.nl2k.ab.ca>

On Tue, May 24, 2016 at 05:15:52PM +0200, Richard Levitte wrote:
> In message <20160524142412.GA6384 at doctor.nl2k.ab.ca> on Tue, 24 May 2016 08:24:12 -0600, The Doctor <doctor at doctor.nl2k.ab.ca> said:
> 
> doctor> On Tue, May 24, 2016 at 12:26:02PM +0200, Richard Levitte wrote:
> doctor> > In message <20160524070954.GA17442 at doctor.nl2k.ab.ca> on Tue, 24 May 2016 01:09:55 -0600, The Doctor <doctor at doctor.nl2k.ab.ca> said:
> doctor> > 
> doctor> > doctor> On Mon, May 23, 2016 at 10:10:46AM +0200, Richard Levitte wrote:
> doctor> > doctor> > In message <20160523070428.GA17582 at doctor.nl2k.ab.ca> on Mon, 23 May 2016 01:04:29 -0600, The Doctor <doctor at doctor.nl2k.ab.ca> said:
> doctor> > doctor> > 
> doctor> > doctor> > doctor> On Sun, May 22, 2016 at 06:34:26AM -0600, The Doctor wrote:
> doctor> > doctor> > doctor> > 
> doctor> > doctor> > doctor> > when executing
> doctor> > doctor> > doctor> > 
> doctor> > doctor> > doctor> > ../apps/openssl x509 -sha1 -CAcreateserial -in reqCA.ss -days 30 -req -out certCA.ss -signkey keyCA.ss -extfile CAss.cnf -extensions v3_ca 
> doctor> > doctor> > doctor> > 
> doctor> > doctor> > doctor> > during the test phase, it looks as if the test hangs.
> doctor> > doctor> > doctor> > 
> doctor> > doctor> > doctor> > Please look into this.
> doctor> > doctor> > doctor> > 
> doctor> > doctor> > doctor> 
> doctor> > doctor> > doctor> 
> doctor> > doctor> > doctor> This issue now exists in 20160523 .
> doctor> > doctor> > doctor> 
> doctor> > doctor> > doctor> Please look into this showstopper.
> doctor> > doctor> > 
> doctor> > doctor> > Can't reproduce.  I've tried on Linux (Debian bleeding edge) and
> doctor> > doctor> > FreeBSD (8.4-RELEASE-p14).  However, I did it with the default config
> doctor> > doctor> > (BSD-x86_64, which is what ./config gives me automagically, and no
> doctor> > doctor> > extra options), please remind me of yours.
> doctor> > doctor> >
> doctor> > doctor> 
> doctor> > doctor> All right,  what changed between 20160520 and 20160521 ?
> doctor> > doctor> 
> doctor> > doctor> Simple question.  That is the source of the showstopper.
> doctor> > 
> doctor> > I'm attaching the only change that I can think makes a difference.
> doctor> > Try a 'patch -R -p1 < xopen_source.patch' and see if that changes
> doctor> > anything.
> doctor> > 
> doctor> > I don't think we're going to back off from that change, so if you can
> doctor> > help us figure out what goes wrong with it on your system and how to
> doctor> > improve the change, that's be great.
> doctor> > 
> doctor> > Cheers,
> doctor> > Richard
> doctor> > 
> doctor> > -- 
> doctor> > Richard Levitte         levitte at openssl.org
> doctor> > OpenSSL Project         http://www.openssl.org/~levitte/
> doctor> 
> doctor> > commit e10b54ca32280d9fec20085f404dcdcf2217c90e
> doctor> > Author: Andy Polyakov <appro at openssl.org>
> doctor> > Date:   Mon May 16 16:44:33 2016 +0200
> doctor> > 
> doctor> >     rand/randfile.c: remove _XOPEN_SOURCE definition.
> doctor> >     
> doctor> >     Defintions of macros similar to _XOPEN_SOURCE belong in command line
> doctor> >     or in worst case prior first #include directive in source. As for
> doctor> >     macros is was allegedly controlling. One can argue that we are
> doctor> >     probably better off demanding S_IS* macros but there are systems
> doctor> >     that just don't comply, hence this compromise solution...
> doctor> >     
> doctor> >     Reviewed-by: Rich Salz <rsalz at openssl.org>
> doctor> >     (cherry picked from commit 2e6d7799ffc47604d06e0465afeb84b91aff8006)
> doctor> > 
> doctor> > diff --git a/crypto/rand/randfile.c b/crypto/rand/randfile.c
> doctor> > index 9537c56..76bdb9a 100644
> doctor> > --- a/crypto/rand/randfile.c
> doctor> > +++ b/crypto/rand/randfile.c
> doctor> > @@ -56,11 +56,6 @@
> doctor> >   * [including the GNU Public Licence.]
> doctor> >   */
> doctor> >  
> doctor> > -/* We need to define this to get macros like S_IFBLK and S_IFCHR */
> doctor> > -#if !defined(OPENSSL_SYS_VXWORKS)
> doctor> > -# define _XOPEN_SOURCE 500
> doctor> > -#endif
> doctor> > -
> doctor> >  #include <errno.h>
> doctor> >  #include <stdio.h>
> doctor> >  #include <stdlib.h>
> doctor> > @@ -80,6 +75,29 @@
> doctor> >  #ifndef OPENSSL_NO_POSIX_IO
> doctor> >  # include <sys/stat.h>
> doctor> >  # include <fcntl.h>
> doctor> > +/*
> doctor> > + * Following should not be needed, and we could have been stricter
> doctor> > + * and demand S_IS*. But some systems just don't comply... Formally
> doctor> > + * below macros are "anatomically incorrect", because normally they
> doctor> > + * would look like ((m) & MASK == TYPE), but since MASK availability
> doctor> > + * is as questionable, we settle for this poor-man fallback...
> doctor> > + */
> doctor> > +# if !defined(S_ISBLK)
> doctor> > +#  if defined(_S_IFBLK)
> doctor> > +#   define S_ISBLK(m) ((m) & _S_IFBLK)
> doctor> > +#  elif defined(S_IFBLK)
> doctor> > +#   define S_ISBLK(m) ((m) & S_IFBLK)
> doctor> > +#  elif defined(_WIN32)
> doctor> > +#   define S_ISBLK(m) 0 /* no concept of block devices on Windows */
> doctor> > +#  endif
> doctor> > +# endif
> doctor> > +# if !defined(S_ISCHR)
> doctor> > +#  if defined(_S_IFCHR)
> doctor> > +#   define S_ISCHR(m) ((m) & _S_IFCHR)
> doctor> > +#  elif defined(S_IFCHR)
> doctor> > +#   define S_ISCHR(m) ((m) & S_IFCHR)
> doctor> > +#  endif
> doctor> > +# endif
> doctor> >  #endif
> doctor> >  
> doctor> >  #ifdef _WIN32
> doctor> > @@ -151,8 +169,8 @@ int RAND_load_file(const char *file, long bytes)
> doctor> >  #endif
> doctor> >      if (in == NULL)
> doctor> >          goto err;
> doctor> > -#if defined(S_IFBLK) && defined(S_IFCHR) && !defined(OPENSSL_NO_POSIX_IO)
> doctor> > -    if (sb.st_mode & (S_IFBLK | S_IFCHR)) {
> doctor> > +#if defined(S_ISBLK) && defined(S_ISCHR) && !defined(OPENSSL_NO_POSIX_IO)
> doctor> > +    if (S_ISBLK(sb.st_mode) || S_ISCHR(sb.st_mode)) {
> doctor> >          /*
> doctor> >           * this file is a device. we don't want read an infinite number of
> doctor> >           * bytes from a random device, nor do we want to use buffered I/O
> doctor> 
> doctor> The patch worked.  What is next?
> 
> So I understand correctly, it works when the patch is reversed (that's
> what -R does), right?  Good, that gives us a point.  However, that
> commit is there for a reason, so like I said, if you can help us
> figure out what goes wrong on your system, everyone will be happier.
>

All right, what if you are using egd instead of rnadomd ?
 
> Cheers,
> Richard
> 
> -- 
> Richard Levitte         levitte at openssl.org
> OpenSSL Project         http://www.openssl.org/~levitte/

-- 
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
Abuse a man unjustly, and you will make friends for him.  -Edgar Watson Howe

From levitte at openssl.org  Tue May 24 21:47:21 2016
From: levitte at openssl.org (Richard Levitte)
Date: Tue, 24 May 2016 23:47:21 +0200 (CEST)
Subject: [openssl-dev] openssl 1.0.2 SNAPSHOT issue that exists since
 20160521
In-Reply-To: <20160524154456.GA23031@doctor.nl2k.ab.ca>
References: <20160524142412.GA6384@doctor.nl2k.ab.ca>
 <20160524.171552.202172377345607274.levitte@openssl.org>
 <20160524154456.GA23031@doctor.nl2k.ab.ca>
Message-ID: <20160524.234721.1707321726956402227.levitte@openssl.org>

In message <20160524154456.GA23031 at doctor.nl2k.ab.ca> on Tue, 24 May 2016 09:44:57 -0600, The Doctor <doctor at doctor.nl2k.ab.ca> said:

doctor> On Tue, May 24, 2016 at 05:15:52PM +0200, Richard Levitte wrote:
doctor> > So I understand correctly, it works when the patch is reversed (that's
doctor> > what -R does), right?  Good, that gives us a point.  However, that
doctor> > commit is there for a reason, so like I said, if you can help us
doctor> > figure out what goes wrong on your system, everyone will be happier.
doctor> >
doctor> 
doctor> All right, what if you are using egd instead of rnadomd ?

How exactly do you mean?

Side note: it feels like you're playing the guessing game with me.  My
patience for that is running thin.  Please give me details.  In the
end, helping us is helping yourself, as we don't have any BSDi system
to try things on ourselves.

-- 
Richard Levitte         levitte at openssl.org
OpenSSL Project         http://www.openssl.org/~levitte/

From rt at openssl.org  Tue May 24 21:51:34 2016
From: rt at openssl.org (Matt Caswell via RT)
Date: Tue, 24 May 2016 21:51:34 +0000
Subject: [openssl-dev] [openssl.org #2021] sni bug
In-Reply-To: <4A942BF3.90905@edelweb.fr>
References: <RT-Ticket-2021@openssl.org> <4A942BF3.90905@edelweb.fr>
Message-ID: <rt-4.0.19-23362-1464126694-1381.2021-6-0@openssl.org>

The code in this area has changed significantly so it is far from clear whether
this report is still relevant. Therefore closing. Please open a new ticket if
required.

Matt

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


From rt at openssl.org  Tue May 24 21:55:04 2016
From: rt at openssl.org (Matt Caswell via RT)
Date: Tue, 24 May 2016 21:55:04 +0000
Subject: [openssl-dev] [openssl.org #2290] [PATCH 2/3] apps/speed: fix
	digest speed measurement and add hmac-sha1 test
In-Reply-To: <1276077246-17849-2-git-send-email-timo.teras@iki.fi>
References: <RT-Ticket-2290@openssl.org>
 <1276077246-17849-1-git-send-email-timo.teras@iki.fi>
 <1276077246-17849-2-git-send-email-timo.teras@iki.fi>
Message-ID: <rt-4.0.19-23362-1464126904-1555.2290-6-0@openssl.org>

The code has moved on too much for this patch to be applicable. Closing this.

Matt

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


From rt at openssl.org  Tue May 24 22:08:54 2016
From: rt at openssl.org (Matt Caswell via RT)
Date: Tue, 24 May 2016 22:08:54 +0000
Subject: [openssl-dev] [openssl.org #1971] [PATCH 09/14] Only test speeds up
	to 4K packets.
In-Reply-To: <20090630051245.GA5685@securecomputing.com>
References: <RT-Ticket-1971@openssl.org>
 <20090630051245.GA5685@securecomputing.com>
Message-ID: <rt-4.0.19-23362-1464127734-611.1971-6-0@openssl.org>

We're not going to do this. Closing.

Matt

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


From rt at openssl.org  Tue May 24 22:11:52 2016
From: rt at openssl.org (Matt Caswell via RT)
Date: Tue, 24 May 2016 22:11:52 +0000
Subject: [openssl-dev] [openssl.org #2257] CVS HEAD: [quite probable] bug in
	ssl3_write: does not indirect through callback like it
	sibling ssl3_read
In-Reply-To: <t2w561cc61d1004301930y9176fb73m6b9e35524105c91d@mail.gmail.com>
References: <RT-Ticket-2257@openssl.org>
 <t2w561cc61d1004301930y9176fb73m6b9e35524105c91d@mail.gmail.com>
Message-ID: <rt-4.0.19-23362-1464127912-380.2257-6-0@openssl.org>

Someone already made this change. Closing.

Matt

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


From rt at openssl.org  Tue May 24 22:31:25 2016
From: rt at openssl.org (Matt Caswell via RT)
Date: Tue, 24 May 2016 22:31:25 +0000
Subject: [openssl-dev] [openssl.org #1878] [PATCH] Fix RSA blinding locking
	hole
In-Reply-To: <200904011321.04549.haisenko@comdasys.com>
References: <RT-Ticket-1878@openssl.org>
 <200904011321.04549.haisenko@comdasys.com>
Message-ID: <rt-4.0.19-23362-1464129085-947.1878-6-0@openssl.org>

It is unclear whether this is still an issue. The code looks quite a bit
different in master and I suspect things have moved on. Given the age of this
ticket I think it should be closed and a new one opened if this issue
resurfaces.

Matt

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


From rt at openssl.org  Tue May 24 22:36:48 2016
From: rt at openssl.org (Matt Caswell via RT)
Date: Tue, 24 May 2016 22:36:48 +0000
Subject: [openssl-dev] [openssl.org #2289] [PATCH 1/3] crypto/hmac: support
	EVP_MD_CTX_FLAG_ONESHOT and set it properly
In-Reply-To: <1276077246-17849-1-git-send-email-timo.teras@iki.fi>
References: <RT-Ticket-2289@openssl.org>
 <1276077246-17849-1-git-send-email-timo.teras@iki.fi>
Message-ID: <rt-4.0.19-23362-1464129408-1114.2289-6-0@openssl.org>

No movement on this in 6 years. Doesn't look like this is going to happen.
Closing.

Matt

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


From rt at openssl.org  Tue May 24 22:39:06 2016
From: rt at openssl.org (Matt Caswell via RT)
Date: Tue, 24 May 2016 22:39:06 +0000
Subject: [openssl-dev] [openssl.org #4342] few missing malloc return checks
	and free in error paths
In-Reply-To: <CA+LSdEiZs1ZFzxJm=bdw0jwGZzqpHE6r06h1ep3Ux7miDqKPiQ@mail.gmail.com>
References: <RT-Ticket-4342@openssl.org>
 <CA+LSdEiZs1ZFzxJm=bdw0jwGZzqpHE6r06h1ep3Ux7miDqKPiQ@mail.gmail.com>
Message-ID: <rt-4.0.19-23362-1464129546-1236.4342-6-0@openssl.org>

This got merged recently. Closing.

Matt

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


From rt at openssl.org  Tue May 24 22:42:16 2016
From: rt at openssl.org (Matt Caswell via RT)
Date: Tue, 24 May 2016 22:42:16 +0000
Subject: [openssl-dev] [openssl.org #4379] "arch/async_posix.h:67:24: error:
	ucontext.h: No such file or directory" under OpenBSD 5.7/64-bit
In-Reply-To: <rt-4.0.19-5499-1462962271-1315.4379-6-0@openssl.org>
References: <RT-Ticket-4379@openssl.org>
 <CAH8yC8k=3OzYiZD3FZ=DpaLB2iLt3SFGRxhR1=ed2_Sw2OthhQ@mail.gmail.com>
 <rt-4.0.19-5499-1462962271-1315.4379-6-0@openssl.org>
Message-ID: <rt-4.0.19-18315-1464129736-580.4379-6-0@openssl.org>

On Wed May 11 10:24:31 2016, matt wrote:
> Hi Jeff
>
> Please could you try the attached patch?

Hi Jeff

Were you able to try out the patch?

Thanks

Matt

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


From rt at openssl.org  Tue May 24 22:43:42 2016
From: rt at openssl.org (Matt Caswell via RT)
Date: Tue, 24 May 2016 22:43:42 +0000
Subject: [openssl-dev] [openssl.org #4537] [PATCH] Fix a NULL dereference in
	chacha20_poly1305_init_key()
In-Reply-To: <20160510115034.17859-1-k@rhe.jp>
References: <RT-Ticket-4537@openssl.org> <20160510115034.17859-1-k@rhe.jp>
Message-ID: <rt-4.0.19-23362-1464129822-519.4537-6-0@openssl.org>

This got merged recently. Closing.

Matt

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


From rt at openssl.org  Tue May 24 22:44:41 2016
From: rt at openssl.org (Matt Caswell via RT)
Date: Tue, 24 May 2016 22:44:41 +0000
Subject: [openssl-dev] [openssl.org #4525] [PATCH] SRP client key
	computation (PR #1017)
In-Reply-To: <CACO4KgY_LsSH3w+vKcK4GdjaaRdMDwAwGQ0UdCFJ6xBLpJwDnQ@mail.gmail.com>
References: <RT-Ticket-4525@openssl.org>
 <CACO4KgY_LsSH3w+vKcK4GdjaaRdMDwAwGQ0UdCFJ6xBLpJwDnQ@mail.gmail.com>
Message-ID: <rt-4.0.19-23362-1464129881-852.4525-6-0@openssl.org>

This got merged recently. Closing.

Matt

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


From rt at openssl.org  Tue May 24 22:47:18 2016
From: rt at openssl.org (Matt Caswell via RT)
Date: Tue, 24 May 2016 22:47:18 +0000
Subject: [openssl-dev] [openssl.org #4430] #1852: [BUG] Invalid Proxy
	Certificates Pass Validation
In-Reply-To: <630646519.2108403.1457973490945.JavaMail.yahoo@mail.yahoo.com>
References: <RT-Ticket-4430@openssl.org>
 <630646519.2108403.1457973490945.JavaMail.yahoo.ref@mail.yahoo.com>
 <630646519.2108403.1457973490945.JavaMail.yahoo@mail.yahoo.com>
Message-ID: <rt-4.0.19-23362-1464130038-1749.4430-6-0@openssl.org>

This ticket was opened in error. The correct ticket that remains open is #1852.
Closing,.

Matt

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


From rt at openssl.org  Tue May 24 23:04:50 2016
From: rt at openssl.org (Richard Levitte via RT)
Date: Tue, 24 May 2016 23:04:50 +0000
Subject: [openssl-dev] [openssl.org #1852] [BUG] Invalid Proxy Certificates
	Pass Validation
In-Reply-To: <rt-4.0.19-27464-1454507625-794.1852-6-0@openssl.org>
References: <RT-Ticket-1852@openssl.org> <49A81357.30509@switch.ch>
 <rt-4.0.19-27464-1454507625-794.1852-6-0@openssl.org>
Message-ID: <rt-4.0.19-23362-1464131089-1951.1852-6-0@openssl.org>

I think we should. I have something half baked that Im playing with...

Cheers,
Richard

On Wed Feb 03 13:53:45 2016, rsalz wrote:
> Re-opening it. It would be good to decide soon if we should do this.

--
Richard Levitte
levitte at openssl.org

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


From doctor at doctor.nl2k.ab.ca  Wed May 25 00:38:55 2016
From: doctor at doctor.nl2k.ab.ca (The Doctor)
Date: Tue, 24 May 2016 18:38:55 -0600
Subject: [openssl-dev] openssl 1.0.2 SNAPSHOT issue that exists since
 20160521
In-Reply-To: <20160524.234721.1707321726956402227.levitte@openssl.org>
References: <20160524142412.GA6384@doctor.nl2k.ab.ca>
 <20160524.171552.202172377345607274.levitte@openssl.org>
 <20160524154456.GA23031@doctor.nl2k.ab.ca>
 <20160524.234721.1707321726956402227.levitte@openssl.org>
Message-ID: <20160525003855.GB12475@doctor.nl2k.ab.ca>

On Tue, May 24, 2016 at 11:47:21PM +0200, Richard Levitte wrote:
> In message <20160524154456.GA23031 at doctor.nl2k.ab.ca> on Tue, 24 May 2016 09:44:57 -0600, The Doctor <doctor at doctor.nl2k.ab.ca> said:
> 
> doctor> On Tue, May 24, 2016 at 05:15:52PM +0200, Richard Levitte wrote:
> doctor> > So I understand correctly, it works when the patch is reversed (that's
> doctor> > what -R does), right?  Good, that gives us a point.  However, that
> doctor> > commit is there for a reason, so like I said, if you can help us
> doctor> > figure out what goes wrong on your system, everyone will be happier.
> doctor> >
> doctor> 
> doctor> All right, what if you are using egd instead of rnadomd ?
> 
> How exactly do you mean?
>

Usually I use egd as the Randomd just does not 
perform to expectation.  Randomd does not act stable here.
 
> Side note: it feels like you're playing the guessing game with me.  My
> patience for that is running thin.  Please give me details.  In the
> end, helping us is helping yourself, as we don't have any BSDi system
> to try things on ourselves.
> 
> -- 
> Richard Levitte         levitte at openssl.org
> OpenSSL Project         http://www.openssl.org/~levitte/

-- 
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
Abuse a man unjustly, and you will make friends for him.  -Edgar Watson Howe

From rt at openssl.org  Wed May 25 10:00:40 2016
From: rt at openssl.org (Richard Levitte via RT)
Date: Wed, 25 May 2016 10:00:40 +0000
Subject: [openssl-dev] [openssl.org #4492] Configure, Unix and Linux,
	and malformed command line when path includes spaces
In-Reply-To: <rt-4.0.19-18315-1464104708-693.4492-6-0@openssl.org>
References: <RT-Ticket-4492@openssl.org>
 <CAH8yC8kfiOtg75fp06doyk3E7YwmmDV6ercVzOJaL2c5+q8tUw@mail.gmail.com>
 <rt-4.0.19-18315-1464104708-693.4492-6-0@openssl.org>
Message-ID: <rt-4.0.19-18315-1464170440-1981.4492-6-0@openssl.org>

That has now made it to master.

Closing ticket, submit a new ticket if you find further issues.

Cheers,
Richard

On Tue May 24 15:45:08 2016, levitte wrote:
> I just pushed a pull request that I think solves this.
>
> https://github.com/openssl/openssl/pull/1120
>
> Care to try it?
>
> Cheers,
> Richard
>
> On Tue Mar 29 06:53:29 2016, noloader at gmail.com wrote:
> > Unix and Linux builds have problems when the path includes spaces.
> > In-tree is witnessing the issue, and out-of-tree may experience the
> > issue.
> >
> > This problem was observed on Windows due to "C:\Program Files" and
> > "C:\Documents and Settings"; see Issues 4486 and 4490. Windows uses
> > UAC, which means make usually does not fails and it sprays the errant
> > directories onto the filesystem.
> >
> > Conventional wisdom is to "don't use spaces"; however, it does not
> > apply to Windows so the problem may as well be completely remediated
> > since it has to be fixed under Windows.
> >
> > To duplicate:
> >
> > cd /tmp
> > git clone git://git.openssl.org/openssl.git "openssl workspace"
> > cd "openssl workspace"
> > ./config
> >
> > You should encounter paths like the following on the command lines.
> > Notice the include options have "-I../openssl -Iworkspace/include -I.
> > -Icrypto/include -Iinclude -Icrypto/bn/workspace/crypto/include".
> >
> > cc -DDSO_DLFCN -DHAVE_DLFCN_H -DOPENSSL_THREADS
> > -DOPENSSL_NO_DYNAMIC_ENGINE -DOPENSSL_PIC -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 -DGHASH_ASM -DECP_NISTZ256_ASM -DPOLY1305_ASM
> > -DOPENSSLDIR="\"/usr/local/ssl\""
> > -DENGINESDIR="\"/usr/local/lib/engines\"" -O3 -D_REENTRANT -arch
> > x86_64 -DL_ENDIAN -Wall -fPIC -I../openssl -Iworkspace/include -I.
> > -Icrypto/include -Iinclude -Icrypto/bn/workspace/crypto/include -MMD
> > -MF crypto/aes/aes-x86_64.d.tmp -MT crypto/aes/aes-x86_64.o -c -o
> > crypto/aes/aes-x86_64.o crypto/aes/aes-x86_64.s
> > ...
> >
> > ***********
> >
> > I see where some of the potential problems are. I just don't have the
> > requisite Perl experience to remediate them and offer a patch. Some
> > other places are where $bilddir, $srcdir and $args{incs} are used.
> >
> > openssl workspace$ grep -R "\-I" * | egrep -iv
> > 'makefile|\.conf|\.h|\.c|\.txt|\.pod|//test|test\.pl'
> > Configurations/descrip.mms.tmpl: staging_instdir =
> > staging_instdir - "]A.;" + ".OPENSSL-INSTALL]"
> > Configurations/descrip.mms.tmpl: staging_instdir =
> > staging_instdir - "A.;" + "[OPENSSL-INSTALL]"
> > Configurations/descrip.mms.tmpl: $(PERL) "-I." "-Mvmsconfig" {-
> > sourcefile("util", "dofile.pl") -} -
> > Configurations/descrip.mms.tmpl: $(PERL) "-I." "-Mvmsconfig" {-
> > sourcefile("util", "dofile.pl") -} -
> > Configurations/descrip.mms.tmpl: \$(PERL) "-I\$(BUILDDIR)"
> > "-Mconfigdata" $dofile -
> > Configure: $withargs{zlib_include}="-I$1";
> > Configure: my $cmd = "$config{perl} \"-I.\" \"-Mconfigdata\"
> > $dofile -o\"Configure\" \"".join("\" \"", at templates)."\" >
> > \"$out.new\"";
> > ...
> > test/run_tests.pl:$switches = "-w \"-I$testlib\" \"-I$utillib\"";
> >
>
>
> --
> Richard Levitte
> levitte at openssl.org


--
Richard Levitte
levitte at openssl.org

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


From rt at openssl.org  Wed May 25 11:39:11 2016
From: rt at openssl.org (Richard Levitte via RT)
Date: Wed, 25 May 2016 11:39:11 +0000
Subject: [openssl-dev] [openssl.org #4486] PATCH: fix NMAKE fatal error
	U1073: "don't know how to make
	'LNAME\openssl\Configurations\windows-makefile.tmpl'"
In-Reply-To: <rt-4.0.19-23362-1464104767-1468.4486-6-0@openssl.org>
References: <RT-Ticket-4486@openssl.org>
 <CAH8yC8ku7J0G4UGQ2vx=c19_XjCFpSdpUbApHm_4W2HwuDmGpg@mail.gmail.com>
 <rt-4.0.19-23362-1464104767-1468.4486-6-0@openssl.org>
Message-ID: <rt-4.0.19-23362-1464176351-1598.4486-6-0@openssl.org>

Now that 4492 was closed, I could give this a go... and no, the proposed patch
wasn't enough, there were a few more places that needed extra quotes.

https://github.com/openssl/openssl/pull/1125

Cheers,
Richard

On Tue May 24 15:46:07 2016, levitte wrote:
> I'm surprised so little is needed... Does it, combined with my fix for 4492?
>
> Cheers,
> Richard
>
> On Sun Mar 27 13:29:37 2016, noloader at gmail.com wrote:
> > Using Strawberry PERL from a typical Windows user desktop and working
> > from Master at c828cd7...
> >
> > > cls && perl Configure VC-WIN32
> > ...
> >
> > > nmake
> > Microsoft (R) Program Maintenance Utility Version 11.00.61030.0
> > Copyright (C) Microsoft Corporation. All rights reserved.
> >
> > NMAKE : fatal error U1073: don't know how to make
> > 'LNAME\openssl\Configurations
> > \windows-makefile.tmpl'
> > Stop.
> >
> > $ git diff
> > diff --git a/Configurations/windows-makefile.tmpl
> > b/Configurations/windows-makefile.tmpl
> > index 0b8ac72..6f97315 100644
> > --- a/Configurations/windows-makefile.tmpl
> > +++ b/Configurations/windows-makefile.tmpl
> > @@ -218,7 +218,7 @@ uninstall_runtime:
> >
> > # Building targets ###################################################
> >
> > -configdata.pm: {- $config{build_file_template} -} $(SRCDIR)\Configure
> > +configdata.pm: "{- $config{build_file_template} -}"
> > $(SRCDIR)\Configure
> > @echo "Detected changed: $?"
> > @echo "Reconfiguring..."
> > $(PERL) $(SRCDIR)\Configure reconf
> >
> > **********
> >
> > After patching:
> >
> > > nmake
> >
> > Microsoft (R) Program Maintenance Utility Version 11.00.61030.0
> > Copyright (C) Microsoft Corporation. All rights reserved.
> >
> > nasm -f win32 -ocrypto\aes\aes-586.obj crypto\aes\aes-586.asm
> > cl -DDSO_WIN32 -DOPENSSL_THREADS -DOPENSSL_NO_DYNAMIC_ENGINE
> > -DOPENSSL_P
> > IC -DOPENSSL_BN_ASM_PART_WORDS -DOPENSSL_IA32_SSE2
> > -DOPENSSL_BN_ASM_MONT -DOPENS
> > SL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM
> > -DRMD160_ASM -DAES
> > _ASM -DVPAES_ASM -DWHIRLPOOL_ASM -DGHASH_ASM -DECP_NISTZ256_ASM
> > -DPOLY1305_ASM "
> > -DENGINESDIR=\"%ProgramFiles(x86)%\\OpenSSL\\lib\\engines\"" "-
> > DOPENSSLDIR=\"%Co
> > mmonProgramFiles(x86)%\\SSL\"" -W3 -wd4090 -Gs0 -GF -Gy -nologo
> > -DOPENSSL_SYS_WI
> > N32 -DWIN32_LEAN_AND_MEAN -DL_ENDIAN -D_CRT_SECURE_NO_DEPRECATE
> > -DUNICODE -D_UNI
> > CODE /MT /Ox /O2 /Ob2 /Zl /Zi /Fdlib -D_WINDLL /I ..\..\Jeffrey /I
> > Walton\openss
> > l\include /I . /I crypto\include /I include /I
> > crypto\bn\Walton\openssl\crypto\i
> > nclude -c /Focrypto\aes\aes_cfb.obj crypto\aes\aes_cfb.c
> > aes_cfb.c
> > cl -DDSO_WIN32 -DOPENSSL_THREADS -DOPENSSL_NO_DYNAMIC_ENGINE
> > -DOPENSSL_P
> > IC -DOPENSSL_BN_ASM_PART_WORDS -DOPENSSL_IA32_SSE2
> > -DOPENSSL_BN_ASM_MONT -DOPENS
> > SL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM
> > -DRMD160_ASM -DAES
> > _ASM -DVPAES_ASM -DWHIRLPOOL_ASM -DGHASH_ASM -DECP_NISTZ256_ASM
> > -DPOLY1305_ASM "
> > -DENGINESDIR=\"%ProgramFiles(x86)%\\OpenSSL\\lib\\engines\"" "-
> > DOPENSSLDIR=\"%Co
> > mmonProgramFiles(x86)%\\SSL\"" -W3 -wd4090 -Gs0 -GF -Gy -nologo
> > -DOPENSSL_SYS_WI
> > N32 -DWIN32_LEAN_AND_MEAN -DL_ENDIAN -D_CRT_SECURE_NO_DEPRECATE
> > -DUNICODE -D_UNI
> > CODE /MT /Ox /O2 /Ob2 /Zl /Zi /Fdlib -D_WINDLL /I ..\..\Jeffrey /I
> > Walton\openss
> > l\include /I . /I crypto\include /I include /I
> > crypto\bn\Walton\openssl\crypto\i
> > nclude -c /Focrypto\aes\aes_ecb.obj crypto\aes\aes_ecb.c
> > aes_ecb.c
> >
> > ...
>
>
> --
> Richard Levitte
> levitte at openssl.org


--
Richard Levitte
levitte at openssl.org

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


From uri at ll.mit.edu  Wed May 25 14:50:00 2016
From: uri at ll.mit.edu (Blumenthal, Uri - 0553 - MITLL)
Date: Wed, 25 May 2016 14:50:00 +0000
Subject: [openssl-dev] Current Github build fails
Message-ID: <D36B33D2.2C8E1%uri@ll.mit.edu>

$ ./Configure darwin64-x86_64-cc threads shared zlib
enable-ec_nistp_64_gcc_128 enable-rfc3779
--prefix=/Users/ur20980/src/openssl-1.1
--openssldir=/Users/ur20980/src/openssl-1.1/etc
Configuring OpenSSL version 1.1.0-pre6-dev (0x0x10100006L)
    no-asan         [default]  OPENSSL_NO_ASAN (skip dir)
    no-crypto-mdebug [default]  OPENSSL_NO_CRYPTO_MDEBUG (skip dir)
    no-crypto-mdebug-backtrace [forced]
OPENSSL_NO_CRYPTO_MDEBUG_BACKTRACE (skip dir)
    no-egd          [default]  OPENSSL_NO_EGD (skip dir)
    no-fuzz         [default]  OPENSSL_NO_FUZZ (skip dir)
    no-heartbeats   [default]  OPENSSL_NO_HEARTBEATS (skip dir)
    no-md2          [default]  OPENSSL_NO_MD2 (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-dynamic [default]
Configuring for darwin64-x86_64-cc
CC            =clang
CFLAG         =-O3 -D_REENTRANT -arch x86_64 -DL_ENDIAN -Wall
SHARED_CFLAG  =-fPIC
DEFINES       =ZLIB DSO_DLFCN HAVE_DLFCN_H NDEBUG OPENSSL_THREADS
OPENSSL_NO_STATIC_ENGINE OPENSSL_PIC OPENSSL_IA32_SSE2 OPENSSL_BN_ASM_MONT
OPENSSL_BN_ASM_MONT5 OPENSSL_BN_ASM_GF2m SHA1_ASM SHA256_ASM SHA512_ASM
MD5_ASM AES_ASM VPAES_ASM BSAES_ASM GHASH_ASM ECP_NISTZ256_ASM POLY1305_ASM
LFLAG         =
PLIB_LFLAG    =-Wl,-search_paths_first
EX_LIBS       =-lz 
APPS_OBJ      =
CPUID_OBJ     =x86_64cpuid.o
UPLINK_OBJ    =
BN_ASM        =asm/x86_64-gcc.o x86_64-mont.o x86_64-mont5.o x86_64-gf2m.o
rsaz_exp.o rsaz-x86_64.o rsaz-avx2.o
EC_ASM        =ecp_nistz256.o ecp_nistz256-x86_64.o
DES_ENC       =des_enc.o fcrypt_b.o
AES_ENC       =aes-x86_64.o vpaes-x86_64.o bsaes-x86_64.o aesni-x86_64.o
aesni-sha1-x86_64.o aesni-sha256-x86_64.o aesni-mb-x86_64.o
BF_ENC        =bf_enc.o
CAST_ENC      =c_enc.o
RC4_ENC       =rc4-x86_64.o rc4-md5-x86_64.o
RC5_ENC       =rc5_enc.o
MD5_OBJ_ASM   =md5-x86_64.o
SHA1_OBJ_ASM  =sha1-x86_64.o sha256-x86_64.o sha512-x86_64.o
sha1-mb-x86_64.o sha256-mb-x86_64.o
RMD160_OBJ_ASM=
CMLL_ENC      =cmll-x86_64.o cmll_misc.o
MODES_OBJ     =ghash-x86_64.o aesni-gcm-x86_64.o
PADLOCK_OBJ   =e_padlock-x86_64.o
CHACHA_ENC    =chacha-x86_64.o
POLY1305_OBJ  =poly1305-x86_64.o
BLAKE2_OBJ    =
PROCESSOR     =
RANLIB        =ranlib -c
ARFLAGS       =
PERL          =/opt/local/bin/perl5.22


SIXTY_FOUR_BIT_LONG mode


Configured for darwin64-x86_64-cc.
$ make depend && make clean && make all && make test && make install
rm -f libcrypto.1.1.dylib
rm -f libcrypto.dylib
rm -f libssl.1.1.dylib
rm -f libssl.dylib
rm -f libcrypto.a libssl.a
rm -f apps/openssl test/aborttest test/afalgtest test/asynciotest
test/asynctest test/bftest test/bntest test/casttest test/cipherlist_test
test/clienthellotest test/constant_time_test test/ct_test test/d2i_test
test/danetest test/destest test/dhtest test/dsatest test/dtlsv1listentest
test/ecdhtest test/ecdsatest test/ectest test/enginetest
test/evp_extra_test test/evp_test test/exptest test/gmdifftest
test/heartbeat_test test/hmactest test/ideatest test/igetest test/md2test
test/md4test test/md5test test/mdc2test test/memleaktest test/nptest
test/p5_crpt2_test test/packettest test/pbelutest test/randtest
test/rc2test test/rc4test test/rc5test test/rmdtest test/rsa_test
test/secmemtest test/sha1test test/sha256t test/sha512t test/srptest
test/ssl_test test/ssl_test_ctx_test test/ssltest_old test/threadstest
test/v3nametest test/verify_extra_test test/wp_test test/x509aux
engines/capi.dylib engines/dasync.dylib engines/ossltest.dylib
engines/padlock.dylib apps/CA.pl apps/tsget tools/c_rehash
rm -f crypto/aes/aesni-sha1-x86_64.s crypto/modes/ghash-x86_64.s
crypto/aes/aes-x86_64.s crypto/camellia/cmll-x86_64.s
crypto/bn/rsaz-avx2.s crypto/sha/sha256-mb-x86_64.s crypto/x86_64cpuid.s
crypto/md5/md5-x86_64.s crypto/rc4/rc4-md5-x86_64.s
crypto/chacha/chacha-x86_64.s crypto/aes/bsaes-x86_64.s
crypto/whrlpool/wp-x86_64.s crypto/rc4/rc4-x86_64.s
crypto/sha/sha256-x86_64.s crypto/aes/aesni-mb-x86_64.s
crypto/aes/aesni-x86_64.s crypto/sha/sha512-x86_64.s
crypto/aes/vpaes-x86_64.s engines/e_padlock-x86_64.s
crypto/bn/x86_64-mont5.s crypto/poly1305/poly1305-x86_64.s
crypto/sha/sha1-mb-x86_64.s crypto/bn/x86_64-mont.s
crypto/bn/x86_64-gf2m.s crypto/ec/ecp_nistz256-x86_64.s
crypto/sha/sha1-x86_64.s crypto/modes/aesni-gcm-x86_64.s
crypto/aes/aesni-sha256-x86_64.s crypto/bn/rsaz-x86_64.s
include/openssl/opensslconf.h crypto/include/internal/bn_conf.h
crypto/include/internal/dso_conf.h crypto/buildinf.h
rm -f `find . -name '*.d'`
rm -f `find . -name '*.o'`
rm -f core
rm -f tags TAGS
rm -f openssl.pc libcrypto.pc libssl.pc
rm -f `find . -type l -a \! -path "./.git/*"`
rm -f ../openssl-1.1.0-pre6-dev.tar
CC="clang" /opt/local/bin/perl5.22 crypto/aes/asm/aes-x86_64.pl macosx
crypto/aes/aes-x86_64.s
clang -DZLIB -DDSO_DLFCN -DHAVE_DLFCN_H -DNDEBUG -DOPENSSL_THREADS
-DOPENSSL_NO_STATIC_ENGINE -DOPENSSL_PIC -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 -DGHASH_ASM -DECP_NISTZ256_ASM -DPOLY1305_ASM
-DOPENSSLDIR="\"/Users/ur20980/src/openssl-1.1/etc\""
-DENGINESDIR="\"/Users/ur20980/src/openssl-1.1/lib/engines\"" -O3
-D_REENTRANT -arch x86_64 -DL_ENDIAN -Wall  -fPIC -Iinclude -I.
-Icrypto/include -MMD -MF crypto/aes/aes-x86_64.d.tmp -MT
crypto/aes/aes-x86_64.o -c -o crypto/aes/aes-x86_64.o
crypto/aes/aes-x86_64.s
clang -DZLIB -DDSO_DLFCN -DHAVE_DLFCN_H -DNDEBUG -DOPENSSL_THREADS
-DOPENSSL_NO_STATIC_ENGINE -DOPENSSL_PIC -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 -DGHASH_ASM -DECP_NISTZ256_ASM -DPOLY1305_ASM
-DOPENSSLDIR="\"/Users/ur20980/src/openssl-1.1/etc\""
-DENGINESDIR="\"/Users/ur20980/src/openssl-1.1/lib/engines\"" -O3
-D_REENTRANT -arch x86_64 -DL_ENDIAN -Wall  -fPIC -Iinclude -I.
-Icrypto/include -MMD -MF crypto/aes/aes_cfb.d.tmp -MT
crypto/aes/aes_cfb.o -c -o crypto/aes/aes_cfb.o crypto/aes/aes_cfb.c
In file included from crypto/aes/aes_cfb.c:10:
include/openssl/aes.h:13:11: fatal error: 'openssl/opensslconf.h' file not
found
# include <openssl/opensslconf.h>
          ^
1 error generated.
make: *** [crypto/aes/aes_cfb.o] Error 1

-- 
Regards,
Uri Blumenthal
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4324 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20160525/0191a961/attachment.bin>

From levitte at openssl.org  Wed May 25 14:58:34 2016
From: levitte at openssl.org (Richard Levitte)
Date: Wed, 25 May 2016 16:58:34 +0200
Subject: [openssl-dev] Current Github build fails
In-Reply-To: <D36B33D2.2C8E1%uri@ll.mit.edu>
References: <D36B33D2.2C8E1%uri@ll.mit.edu>
Message-ID: <2084B495-B2BB-4771-B9A8-D811C597C55E@openssl.org>

Yes. There's a bug where the 'clean' target removes header files generated by Configure. I'll fix later tonight. 

Cheers 
Richard 

"Blumenthal, Uri - 0553 - MITLL" <uri at ll.mit.edu> skrev: (25 maj 2016 16:50:00 CEST)
>$ ./Configure darwin64-x86_64-cc threads shared zlib
>enable-ec_nistp_64_gcc_128 enable-rfc3779
>--prefix=/Users/ur20980/src/openssl-1.1
>--openssldir=/Users/ur20980/src/openssl-1.1/etc
>Configuring OpenSSL version 1.1.0-pre6-dev (0x0x10100006L)
>    no-asan         [default]  OPENSSL_NO_ASAN (skip dir)
>    no-crypto-mdebug [default]  OPENSSL_NO_CRYPTO_MDEBUG (skip dir)
>    no-crypto-mdebug-backtrace [forced]
>OPENSSL_NO_CRYPTO_MDEBUG_BACKTRACE (skip dir)
>    no-egd          [default]  OPENSSL_NO_EGD (skip dir)
>    no-fuzz         [default]  OPENSSL_NO_FUZZ (skip dir)
>    no-heartbeats   [default]  OPENSSL_NO_HEARTBEATS (skip dir)
>    no-md2          [default]  OPENSSL_NO_MD2 (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-dynamic [default]
>Configuring for darwin64-x86_64-cc
>CC            =clang
>CFLAG         =-O3 -D_REENTRANT -arch x86_64 -DL_ENDIAN -Wall
>SHARED_CFLAG  =-fPIC
>DEFINES       =ZLIB DSO_DLFCN HAVE_DLFCN_H NDEBUG OPENSSL_THREADS
>OPENSSL_NO_STATIC_ENGINE OPENSSL_PIC OPENSSL_IA32_SSE2
>OPENSSL_BN_ASM_MONT
>OPENSSL_BN_ASM_MONT5 OPENSSL_BN_ASM_GF2m SHA1_ASM SHA256_ASM SHA512_ASM
>MD5_ASM AES_ASM VPAES_ASM BSAES_ASM GHASH_ASM ECP_NISTZ256_ASM
>POLY1305_ASM
>LFLAG         =
>PLIB_LFLAG    =-Wl,-search_paths_first
>EX_LIBS       =-lz 
>APPS_OBJ      =
>CPUID_OBJ     =x86_64cpuid.o
>UPLINK_OBJ    =
>BN_ASM        =asm/x86_64-gcc.o x86_64-mont.o x86_64-mont5.o
>x86_64-gf2m.o
>rsaz_exp.o rsaz-x86_64.o rsaz-avx2.o
>EC_ASM        =ecp_nistz256.o ecp_nistz256-x86_64.o
>DES_ENC       =des_enc.o fcrypt_b.o
>AES_ENC       =aes-x86_64.o vpaes-x86_64.o bsaes-x86_64.o
>aesni-x86_64.o
>aesni-sha1-x86_64.o aesni-sha256-x86_64.o aesni-mb-x86_64.o
>BF_ENC        =bf_enc.o
>CAST_ENC      =c_enc.o
>RC4_ENC       =rc4-x86_64.o rc4-md5-x86_64.o
>RC5_ENC       =rc5_enc.o
>MD5_OBJ_ASM   =md5-x86_64.o
>SHA1_OBJ_ASM  =sha1-x86_64.o sha256-x86_64.o sha512-x86_64.o
>sha1-mb-x86_64.o sha256-mb-x86_64.o
>RMD160_OBJ_ASM=
>CMLL_ENC      =cmll-x86_64.o cmll_misc.o
>MODES_OBJ     =ghash-x86_64.o aesni-gcm-x86_64.o
>PADLOCK_OBJ   =e_padlock-x86_64.o
>CHACHA_ENC    =chacha-x86_64.o
>POLY1305_OBJ  =poly1305-x86_64.o
>BLAKE2_OBJ    =
>PROCESSOR     =
>RANLIB        =ranlib -c
>ARFLAGS       =
>PERL          =/opt/local/bin/perl5.22
>
>
>SIXTY_FOUR_BIT_LONG mode
>
>
>Configured for darwin64-x86_64-cc.
>$ make depend && make clean && make all && make test && make install
>rm -f libcrypto.1.1.dylib
>rm -f libcrypto.dylib
>rm -f libssl.1.1.dylib
>rm -f libssl.dylib
>rm -f libcrypto.a libssl.a
>rm -f apps/openssl test/aborttest test/afalgtest test/asynciotest
>test/asynctest test/bftest test/bntest test/casttest
>test/cipherlist_test
>test/clienthellotest test/constant_time_test test/ct_test test/d2i_test
>test/danetest test/destest test/dhtest test/dsatest
>test/dtlsv1listentest
>test/ecdhtest test/ecdsatest test/ectest test/enginetest
>test/evp_extra_test test/evp_test test/exptest test/gmdifftest
>test/heartbeat_test test/hmactest test/ideatest test/igetest
>test/md2test
>test/md4test test/md5test test/mdc2test test/memleaktest test/nptest
>test/p5_crpt2_test test/packettest test/pbelutest test/randtest
>test/rc2test test/rc4test test/rc5test test/rmdtest test/rsa_test
>test/secmemtest test/sha1test test/sha256t test/sha512t test/srptest
>test/ssl_test test/ssl_test_ctx_test test/ssltest_old test/threadstest
>test/v3nametest test/verify_extra_test test/wp_test test/x509aux
>engines/capi.dylib engines/dasync.dylib engines/ossltest.dylib
>engines/padlock.dylib apps/CA.pl apps/tsget tools/c_rehash
>rm -f crypto/aes/aesni-sha1-x86_64.s crypto/modes/ghash-x86_64.s
>crypto/aes/aes-x86_64.s crypto/camellia/cmll-x86_64.s
>crypto/bn/rsaz-avx2.s crypto/sha/sha256-mb-x86_64.s
>crypto/x86_64cpuid.s
>crypto/md5/md5-x86_64.s crypto/rc4/rc4-md5-x86_64.s
>crypto/chacha/chacha-x86_64.s crypto/aes/bsaes-x86_64.s
>crypto/whrlpool/wp-x86_64.s crypto/rc4/rc4-x86_64.s
>crypto/sha/sha256-x86_64.s crypto/aes/aesni-mb-x86_64.s
>crypto/aes/aesni-x86_64.s crypto/sha/sha512-x86_64.s
>crypto/aes/vpaes-x86_64.s engines/e_padlock-x86_64.s
>crypto/bn/x86_64-mont5.s crypto/poly1305/poly1305-x86_64.s
>crypto/sha/sha1-mb-x86_64.s crypto/bn/x86_64-mont.s
>crypto/bn/x86_64-gf2m.s crypto/ec/ecp_nistz256-x86_64.s
>crypto/sha/sha1-x86_64.s crypto/modes/aesni-gcm-x86_64.s
>crypto/aes/aesni-sha256-x86_64.s crypto/bn/rsaz-x86_64.s
>include/openssl/opensslconf.h crypto/include/internal/bn_conf.h
>crypto/include/internal/dso_conf.h crypto/buildinf.h
>rm -f `find . -name '*.d'`
>rm -f `find . -name '*.o'`
>rm -f core
>rm -f tags TAGS
>rm -f openssl.pc libcrypto.pc libssl.pc
>rm -f `find . -type l -a \! -path "./.git/*"`
>rm -f ../openssl-1.1.0-pre6-dev.tar
>CC="clang" /opt/local/bin/perl5.22 crypto/aes/asm/aes-x86_64.pl macosx
>crypto/aes/aes-x86_64.s
>clang -DZLIB -DDSO_DLFCN -DHAVE_DLFCN_H -DNDEBUG -DOPENSSL_THREADS
>-DOPENSSL_NO_STATIC_ENGINE -DOPENSSL_PIC -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 -DGHASH_ASM -DECP_NISTZ256_ASM -DPOLY1305_ASM
>-DOPENSSLDIR="\"/Users/ur20980/src/openssl-1.1/etc\""
>-DENGINESDIR="\"/Users/ur20980/src/openssl-1.1/lib/engines\"" -O3
>-D_REENTRANT -arch x86_64 -DL_ENDIAN -Wall  -fPIC -Iinclude -I.
>-Icrypto/include -MMD -MF crypto/aes/aes-x86_64.d.tmp -MT
>crypto/aes/aes-x86_64.o -c -o crypto/aes/aes-x86_64.o
>crypto/aes/aes-x86_64.s
>clang -DZLIB -DDSO_DLFCN -DHAVE_DLFCN_H -DNDEBUG -DOPENSSL_THREADS
>-DOPENSSL_NO_STATIC_ENGINE -DOPENSSL_PIC -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 -DGHASH_ASM -DECP_NISTZ256_ASM -DPOLY1305_ASM
>-DOPENSSLDIR="\"/Users/ur20980/src/openssl-1.1/etc\""
>-DENGINESDIR="\"/Users/ur20980/src/openssl-1.1/lib/engines\"" -O3
>-D_REENTRANT -arch x86_64 -DL_ENDIAN -Wall  -fPIC -Iinclude -I.
>-Icrypto/include -MMD -MF crypto/aes/aes_cfb.d.tmp -MT
>crypto/aes/aes_cfb.o -c -o crypto/aes/aes_cfb.o crypto/aes/aes_cfb.c
>In file included from crypto/aes/aes_cfb.c:10:
>include/openssl/aes.h:13:11: fatal error: 'openssl/opensslconf.h' file
>not
>found
># include <openssl/opensslconf.h>
>          ^
>1 error generated.
>make: *** [crypto/aes/aes_cfb.o] Error 1

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

From levitte at openssl.org  Wed May 25 18:56:53 2016
From: levitte at openssl.org (Richard Levitte)
Date: Wed, 25 May 2016 20:56:53 +0200 (CEST)
Subject: [openssl-dev] Current Github build fails
In-Reply-To: <2084B495-B2BB-4771-B9A8-D811C597C55E@openssl.org>
References: <D36B33D2.2C8E1%uri@ll.mit.edu>
 <2084B495-B2BB-4771-B9A8-D811C597C55E@openssl.org>
Message-ID: <20160525.205653.1298317536965356146.levitte@openssl.org>

This should solve the problem:

https://github.com/openssl/openssl/pull/1128

Cheers,
Richard

In message <2084B495-B2BB-4771-B9A8-D811C597C55E at openssl.org> on Wed, 25 May 2016 16:58:34 +0200, Richard Levitte <levitte at openssl.org> said:

levitte> Yes. There's a bug where the 'clean' target removes header files generated by Configure. I'll fix later tonight. 
levitte> 
levitte> Cheers 
levitte> Richard 
levitte> 
levitte> "Blumenthal, Uri - 0553 - MITLL" <uri at ll.mit.edu> skrev: (25 maj 2016 16:50:00 CEST)
levitte> >$ ./Configure darwin64-x86_64-cc threads shared zlib
levitte> >enable-ec_nistp_64_gcc_128 enable-rfc3779
levitte> >--prefix=/Users/ur20980/src/openssl-1.1
levitte> >--openssldir=/Users/ur20980/src/openssl-1.1/etc
levitte> >Configuring OpenSSL version 1.1.0-pre6-dev (0x0x10100006L)
levitte> >    no-asan         [default]  OPENSSL_NO_ASAN (skip dir)
levitte> >    no-crypto-mdebug [default]  OPENSSL_NO_CRYPTO_MDEBUG (skip dir)
levitte> >    no-crypto-mdebug-backtrace [forced]
levitte> >OPENSSL_NO_CRYPTO_MDEBUG_BACKTRACE (skip dir)
levitte> >    no-egd          [default]  OPENSSL_NO_EGD (skip dir)
levitte> >    no-fuzz         [default]  OPENSSL_NO_FUZZ (skip dir)
levitte> >    no-heartbeats   [default]  OPENSSL_NO_HEARTBEATS (skip dir)
levitte> >    no-md2          [default]  OPENSSL_NO_MD2 (skip dir)
levitte> >    no-rc5          [default]  OPENSSL_NO_RC5 (skip dir)
levitte> >    no-sctp         [default]  OPENSSL_NO_SCTP (skip dir)
levitte> >    no-ssl-trace    [default]  OPENSSL_NO_SSL_TRACE (skip dir)
levitte> >    no-ssl3         [default]  OPENSSL_NO_SSL3 (skip dir)
levitte> >    no-ssl3-method  [default]  OPENSSL_NO_SSL3_METHOD (skip dir)
levitte> >    no-ubsan        [default]  OPENSSL_NO_UBSAN (skip dir)
levitte> >    no-unit-test    [default]  OPENSSL_NO_UNIT_TEST (skip dir)
levitte> >  no-weak-ssl-ciphers [default]  OPENSSL_NO_WEAK_SSL_CIPHERS (skip dir)
levitte> >    no-zlib-dynamic [default]
levitte> >Configuring for darwin64-x86_64-cc
levitte> >CC            =clang
levitte> >CFLAG         =-O3 -D_REENTRANT -arch x86_64 -DL_ENDIAN -Wall
levitte> >SHARED_CFLAG  =-fPIC
levitte> >DEFINES       =ZLIB DSO_DLFCN HAVE_DLFCN_H NDEBUG OPENSSL_THREADS
levitte> >OPENSSL_NO_STATIC_ENGINE OPENSSL_PIC OPENSSL_IA32_SSE2
levitte> >OPENSSL_BN_ASM_MONT
levitte> >OPENSSL_BN_ASM_MONT5 OPENSSL_BN_ASM_GF2m SHA1_ASM SHA256_ASM SHA512_ASM
levitte> >MD5_ASM AES_ASM VPAES_ASM BSAES_ASM GHASH_ASM ECP_NISTZ256_ASM
levitte> >POLY1305_ASM
levitte> >LFLAG         =
levitte> >PLIB_LFLAG    =-Wl,-search_paths_first
levitte> >EX_LIBS       =-lz 
levitte> >APPS_OBJ      =
levitte> >CPUID_OBJ     =x86_64cpuid.o
levitte> >UPLINK_OBJ    =
levitte> >BN_ASM        =asm/x86_64-gcc.o x86_64-mont.o x86_64-mont5.o
levitte> >x86_64-gf2m.o
levitte> >rsaz_exp.o rsaz-x86_64.o rsaz-avx2.o
levitte> >EC_ASM        =ecp_nistz256.o ecp_nistz256-x86_64.o
levitte> >DES_ENC       =des_enc.o fcrypt_b.o
levitte> >AES_ENC       =aes-x86_64.o vpaes-x86_64.o bsaes-x86_64.o
levitte> >aesni-x86_64.o
levitte> >aesni-sha1-x86_64.o aesni-sha256-x86_64.o aesni-mb-x86_64.o
levitte> >BF_ENC        =bf_enc.o
levitte> >CAST_ENC      =c_enc.o
levitte> >RC4_ENC       =rc4-x86_64.o rc4-md5-x86_64.o
levitte> >RC5_ENC       =rc5_enc.o
levitte> >MD5_OBJ_ASM   =md5-x86_64.o
levitte> >SHA1_OBJ_ASM  =sha1-x86_64.o sha256-x86_64.o sha512-x86_64.o
levitte> >sha1-mb-x86_64.o sha256-mb-x86_64.o
levitte> >RMD160_OBJ_ASM=
levitte> >CMLL_ENC      =cmll-x86_64.o cmll_misc.o
levitte> >MODES_OBJ     =ghash-x86_64.o aesni-gcm-x86_64.o
levitte> >PADLOCK_OBJ   =e_padlock-x86_64.o
levitte> >CHACHA_ENC    =chacha-x86_64.o
levitte> >POLY1305_OBJ  =poly1305-x86_64.o
levitte> >BLAKE2_OBJ    =
levitte> >PROCESSOR     =
levitte> >RANLIB        =ranlib -c
levitte> >ARFLAGS       =
levitte> >PERL          =/opt/local/bin/perl5.22
levitte> >
levitte> >
levitte> >SIXTY_FOUR_BIT_LONG mode
levitte> >
levitte> >
levitte> >Configured for darwin64-x86_64-cc.
levitte> >$ make depend && make clean && make all && make test && make install
levitte> >rm -f libcrypto.1.1.dylib
levitte> >rm -f libcrypto.dylib
levitte> >rm -f libssl.1.1.dylib
levitte> >rm -f libssl.dylib
levitte> >rm -f libcrypto.a libssl.a
levitte> >rm -f apps/openssl test/aborttest test/afalgtest test/asynciotest
levitte> >test/asynctest test/bftest test/bntest test/casttest
levitte> >test/cipherlist_test
levitte> >test/clienthellotest test/constant_time_test test/ct_test test/d2i_test
levitte> >test/danetest test/destest test/dhtest test/dsatest
levitte> >test/dtlsv1listentest
levitte> >test/ecdhtest test/ecdsatest test/ectest test/enginetest
levitte> >test/evp_extra_test test/evp_test test/exptest test/gmdifftest
levitte> >test/heartbeat_test test/hmactest test/ideatest test/igetest
levitte> >test/md2test
levitte> >test/md4test test/md5test test/mdc2test test/memleaktest test/nptest
levitte> >test/p5_crpt2_test test/packettest test/pbelutest test/randtest
levitte> >test/rc2test test/rc4test test/rc5test test/rmdtest test/rsa_test
levitte> >test/secmemtest test/sha1test test/sha256t test/sha512t test/srptest
levitte> >test/ssl_test test/ssl_test_ctx_test test/ssltest_old test/threadstest
levitte> >test/v3nametest test/verify_extra_test test/wp_test test/x509aux
levitte> >engines/capi.dylib engines/dasync.dylib engines/ossltest.dylib
levitte> >engines/padlock.dylib apps/CA.pl apps/tsget tools/c_rehash
levitte> >rm -f crypto/aes/aesni-sha1-x86_64.s crypto/modes/ghash-x86_64.s
levitte> >crypto/aes/aes-x86_64.s crypto/camellia/cmll-x86_64.s
levitte> >crypto/bn/rsaz-avx2.s crypto/sha/sha256-mb-x86_64.s
levitte> >crypto/x86_64cpuid.s
levitte> >crypto/md5/md5-x86_64.s crypto/rc4/rc4-md5-x86_64.s
levitte> >crypto/chacha/chacha-x86_64.s crypto/aes/bsaes-x86_64.s
levitte> >crypto/whrlpool/wp-x86_64.s crypto/rc4/rc4-x86_64.s
levitte> >crypto/sha/sha256-x86_64.s crypto/aes/aesni-mb-x86_64.s
levitte> >crypto/aes/aesni-x86_64.s crypto/sha/sha512-x86_64.s
levitte> >crypto/aes/vpaes-x86_64.s engines/e_padlock-x86_64.s
levitte> >crypto/bn/x86_64-mont5.s crypto/poly1305/poly1305-x86_64.s
levitte> >crypto/sha/sha1-mb-x86_64.s crypto/bn/x86_64-mont.s
levitte> >crypto/bn/x86_64-gf2m.s crypto/ec/ecp_nistz256-x86_64.s
levitte> >crypto/sha/sha1-x86_64.s crypto/modes/aesni-gcm-x86_64.s
levitte> >crypto/aes/aesni-sha256-x86_64.s crypto/bn/rsaz-x86_64.s
levitte> >include/openssl/opensslconf.h crypto/include/internal/bn_conf.h
levitte> >crypto/include/internal/dso_conf.h crypto/buildinf.h
levitte> >rm -f `find . -name '*.d'`
levitte> >rm -f `find . -name '*.o'`
levitte> >rm -f core
levitte> >rm -f tags TAGS
levitte> >rm -f openssl.pc libcrypto.pc libssl.pc
levitte> >rm -f `find . -type l -a \! -path "./.git/*"`
levitte> >rm -f ../openssl-1.1.0-pre6-dev.tar
levitte> >CC="clang" /opt/local/bin/perl5.22 crypto/aes/asm/aes-x86_64.pl macosx
levitte> >crypto/aes/aes-x86_64.s
levitte> >clang -DZLIB -DDSO_DLFCN -DHAVE_DLFCN_H -DNDEBUG -DOPENSSL_THREADS
levitte> >-DOPENSSL_NO_STATIC_ENGINE -DOPENSSL_PIC -DOPENSSL_IA32_SSE2
levitte> >-DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m
levitte> >-DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DAES_ASM -DVPAES_ASM
levitte> >-DBSAES_ASM -DGHASH_ASM -DECP_NISTZ256_ASM -DPOLY1305_ASM
levitte> >-DOPENSSLDIR="\"/Users/ur20980/src/openssl-1.1/etc\""
levitte> >-DENGINESDIR="\"/Users/ur20980/src/openssl-1.1/lib/engines\"" -O3
levitte> >-D_REENTRANT -arch x86_64 -DL_ENDIAN -Wall  -fPIC -Iinclude -I.
levitte> >-Icrypto/include -MMD -MF crypto/aes/aes-x86_64.d.tmp -MT
levitte> >crypto/aes/aes-x86_64.o -c -o crypto/aes/aes-x86_64.o
levitte> >crypto/aes/aes-x86_64.s
levitte> >clang -DZLIB -DDSO_DLFCN -DHAVE_DLFCN_H -DNDEBUG -DOPENSSL_THREADS
levitte> >-DOPENSSL_NO_STATIC_ENGINE -DOPENSSL_PIC -DOPENSSL_IA32_SSE2
levitte> >-DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m
levitte> >-DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DAES_ASM -DVPAES_ASM
levitte> >-DBSAES_ASM -DGHASH_ASM -DECP_NISTZ256_ASM -DPOLY1305_ASM
levitte> >-DOPENSSLDIR="\"/Users/ur20980/src/openssl-1.1/etc\""
levitte> >-DENGINESDIR="\"/Users/ur20980/src/openssl-1.1/lib/engines\"" -O3
levitte> >-D_REENTRANT -arch x86_64 -DL_ENDIAN -Wall  -fPIC -Iinclude -I.
levitte> >-Icrypto/include -MMD -MF crypto/aes/aes_cfb.d.tmp -MT
levitte> >crypto/aes/aes_cfb.o -c -o crypto/aes/aes_cfb.o crypto/aes/aes_cfb.c
levitte> >In file included from crypto/aes/aes_cfb.c:10:
levitte> >include/openssl/aes.h:13:11: fatal error: 'openssl/opensslconf.h' file
levitte> >not
levitte> >found
levitte> ># include <openssl/opensslconf.h>
levitte> >          ^
levitte> >1 error generated.
levitte> >make: *** [crypto/aes/aes_cfb.o] Error 1
levitte> 
levitte> -- 
levitte> Sent from my Android device with K-9 Mail. Please excuse my brevity.
levitte> -- 
levitte> openssl-dev mailing list
levitte> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
levitte> 

From levitte at openssl.org  Wed May 25 19:27:14 2016
From: levitte at openssl.org (Richard Levitte)
Date: Wed, 25 May 2016 21:27:14 +0200 (CEST)
Subject: [openssl-dev] Current Github build fails
In-Reply-To: <20160525.205653.1298317536965356146.levitte@openssl.org>
References: <D36B33D2.2C8E1%uri@ll.mit.edu>
 <2084B495-B2BB-4771-B9A8-D811C597C55E@openssl.org>
 <20160525.205653.1298317536965356146.levitte@openssl.org>
Message-ID: <20160525.212714.799411601518803917.levitte@openssl.org>

... and has now made it to master.

Cheers,
richard

In message <20160525.205653.1298317536965356146.levitte at openssl.org> on Wed, 25 May 2016 20:56:53 +0200 (CEST), Richard Levitte <levitte at openssl.org> said:

levitte> This should solve the problem:
levitte> 
levitte> https://github.com/openssl/openssl/pull/1128
levitte> 
levitte> Cheers,
levitte> Richard
levitte> 
levitte> In message <2084B495-B2BB-4771-B9A8-D811C597C55E at openssl.org> on Wed, 25 May 2016 16:58:34 +0200, Richard Levitte <levitte at openssl.org> said:
levitte> 
levitte> levitte> Yes. There's a bug where the 'clean' target removes header files generated by Configure. I'll fix later tonight. 
levitte> levitte> 
levitte> levitte> Cheers 
levitte> levitte> Richard 
levitte> levitte> 
levitte> levitte> "Blumenthal, Uri - 0553 - MITLL" <uri at ll.mit.edu> skrev: (25 maj 2016 16:50:00 CEST)
levitte> levitte> >$ ./Configure darwin64-x86_64-cc threads shared zlib
levitte> levitte> >enable-ec_nistp_64_gcc_128 enable-rfc3779
levitte> levitte> >--prefix=/Users/ur20980/src/openssl-1.1
levitte> levitte> >--openssldir=/Users/ur20980/src/openssl-1.1/etc
levitte> levitte> >Configuring OpenSSL version 1.1.0-pre6-dev (0x0x10100006L)
levitte> levitte> >    no-asan         [default]  OPENSSL_NO_ASAN (skip dir)
levitte> levitte> >    no-crypto-mdebug [default]  OPENSSL_NO_CRYPTO_MDEBUG (skip dir)
levitte> levitte> >    no-crypto-mdebug-backtrace [forced]
levitte> levitte> >OPENSSL_NO_CRYPTO_MDEBUG_BACKTRACE (skip dir)
levitte> levitte> >    no-egd          [default]  OPENSSL_NO_EGD (skip dir)
levitte> levitte> >    no-fuzz         [default]  OPENSSL_NO_FUZZ (skip dir)
levitte> levitte> >    no-heartbeats   [default]  OPENSSL_NO_HEARTBEATS (skip dir)
levitte> levitte> >    no-md2          [default]  OPENSSL_NO_MD2 (skip dir)
levitte> levitte> >    no-rc5          [default]  OPENSSL_NO_RC5 (skip dir)
levitte> levitte> >    no-sctp         [default]  OPENSSL_NO_SCTP (skip dir)
levitte> levitte> >    no-ssl-trace    [default]  OPENSSL_NO_SSL_TRACE (skip dir)
levitte> levitte> >    no-ssl3         [default]  OPENSSL_NO_SSL3 (skip dir)
levitte> levitte> >    no-ssl3-method  [default]  OPENSSL_NO_SSL3_METHOD (skip dir)
levitte> levitte> >    no-ubsan        [default]  OPENSSL_NO_UBSAN (skip dir)
levitte> levitte> >    no-unit-test    [default]  OPENSSL_NO_UNIT_TEST (skip dir)
levitte> levitte> >  no-weak-ssl-ciphers [default]  OPENSSL_NO_WEAK_SSL_CIPHERS (skip dir)
levitte> levitte> >    no-zlib-dynamic [default]
levitte> levitte> >Configuring for darwin64-x86_64-cc
levitte> levitte> >CC            =clang
levitte> levitte> >CFLAG         =-O3 -D_REENTRANT -arch x86_64 -DL_ENDIAN -Wall
levitte> levitte> >SHARED_CFLAG  =-fPIC
levitte> levitte> >DEFINES       =ZLIB DSO_DLFCN HAVE_DLFCN_H NDEBUG OPENSSL_THREADS
levitte> levitte> >OPENSSL_NO_STATIC_ENGINE OPENSSL_PIC OPENSSL_IA32_SSE2
levitte> levitte> >OPENSSL_BN_ASM_MONT
levitte> levitte> >OPENSSL_BN_ASM_MONT5 OPENSSL_BN_ASM_GF2m SHA1_ASM SHA256_ASM SHA512_ASM
levitte> levitte> >MD5_ASM AES_ASM VPAES_ASM BSAES_ASM GHASH_ASM ECP_NISTZ256_ASM
levitte> levitte> >POLY1305_ASM
levitte> levitte> >LFLAG         =
levitte> levitte> >PLIB_LFLAG    =-Wl,-search_paths_first
levitte> levitte> >EX_LIBS       =-lz 
levitte> levitte> >APPS_OBJ      =
levitte> levitte> >CPUID_OBJ     =x86_64cpuid.o
levitte> levitte> >UPLINK_OBJ    =
levitte> levitte> >BN_ASM        =asm/x86_64-gcc.o x86_64-mont.o x86_64-mont5.o
levitte> levitte> >x86_64-gf2m.o
levitte> levitte> >rsaz_exp.o rsaz-x86_64.o rsaz-avx2.o
levitte> levitte> >EC_ASM        =ecp_nistz256.o ecp_nistz256-x86_64.o
levitte> levitte> >DES_ENC       =des_enc.o fcrypt_b.o
levitte> levitte> >AES_ENC       =aes-x86_64.o vpaes-x86_64.o bsaes-x86_64.o
levitte> levitte> >aesni-x86_64.o
levitte> levitte> >aesni-sha1-x86_64.o aesni-sha256-x86_64.o aesni-mb-x86_64.o
levitte> levitte> >BF_ENC        =bf_enc.o
levitte> levitte> >CAST_ENC      =c_enc.o
levitte> levitte> >RC4_ENC       =rc4-x86_64.o rc4-md5-x86_64.o
levitte> levitte> >RC5_ENC       =rc5_enc.o
levitte> levitte> >MD5_OBJ_ASM   =md5-x86_64.o
levitte> levitte> >SHA1_OBJ_ASM  =sha1-x86_64.o sha256-x86_64.o sha512-x86_64.o
levitte> levitte> >sha1-mb-x86_64.o sha256-mb-x86_64.o
levitte> levitte> >RMD160_OBJ_ASM=
levitte> levitte> >CMLL_ENC      =cmll-x86_64.o cmll_misc.o
levitte> levitte> >MODES_OBJ     =ghash-x86_64.o aesni-gcm-x86_64.o
levitte> levitte> >PADLOCK_OBJ   =e_padlock-x86_64.o
levitte> levitte> >CHACHA_ENC    =chacha-x86_64.o
levitte> levitte> >POLY1305_OBJ  =poly1305-x86_64.o
levitte> levitte> >BLAKE2_OBJ    =
levitte> levitte> >PROCESSOR     =
levitte> levitte> >RANLIB        =ranlib -c
levitte> levitte> >ARFLAGS       =
levitte> levitte> >PERL          =/opt/local/bin/perl5.22
levitte> levitte> >
levitte> levitte> >
levitte> levitte> >SIXTY_FOUR_BIT_LONG mode
levitte> levitte> >
levitte> levitte> >
levitte> levitte> >Configured for darwin64-x86_64-cc.
levitte> levitte> >$ make depend && make clean && make all && make test && make install
levitte> levitte> >rm -f libcrypto.1.1.dylib
levitte> levitte> >rm -f libcrypto.dylib
levitte> levitte> >rm -f libssl.1.1.dylib
levitte> levitte> >rm -f libssl.dylib
levitte> levitte> >rm -f libcrypto.a libssl.a
levitte> levitte> >rm -f apps/openssl test/aborttest test/afalgtest test/asynciotest
levitte> levitte> >test/asynctest test/bftest test/bntest test/casttest
levitte> levitte> >test/cipherlist_test
levitte> levitte> >test/clienthellotest test/constant_time_test test/ct_test test/d2i_test
levitte> levitte> >test/danetest test/destest test/dhtest test/dsatest
levitte> levitte> >test/dtlsv1listentest
levitte> levitte> >test/ecdhtest test/ecdsatest test/ectest test/enginetest
levitte> levitte> >test/evp_extra_test test/evp_test test/exptest test/gmdifftest
levitte> levitte> >test/heartbeat_test test/hmactest test/ideatest test/igetest
levitte> levitte> >test/md2test
levitte> levitte> >test/md4test test/md5test test/mdc2test test/memleaktest test/nptest
levitte> levitte> >test/p5_crpt2_test test/packettest test/pbelutest test/randtest
levitte> levitte> >test/rc2test test/rc4test test/rc5test test/rmdtest test/rsa_test
levitte> levitte> >test/secmemtest test/sha1test test/sha256t test/sha512t test/srptest
levitte> levitte> >test/ssl_test test/ssl_test_ctx_test test/ssltest_old test/threadstest
levitte> levitte> >test/v3nametest test/verify_extra_test test/wp_test test/x509aux
levitte> levitte> >engines/capi.dylib engines/dasync.dylib engines/ossltest.dylib
levitte> levitte> >engines/padlock.dylib apps/CA.pl apps/tsget tools/c_rehash
levitte> levitte> >rm -f crypto/aes/aesni-sha1-x86_64.s crypto/modes/ghash-x86_64.s
levitte> levitte> >crypto/aes/aes-x86_64.s crypto/camellia/cmll-x86_64.s
levitte> levitte> >crypto/bn/rsaz-avx2.s crypto/sha/sha256-mb-x86_64.s
levitte> levitte> >crypto/x86_64cpuid.s
levitte> levitte> >crypto/md5/md5-x86_64.s crypto/rc4/rc4-md5-x86_64.s
levitte> levitte> >crypto/chacha/chacha-x86_64.s crypto/aes/bsaes-x86_64.s
levitte> levitte> >crypto/whrlpool/wp-x86_64.s crypto/rc4/rc4-x86_64.s
levitte> levitte> >crypto/sha/sha256-x86_64.s crypto/aes/aesni-mb-x86_64.s
levitte> levitte> >crypto/aes/aesni-x86_64.s crypto/sha/sha512-x86_64.s
levitte> levitte> >crypto/aes/vpaes-x86_64.s engines/e_padlock-x86_64.s
levitte> levitte> >crypto/bn/x86_64-mont5.s crypto/poly1305/poly1305-x86_64.s
levitte> levitte> >crypto/sha/sha1-mb-x86_64.s crypto/bn/x86_64-mont.s
levitte> levitte> >crypto/bn/x86_64-gf2m.s crypto/ec/ecp_nistz256-x86_64.s
levitte> levitte> >crypto/sha/sha1-x86_64.s crypto/modes/aesni-gcm-x86_64.s
levitte> levitte> >crypto/aes/aesni-sha256-x86_64.s crypto/bn/rsaz-x86_64.s
levitte> levitte> >include/openssl/opensslconf.h crypto/include/internal/bn_conf.h
levitte> levitte> >crypto/include/internal/dso_conf.h crypto/buildinf.h
levitte> levitte> >rm -f `find . -name '*.d'`
levitte> levitte> >rm -f `find . -name '*.o'`
levitte> levitte> >rm -f core
levitte> levitte> >rm -f tags TAGS
levitte> levitte> >rm -f openssl.pc libcrypto.pc libssl.pc
levitte> levitte> >rm -f `find . -type l -a \! -path "./.git/*"`
levitte> levitte> >rm -f ../openssl-1.1.0-pre6-dev.tar
levitte> levitte> >CC="clang" /opt/local/bin/perl5.22 crypto/aes/asm/aes-x86_64.pl macosx
levitte> levitte> >crypto/aes/aes-x86_64.s
levitte> levitte> >clang -DZLIB -DDSO_DLFCN -DHAVE_DLFCN_H -DNDEBUG -DOPENSSL_THREADS
levitte> levitte> >-DOPENSSL_NO_STATIC_ENGINE -DOPENSSL_PIC -DOPENSSL_IA32_SSE2
levitte> levitte> >-DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m
levitte> levitte> >-DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DAES_ASM -DVPAES_ASM
levitte> levitte> >-DBSAES_ASM -DGHASH_ASM -DECP_NISTZ256_ASM -DPOLY1305_ASM
levitte> levitte> >-DOPENSSLDIR="\"/Users/ur20980/src/openssl-1.1/etc\""
levitte> levitte> >-DENGINESDIR="\"/Users/ur20980/src/openssl-1.1/lib/engines\"" -O3
levitte> levitte> >-D_REENTRANT -arch x86_64 -DL_ENDIAN -Wall  -fPIC -Iinclude -I.
levitte> levitte> >-Icrypto/include -MMD -MF crypto/aes/aes-x86_64.d.tmp -MT
levitte> levitte> >crypto/aes/aes-x86_64.o -c -o crypto/aes/aes-x86_64.o
levitte> levitte> >crypto/aes/aes-x86_64.s
levitte> levitte> >clang -DZLIB -DDSO_DLFCN -DHAVE_DLFCN_H -DNDEBUG -DOPENSSL_THREADS
levitte> levitte> >-DOPENSSL_NO_STATIC_ENGINE -DOPENSSL_PIC -DOPENSSL_IA32_SSE2
levitte> levitte> >-DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m
levitte> levitte> >-DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DAES_ASM -DVPAES_ASM
levitte> levitte> >-DBSAES_ASM -DGHASH_ASM -DECP_NISTZ256_ASM -DPOLY1305_ASM
levitte> levitte> >-DOPENSSLDIR="\"/Users/ur20980/src/openssl-1.1/etc\""
levitte> levitte> >-DENGINESDIR="\"/Users/ur20980/src/openssl-1.1/lib/engines\"" -O3
levitte> levitte> >-D_REENTRANT -arch x86_64 -DL_ENDIAN -Wall  -fPIC -Iinclude -I.
levitte> levitte> >-Icrypto/include -MMD -MF crypto/aes/aes_cfb.d.tmp -MT
levitte> levitte> >crypto/aes/aes_cfb.o -c -o crypto/aes/aes_cfb.o crypto/aes/aes_cfb.c
levitte> levitte> >In file included from crypto/aes/aes_cfb.c:10:
levitte> levitte> >include/openssl/aes.h:13:11: fatal error: 'openssl/opensslconf.h' file
levitte> levitte> >not
levitte> levitte> >found
levitte> levitte> ># include <openssl/opensslconf.h>
levitte> levitte> >          ^
levitte> levitte> >1 error generated.
levitte> levitte> >make: *** [crypto/aes/aes_cfb.o] Error 1
levitte> levitte> 
levitte> levitte> -- 
levitte> levitte> Sent from my Android device with K-9 Mail. Please excuse my brevity.
levitte> levitte> -- 
levitte> levitte> openssl-dev mailing list
levitte> levitte> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
levitte> levitte> 
levitte> -- 
levitte> openssl-dev mailing list
levitte> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
levitte> 

From rt at openssl.org  Wed May 25 21:11:55 2016
From: rt at openssl.org (Andy Polyakov via RT)
Date: Wed, 25 May 2016 21:11:55 +0000
Subject: [openssl-dev] [openssl.org #4491] [PATCH] VMX-crypto: Add XTS
	support
In-Reply-To: <9a91ca36-4273-31d1-6351-a67301b56da1@openssl.org>
References: <RT-Ticket-4491@openssl.org>
 <20160328150622.GA15807@london.kopenhagen>
 <rt-4.0.19-2648-1459177780-622.4491-21-0@openssl.org>
 <9a91ca36-4273-31d1-6351-a67301b56da1@openssl.org>
Message-ID: <rt-4.0.19-18315-1464210715-182.4491-6-0@openssl.org>

> Author: Leonidas Da Silva Barbosa <leosilva at linux.vnet.ibm.com>
> ASM implementation
> 
> Signed-off-by: Paulo Flabiano Smorigo <pfsmorigo at linux.vnet.ibm.com>
> Signed-off-by: Leonidas Da Silva Barbosa <leosilva at linux.vnet.ibm.com>
> ---
> +my ($inp,$out,$len,$key,$tweak,$enc,$rounds,$idx)=map("r$_",(3..10));

There seem to be misunderstanding. EVP layer expects XTS "stream"
subroutine to accept clear-text initial tweak (for this both keys are
passed) and to handle lengths not divisible by 16. Suggested code does
neither. I fail to follow tweak caclucations, it seems more complicated
than necessary. I managed to do in 5 instructions:

        vsrab           $tmp,$tweak,$seven
        vaddubm         $tweak,$tweak,$tweak
        vsldoi          $tmp,$tmp,$tmp,15
        vand            $tmp,$tmp,$eighty7
        vxor            $tweak,$tweak,$tmp

Please review attached code. Even though it's almost 4x faster, it will
be improved even further shortly.


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

-------------- next part --------------
diff --git a/crypto/aes/asm/aesp8-ppc.pl b/crypto/aes/asm/aesp8-ppc.pl
index a1891cc..8ea52cd 100755
--- a/crypto/aes/asm/aesp8-ppc.pl
+++ b/crypto/aes/asm/aesp8-ppc.pl
@@ -1887,6 +1887,415 @@ Lctr32_enc8x_done:
 ___
 }}	}}}
 
+#########################################################################
+{{{	# XTS procedure[s]						#
+my ($inp,$out,$len,$key1,$key2,$ivp,$rounds,$idx) =	map("r$_",(3..10));
+my ($rndkey0,$rndkey1,$inout,$tmp) =			map("v$_",(0..3));
+my ($inptail,$inpperm,$output,$leperm,$keyperm) =	map("v$_",(4..8));
+my ($tweak,$seven,$eighty7,$tweak1) =			map("v$_",(9..12));
+
+   ($inp,$idx) = ($idx,$inp);				# reassign
+
+$code.=<<___;
+.globl	.${prefix}_xts_encrypt
+.align	5
+.${prefix}_xts_encrypt:
+	mr		$inp,r3				# reassign
+	li		r3,-1
+	${UCMP}i	$len,16
+	bltlr-
+
+	lis		r0,0xfff0
+	mfspr		r12,256				# save vrsave
+	li		r11,0
+	mtspr		256,r0
+
+	vspltisb	$seven,0x07			# 0x070707..07
+	le?lvsl		$leperm,r11,r11
+	le?vspltisb	$tmp,0x0f
+	le?vxor		$leperm,$leperm,$seven
+
+	li		$idx,15
+	lvx		$tweak,0,$ivp			# load [unaligned] iv
+	lvsl		$inpperm,0,$ivp
+	lvx		$inptail,$idx,$ivp
+	le?vxor		$inpperm,$inpperm,$tmp
+	vperm		$tweak,$tweak,$inptail,$inpperm
+
+	?lvsl		$keyperm,0,$key2		# prepare for unaligned key
+	lwz		$rounds,240($key2)
+	srwi		$rounds,$rounds,1
+	subi		$rounds,$rounds,1
+	li		$idx,16
+
+	neg		r11,$inp
+	lvsr		$inpperm,0,r11			# prepare for unaligned load
+	lvx		$inout,0,$inp
+	addi		$inp,$inp,15			# 15 is not typo
+	le?vxor		$inpperm,$inpperm,$tmp
+
+	lvx		$rndkey0,0,$key2
+	lvx		$rndkey1,$idx,$key2
+	addi		$idx,$idx,16
+	?vperm		$rndkey0,$rndkey0,$rndkey1,$keyperm
+	vxor		$tweak,$tweak,$rndkey0
+	lvx		$rndkey0,$idx,$key2
+	addi		$idx,$idx,16
+	mtctr		$rounds
+
+Ltweak_xts_enc:
+	?vperm		$rndkey1,$rndkey1,$rndkey0,$keyperm
+	vcipher		$tweak,$tweak,$rndkey1
+	lvx		$rndkey1,$idx,$key2
+	addi		$idx,$idx,16
+	?vperm		$rndkey0,$rndkey0,$rndkey1,$keyperm
+	vcipher		$tweak,$tweak,$rndkey0
+	lvx		$rndkey0,$idx,$key2
+	addi		$idx,$idx,16
+	bdnz		Ltweak_xts_enc
+
+	?vperm		$rndkey1,$rndkey1,$rndkey0,$keyperm
+	vcipher		$tweak,$tweak,$rndkey1
+	lvx		$rndkey1,$idx,$key2
+	li		$idx,16
+	?vperm		$rndkey0,$rndkey0,$rndkey1,$keyperm
+	vcipherlast	$tweak,$tweak,$rndkey0
+
+	lvx		$inptail,0,$inp
+	addi		$inp,$inp,16
+
+	?lvsl		$keyperm,0,$key1		# prepare for unaligned key
+	lwz		$rounds,240($key1)
+	srwi		$rounds,$rounds,1
+	subi		$rounds,$rounds,1
+	li		$idx,16
+
+	vslb		$eighty7,$seven,$seven		# 0x808080..80
+	vor		$eighty7,$eighty7,$seven	# 0x878787..87
+	vspltisb	$tmp,1				# 0x010101..01
+	vsldoi		$eighty7,$eighty7,$tmp,15	# 0x870101..01
+
+	lvx		$rndkey0,0,$key1
+	lvx		$rndkey1,$idx,$key1
+	addi		$idx,$idx,16
+	vperm		$inout,$inout,$inptail,$inpperm
+	?vperm		$rndkey0,$rndkey0,$rndkey1,$keyperm
+	vxor		$inout,$inout,$tweak
+	vxor		$inout,$inout,$rndkey0
+	lvx		$rndkey0,$idx,$key1
+	addi		$idx,$idx,16
+	mtctr		$rounds
+	be?b		Loop_xts_enc
+
+.align	5
+Loop_xts_enc:
+	?vperm		$rndkey1,$rndkey1,$rndkey0,$keyperm
+	vcipher		$inout,$inout,$rndkey1
+	lvx		$rndkey1,$idx,$key1
+	addi		$idx,$idx,16
+	?vperm		$rndkey0,$rndkey0,$rndkey1,$keyperm
+	vcipher		$inout,$inout,$rndkey0
+	lvx		$rndkey0,$idx,$key1
+	addi		$idx,$idx,16
+	bdnz		Loop_xts_enc
+
+	?vperm		$rndkey1,$rndkey1,$rndkey0,$keyperm
+	vcipher		$inout,$inout,$rndkey1
+	lvx		$rndkey1,$idx,$key1
+	li		$idx,16
+	?vperm		$rndkey0,$rndkey0,$rndkey1,$keyperm
+	vxor		$rndkey0,$rndkey0,$tweak
+	vcipherlast	$output,$inout,$rndkey0
+
+	le?vperm	$tmp,$output,$output,$leperm
+	be?nop
+	le?stvx_u	$tmp,0,$out
+	be?stvx_u	$output,0,$out
+	addi		$out,$out,16
+
+	subic.		$len,$len,16
+	beq		Lxts_enc_done
+
+	vmr		$inout,$inptail
+	lvx		$inptail,0,$inp
+	addi		$inp,$inp,16
+	lvx		$rndkey0,0,$key1
+	lvx		$rndkey1,$idx,$key1
+	addi		$idx,$idx,16
+
+	vsrab		$tmp,$tweak,$seven		# next tweak value
+	vaddubm		$tweak,$tweak,$tweak
+	vsldoi		$tmp,$tmp,$tmp,15
+	vand		$tmp,$tmp,$eighty7
+	vxor		$tweak,$tweak,$tmp
+
+	vperm		$inout,$inout,$inptail,$inpperm
+	?vperm		$rndkey0,$rndkey0,$rndkey1,$keyperm
+	vxor		$inout,$inout,$tweak
+	vxor		$output,$output,$rndkey0	# just in case $len<16
+	vxor		$inout,$inout,$rndkey0
+	lvx		$rndkey0,$idx,$key1
+	addi		$idx,$idx,16
+
+	mtctr		$rounds
+	${UCMP}i	$len,16
+	bge		Loop_xts_enc
+
+	vxor		$output,$output,$tweak
+	lvsr		$inpperm,0,$len			# $inpperm is no longer needed
+	vxor		$inptail,$inptail,$inptail	# $inptail is no longer needed
+	vspltisb	$tmp,-1
+	vperm		$inptail,$inptail,$tmp,$inpperm
+	vsel		$inout,$inout,$output,$inptail
+
+	subi		r11,$out,17
+	subi		$out,$out,16
+	mtctr		$len
+	li		$len,16
+Loop_xts_enc_steal:
+	lbzu		r0,1(r11)
+	stb		r0,16(r11)
+	bdnz		Loop_xts_enc_steal
+
+	mtctr		$rounds
+	b		Loop_xts_enc			# one more time...
+
+Lxts_enc_done:
+	mtspr		256,r12				# restore vrsave
+	li		r3,0
+	blr
+	.long		0
+	.byte		0,12,0x04,0,0x80,6,6,0
+	.long		0
+.size	.${prefix}_xts_encrypt,.-.${prefix}_xts_encrypt
+
+.globl	.${prefix}_xts_decrypt
+.align	5
+.${prefix}_xts_decrypt:
+	mr		$inp,r3				# reassign
+	li		r3,-1
+	${UCMP}i	$len,16
+	bltlr-
+
+	lis		r0,0xfff8
+	mfspr		r12,256				# save vrsave
+	li		r11,0
+	mtspr		256,r0
+
+	andi.		r0,$len,15
+	neg		r0,r0
+	andi.		r0,r0,16
+	sub		$len,$len,r0
+
+	vspltisb	$seven,0x07			# 0x070707..07
+	le?lvsl		$leperm,r11,r11
+	le?vspltisb	$tmp,0x0f
+	le?vxor		$leperm,$leperm,$seven
+
+	li		$idx,15
+	lvx		$tweak,0,$ivp			# load [unaligned] iv
+	lvsl		$inpperm,0,$ivp
+	lvx		$inptail,$idx,$ivp
+	le?vxor		$inpperm,$inpperm,$tmp
+	vperm		$tweak,$tweak,$inptail,$inpperm
+
+	?lvsl		$keyperm,0,$key2		# prepare for unaligned key
+	lwz		$rounds,240($key2)
+	srwi		$rounds,$rounds,1
+	subi		$rounds,$rounds,1
+	li		$idx,16
+
+	neg		r11,$inp
+	lvsr		$inpperm,0,r11			# prepare for unaligned load
+	lvx		$inout,0,$inp
+	addi		$inp,$inp,15			# 15 is not typo
+	le?vxor		$inpperm,$inpperm,$tmp
+
+	lvx		$rndkey0,0,$key2
+	lvx		$rndkey1,$idx,$key2
+	addi		$idx,$idx,16
+	?vperm		$rndkey0,$rndkey0,$rndkey1,$keyperm
+	vxor		$tweak,$tweak,$rndkey0
+	lvx		$rndkey0,$idx,$key2
+	addi		$idx,$idx,16
+	mtctr		$rounds
+
+Ltweak_xts_dec:
+	?vperm		$rndkey1,$rndkey1,$rndkey0,$keyperm
+	vcipher		$tweak,$tweak,$rndkey1
+	lvx		$rndkey1,$idx,$key2
+	addi		$idx,$idx,16
+	?vperm		$rndkey0,$rndkey0,$rndkey1,$keyperm
+	vcipher		$tweak,$tweak,$rndkey0
+	lvx		$rndkey0,$idx,$key2
+	addi		$idx,$idx,16
+	bdnz		Ltweak_xts_dec
+
+	?vperm		$rndkey1,$rndkey1,$rndkey0,$keyperm
+	vcipher		$tweak,$tweak,$rndkey1
+	lvx		$rndkey1,$idx,$key2
+	li		$idx,16
+	?vperm		$rndkey0,$rndkey0,$rndkey1,$keyperm
+	vcipherlast	$tweak,$tweak,$rndkey0
+
+	lvx		$inptail,0,$inp
+	addi		$inp,$inp,16
+
+	?lvsl		$keyperm,0,$key1		# prepare for unaligned key
+	lwz		$rounds,240($key1)
+	srwi		$rounds,$rounds,1
+	subi		$rounds,$rounds,1
+	li		$idx,16
+
+	vslb		$eighty7,$seven,$seven		# 0x808080..80
+	vor		$eighty7,$eighty7,$seven	# 0x878787..87
+	vspltisb	$tmp,1				# 0x010101..01
+	vsldoi		$eighty7,$eighty7,$tmp,15	# 0x870101..01
+
+	lvx		$rndkey0,0,$key1
+	lvx		$rndkey1,$idx,$key1
+	addi		$idx,$idx,16
+	vperm		$inout,$inout,$inptail,$inpperm
+	?vperm		$rndkey0,$rndkey0,$rndkey1,$keyperm
+	vxor		$inout,$inout,$tweak
+	vxor		$inout,$inout,$rndkey0
+	lvx		$rndkey0,$idx,$key1
+	addi		$idx,$idx,16
+	mtctr		$rounds
+
+	${UCMP}i	$len,16
+	blt		Ltail_xts_dec
+	b		Loop_xts_dec
+
+.align	5
+Loop_xts_dec:
+	?vperm		$rndkey1,$rndkey1,$rndkey0,$keyperm
+	vncipher	$inout,$inout,$rndkey1
+	lvx		$rndkey1,$idx,$key1
+	addi		$idx,$idx,16
+	?vperm		$rndkey0,$rndkey0,$rndkey1,$keyperm
+	vncipher	$inout,$inout,$rndkey0
+	lvx		$rndkey0,$idx,$key1
+	addi		$idx,$idx,16
+	bdnz		Loop_xts_dec
+
+	?vperm		$rndkey1,$rndkey1,$rndkey0,$keyperm
+	vncipher	$inout,$inout,$rndkey1
+	lvx		$rndkey1,$idx,$key1
+	li		$idx,16
+	?vperm		$rndkey0,$rndkey0,$rndkey1,$keyperm
+	vxor		$rndkey0,$rndkey0,$tweak
+	vncipherlast	$output,$inout,$rndkey0
+
+	le?vperm	$tmp,$output,$output,$leperm
+	be?nop
+	le?stvx_u	$tmp,0,$out
+	be?stvx_u	$output,0,$out
+	addi		$out,$out,16
+
+	subic.		$len,$len,16
+	beq		Lxts_dec_done
+
+	vmr		$inout,$inptail
+	lvx		$inptail,0,$inp
+	addi		$inp,$inp,16
+	lvx		$rndkey0,0,$key1
+	lvx		$rndkey1,$idx,$key1
+	addi		$idx,$idx,16
+
+	vsrab		$tmp,$tweak,$seven		# next tweak value
+	vaddubm		$tweak,$tweak,$tweak
+	vsldoi		$tmp,$tmp,$tmp,15
+	vand		$tmp,$tmp,$eighty7
+	vxor		$tweak,$tweak,$tmp
+
+	vperm		$inout,$inout,$inptail,$inpperm
+	?vperm		$rndkey0,$rndkey0,$rndkey1,$keyperm
+	vxor		$inout,$inout,$tweak
+	vxor		$inout,$inout,$rndkey0
+	lvx		$rndkey0,$idx,$key1
+	addi		$idx,$idx,16
+
+	mtctr		$rounds
+	${UCMP}i	$len,16
+	bge		Loop_xts_dec
+
+Ltail_xts_dec:
+	vsrab		$tmp,$tweak,$seven		# next tweak value
+	vaddubm		$tweak1,$tweak,$tweak
+	vsldoi		$tmp,$tmp,$tmp,15
+	vand		$tmp,$tmp,$eighty7
+	vxor		$tweak1,$tweak1,$tmp
+
+	vxor		$inout,$inout,$tweak		# :-(
+	vxor		$inout,$inout,$tweak1		# :-)
+
+Loop_xts_dec_short:
+	?vperm		$rndkey1,$rndkey1,$rndkey0,$keyperm
+	vncipher	$inout,$inout,$rndkey1
+	lvx		$rndkey1,$idx,$key1
+	addi		$idx,$idx,16
+	?vperm		$rndkey0,$rndkey0,$rndkey1,$keyperm
+	vncipher	$inout,$inout,$rndkey0
+	lvx		$rndkey0,$idx,$key1
+	addi		$idx,$idx,16
+	bdnz		Loop_xts_dec_short
+
+	?vperm		$rndkey1,$rndkey1,$rndkey0,$keyperm
+	vncipher	$inout,$inout,$rndkey1
+	lvx		$rndkey1,$idx,$key1
+	li		$idx,16
+	?vperm		$rndkey0,$rndkey0,$rndkey1,$keyperm
+	vxor		$rndkey0,$rndkey0,$tweak1
+	vncipherlast	$output,$inout,$rndkey0
+
+	le?vperm	$tmp,$output,$output,$leperm
+	be?nop
+	le?stvx_u	$tmp,0,$out
+	be?stvx_u	$output,0,$out
+
+	vmr		$inout,$inptail
+	lvx		$inptail,0,$inp
+	#addi		$inp,$inp,16
+	lvx		$rndkey0,0,$key1
+	lvx		$rndkey1,$idx,$key1
+	addi		$idx,$idx,16
+	vperm		$inout,$inout,$inptail,$inpperm
+	?vperm		$rndkey0,$rndkey0,$rndkey1,$keyperm
+
+	lvsr		$inpperm,0,$len			# $inpperm is no longer needed
+	vxor		$inptail,$inptail,$inptail	# $inptail is no longer needed
+	vspltisb	$tmp,-1
+	vperm		$inptail,$inptail,$tmp,$inpperm
+	vsel		$inout,$inout,$output,$inptail
+
+	vxor		$rndkey0,$rndkey0,$tweak
+	vxor		$inout,$inout,$rndkey0
+	lvx		$rndkey0,$idx,$key1
+	addi		$idx,$idx,16
+
+	subi		r11,$out,1
+	mtctr		$len
+	li		$len,16
+Loop_xts_dec_steal:
+	lbzu		r0,1(r11)
+	stb		r0,16(r11)
+	bdnz		Loop_xts_dec_steal
+
+	mtctr		$rounds
+	b		Loop_xts_dec			# one more time...
+
+Lxts_dec_done:
+	mtspr		256,r12				# restore vrsave
+	li		r3,0
+	blr
+	.long		0
+	.byte		0,12,0x04,0,0x80,6,6,0
+	.long		0
+.size	.${prefix}_xts_decrypt,.-.${prefix}_xts_decrypt
+___
+}}}
+
 my $consts=1;
 foreach(split("\n",$code)) {
         s/\`([^\`]*)\`/eval($1)/geo;
diff --git a/crypto/evp/e_aes.c b/crypto/evp/e_aes.c
index ae39992..4dd791e 100644
--- a/crypto/evp/e_aes.c
+++ b/crypto/evp/e_aes.c
@@ -155,6 +155,8 @@ void AES_xts_decrypt(const char *inp, char *out, size_t len,
 # define HWAES_decrypt aes_p8_decrypt
 # define HWAES_cbc_encrypt aes_p8_cbc_encrypt
 # define HWAES_ctr32_encrypt_blocks aes_p8_ctr32_encrypt_blocks
+# define HWAES_xts_encrypt aes_p8_xts_encrypt
+# define HWAES_xts_decrypt aes_p8_xts_decrypt
 #endif
 
 #if     defined(AES_ASM) && !defined(I386_ONLY) &&      (  \
@@ -1008,6 +1010,12 @@ void HWAES_cbc_encrypt(const unsigned char *in, unsigned char *out,
 void HWAES_ctr32_encrypt_blocks(const unsigned char *in, unsigned char *out,
                                 size_t len, const AES_KEY *key,
                                 const unsigned char ivec[16]);
+void HWAES_xts_encrypt(const unsigned char *inp, unsigned char *out,
+                       size_t len, const AES_KEY *key1,
+                       const AES_KEY *key2, const unsigned char iv[16]);
+void HWAES_xts_decrypt(const unsigned char *inp, unsigned char *out,
+                       size_t len, const AES_KEY *key1,
+                       const AES_KEY *key2, const unsigned char iv[16]);
 #endif
 
 #define BLOCK_CIPHER_generic_pack(nid,keylen,flags)             \
@@ -1803,11 +1811,17 @@ static int aes_xts_init_key(EVP_CIPHER_CTX *ctx, const unsigned char *key,
                                           EVP_CIPHER_CTX_key_length(ctx) * 4,
                                           &xctx->ks1.ks);
                     xctx->xts.block1 = (block128_f) HWAES_encrypt;
+# ifdef HWAES_xts_encrypt
+                    xctx->stream = HWAES_xts_encrypt;
+# endif
                 } else {
                     HWAES_set_decrypt_key(key,
                                           EVP_CIPHER_CTX_key_length(ctx) * 4,
                                           &xctx->ks1.ks);
                     xctx->xts.block1 = (block128_f) HWAES_decrypt;
+# ifdef HWAES_xts_decrypt
+                    xctx->stream = HWAES_xts_decrypt;
+#endif
                 }
 
                 HWAES_set_encrypt_key(key + EVP_CIPHER_CTX_key_length(ctx) / 2,

From rt at openssl.org  Wed May 25 21:26:12 2016
From: rt at openssl.org (Richard Levitte via RT)
Date: Wed, 25 May 2016 21:26:12 +0000
Subject: [openssl-dev] [openssl.org #4489] PATCH: fix Windows deprecated
	strdup in crypto\conf\conf_lib.c
In-Reply-To: <rt-4.0.19-7017-1459252961-1610.4489-6-0@openssl.org>
References: <RT-Ticket-4489@openssl.org>
 <CAH8yC8kH=fo1qywG6FuRv0bZeNC06jELmXQmtDLeSgjp+Boj5w@mail.gmail.com>
 <rt-4.0.19-28875-1459154290-371.4489-21-0@openssl.org>
 <8D8F432F-5C2B-43D5-B709-FA144D91B1F2@dukhovni.org>
 <rt-4.0.19-2648-1459170990-1918.4489-6-0@openssl.org>
 <56FA6C32.6000004@openssl.org>
 <rt-4.0.19-28874-1459252232-35.4489-6-0@openssl.org>
 <CAH8yC8kXjXuM8gs56WTiiYLqvf2vK2wBhSH8swtTfjW=vbBsxA@mail.gmail.com>
 <rt-4.0.19-7017-1459252961-1610.4489-6-0@openssl.org>
Message-ID: <rt-4.0.19-18315-1464211572-171.4489-6-0@openssl.org>

On Tue Mar 29 12:02:41 2016, noloader at gmail.com wrote:
> >>> $ cat conf_lib.patch
> >>> diff --git a/crypto/conf/conf_lib.c b/crypto/conf/conf_lib.c
> >>> index f197714..7bc3ac0 100644
> >>> --- a/crypto/conf/conf_lib.c
> >>> +++ b/crypto/conf/conf_lib.c
> >>> @@ -392,7 +392,7 @@ void
> >>> OPENSSL_INIT_set_config_filename(OPENSSL_INIT_SETTINGS *settings,
> >>> const char *config_file)
> >>> {
> >>> free(settings->config_name);
> >>> - settings->config_name = config_file == NULL ? NULL :
> >>> strdup(config_file);
> >>> + settings->config_name = config_file == NULL ? NULL :
> >>> OPENSSL_strdup(config_file);
> >>> }
> >>> #endif
> >>
> >> If you're going to change strdup -> OPENSSL_strdup, then the
> >> previous
> >> line needs to also change free -> OPENSSL_free.
> >
> > Few lines up there is rationale for malloc/free and by association
> > strdup. Switching to OPENSSL_[strdup|malloc|free] goes against it. On
> > Windows one can/should switch to _strdup (it also solves another real
> > yet subtle problem, not just warning). If lack of strdup is concern
> > (relly? which Fedora, BSD, Linux can it be?), then one might have to
> > consider local few-liner implementation. And conf_sap.c suffers from
> > this too...
>
> The odd thing with this one was, the switch from strdup to _strdup
> should have occurred with the patch from Issue 4488 occurred. For some
> reason, the text substitution was not occurring, even after including
> the header "openssl/e_os.h" in conf_lib.c.

It should be just "e_os.h"

I just tried, and it worked. With your patch, no more ISO C++ function
warnings.

I'll make a pull request in a few...

>
> I'm probably missing some other interaction among the headers.
>
> For completeness, below is the thrust of the 4488 patch. If
> Microsoft's compiler is from Visual Studio 2003 or above, then follow
> Microsoft's recommendations reported in the warning.
>
> ***********
>
> $ git diff e_os.h > e_os.patch
> $ cat e_os.patch
> diff --git a/e_os.h b/e_os.h
> index f0a441e..1fe3ffb 100644
> --- a/e_os.h
> +++ b/e_os.h
> @@ -520,6 +520,13 @@ struct servent *PASCAL getservbyname(const char
> *, const char *);
> # if defined(OPENSSL_SYS_WINDOWS)
> # define strcasecmp _stricmp
> # define strncasecmp _strnicmp
> +# if (_MSC_VER >= 1310)
> +# define open _open
> +# define fdopen _fdopen
> +# define close _close
> +# define strdup _strdup
> +# define unlink _unlink
> +# endif
>
> # elif defined(OPENSSL_SYS_VMS)
> /* VMS below version 7.0 doesn't have strcasecmp() */
> # include "internal/o_str.h"


--
Richard Levitte
levitte at openssl.org

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


From rt at openssl.org  Wed May 25 21:42:40 2016
From: rt at openssl.org (Richard Levitte via RT)
Date: Wed, 25 May 2016 21:42:40 +0000
Subject: [openssl-dev] [openssl.org #4488] PATCH: fix Windows "The POSIX
	name for this item is deprecated. Instead,
	use the ISO C++ conformant name..."
In-Reply-To: <CAH8yC8nk+39mvT34Eu1_YN_8X3iCci3yNh40+n6G6bJ1Lg9i=g@mail.gmail.com>
References: <RT-Ticket-4488@openssl.org>
 <CAH8yC8nk+39mvT34Eu1_YN_8X3iCci3yNh40+n6G6bJ1Lg9i=g@mail.gmail.com>
Message-ID: <rt-4.0.19-18315-1464212560-1208.4488-6-0@openssl.org>

Patch applied, https://github.com/openssl/openssl/pull/1129

Furthermore, I merged ticket 4488 and 4489, because the solution is all in the
same commit.

--
Richard Levitte
levitte at openssl.org

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


From rt at openssl.org  Wed May 25 21:46:02 2016
From: rt at openssl.org (Richard Levitte via RT)
Date: Wed, 25 May 2016 21:46:02 +0000
Subject: [openssl-dev] [openssl.org #4458] "implicitly declared function"
	warnings due to missing <strings.h> include
In-Reply-To: <CAH8yC8m0CgDJ3nBaOo1LbSNRz7nParnc72-mDxC1wasqTcXepg@mail.gmail.com>
References: <RT-Ticket-4458@openssl.org>
 <CAH8yC8m0CgDJ3nBaOo1LbSNRz7nParnc72-mDxC1wasqTcXepg@mail.gmail.com>
Message-ID: <rt-4.0.19-18315-1464212761-602.4458-6-0@openssl.org>

I don't get such warnings. Can you tell me what system and with what tool chain
(including versions)?

On Sun Mar 20 13:07:43 2016, noloader at gmail.com wrote:
> The missing <strings.h> include caused a number of "implicitly
> declared function" warnings due to use of strcmpcase and strncmpcase.
>
> $ egrep -IR '(strcasecmp|strncasecmp)' * | cut -f 1 -d ':' | sort | uniq
> apps/apps.c
> apps/ca.c
> apps/ocsp.c
> apps/rehash.c
> apps/s_server.c
> crypto/asn1/ameth_lib.c
> crypto/engine/tb_asnmth.c
> crypto/o_str.c
> crypto/x509v3/v3_ncons.c
> crypto/x509v3/v3_tlsf.c
> crypto/x509v3/v3_utl.c
> e_os.h
> include/internal/o_str.h
> ssl/ssl_conf.c
> test/ssltest.c
> test/v3nametest.c
>


--
Richard Levitte
levitte at openssl.org

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


From brian at briansmith.org  Wed May 25 21:55:34 2016
From: brian at briansmith.org (Brian Smith)
Date: Wed, 25 May 2016 11:55:34 -1000
Subject: [openssl-dev] Making assembly language optimizations working on
	Cortex-M3
In-Reply-To: <56056D20.9020806@openssl.org>
References: <CAFewVt5Uy0grGbx-wKjoC2VyTGC9kkyO0bjMuub8BW=kKgU4nQ@mail.gmail.com>
 <55C4DC74.6060900@openssl.org>
 <CAFewVt6eVFgbHenDoy9WQD69hnk4qpWZFUmbuOzA86+=YzH=iA@mail.gmail.com>
 <55C873B8.9060602@openssl.org> <56056D20.9020806@openssl.org>
Message-ID: <CAFewVt51vSR3MC8pjBw9Pj=9ZRUPmMes_Qc0=-E0A18iesoa_g@mail.gmail.com>

[Sorry for the **long** delay in responding.]

Andy Polyakov <appro at openssl.org> wrote:

>
> http://git.openssl.org/gitweb/?p=openssl.git;a=commitdiff;h=11208dcfb9105e8afa37233185decefd45e89e17
> made whole assembly pack Thumb2-friendly, so that now you should be able
> to compile all modules. Please, double-check.


This is awesome!

I have a question about the `it` and `itt` instructions you inserted. You
wrapped them in `#ifdef __thumb2__`, which is not wrong, but AFAICT is
usually unnecessary. Is this to support some old assemblers that don't
compile `it` (etc.) into nothing for non-Thumb builds?


> There is no option to
> disable NEON (yet?), because a) I want to expose it to more build cases
> to catch eventual bugs; b) would like to suggest idea of supporting
> Cortex-M with -march=armv6t2 -mthumb. Latter means that you'll loose
> some performance, because it won't utilize word load instruction's
> capability to handle misaligned access in ARMv7. But on the other hand
> it won't have ideas about compiling NEON, and you'll be excused to think
> about which particular Cortex-M is targeted, one will be able to cover
> all with single config/buid. Can it be viable compromise? One would
> still be able to tune for favorite Mx...


For Cortex-M4 and friends, one would really want to use the full
ARMv7-M instruction
set (i.e. not compile for armv6t2). In general Cortex-M platforms are so
limited that every bit of performance and space savings matters. So, I
think it is definitely worthwhile to support the non-NEON ARMv7-M
configuration. One easy way to do this would be to avoid building NEON code
when __TARGET_PROFILE_M is defined. Alternatively, similar to what
BoringSSL did, you could have an option that says "instead of doing runtime
feature detection, instead detect features at compile time based on
__ARM_NEON__ and the like." I think such a configuration would also help
the C compiler do whole-program optimization better.

Again, thanks for doing this!

Cheers,
Brian
-- 
https://briansmith.org/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20160525/8b8168dd/attachment.html>

From appro at openssl.org  Wed May 25 22:25:35 2016
From: appro at openssl.org (Andy Polyakov)
Date: Thu, 26 May 2016 00:25:35 +0200
Subject: [openssl-dev] Making assembly language optimizations working on
 Cortex-M3
In-Reply-To: <CAFewVt51vSR3MC8pjBw9Pj=9ZRUPmMes_Qc0=-E0A18iesoa_g@mail.gmail.com>
References: <CAFewVt5Uy0grGbx-wKjoC2VyTGC9kkyO0bjMuub8BW=kKgU4nQ@mail.gmail.com>
 <55C4DC74.6060900@openssl.org>
 <CAFewVt6eVFgbHenDoy9WQD69hnk4qpWZFUmbuOzA86+=YzH=iA@mail.gmail.com>
 <55C873B8.9060602@openssl.org> <56056D20.9020806@openssl.org>
 <CAFewVt51vSR3MC8pjBw9Pj=9ZRUPmMes_Qc0=-E0A18iesoa_g@mail.gmail.com>
Message-ID: <56b00a41-ed5f-4998-b0fb-55a6a39e4544@openssl.org>

> 
>     http://git.openssl.org/gitweb/?p=openssl.git;a=commitdiff;h=11208dcfb9105e8afa37233185decefd45e89e17
>     made whole assembly pack Thumb2-friendly, so that now you should be able
>     to compile all modules. Please, double-check.
> 
> 
> This is awesome!
> 
> I have a question about the `it` and `itt` instructions you inserted.
> You wrapped them in `#ifdef __thumb2__`, which is not wrong, but AFAICT
> is usually unnecessary. Is this to support some old assemblers that
> don't compile `it` (etc.) into nothing for non-Thumb builds?

Yes. Note that #ifdefs are normally omitted in NEON code paths, because
assemblers capable of assembling NEON code are assumed to handle even
'it' without __thumb2__.

>     There is no option to
>     disable NEON (yet?), because a) I want to expose it to more build cases
>     to catch eventual bugs; b) would like to suggest idea of supporting
>     Cortex-M with -march=armv6t2 -mthumb. Latter means that you'll loose
>     some performance, because it won't utilize word load instruction's
>     capability to handle misaligned access in ARMv7. But on the other hand
>     it won't have ideas about compiling NEON, and you'll be excused to think
>     about which particular Cortex-M is targeted, one will be able to cover
>     all with single config/buid. Can it be viable compromise? One would
>     still be able to tune for favorite Mx...
> 
> 
> For Cortex-M4 and friends, one would really want to use the
> full ARMv7-M instruction set (i.e. not compile for armv6t2). In general
> Cortex-M platforms are so limited that every bit of performance and
> space savings matters. So, I think it is definitely worthwhile to
> support the non-NEON ARMv7-M configuration. One easy way to do this
> would be to avoid building NEON code when __TARGET_PROFILE_M is defined.

I don't see no __TARGET_PROFILE_M defined by gcc... Or do you mean that
*we* can be defined in arm_arch.h? Or maybe you are talking about ARM's
compiler... Anyway, care to make a suggestion in form of patch? That
would be suitable even for gcc? [Just in case, no, I don't have ARM's
compiler, only its manual.]

> Alternatively, similar to what BoringSSL did, you could have an option
> that says "instead of doing runtime feature detection, instead detect
> features at compile time based on __ARM_NEON__ and the like." I think
> such a configuration would also help the C compiler do whole-program
> optimization better.

I doubt that, because compiler doesn't look at assembly modules.


From brian at briansmith.org  Wed May 25 22:47:28 2016
From: brian at briansmith.org (Brian Smith)
Date: Wed, 25 May 2016 12:47:28 -1000
Subject: [openssl-dev] Making assembly language optimizations working on
	Cortex-M3
In-Reply-To: <56b00a41-ed5f-4998-b0fb-55a6a39e4544@openssl.org>
References: <CAFewVt5Uy0grGbx-wKjoC2VyTGC9kkyO0bjMuub8BW=kKgU4nQ@mail.gmail.com>
 <55C4DC74.6060900@openssl.org>
 <CAFewVt6eVFgbHenDoy9WQD69hnk4qpWZFUmbuOzA86+=YzH=iA@mail.gmail.com>
 <55C873B8.9060602@openssl.org> <56056D20.9020806@openssl.org>
 <CAFewVt51vSR3MC8pjBw9Pj=9ZRUPmMes_Qc0=-E0A18iesoa_g@mail.gmail.com>
 <56b00a41-ed5f-4998-b0fb-55a6a39e4544@openssl.org>
Message-ID: <CAFewVt62ktb43T7WdAfoHbR_NfGpB46_Po+rbqRcvPMmNT=4cg@mail.gmail.com>

Andy Polyakov <appro at openssl.org> wrote:

> > Cortex-M platforms are so limited that every bit of performance and
> > space savings matters. So, I think it is definitely worthwhile to
> > support the non-NEON ARMv7-M configuration. One easy way to do this
> > would be to avoid building NEON code when __TARGET_PROFILE_M is defined.
>
> I don't see no __TARGET_PROFILE_M defined by gcc


I see. I didn't realize that GCC didn't emulate this ARM compiler feature.
Never mind.


> Anyway, care to make a suggestion in form of patch? That
> would be suitable even for gcc? [Just in case, no, I don't have ARM's
> compiler, only its manual.]
>

I can try to make a patch to bring BoringSSL's OPENSSL_STATIC_ARMCAP
mechanism to OpenSSL, if you think that is an OK approach.


> > Alternatively, similar to what BoringSSL did, you could have an option
> > that says "instead of doing runtime feature detection, instead detect
> > features at compile time based on __ARM_NEON__ and the like." I think
> > such a configuration would also help the C compiler do whole-program
> > optimization better.
>
> I doubt that, because compiler doesn't look at assembly modules.


For example, in the AES-GCM code, there is a runtime check to decide
between various implementations. With the OPENSSL_STATIC_ARMCAP-like
approach, in theory the compiler's constant propagation and dead code
elimination can work together to automatically optimize away the code paths
that aren't applicable to the current configuration, without needing to
maintain lots of #ifdefs.

Cheers,
Brian
-- 
https://briansmith.org/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20160525/a547b678/attachment.html>

From rt at openssl.org  Wed May 25 22:49:21 2016
From: rt at openssl.org (Richard Levitte via RT)
Date: Wed, 25 May 2016 22:49:21 +0000
Subject: [openssl-dev] [openssl.org #4488] PATCH: fix Windows "The POSIX
	name for this item is deprecated. Instead,
	use the ISO C++ conformant name..."
In-Reply-To: <rt-4.0.19-18315-1464212560-1076.4488-6-0@openssl.org>
References: <RT-Ticket-4488@openssl.org>
 <CAH8yC8nk+39mvT34Eu1_YN_8X3iCci3yNh40+n6G6bJ1Lg9i=g@mail.gmail.com>
 <rt-4.0.19-18315-1464212560-1076.4488-6-0@openssl.org>
Message-ID: <rt-4.0.19-18315-1464216561-308.4488-6-0@openssl.org>

This has made it to master. Closing this ticket.

Cheers,
Richard

On Wed May 25 21:42:40 2016, levitte wrote:
> Patch applied, https://github.com/openssl/openssl/pull/1129
>
> Furthermore, I merged ticket 4488 and 4489, because the solution is
> all in the
> same commit.
>
> --
> Richard Levitte
> levitte at openssl.org


--
Richard Levitte
levitte at openssl.org

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


From rt at openssl.org  Wed May 25 22:50:54 2016
From: rt at openssl.org (Matt Caswell via RT)
Date: Wed, 25 May 2016 22:50:54 +0000
Subject: [openssl-dev] [openssl.org #4501] bug in BN_mod_word
In-Reply-To: <CAO1trb2WYS_cm_qoUAnsKO34=x8E3846EEGL=8mBdwN_eRnfNw@mail.gmail.com>
References: <RT-Ticket-4501@openssl.org>
 <CAO1trb2WYS_cm_qoUAnsKO34=x8E3846EEGL=8mBdwN_eRnfNw@mail.gmail.com>
Message-ID: <rt-4.0.19-23362-1464216654-578.4501-6-0@openssl.org>

On Thu Apr 07 11:44:09 2016, peter.chernyshev at gmail.com wrote:
> ?????? ????!
> ????????? ?????????? BN_mod_word
> BN_ULONG BN_mod_word(const BIGNUM *a, BN_ULONG w);
>
> ???????? ??????? ?? 64 ??? ?????? ??? ????????? w>2^32, ???? ????????? ???
> BN_ULONG (64 ????).
>
> ????
>
> Hello!
> BN part program
>
> BN_ULONG BN_mod_word (const BIGNUM * a, BN_ULONG w);
>
> does not work properly on 64-bit machine with some w> 2 ^ 32, although
> declared as BN_ULONG (64 bits).

Hello

Do you have a test case for this that demonstrates this problem?

Thanks

Matt

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


From brian at briansmith.org  Wed May 25 22:52:17 2016
From: brian at briansmith.org (Brian Smith)
Date: Wed, 25 May 2016 12:52:17 -1000
Subject: [openssl-dev] Why is `volatile` used in
	MOD_EXP_CTIME_COPY_FROM_PREBUF?
Message-ID: <CAFewVt6veq_LtS0z09rrsvjAoZwFV1mPJJFBCLJRF+xro+je2A@mail.gmail.com>

See
https://github.com/openssl/openssl/commit/d6482a82bc2228327aa4ba98aeeecd9979542a31#diff-3aca3afd18ad75a8f6a09a9860bc6ef5R631

+ volatile BN_ULONG *table = (volatile BN_ULONG *)buf;

Why is `volatile` used here? Is it to work around the effective type
(strict aliasing) violations or for some other reason? I think it would be
good to document this, or better, find a way to avoid needing to use
`volatile` in the first place.

Thanks,
Brian
-- 
https://briansmith.org/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20160525/d47b29fe/attachment.html>

From brian at briansmith.org  Thu May 26 01:12:01 2016
From: brian at briansmith.org (Brian Smith)
Date: Wed, 25 May 2016 15:12:01 -1000
Subject: [openssl-dev] Syncing OpenSSL and BoringSSL mont ASM code
Message-ID: <CAFewVt7pSjfmfztaoXFKMvurKmDHe1D36ipSpBssh+XAm9eQYQ@mail.gmail.com>

1. Please see
https://boringssl.googlesource.com/boringssl/+/75b833cc819a9d189adb0fdd56327bee600ff9e9
.

I think it would be good for OpenSSL to work with Google to integrate this
patch.

2. Is the `__chkstk` code that was added [1] to `bn_mul_mont` really
necessary? I noticed that when BoringSSL integrated the patch to fix the
constant-timedness issues in bn_mul_mont, it omitted the __chkstk stuff.
Even after reading the code and the comments, it still isn't clear to me
how/why it matters.

[1]
https://github.com/openssl/openssl/commit/adc4f1fc25b2cac90076f1e1695b05b7aeeae501

Thanks,
Brian
-- 
https://briansmith.org/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20160525/857f9aa5/attachment.html>

From openssl-users at dukhovni.org  Thu May 26 01:39:33 2016
From: openssl-users at dukhovni.org (Viktor Dukhovni)
Date: Thu, 26 May 2016 01:39:33 +0000
Subject: [openssl-dev] [openssl.org #4458] "implicitly declared
 function" warnings due to missing <strings.h> include
In-Reply-To: <rt-4.0.19-18315-1464212761-602.4458-6-0@openssl.org>
References: <RT-Ticket-4458@openssl.org>
 <CAH8yC8m0CgDJ3nBaOo1LbSNRz7nParnc72-mDxC1wasqTcXepg@mail.gmail.com>
 <rt-4.0.19-18315-1464212761-602.4458-6-0@openssl.org>
Message-ID: <20160526013933.GE3300@mournblade.imrryr.org>

On Wed, May 25, 2016 at 09:46:02PM +0000, Richard Levitte via RT wrote:

> I don't get such warnings. Can you tell me what system and with what tool chain
> (including versions)?

I think that the report is correct, we must be getting away with <string.h>
on most platforms.  On NetBSD, for example, <string.h> includes <strings.h>
when _NETBSD_SOURCE is defined true, which requires:

    #if !defined(_ANSI_SOURCE) && !defined(_POSIX_C_SOURCE) && \
	!defined(_XOPEN_SOURCE) && !defined(_NETBSD_SOURCE)
    #define _NETBSD_SOURCE 1
    #endif

So generally you get the extended features, but not always.  The
fix might be:

diff --git a/e_os.h b/e_os.h
index 1c4c204..4b3e6fd 100644
--- a/e_os.h
+++ b/e_os.h
@@ -475,6 +475,8 @@ struct servent *PASCAL getservbyname(const char *, const char *);
 #  define strcasecmp OPENSSL_strcasecmp
 #  define strncasecmp OPENSSL_strncasecmp
 #  define OPENSSL_IMPLEMENTS_strncasecmp
+# else
+#  include <strings.h>
 # endif
 
 /* vxworks */

-- 
	Viktor.

From angus at magsys.co.uk  Thu May 26 13:44:00 2016
From: angus at magsys.co.uk (Angus Robertson - Magenta Systems Ltd)
Date: Thu, 26 May 2016 14:44 +0100 (BST)
Subject: [openssl-dev] 1.1.0 pre5 seems to ignore CIPHER_SERVER_PREFERENCE
Message-ID: <memo.20160526144452.1028A@magsys.adsl.magsys.co.uk>

I have two custom Windows web sites, running released and beta versions
of OpenSSL.  The beta version only gets an A- score with SSL Labs,
whereas the release version gets A+.  

https://www1.telecom-tariffs.co.uk/serverinfo.htm

shows server status, and that it's running OpenSSL 1.1.0-pre5 (beta) 19
Apr 2016, SSL Labs says: 'Cipher Suites (sorted by strength as the
server has no preference;)  The server does not support Forward Secrecy
with the reference browsers. Grade reduced to A-.'

https://www.telecom-tariffs.co.uk/serverinfo.htm

is the main live server running OpenSSL 1.0.2h 3 May 2016, and gets a
score A+ saying 'Cipher Suites (SSL 3+ suites in server-preferred
order)'. 

The application is identical with CIPHER_SERVER_PREFERENCE specified
and a Mozilla intermediate cipher list (shown on the status page), but
SSL Labs suggests there is no server preference so forward security
ciphers are not prioritised. 

The OpenSSL implementation is for Windows Embarcadero Delphi and the
free ICS internet component suite which I support, it uses our own
Pascal version of the OpenSSL C header files, originally created 10
years ago and updated for each new OpenSSL release, so there is a risk
we might miss subtle header changes like constants changing.

I realise pre5 is a month old, but can not see this issued raised in
the last month.   

Angus
 



From rt at openssl.org  Thu May 26 16:07:34 2016
From: rt at openssl.org (Matt Caswell via RT)
Date: Thu, 26 May 2016 16:07:34 +0000
Subject: [openssl-dev] [openssl.org #4180] Isses with respect to malloc
	failures handling.
In-Reply-To: <DM2PR05MB44897C90A69988BF95E3E52CCED0@DM2PR05MB448.namprd05.prod.outlook.com>
References: <RT-Ticket-4180@openssl.org>
 <DM2PR05MB44897C90A69988BF95E3E52CCED0@DM2PR05MB448.namprd05.prod.outlook.com>
Message-ID: <rt-4.0.19-23362-1464278854-1114.4180-6-0@openssl.org>

You don't say what version of OpenSSL you were testing. It seems to be either
1.0.2 or 1.0.1 (not master). Anyway, comments inserted.

On Mon Dec 14 13:45:20 2015, skoripella at juniper.net wrote:
> Issue 1)
> We could have failed to allocate the ctx->cipher_data in
> EVP_CipherInit_ex
>
> ctx->cipher_data = OPENSSL_malloc(ctx->cipher->ctx_size);
> if (!ctx->cipher_data) {
> EVPerr(EVP_F_EVP_CIPHERINIT_EX, ERR_R_MALLOC_FAILURE);
> return 0;
> }
>
> We do subsequently return error from EVP_CipherInit_ex. However during
> shutdown because of this error we are not checking for the NULL
> cipher_data causing cores

This seems very strange to me. If we have already returned a fatal error...then
its just that - fatal. Don't try and do a graceful shutdown on an already dead
connection.

>
========================================================================================
> Issue 2
> In file pmeth_gn.c function EVP_PKEY_keygen, openssl code tries to
> allocate EVP_PKEY using EVP_PKEY_new and immediately follows with a
> dereference of the same in the below path without checking if the
> allocation was successful or not.

Fixed in 8e0a94a58.

> Issue 3:
>
> In file s3_enc.c in function ssl3_digest_cached_records,
> EVP_DigestInit_ex is called to initialize the EVP digest. Internally
> to EVP_DigestInit_ex ctx->md_data is allocated and if it fails an
> error is returned. However in ssl3_digest_cached_records the return
> value is not checked, causing a null dereference with the below

Fixed in ada5de7c and similar commit in master (this was the only one
applicable to master BTW).


> Issue 4:
> In file ssl_lib.c, in function ssl_replace_hash, an EVP_MD_CTX is
> created using EVP_MD_CTX_create. However, the return value of this
> allocation is not checked and a dereference is made just below in
> EVP_DigestInit_ex causing a core.

This was fixed in 56d9134675 which was commited a few weeks before the date of
your report.

>
=======================================================================================
> Issue 5:
> In tl_enc.c, in function tls1_enc in the case of
> /\* Explicit IV length, block ciphers and TLS version 1.1 or later \*/
> openssl tries to dereference cipher after getting the value of cipher
> from s->enc_write_ctx. However cipher can be null. This can happen
> because we returned NULL in Issue 4) above and s->enc_write_ctx-
> >cipher might not have been set. Typically
> s->enc_write_ctx->cipher would have been set in the below path but
> because of Issue 4 above we did not set s->enc_write_ctx->cipher.

Issue 4 above resulted in a core if it failed...so this confuses me! Anyway I
could not see how this could occur if Issue 4 fails more gracefully. All
callers of ssl_replace_hash propagate the error. Perhaps an issue similar to
issue 1 above? Or maybe its been fixed since. I'm assuming this is no longer an
issue. Please raise a new ticket if it is.

> Issue 6:
> Similar issue as above exists in s3_pkt.c function do_ssl3_write in
> the case
> /\* Explicit IV length, block ciphers and TLS version 1.1 or later \*/
> where again s->enc_write_ctx->cipher can be NULL.

As for issue 5.

>
=======================================================================================
> Issue 7:
> In file t1_enc.c, in function tls1_mac, openssl after calling
> EVP_DigestSignFinal has an assert on the return value to be greater
> than 0. However, EVP_DigestSignFinal internally allocates memory and
> if this memory allocation fails, an error is returned. Hence this
> assert is overaggressive for low memory cases. So Pls see if instead
> of coring, the error can be handled gracefully.

This was fixed in the same commit mentioned above that was committed a few
weeks before your report.

>
========================================================================================
> Issue 8:
> In file t1_enc.c, in function tls1_setup_key_block, memory is
> allocated twice for the keyblock through p1 and p2. If p1 succeeds but
> p2 fails, p1 is freed but the freed pointer p1 is left dangling inside
> s->s3->tmp.key_block which is later attempted to be freed while
> freeing s->s3 resulting in a double free.
> The fix would be to set the s->s3->tmp.key_block to NULL

This was fixed in ec8f246e6ed4 a few weeks ago.

Closing this ticket.

Matt

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


From appro at openssl.org  Thu May 26 19:02:21 2016
From: appro at openssl.org (Andy Polyakov)
Date: Thu, 26 May 2016 21:02:21 +0200
Subject: [openssl-dev] Making assembly language optimizations working on
 Cortex-M3
In-Reply-To: <CAFewVt62ktb43T7WdAfoHbR_NfGpB46_Po+rbqRcvPMmNT=4cg@mail.gmail.com>
References: <CAFewVt5Uy0grGbx-wKjoC2VyTGC9kkyO0bjMuub8BW=kKgU4nQ@mail.gmail.com>
 <55C4DC74.6060900@openssl.org>
 <CAFewVt6eVFgbHenDoy9WQD69hnk4qpWZFUmbuOzA86+=YzH=iA@mail.gmail.com>
 <55C873B8.9060602@openssl.org> <56056D20.9020806@openssl.org>
 <CAFewVt51vSR3MC8pjBw9Pj=9ZRUPmMes_Qc0=-E0A18iesoa_g@mail.gmail.com>
 <56b00a41-ed5f-4998-b0fb-55a6a39e4544@openssl.org>
 <CAFewVt62ktb43T7WdAfoHbR_NfGpB46_Po+rbqRcvPMmNT=4cg@mail.gmail.com>
Message-ID: <738e4039-092b-9a64-01b6-c60aab0a5769@openssl.org>

>     > Cortex-M platforms are so limited that every bit of performance and
>     > space savings matters. So, I think it is definitely worthwhile to
>     > support the non-NEON ARMv7-M configuration. One easy way to do this
>     > would be to avoid building NEON code when __TARGET_PROFILE_M is defined.
> 
>     I don't see no __TARGET_PROFILE_M defined by gcc
> 
> 
> I see. I didn't realize that GCC didn't emulate this ARM compiler
> feature. Never mind.

But gcc defines __ARM_ARCH_7M__, which can be used to e.g.

#if !defined(__TARGET_PROFILE_M) && defined(__ARM_ARCH_7M__)
# define __TARGET_PROFILE_M
#endif

>     Anyway, care to make a suggestion in form of patch? That
>     would be suitable even for gcc? [Just in case, no, I don't have ARM's
>     compiler, only its manual.]
> 
> 
> I can try to make a patch to bring BoringSSL's OPENSSL_STATIC_ARMCAP
> mechanism to OpenSSL, if you think that is an OK approach.

I don't understand. Original question was about conditional *omission*
of NEON code (which incidentally means even omission of run-time
switches), while BoringSSL's OPENSSL_STATIC_ARMCAP is about *keeping*
NEON as well as run-time switch *code*, just setting OPENSSL_armcap_P to
a chosen value at compile time... I mean it looks like we somehow
started to talk about different things... When I wrote "care to make
suggestion" I was thinking about going through all #if __ARM_ARCH__>=7
and complementing some of them with !defined(something_M)...

>     > Alternatively, similar to what BoringSSL did, you could have an option
>     > that says "instead of doing runtime feature detection, instead detect
>     > features at compile time based on __ARM_NEON__ and the like." I think
>     > such a configuration would also help the C compiler do whole-program
>     > optimization better.
> 
>     I doubt that, because compiler doesn't look at assembly modules.
> 
> 
> For example, in the AES-GCM code, there is a runtime check to decide
> between various implementations. With the OPENSSL_STATIC_ARMCAP-like
> approach, in theory the compiler's constant propagation and dead code
> elimination can work together to automatically optimize away the code
> paths that aren't applicable to the current configuration, without
> needing to maintain lots of #ifdefs.

Compiler might remove dead code it would generate itself, but it still
won't omit anything from assembly module. Linker takes them in as
monolithic blocks.


From appro at openssl.org  Thu May 26 19:18:48 2016
From: appro at openssl.org (Andy Polyakov)
Date: Thu, 26 May 2016 21:18:48 +0200
Subject: [openssl-dev] Why is `volatile` used in
 MOD_EXP_CTIME_COPY_FROM_PREBUF?
In-Reply-To: <CAFewVt6veq_LtS0z09rrsvjAoZwFV1mPJJFBCLJRF+xro+je2A@mail.gmail.com>
References: <CAFewVt6veq_LtS0z09rrsvjAoZwFV1mPJJFBCLJRF+xro+je2A@mail.gmail.com>
Message-ID: <bcd94c5d-6453-8723-e1b7-99452dc4c3c1@openssl.org>

> See
> https://github.com/openssl/openssl/commit/d6482a82bc2228327aa4ba98aeeecd9979542a31#diff-3aca3afd18ad75a8f6a09a9860bc6ef5R631
> 
> + volatile BN_ULONG *table = (volatile BN_ULONG *)buf;
> 
> Why is `volatile` used here? Is it to work around the effective type
> (strict aliasing) violations or for some other reason?

Isn't it obvious? Volatile is there to discourage compiler from
reordering loads from the the table. I mean concern is that if reordered
in specific manner loads might give away the information we are trying
to conceal.

> I think it would
> be good to document this, or better, find a way to avoid needing to use
> `volatile` in the first place.

Well, the only guaranteed way is to implement it in assembly. Note that
on most popular/relevant platform it *is* implemented in assembly.


From appro at openssl.org  Thu May 26 20:06:37 2016
From: appro at openssl.org (Andy Polyakov)
Date: Thu, 26 May 2016 22:06:37 +0200
Subject: [openssl-dev] Syncing OpenSSL and BoringSSL mont ASM code
In-Reply-To: <CAFewVt7pSjfmfztaoXFKMvurKmDHe1D36ipSpBssh+XAm9eQYQ@mail.gmail.com>
References: <CAFewVt7pSjfmfztaoXFKMvurKmDHe1D36ipSpBssh+XAm9eQYQ@mail.gmail.com>
Message-ID: <27003f6c-a765-2c05-2c03-8eedc4969f52@openssl.org>

> 1. Please
> see https://boringssl.googlesource.com/boringssl/+/75b833cc819a9d189adb0fdd56327bee600ff9e9.
> 
> I think it would be good for OpenSSL to work with Google to integrate
> this patch.

Will be looked into...

> 2. Is the `__chkstk` code that was added [1] to `bn_mul_mont` really
> necessary?

The SEGV that is mentioned in the commit message and commentary was
actually observed and reported. Well, it's not called SEGV on Windows,
but equivalent has same devastating effect, i.e. application crash. It
takes super-long RSA key, longer than you'd normally use, so it's not
something that a lot of users risk suffering from. But the problem is
real nevertheless.


From tj at castaglia.org  Thu May 26 21:27:38 2016
From: tj at castaglia.org (TJ Saunders)
Date: Thu, 26 May 2016 14:27:38 -0700
Subject: [openssl-dev] How to get SSL version from SSL_SESSION using
	OpenSSL-1.1.x?
Message-ID: <1464298058.3088376.619962057.689B6D4E@webmail.messagingengine.com>


I'm currently working on updating proftpd and its various modules to
work with the changed APIs in OpenSSL-1.1.x.  My current obstacle(?) is
to determine the SSL protocol version, given an SSL_SESSION pointer.

Using OpenSSL-1.0.x, I currently use:

  ssl_version = sess->ssl_version;

However, I don't see an equivalent accessor in the 1.1.x APIs.  Have I
missed something, or does such a thing not exist yet?

Cheers,
TJ

From matt at openssl.org  Thu May 26 21:45:54 2016
From: matt at openssl.org (Matt Caswell)
Date: Thu, 26 May 2016 22:45:54 +0100
Subject: [openssl-dev] How to get SSL version from SSL_SESSION using
 OpenSSL-1.1.x?
In-Reply-To: <1464298058.3088376.619962057.689B6D4E@webmail.messagingengine.com>
References: <1464298058.3088376.619962057.689B6D4E@webmail.messagingengine.com>
Message-ID: <57476E92.7070503@openssl.org>



On 26/05/16 22:27, TJ Saunders wrote:
> 
> I'm currently working on updating proftpd and its various modules to
> work with the changed APIs in OpenSSL-1.1.x.  My current obstacle(?) is
> to determine the SSL protocol version, given an SSL_SESSION pointer.
> 
> Using OpenSSL-1.0.x, I currently use:
> 
>   ssl_version = sess->ssl_version;
> 
> However, I don't see an equivalent accessor in the 1.1.x APIs.  Have I
> missed something, or does such a thing not exist yet?

I don't think such a thing exists at the moment. Out of interest why do
you need it?

Matt


From tj at castaglia.org  Thu May 26 21:48:19 2016
From: tj at castaglia.org (TJ Saunders)
Date: Thu, 26 May 2016 14:48:19 -0700
Subject: [openssl-dev] How to get SSL version from SSL_SESSION using
 OpenSSL-1.1.x?
In-Reply-To: <57476E92.7070503@openssl.org>
References: <1464298058.3088376.619962057.689B6D4E@webmail.messagingengine.com>
 <57476E92.7070503@openssl.org>
Message-ID: <1464299299.3092961.619978617.76B8C729@webmail.messagingengine.com>



> > I'm currently working on updating proftpd and its various modules to
> > work with the changed APIs in OpenSSL-1.1.x.  My current obstacle(?) is
> > to determine the SSL protocol version, given an SSL_SESSION pointer.
> > 
> > Using OpenSSL-1.0.x, I currently use:
> > 
> >   ssl_version = sess->ssl_version;
> > 
> > However, I don't see an equivalent accessor in the 1.1.x APIs.  Have I
> > missed something, or does such a thing not exist yet?
> 
> I don't think such a thing exists at the moment. Out of interest why do
> you need it?

One of the modules maintains the server-side SSL session cache,
comprised of SSL_SESSION objects.  For debugging purposes, there's a
tool to dump out the sessions in the cache.  I had initially used
SSL_SESSION_print() for this dump utility, but that prints out more of
the session data (e.g. the master key) than I'd wanted.  Thus I ended up
writing my own code for printing out the fields of the SSL_SESSION which
I thought would be of interest -- including the protocol version of the
SSL_SESSION.

Cheers,
TJ

From matt at openssl.org  Thu May 26 21:52:22 2016
From: matt at openssl.org (Matt Caswell)
Date: Thu, 26 May 2016 22:52:22 +0100
Subject: [openssl-dev] How to get SSL version from SSL_SESSION using
 OpenSSL-1.1.x?
In-Reply-To: <1464299299.3092961.619978617.76B8C729@webmail.messagingengine.com>
References: <1464298058.3088376.619962057.689B6D4E@webmail.messagingengine.com>
 <57476E92.7070503@openssl.org>
 <1464299299.3092961.619978617.76B8C729@webmail.messagingengine.com>
Message-ID: <57477016.1070707@openssl.org>



On 26/05/16 22:48, TJ Saunders wrote:
> 
> 
>>> I'm currently working on updating proftpd and its various modules to
>>> work with the changed APIs in OpenSSL-1.1.x.  My current obstacle(?) is
>>> to determine the SSL protocol version, given an SSL_SESSION pointer.
>>>
>>> Using OpenSSL-1.0.x, I currently use:
>>>
>>>   ssl_version = sess->ssl_version;
>>>
>>> However, I don't see an equivalent accessor in the 1.1.x APIs.  Have I
>>> missed something, or does such a thing not exist yet?
>>
>> I don't think such a thing exists at the moment. Out of interest why do
>> you need it?
> 
> One of the modules maintains the server-side SSL session cache,
> comprised of SSL_SESSION objects.  For debugging purposes, there's a
> tool to dump out the sessions in the cache.  I had initially used
> SSL_SESSION_print() for this dump utility, but that prints out more of
> the session data (e.g. the master key) than I'd wanted.  Thus I ended up
> writing my own code for printing out the fields of the SSL_SESSION which
> I thought would be of interest -- including the protocol version of the
> SSL_SESSION.

That sounds fairly reasonable. I suggest raising a github pull request
to add the accessor (or just an issue if you prefer).

Matt


From openssl-users at dukhovni.org  Thu May 26 21:58:10 2016
From: openssl-users at dukhovni.org (Viktor Dukhovni)
Date: Thu, 26 May 2016 21:58:10 +0000
Subject: [openssl-dev] How to get SSL version from SSL_SESSION using
 OpenSSL-1.1.x?
In-Reply-To: <57476E92.7070503@openssl.org>
References: <1464298058.3088376.619962057.689B6D4E@webmail.messagingengine.com>
 <57476E92.7070503@openssl.org>
Message-ID: <20160526215809.GJ3300@mournblade.imrryr.org>

On Thu, May 26, 2016 at 10:45:54PM +0100, Matt Caswell wrote:

> > Using OpenSSL-1.0.x, I currently use:
> > 
> >   ssl_version = sess->ssl_version;
> > 
> > However, I don't see an equivalent accessor in the 1.1.x APIs.  Have I
> > missed something, or does such a thing not exist yet?
> 
> I don't think such a thing exists at the moment. Out of interest why do
> you need it?

The following should work:

    const char *get_session_protocol(SSL_CTX *ctx, SSL_SESSION *session)
    {
	const char *protocol;
	SSL_CTX *tmp_ctx = NULL;

	/* Typically you'd pass in a suitable non-NULL ctx */
	if (ctx == NULL)
	    ctx = tmp_ctx = SSL_CTX_new(TLS_method());

	ssl = SSL_new(ctx);
	SSL_set_session(ssl, session);
	protocol = SSL_get_version(ssl);

	SSL_free(ssl);
	SSL_CTX_free(tmp_ctx);

	return protocol;
    }

-- 
	Viktor.

From openssl-users at dukhovni.org  Thu May 26 22:14:48 2016
From: openssl-users at dukhovni.org (Viktor Dukhovni)
Date: Thu, 26 May 2016 22:14:48 +0000
Subject: [openssl-dev] How to get SSL version from SSL_SESSION using
 OpenSSL-1.1.x?
In-Reply-To: <20160526215809.GJ3300@mournblade.imrryr.org>
References: <1464298058.3088376.619962057.689B6D4E@webmail.messagingengine.com>
 <57476E92.7070503@openssl.org>
 <20160526215809.GJ3300@mournblade.imrryr.org>
Message-ID: <20160526221448.GL3300@mournblade.imrryr.org>

On Thu, May 26, 2016 at 09:58:09PM +0000, Viktor Dukhovni wrote:

> The following should work:
> 
>     const char *get_session_protocol(SSL_CTX *ctx, SSL_SESSION *session)
>     {
> 	const char *protocol;
> 	SSL_CTX *tmp_ctx = NULL;
> 
> 	/* Typically you'd pass in a suitable non-NULL ctx */
> 	if (ctx == NULL)
> 	    ctx = tmp_ctx = SSL_CTX_new(TLS_method());
> 
> 	ssl = SSL_new(ctx);
> 	SSL_set_session(ssl, session);
> 	protocol = SSL_get_version(ssl);
> 
> 	SSL_free(ssl);
> 	SSL_CTX_free(tmp_ctx);
> 
> 	return protocol;
>     }

But it does not, sorry about that.  The session version is not
directly copied to the SSL object.

-- 
	Viktor.

From tj at castaglia.org  Thu May 26 22:43:00 2016
From: tj at castaglia.org (TJ Saunders)
Date: Thu, 26 May 2016 15:43:00 -0700
Subject: [openssl-dev] How to get SSL version from SSL_SESSION using
 OpenSSL-1.1.x?
In-Reply-To: <57477016.1070707@openssl.org>
References: <1464298058.3088376.619962057.689B6D4E@webmail.messagingengine.com>
 <57476E92.7070503@openssl.org>
 <1464299299.3092961.619978617.76B8C729@webmail.messagingengine.com>
 <57477016.1070707@openssl.org>
Message-ID: <1464302580.3105739.620016817.31B73F1A@webmail.messagingengine.com>



On Thu, May 26, 2016, at 14:52, Matt Caswell wrote:

> > One of the modules maintains the server-side SSL session cache,
> > comprised of SSL_SESSION objects.  For debugging purposes, there's a
> > tool to dump out the sessions in the cache.  I had initially used
> > SSL_SESSION_print() for this dump utility, but that prints out more of
> > the session data (e.g. the master key) than I'd wanted.  Thus I ended up
> > writing my own code for printing out the fields of the SSL_SESSION which
> > I thought would be of interest -- including the protocol version of the
> > SSL_SESSION.
> 
> That sounds fairly reasonable. I suggest raising a github pull request
> to add the accessor (or just an issue if you prefer).

Done; see:

  https://github.com/openssl/openssl/pull/1135

Thanks,
TJ


From openssl-users at dukhovni.org  Fri May 27 03:41:59 2016
From: openssl-users at dukhovni.org (Viktor Dukhovni)
Date: Thu, 26 May 2016 23:41:59 -0400
Subject: [openssl-dev] 1.1.0 pre5 seems to ignore
	CIPHER_SERVER_PREFERENCE
In-Reply-To: <memo.20160526144452.1028A@magsys.adsl.magsys.co.uk>
References: <memo.20160526144452.1028A@magsys.adsl.magsys.co.uk>
Message-ID: <3E83D5E2-1753-44A5-BC41-710B7A7E8CC1@dukhovni.org>


> On May 26, 2016, at 9:44 AM, Angus Robertson - Magenta Systems Ltd <angus at magsys.co.uk> wrote:
> 
> I have two custom Windows web sites, running released and beta versions
> of OpenSSL.  The beta version only gets an A- score with SSL Labs,
> whereas the release version gets A+.  
> 
> https://www1.telecom-tariffs.co.uk/serverinfo.htm
> 
> shows server status, and that it's running OpenSSL 1.1.0-pre5 (beta) 19
> Apr 2016, SSL Labs says: 'Cipher Suites (sorted by strength as the
> server has no preference;)  The server does not support Forward Secrecy
> with the reference browsers. Grade reduced to A-.'
> 
> https://www.telecom-tariffs.co.uk/serverinfo.htm
> 
> is the main live server running OpenSSL 1.0.2h 3 May 2016, and gets a
> score A+ saying 'Cipher Suites (SSL 3+ suites in server-preferred
> order)'.

Sites like SSL Labs sometimes have bugs, and also your server configuration
may lack DHE or ECDHE parameters.  In any case, OpenSSL 1.1.0 beta does support
server preference, and I don't think any recent commits either broke or fixed
this.

Testing against with Postfix compiled against HEAD I see:

   # postconf -e "tls_preempt_cipherlist = no"
   # postfix reload
   postfix/postfix-script: refreshing the Postfix mail system

   # posttls-finger -Lsummary -lencrypt -c -o "tls_medium_cipherlist = AES128-SHA:AES256-SHA" "[localhost]:25"
   posttls-finger: Untrusted TLS connection established to localhost[127.0.0.1]:25: TLSv1.2 with cipher AES128-SHA (128/128 bits)

   # postconf -e "tls_preempt_cipherlist = yes"
   # postfix reload
   postfix/postfix-script: refreshing the Postfix mail system
   # posttls-finger -Lsummary -lencrypt -c -o "tls_medium_cipherlist = AES128-SHA:AES256-SHA" "[localhost]:25"
   posttls-finger: Untrusted TLS connection established to localhost[127.0.0.1]:25: TLSv1.2 with cipher AES256-SHA (256/256 bits)

Which shows the server preference in effect for the second connection (AES256 used despite client's preference for AES128).

-- 
	Viktor.


From darshanmody at avaya.com  Fri May 27 09:11:26 2016
From: darshanmody at avaya.com (Mody, Darshan (Darshan))
Date: Fri, 27 May 2016 09:11:26 +0000
Subject: [openssl-dev] FIPs mode and openssl
Message-ID: <25D2EC755404B4409F263AC6D050FEBB25D53DF1@AZ-FFEXMB03.global.avaya.com>

Hi,



I have a query with regards to FIPS mode and use of Openssl. I have put my kernel image n FIPs mode using the documentation (https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Security_Guide/sect-Security_Guide-Federal_Standards_And_Regulations-Federal_Information_Processing_Standard.html)



Do I need to put the openssl in FIPs mode using the API FIPS_mode_set(1) or will by default the openssl will put itself in FIPS mode for my application. There are couple of application on the server we use openssl. Do I need to put each of the application openssl in FIPS mode or will it put itself in FIPS since the kernel is in FIPS mode.



Thanks

Darshan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20160527/d8a436ce/attachment-0001.html>

From marquess at openssl.com  Fri May 27 09:28:34 2016
From: marquess at openssl.com (Steve Marquess)
Date: Fri, 27 May 2016 05:28:34 -0400
Subject: [openssl-dev] FIPs mode and openssl
In-Reply-To: <25D2EC755404B4409F263AC6D050FEBB25D53DF1@AZ-FFEXMB03.global.avaya.com>
References: <25D2EC755404B4409F263AC6D050FEBB25D53DF1@AZ-FFEXMB03.global.avaya.com>
Message-ID: <57481342.60407@openssl.com>

On 05/27/2016 05:11 AM, Mody, Darshan (Darshan) wrote:
> Hi,
> 
>  
> 
> I have a query with regards to FIPS mode and use of Openssl. I have put
> my kernel image n FIPs mode using the documentation
> (https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Security_Guide/sect-Security_Guide-Federal_Standards_And_Regulations-Federal_Information_Processing_Standard.html)
> 
>  
> 
> Do I need to put the openssl in FIPs mode using the API FIPS_mode_set(1)
> or will by default the openssl will put itself in FIPS mode for my
> application. There are couple of application on the server we use
> openssl. Do I need to put each of the application openssl in FIPS mode
> or will it put itself in FIPS since the kernel is in FIPS mode.
> 
>  
> 
> Thanks
> 
> Darshan
> 
> 
> 


You are using the Red Hat FIPS module, not the OpenSSL one, so you'll
need to ask that vendor.

-Steve M.

-- 
Steve Marquess
OpenSSL Validation Services, Inc.
1829 Mount Ephraim Road
Adamstown, MD  21710
USA
+1 877 673 6775 s/b
+1 301 874 2571 direct
marquess at openssl.com
gpg/pgp key: http://openssl.com/docs/0x6D1892F5.asc

From rt at openssl.org  Fri May 27 09:37:33 2016
From: rt at openssl.org (Matt Caswell via RT)
Date: Fri, 27 May 2016 09:37:33 +0000
Subject: [openssl-dev] [openssl.org #2270] CVS HEAD: bugfix for BIO printf()
	code: floating point does not print + other wrongs in that code path
In-Reply-To: <AANLkTimD4hxjzkF9Y-pdlWvlZl_YDdBPelfUsCEJcZNw@mail.gmail.com>
References: <RT-Ticket-2270@openssl.org>
 <AANLkTimD4hxjzkF9Y-pdlWvlZl_YDdBPelfUsCEJcZNw@mail.gmail.com>
Message-ID: <rt-4.0.19-23362-1464341853-551.2270-6-0@openssl.org>

I applied this patch in part. The code has moved on since this was written and
this was from pre-reformat times so I added the changes that were still
applicable "manually". See commit 242073bdbc. Also properly implemented the %e
and %g format specifiers in commit d6056f085d. Finally I added a test for all
of this in f8f686ec1c.

Closing.

Matt

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


From beldmit at gmail.com  Fri May 27 09:44:02 2016
From: beldmit at gmail.com (Dmitry Belyavsky)
Date: Fri, 27 May 2016 12:44:02 +0300
Subject: [openssl-dev] [openssl.org #4545] Crash in crypto/rand/md_rand.c
In-Reply-To: <rt-4.0.19-1993-1463759389-386.4545-21-0@openssl.org>
References: <RT-Ticket-4545@openssl.org>
 <DB5PR0101MB1608B2BF4FDA7D1791AD17709E4B0@DB5PR0101MB1608.eurprd01.prod.exchangelabs.com>
 <rt-4.0.19-1993-1463759389-386.4545-21-0@openssl.org>
Message-ID: <CADqLbzL+utPi1mz=52eCW6VWw_a5q0wOk5=uaGhbYCCYFRSUfg@mail.gmail.com>

Hello,

I can confirm that I have seen a similar behavior in multi-thread
environment. Unfortunately, I do not have a script to reproduce it either.

On Fri, May 20, 2016 at 6:49 PM, Mick Saxton via RT <rt at openssl.org> wrote:

> Hi
>
> Before going any further I would like to state that I have only seen this
> problem when we have 10000 or more concurrent connections.
>
> Mostly we notice it on Windows but I have seen it on linux (Ubuntu).
>
> I first noticed it when using v1.0.2d but have seen it again since
> upgrading to v1.0.2h.
>
> It can happen in one of two places and results in a call to MD_Update with
> a negative value.
>
> I have come up with a temporary fix which avoids the possibility of
> crashing at the expense of some randomness.
> The system is very highly stressed at this point so debugging further is
> difficult.
>
> The fix I am using is probably not what you eventually will want to
> implement but it does improve stability.
>
> 273:            MD_Update(&m, &(state[st_idx]), (j - k) );
> Change to
> 273:            MD_Update(&m, &(state[st_idx]), (j - k) > 0 ? j - k : 1);
> // micks at 1e.com (j -k) must not be negative
>
> And
>
> 495:            MD_Update(&m, &(state[st_idx]), MD_DIGEST_LENGTH / 2 - k )
> Change to
> 495:            MD_Update(&m, &(state[st_idx]), MD_DIGEST_LENGTH / 2 - k >
> 0 ? MD_DIGEST_LENGTH / 2 - k : 1);  // micks at 1e.com (j -k) must not be
> negative
>
>
> I do have a test program which can reproduce this behaviour.
>
> If I can be of further help - please contact me by email.
>
> Regards
> Mick Saxton
>
> ________________________________
>
>
> Legal Notice: This email is intended only for the person(s) to whom it is
> addressed. If you are not an intended recipient and have received this
> message in error, please notify the sender immediately by replying to this
> email or calling +44(0) 2083269015 (UK) or +1 866 592 4214 (USA). This
> email and any attachments may be privileged and/or confidential. The
> unauthorized use, disclosure, copying or printing of any information it
> contains is strictly prohibited. The opinions expressed in this email are
> those of the author and do not necessarily represent the views of 1E Ltd.
> Nothing in this email will operate to bind 1E to any order or other
> contract.
>
> --
> Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4545
> Please log in as guest with password guest if prompted
>
>
> --
> openssl-dev mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
>
>


-- 
SY, Dmitry Belyavsky
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20160527/a4e6a8ca/attachment.html>

From rt at openssl.org  Fri May 27 09:44:12 2016
From: rt at openssl.org (Dmitry Belyavsky via RT)
Date: Fri, 27 May 2016 09:44:12 +0000
Subject: [openssl-dev] [openssl.org #4545] Crash in crypto/rand/md_rand.c
In-Reply-To: <CADqLbzL+utPi1mz=52eCW6VWw_a5q0wOk5=uaGhbYCCYFRSUfg@mail.gmail.com>
References: <RT-Ticket-4545@openssl.org>
 <DB5PR0101MB1608B2BF4FDA7D1791AD17709E4B0@DB5PR0101MB1608.eurprd01.prod.exchangelabs.com>
 <rt-4.0.19-1993-1463759389-386.4545-21-0@openssl.org>
 <CADqLbzL+utPi1mz=52eCW6VWw_a5q0wOk5=uaGhbYCCYFRSUfg@mail.gmail.com>
Message-ID: <rt-4.0.19-23362-1464342252-1262.4545-6-0@openssl.org>

Hello,

I can confirm that I have seen a similar behavior in multi-thread
environment. Unfortunately, I do not have a script to reproduce it either.

On Fri, May 20, 2016 at 6:49 PM, Mick Saxton via RT <rt at openssl.org> wrote:

> Hi
>
> Before going any further I would like to state that I have only seen this
> problem when we have 10000 or more concurrent connections.
>
> Mostly we notice it on Windows but I have seen it on linux (Ubuntu).
>
> I first noticed it when using v1.0.2d but have seen it again since
> upgrading to v1.0.2h.
>
> It can happen in one of two places and results in a call to MD_Update with
> a negative value.
>
> I have come up with a temporary fix which avoids the possibility of
> crashing at the expense of some randomness.
> The system is very highly stressed at this point so debugging further is
> difficult.
>
> The fix I am using is probably not what you eventually will want to
> implement but it does improve stability.
>
> 273:            MD_Update(&m, &(state[st_idx]), (j - k) );
> Change to
> 273:            MD_Update(&m, &(state[st_idx]), (j - k) > 0 ? j - k : 1);
> // micks at 1e.com (j -k) must not be negative
>
> And
>
> 495:            MD_Update(&m, &(state[st_idx]), MD_DIGEST_LENGTH / 2 - k )
> Change to
> 495:            MD_Update(&m, &(state[st_idx]), MD_DIGEST_LENGTH / 2 - k >
> 0 ? MD_DIGEST_LENGTH / 2 - k : 1);  // micks at 1e.com (j -k) must not be
> negative
>
>
> I do have a test program which can reproduce this behaviour.
>
> If I can be of further help - please contact me by email.
>
> Regards
> Mick Saxton
>
> ________________________________
>
>
> Legal Notice: This email is intended only for the person(s) to whom it is
> addressed. If you are not an intended recipient and have received this
> message in error, please notify the sender immediately by replying to this
> email or calling +44(0) 2083269015 (UK) or +1 866 592 4214 (USA). This
> email and any attachments may be privileged and/or confidential. The
> unauthorized use, disclosure, copying or printing of any information it
> contains is strictly prohibited. The opinions expressed in this email are
> those of the author and do not necessarily represent the views of 1E Ltd.
> Nothing in this email will operate to bind 1E to any order or other
> contract.
>
> --
> Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4545
> Please log in as guest with password guest if prompted
>
>
> --
> openssl-dev mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
>
>


-- 
SY, Dmitry Belyavsky

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


From rt at openssl.org  Fri May 27 09:46:19 2016
From: rt at openssl.org (Matt Caswell via RT)
Date: Fri, 27 May 2016 09:46:19 +0000
Subject: [openssl-dev] [openssl.org #4545] Crash in crypto/rand/md_rand.c
In-Reply-To: <DB5PR0101MB1608B2BF4FDA7D1791AD17709E4B0@DB5PR0101MB1608.eurprd01.prod.exchangelabs.com>
References: <RT-Ticket-4545@openssl.org>
 <DB5PR0101MB1608B2BF4FDA7D1791AD17709E4B0@DB5PR0101MB1608.eurprd01.prod.exchangelabs.com>
Message-ID: <rt-4.0.19-18315-1464342379-895.4545-6-0@openssl.org>

On Fri May 20 15:49:49 2016, micks at 1e.com wrote:
> Hi
>
> Before going any further I would like to state that I have only seen
> this problem when we have 10000 or more concurrent connections.
>
> Mostly we notice it on Windows but I have seen it on linux (Ubuntu).
>
> I first noticed it when using v1.0.2d but have seen it again since
> upgrading to v1.0.2h.
>
> It can happen in one of two places and results in a call to MD_Update
> with a negative value.
>
> I have come up with a temporary fix which avoids the possibility of
> crashing at the expense of some randomness.
> The system is very highly stressed at this point so debugging further
> is difficult.
>
> The fix I am using is probably not what you eventually will want to
> implement but it does improve stability.
>
> 273: MD_Update(&m, &(state[st_idx]), (j - k) );
> Change to
> 273: MD_Update(&m, &(state[st_idx]), (j - k) > 0 ? j - k :
> 1); // micks at 1e.com (j -k) must not be negative
>
> And
>
> 495: MD_Update(&m, &(state[st_idx]), MD_DIGEST_LENGTH / 2 -
> k )
> Change to
> 495: MD_Update(&m, &(state[st_idx]), MD_DIGEST_LENGTH / 2 -
> k > 0 ? MD_DIGEST_LENGTH / 2 - k : 1); // micks at 1e.com (j -k) must
> not be negative
>
>
> I do have a test program which can reproduce this behaviour.

Hi Mick

Are you able to share your test program?

Thanks

Matt

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


From darshanmody at avaya.com  Fri May 27 09:50:47 2016
From: darshanmody at avaya.com (Mody, Darshan (Darshan))
Date: Fri, 27 May 2016 09:50:47 +0000
Subject: [openssl-dev] FIPs mode and openssl
In-Reply-To: <57481342.60407@openssl.com>
References: <25D2EC755404B4409F263AC6D050FEBB25D53DF1@AZ-FFEXMB03.global.avaya.com>,
 <57481342.60407@openssl.com>
Message-ID: <25D2EC755404B4409F263AC6D050FEBB25D53F08@AZ-FFEXMB03.global.avaya.com>

Thanks Steve,

My question here is do I need to put openssl in FIPS mode for my application, even when Kernel is in FIPS mode. I get FIPS_mode() returning true when I initialize openssl from my application.

Regards
Darshan

________________________________________
From: openssl-dev [openssl-dev-bounces at openssl.org] on behalf of Steve Marquess [marquess at openssl.com]
Sent: Friday, May 27, 2016 2:58 PM
To: openssl-dev at openssl.org
Subject: Re: [openssl-dev] FIPs mode and openssl

On 05/27/2016 05:11 AM, Mody, Darshan (Darshan) wrote:
> Hi,
>
>
>
> I have a query with regards to FIPS mode and use of Openssl. I have put
> my kernel image n FIPs mode using the documentation
> (https://urldefense.proofpoint.com/v2/url?u=https-3A__access.redhat.com_documentation_en-2DUS_Red-5FHat-5FEnterprise-5FLinux_6_html_Security-5FGuide_sect-2DSecurity-5FGuide-2DFederal-5FStandards-5FAnd-5FRegulations-2DFederal-5FInformation-5FProcessing-5FStandard.html&d=CwICAg&c=BFpWQw8bsuKpl1SgiZH64Q&r=bsEULbVnjelD7InzgsegHBEbtXzaIDagy9EuEhJrKfQ&m=GTOvXwENarIDt6ceeifX3cwsUHwEPSoA5Nst5bYguXc&s=-Gf_V2cek9XebA8eKWhFeL2hXCtHLqwJauOD0IuopLU&e= )
>
>
>
> Do I need to put the openssl in FIPs mode using the API FIPS_mode_set(1)
> or will by default the openssl will put itself in FIPS mode for my
> application. There are couple of application on the server we use
> openssl. Do I need to put each of the application openssl in FIPS mode
> or will it put itself in FIPS since the kernel is in FIPS mode.
>
>
>
> Thanks
>
> Darshan
>
>
>


You are using the Red Hat FIPS module, not the OpenSSL one, so you'll
need to ask that vendor.

-Steve M.

--
Steve Marquess
OpenSSL Validation Services, Inc.
1829 Mount Ephraim Road
Adamstown, MD  21710
USA
+1 877 673 6775 s/b
+1 301 874 2571 direct
marquess at openssl.com
gpg/pgp key: https://urldefense.proofpoint.com/v2/url?u=http-3A__openssl.com_docs_0x6D1892F5.asc&d=CwICAg&c=BFpWQw8bsuKpl1SgiZH64Q&r=bsEULbVnjelD7InzgsegHBEbtXzaIDagy9EuEhJrKfQ&m=GTOvXwENarIDt6ceeifX3cwsUHwEPSoA5Nst5bYguXc&s=pvfmLNV5wFtbE8TvbGtpQdBRmzZzuuCQF0UgxmaZW34&e=
--
openssl-dev mailing list
To unsubscribe: https://urldefense.proofpoint.com/v2/url?u=https-3A__mta.openssl.org_mailman_listinfo_openssl-2Ddev&d=CwICAg&c=BFpWQw8bsuKpl1SgiZH64Q&r=bsEULbVnjelD7InzgsegHBEbtXzaIDagy9EuEhJrKfQ&m=GTOvXwENarIDt6ceeifX3cwsUHwEPSoA5Nst5bYguXc&s=XQfgkJcZEf0I-0-rMIEw2wp4U7mgrCk8EPGFlSM461U&e=
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20160527/38ed78d9/attachment-0001.html>

From rt at openssl.org  Fri May 27 10:07:17 2016
From: rt at openssl.org (Mick Saxton via RT)
Date: Fri, 27 May 2016 10:07:17 +0000
Subject: [openssl-dev] [openssl.org #4545] Crash in crypto/rand/md_rand.c
In-Reply-To: <DB5PR0101MB1608776B66F320B377BA7EA49E420@DB5PR0101MB1608.eurprd01.prod.exchangelabs.com>
References: <RT-Ticket-4545@openssl.org>
 <DB5PR0101MB1608B2BF4FDA7D1791AD17709E4B0@DB5PR0101MB1608.eurprd01.prod.exchangelabs.com>
 <rt-4.0.19-18315-1464342379-895.4545-6-0@openssl.org>
 <DB5PR0101MB1608776B66F320B377BA7EA49E420@DB5PR0101MB1608.eurprd01.prod.exchangelabs.com>
Message-ID: <rt-4.0.19-18315-1464343637-1337.4545-6-0@openssl.org>

Hi Matt

The test program runs against our major new development so I cannot share it as is.

I will try to produce a skeleton version which I could let you have.

-          But that will be end if next week as I am away for a few days

-          That is providing that exhibits the bug.

Mick


From: Matt Caswell via RT [mailto:rt at openssl.org]
Sent: 27 May 2016 10:46
To: Mick Saxton
Cc: openssl-dev at openssl.org
Subject: [openssl.org #4545] Crash in crypto/rand/md_rand.c

On Fri May 20 15:49:49 2016, micks at 1e.com<mailto:micks at 1e.com> wrote:
> Hi
>
> Before going any further I would like to state that I have only seen
> this problem when we have 10000 or more concurrent connections.
>
> Mostly we notice it on Windows but I have seen it on linux (Ubuntu).
>
> I first noticed it when using v1.0.2d but have seen it again since
> upgrading to v1.0.2h.
>
> It can happen in one of two places and results in a call to MD_Update
> with a negative value.
>
> I have come up with a temporary fix which avoids the possibility of
> crashing at the expense of some randomness.
> The system is very highly stressed at this point so debugging further
> is difficult.
>
> The fix I am using is probably not what you eventually will want to
> implement but it does improve stability.
>
> 273: MD_Update(&m, &(state[st_idx]), (j - k) );
> Change to
> 273: MD_Update(&m, &(state[st_idx]), (j - k) > 0 ? j - k :
> 1); // micks at 1e.com<mailto:micks at 1e.com> (j -k) must not be negative
>
> And
>
> 495: MD_Update(&m, &(state[st_idx]), MD_DIGEST_LENGTH / 2 -
> k )
> Change to
> 495: MD_Update(&m, &(state[st_idx]), MD_DIGEST_LENGTH / 2 -
> k > 0 ? MD_DIGEST_LENGTH / 2 - k : 1); // micks at 1e.com<mailto:micks at 1e.com> (j -k) must
> not be negative
>
>
> I do have a test program which can reproduce this behaviour.

Hi Mick

Are you able to share your test program?

Thanks

Matt

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

________________________________


Legal Notice: This email is intended only for the person(s) to whom it is addressed. If you are not an intended recipient and have received this message in error, please notify the sender immediately by replying to this email or calling +44(0) 2083269015 (UK) or +1 866 592 4214 (USA). This email and any attachments may be privileged and/or confidential. The unauthorized use, disclosure, copying or printing of any information it contains is strictly prohibited. The opinions expressed in this email are those of the author and do not necessarily represent the views of 1E Ltd. Nothing in this email will operate to bind 1E to any order or other contract.

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


From matt at openssl.org  Fri May 27 10:09:18 2016
From: matt at openssl.org (Matt Caswell)
Date: Fri, 27 May 2016 11:09:18 +0100
Subject: [openssl-dev] [openssl.org #4545] Crash in crypto/rand/md_rand.c
In-Reply-To: <rt-4.0.19-18315-1464343637-1337.4545-6-0@openssl.org>
References: <RT-Ticket-4545@openssl.org>
 <DB5PR0101MB1608B2BF4FDA7D1791AD17709E4B0@DB5PR0101MB1608.eurprd01.prod.exchangelabs.com>
 <rt-4.0.19-18315-1464342379-895.4545-6-0@openssl.org>
 <DB5PR0101MB1608776B66F320B377BA7EA49E420@DB5PR0101MB1608.eurprd01.prod.exchangelabs.com>
 <rt-4.0.19-18315-1464343637-1337.4545-6-0@openssl.org>
Message-ID: <57481CCE.8080109@openssl.org>



On 27/05/16 11:07, Mick Saxton via RT wrote:
> Hi Matt
> 
> The test program runs against our major new development so I cannot share it as is.
> 
> I will try to produce a skeleton version which I could let you have.
> 
> -          But that will be end if next week as I am away for a few days
> 
> -          That is providing that exhibits the bug.

That will be fine. Many thanks.

Matt


From rt at openssl.org  Fri May 27 10:09:19 2016
From: rt at openssl.org (Matt Caswell via RT)
Date: Fri, 27 May 2016 10:09:19 +0000
Subject: [openssl-dev] [openssl.org #4545] Crash in crypto/rand/md_rand.c
In-Reply-To: <57481CCE.8080109@openssl.org>
References: <RT-Ticket-4545@openssl.org>
 <DB5PR0101MB1608B2BF4FDA7D1791AD17709E4B0@DB5PR0101MB1608.eurprd01.prod.exchangelabs.com>
 <rt-4.0.19-18315-1464342379-895.4545-6-0@openssl.org>
 <DB5PR0101MB1608776B66F320B377BA7EA49E420@DB5PR0101MB1608.eurprd01.prod.exchangelabs.com>
 <rt-4.0.19-18315-1464343637-1337.4545-6-0@openssl.org>
 <57481CCE.8080109@openssl.org>
Message-ID: <rt-4.0.19-18315-1464343759-1014.4545-6-0@openssl.org>



On 27/05/16 11:07, Mick Saxton via RT wrote:
> Hi Matt
> 
> The test program runs against our major new development so I cannot share it as is.
> 
> I will try to produce a skeleton version which I could let you have.
> 
> -          But that will be end if next week as I am away for a few days
> 
> -          That is providing that exhibits the bug.

That will be fine. Many thanks.

Matt


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


From rt at openssl.org  Fri May 27 11:38:59 2016
From: rt at openssl.org (Stephen Henson via RT)
Date: Fri, 27 May 2016 11:38:59 +0000
Subject: [openssl-dev] [openssl.org #2369] mail/rfc822Mailbox should be
	encoded as IA5String, not DirectoryString
In-Reply-To: <4CE19411.2040700@seantek.com>
References: <RT-Ticket-2369@openssl.org> <4CE19411.2040700@seantek.com>
Message-ID: <rt-4.0.19-18315-1464349139-514.2369-6-0@openssl.org>

Fixed now, 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=2369
Please log in as guest with password guest if prompted


From meissner at suse.de  Fri May 27 13:33:02 2016
From: meissner at suse.de (Marcus Meissner)
Date: Fri, 27 May 2016 15:33:02 +0200
Subject: [openssl-dev] FIPs mode and openssl
In-Reply-To: <25D2EC755404B4409F263AC6D050FEBB25D53F08@AZ-FFEXMB03.global.avaya.com>
References: <25D2EC755404B4409F263AC6D050FEBB25D53DF1@AZ-FFEXMB03.global.avaya.com>
 <57481342.60407@openssl.com>
 <25D2EC755404B4409F263AC6D050FEBB25D53F08@AZ-FFEXMB03.global.avaya.com>
Message-ID: <20160527133302.GA3464@suse.de>

On Fri, May 27, 2016 at 09:50:47AM +0000, Mody, Darshan (Darshan) wrote:
> Thanks Steve,
> 
> My question here is do I need to put openssl in FIPS mode for my application, even when Kernel is in FIPS mode. I get FIPS_mode() returning true when I initialize openssl from my application.

You still need to ask Redhat.

But if I remember the code correctly, it will also put openssl into FIPS mode as it checks
/proc/sys/crypto/fips_enabled from the kernel and goes to FIPS mode.

Ciao, marcus
 
> Regards
> Darshan
> 
> ________________________________________
> From: openssl-dev [openssl-dev-bounces at openssl.org] on behalf of Steve Marquess [marquess at openssl.com]
> Sent: Friday, May 27, 2016 2:58 PM
> To: openssl-dev at openssl.org
> Subject: Re: [openssl-dev] FIPs mode and openssl
> 
> On 05/27/2016 05:11 AM, Mody, Darshan (Darshan) wrote:
> > Hi,
> >
> >
> >
> > I have a query with regards to FIPS mode and use of Openssl. I have put
> > my kernel image n FIPs mode using the documentation
> > (https://urldefense.proofpoint.com/v2/url?u=https-3A__access.redhat.com_documentation_en-2DUS_Red-5FHat-5FEnterprise-5FLinux_6_html_Security-5FGuide_sect-2DSecurity-5FGuide-2DFederal-5FStandards-5FAnd-5FRegulations-2DFederal-5FInformation-5FProcessing-5FStandard.html&d=CwICAg&c=BFpWQw8bsuKpl1SgiZH64Q&r=bsEULbVnjelD7InzgsegHBEbtXzaIDagy9EuEhJrKfQ&m=GTOvXwENarIDt6ceeifX3cwsUHwEPSoA5Nst5bYguXc&s=-Gf_V2cek9XebA8eKWhFeL2hXCtHLqwJauOD0IuopLU&e= )
> >
> >
> >
> > Do I need to put the openssl in FIPs mode using the API FIPS_mode_set(1)
> > or will by default the openssl will put itself in FIPS mode for my
> > application. There are couple of application on the server we use
> > openssl. Do I need to put each of the application openssl in FIPS mode
> > or will it put itself in FIPS since the kernel is in FIPS mode.
> >
> >
> >
> > Thanks
> >
> > Darshan
> >
> >
> >
> 
> 
> You are using the Red Hat FIPS module, not the OpenSSL one, so you'll
> need to ask that vendor.
> 
> -Steve M.
> 
> --
> Steve Marquess
> OpenSSL Validation Services, Inc.
> 1829 Mount Ephraim Road
> Adamstown, MD  21710
> USA
> +1 877 673 6775 s/b
> +1 301 874 2571 direct
> marquess at openssl.com
> gpg/pgp key: https://urldefense.proofpoint.com/v2/url?u=http-3A__openssl.com_docs_0x6D1892F5.asc&d=CwICAg&c=BFpWQw8bsuKpl1SgiZH64Q&r=bsEULbVnjelD7InzgsegHBEbtXzaIDagy9EuEhJrKfQ&m=GTOvXwENarIDt6ceeifX3cwsUHwEPSoA5Nst5bYguXc&s=pvfmLNV5wFtbE8TvbGtpQdBRmzZzuuCQF0UgxmaZW34&e=
> --
> openssl-dev mailing list
> To unsubscribe: https://urldefense.proofpoint.com/v2/url?u=https-3A__mta.openssl.org_mailman_listinfo_openssl-2Ddev&d=CwICAg&c=BFpWQw8bsuKpl1SgiZH64Q&r=bsEULbVnjelD7InzgsegHBEbtXzaIDagy9EuEhJrKfQ&m=GTOvXwENarIDt6ceeifX3cwsUHwEPSoA5Nst5bYguXc&s=XQfgkJcZEf0I-0-rMIEw2wp4U7mgrCk8EPGFlSM461U&e=

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


-- 
Marcus Meissner,SUSE LINUX GmbH; Maxfeldstrasse 5; D-90409 Nuernberg; Zi. 3.1-33,+49-911-740 53-432,,serv=loki,mail=wotan,type=real <meissner at suse.de>

From hkario at redhat.com  Fri May 27 14:31:38 2016
From: hkario at redhat.com (Hubert Kario)
Date: Fri, 27 May 2016 16:31:38 +0200
Subject: [openssl-dev] FIPs mode and openssl
In-Reply-To: <25D2EC755404B4409F263AC6D050FEBB25D53DF1@AZ-FFEXMB03.global.avaya.com>
References: <25D2EC755404B4409F263AC6D050FEBB25D53DF1@AZ-FFEXMB03.global.avaya.com>
Message-ID: <13819302.qB7dMA1BdK@pintsize.usersys.redhat.com>

On Friday 27 May 2016 09:11:26 Mody, Darshan wrote:
> Hi,
> 
> 
> 
> I have a query with regards to FIPS mode and use of Openssl. I have
> put my kernel image n FIPs mode using the documentation
> (https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Lin
> ux/6/html/Security_Guide/sect-Security_Guide-Federal_Standards_And_Reg
> ulations-Federal_Information_Processing_Standard.html)
> 
> 
> 
> Do I need to put the openssl in FIPs mode using the API
> FIPS_mode_set(1) or will by default the openssl will put itself in
> FIPS mode for my application. There are couple of application on the
> server we use openssl. Do I need to put each of the application
> openssl in FIPS mode or will it put itself in FIPS since the kernel
> is in FIPS mode.

People on this mailing list cannot provide you with authoritative answer 
on this question. There are many pieces to the FIPS puzzle, setting the 
kernel fips flag is just one item.

Please contact support directly.
-- 
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purky?ova 99/71, 612 45, Brno, Czech Republic
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part.
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20160527/606b3d3c/attachment.sig>

From rt at openssl.org  Fri May 27 14:45:21 2016
From: rt at openssl.org (Matt Caswell via RT)
Date: Fri, 27 May 2016 14:45:21 +0000
Subject: [openssl-dev] [openssl.org #4255] OpenSSL-1.1.0-pre2 failures using
	MinGW-W64
In-Reply-To: <rt-4.0.19-5500-1462883800-449.4255-6-0@openssl.org>
References: <RT-Ticket-4255@openssl.org>
 <1453060954.186021958.y9vnrjtk@frv39.fwdcdn.com>
 <rt-4.0.19-5500-1462883800-449.4255-6-0@openssl.org>
Message-ID: <rt-4.0.19-18315-1464360320-408.4255-6-0@openssl.org>

On Tue May 10 12:36:40 2016, matt wrote:
> Re-opening. OP reports there are still issues with "make test" hanging.

The "make test" hang issue on mingw should now be resolved in the head of
master. Unfortunately there is now a completely different issue preventing
compilation for mingw :-( That is nothing to do with this ticket though so
closing.

Matt

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


From matt at openssl.org  Fri May 27 15:03:48 2016
From: matt at openssl.org (Matt Caswell)
Date: Fri, 27 May 2016 16:03:48 +0100
Subject: [openssl-dev] [openssl.org #4255] OpenSSL-1.1.0-pre2 failures
	using MinGW-W64
In-Reply-To: <1464360684.730620638.affeo51d@frv39.fwdcdn.com>
References: <RT-Ticket-4255@openssl.org>
 <1453060954.186021958.y9vnrjtk@frv39.fwdcdn.com>
 <rt-4.0.19-5500-1462883800-449.4255-6-0@openssl.org>
 <rt-4.0.19-18315-1464360320-408.4255-6-0@openssl.org>
 <1464360684.730620638.affeo51d@frv39.fwdcdn.com>
Message-ID: <574861D4.3000001@openssl.org>



On 27/05/16 15:58, sav_ix at ukr.net wrote:
>  
> 
> --- ???????? ????????? ---
> ?? ????: "Matt Caswell via RT" <rt at openssl.org>
> ????: 27 ??? 2016, 17:45:28
> 
>     The "make test" hang issue on mingw should now be resolved in the head of
>     master. Unfortunately there is now a completely different issue preventing
>     compilation for mingw :-( That is nothing to do with this ticket though so
>     closing.
> 
> Hi,
> 
> Thank you for fixing that issue. I'll test it when Mingw-w64 builds
> would be restored.
> 
> Got few questions, if you don't mind:
> 
> 1. Which issue or PR I should look to figure out, whether Mingw builds
> are available again.

There isn't an existing ticket for it but Andy has a commit entitled
"crypto/o_str.c: strerror_s is provided by specific compiler run-time,"
which is currently in internal review that fixes the issue.


> 
> 2. Results for some tests using MSVC there are:
> 
> skipped: TLSProxy isn't usable on MSWin32
> 
> Since PR:
> Fix intermittent windows failures in TLSProxy tests
> https://github.com/openssl/openssl/commit/cb2e10f257a464c6b475b321dd9e4769df84dbf6
> 
> already pushed to master, does it make sense to enable that tests for
> MSVC builds? I can open such issue on GitHub, if needed.

No, I already tried it. There are yet more issues which only seem to
affect the MSVC build that I haven't tracked down yet.

Matt

From rt at openssl.org  Fri May 27 15:39:58 2016
From: rt at openssl.org (Richard Levitte via RT)
Date: Fri, 27 May 2016 15:39:58 +0000
Subject: [openssl-dev] [openssl.org #4311] OpenSSL 1.1.0-pre3: quote
	PERL=$(PERL) in Makefiles
In-Reply-To: <rt-4.0.19-5499-1462963906-1451.4311-6-0@openssl.org>
References: <RT-Ticket-4311@openssl.org> <56C36B8A.50507@kippdata.de>
 <rt-4.0.19-5500-1462886302-337.4311-6-0@openssl.org>
 <rt-4.0.19-5500-1462886957-1375.4311-6-0@openssl.org>
 <8c38ec6c-080b-9060-17ab-d1519339c2e4@kippdata.de>
 <rt-4.0.19-5500-1462892176-947.4311-6-0@openssl.org>
 <rt-4.0.19-18545-1462910089-1637.4311-6-0@openssl.org>
 <634a5843-2ad4-c5b5-8882-2964b9798bde@kippdata.de>
 <rt-4.0.19-5499-1462963906-1451.4311-6-0@openssl.org>
Message-ID: <rt-4.0.19-23362-1464363598-372.4311-6-0@openssl.org>

On Wed May 11 10:51:46 2016, rainer.jung at kippdata.de wrote:
> Am 10.05.2016 um 21:54 schrieb Richard Levitte via RT:
> > I understand this part. What I'm questioning is the need to set PERL
> > to
> > "/usr/bin/env perl" to begin with. It's practically not different at
> > all from
> > setting it to just "perl", all this does is that any time the
> > environment
> > variable PERL is used to run a perl script is to have an extra
> > process between
> > the shell and perl itself that will simply pass along the exact
> > environment
> > that it got from the shell. In effect, any time the environment
> > variable PERL
> > with your assignment is used to run a script (assuming the quoting
> > you
> > suggest), i.e.:
> >
> > $PERL blah.pl
> >
> > it would expand to this:
> >
> > /usr/bin/env perl blah.pl
> >
> > If it's only assigned "perl", the command would expand to this:
> >
> > perl blah.pl
> >
> > perl itself literally gets the exact same environment in both cases.
>
> I agree.
>
> > Mind you, I did read your reasoning around #! in scripts.
> > Unfortunately, that
> > reasoning is flawed, that won't be affected by the environment
> > variable PERL.
>
> I had to rad my ticket again, and actually this is the only reason for
> the ticket: the following perl scripts are generated from .in files
> during building OpenSSL and get installed and executed later in
> another
> environment:
>
> - c_rehash
> - CA.pl
> - tsget
>
> All of them contain in the .in file the magic header:
>
> #!{- $config{perl} -}
>
> IMHO $config{perl} - detected and set during config and Configure from
> the PERL env var and as a fallback from the PATH - is used as the perl
> during build time and also put into the scripts for use on the target
> system.
>
> But those two perl paths should be defined independently from each
> other.
>
> You say the reasoning is flawed, but to me it looks like:
>
> - config checks whether the PERL env var is set. If not it searches
> for
> a perl in the path and sets the PERL env var to that one.
>
> - config calls Configure
>
> - Configure sets $config{perl} from the PERL env var
>
> - the scripts c_rehash, CA.pl and tsget are generated from their .in
> files and their first line
>
> #!{- $config{perl} -}
>
> is replaced by #!$PERL (with $PERL resolved).
>
> I'd love if I were wrong and there would already be a way to set the
> perl for those scripts independently from the one used for the build
> process. If you think that demand is too specific, I can live with
> patching the scripts myself. But IMHO it would be nice not to enforce
> the same restrictions on the build procedure perl to the runtime perl
> for those simple scripts. For the build procedure it should be the
> required 5.10 with modules etc. For the three scripts typically the
> platform perl would suffice.

Thanks for your explanation. Your patch has just made it to the master branch.

Closing this ticket.

Cheers,
Richard

--
Richard Levitte
levitte at openssl.org

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


From rt at openssl.org  Fri May 27 15:43:15 2016
From: rt at openssl.org (Richard Levitte via RT)
Date: Fri, 27 May 2016 15:43:15 +0000
Subject: [openssl-dev] [openssl.org #4486] PATCH: fix NMAKE fatal error
	U1073: "don't know how to make
	'LNAME\openssl\Configurations\windows-makefile.tmpl'"
In-Reply-To: <rt-4.0.19-23362-1464176351-1454.4486-6-0@openssl.org>
References: <RT-Ticket-4486@openssl.org>
 <CAH8yC8ku7J0G4UGQ2vx=c19_XjCFpSdpUbApHm_4W2HwuDmGpg@mail.gmail.com>
 <rt-4.0.19-23362-1464104767-1468.4486-6-0@openssl.org>
 <rt-4.0.19-23362-1464176351-1454.4486-6-0@openssl.org>
Message-ID: <rt-4.0.19-23362-1464363795-1486.4486-6-0@openssl.org>

The fix just got merged into master. Having heard nothing else, I'm closing
this ticket.

Cheers,
Richard

On Wed May 25 11:39:11 2016, levitte wrote:
> Now that 4492 was closed, I could give this a go... and no, the
> proposed patch
> wasn't enough, there were a few more places that needed extra quotes.
>
> https://github.com/openssl/openssl/pull/1125
>
> Cheers,
> Richard
>
> On Tue May 24 15:46:07 2016, levitte wrote:
> > I'm surprised so little is needed... Does it, combined with my fix
> > for 4492?
> >
> > Cheers,
> > Richard
> >
> > On Sun Mar 27 13:29:37 2016, noloader at gmail.com wrote:
> > > Using Strawberry PERL from a typical Windows user desktop and
> > > working
> > > from Master at c828cd7...
> > >
> > > > cls && perl Configure VC-WIN32
> > > ...
> > >
> > > > nmake
> > > Microsoft (R) Program Maintenance Utility Version 11.00.61030.0
> > > Copyright (C) Microsoft Corporation. All rights reserved.
> > >
> > > NMAKE : fatal error U1073: don't know how to make
> > > 'LNAME\openssl\Configurations
> > > \windows-makefile.tmpl'
> > > Stop.
> > >
> > > $ git diff
> > > diff --git a/Configurations/windows-makefile.tmpl
> > > b/Configurations/windows-makefile.tmpl
> > > index 0b8ac72..6f97315 100644
> > > --- a/Configurations/windows-makefile.tmpl
> > > +++ b/Configurations/windows-makefile.tmpl
> > > @@ -218,7 +218,7 @@ uninstall_runtime:
> > >
> > > # Building targets
> > > ###################################################
> > >
> > > -configdata.pm: {- $config{build_file_template} -}
> > > $(SRCDIR)\Configure
> > > +configdata.pm: "{- $config{build_file_template} -}"
> > > $(SRCDIR)\Configure
> > > @echo "Detected changed: $?"
> > > @echo "Reconfiguring..."
> > > $(PERL) $(SRCDIR)\Configure reconf
> > >
> > > **********
> > >
> > > After patching:
> > >
> > > > nmake
> > >
> > > Microsoft (R) Program Maintenance Utility Version 11.00.61030.0
> > > Copyright (C) Microsoft Corporation. All rights reserved.
> > >
> > > nasm -f win32 -ocrypto\aes\aes-586.obj crypto\aes\aes-586.asm
> > > cl -DDSO_WIN32 -DOPENSSL_THREADS -DOPENSSL_NO_DYNAMIC_ENGINE
> > > -DOPENSSL_P
> > > IC -DOPENSSL_BN_ASM_PART_WORDS -DOPENSSL_IA32_SSE2
> > > -DOPENSSL_BN_ASM_MONT -DOPENS
> > > SL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM
> > > -DRMD160_ASM -DAES
> > > _ASM -DVPAES_ASM -DWHIRLPOOL_ASM -DGHASH_ASM -DECP_NISTZ256_ASM
> > > -DPOLY1305_ASM "
> > > -DENGINESDIR=\"%ProgramFiles(x86)%\\OpenSSL\\lib\\engines\"" "-
> > > DOPENSSLDIR=\"%Co
> > > mmonProgramFiles(x86)%\\SSL\"" -W3 -wd4090 -Gs0 -GF -Gy -nologo
> > > -DOPENSSL_SYS_WI
> > > N32 -DWIN32_LEAN_AND_MEAN -DL_ENDIAN -D_CRT_SECURE_NO_DEPRECATE
> > > -DUNICODE -D_UNI
> > > CODE /MT /Ox /O2 /Ob2 /Zl /Zi /Fdlib -D_WINDLL /I ..\..\Jeffrey /I
> > > Walton\openss
> > > l\include /I . /I crypto\include /I include /I
> > > crypto\bn\Walton\openssl\crypto\i
> > > nclude -c /Focrypto\aes\aes_cfb.obj crypto\aes\aes_cfb.c
> > > aes_cfb.c
> > > cl -DDSO_WIN32 -DOPENSSL_THREADS -DOPENSSL_NO_DYNAMIC_ENGINE
> > > -DOPENSSL_P
> > > IC -DOPENSSL_BN_ASM_PART_WORDS -DOPENSSL_IA32_SSE2
> > > -DOPENSSL_BN_ASM_MONT -DOPENS
> > > SL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM
> > > -DRMD160_ASM -DAES
> > > _ASM -DVPAES_ASM -DWHIRLPOOL_ASM -DGHASH_ASM -DECP_NISTZ256_ASM
> > > -DPOLY1305_ASM "
> > > -DENGINESDIR=\"%ProgramFiles(x86)%\\OpenSSL\\lib\\engines\"" "-
> > > DOPENSSLDIR=\"%Co
> > > mmonProgramFiles(x86)%\\SSL\"" -W3 -wd4090 -Gs0 -GF -Gy -nologo
> > > -DOPENSSL_SYS_WI
> > > N32 -DWIN32_LEAN_AND_MEAN -DL_ENDIAN -D_CRT_SECURE_NO_DEPRECATE
> > > -DUNICODE -D_UNI
> > > CODE /MT /Ox /O2 /Ob2 /Zl /Zi /Fdlib -D_WINDLL /I ..\..\Jeffrey /I
> > > Walton\openss
> > > l\include /I . /I crypto\include /I include /I
> > > crypto\bn\Walton\openssl\crypto\i
> > > nclude -c /Focrypto\aes\aes_ecb.obj crypto\aes\aes_ecb.c
> > > aes_ecb.c
> > >
> > > ...
> >
> >
> > --
> > Richard Levitte
> > levitte at openssl.org
>
>
> --
> Richard Levitte
> levitte at openssl.org


--
Richard Levitte
levitte at openssl.org

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


From rt at openssl.org  Fri May 27 18:34:13 2016
From: rt at openssl.org (Peter Chernyshev via RT)
Date: Fri, 27 May 2016 18:34:13 +0000
Subject: [openssl-dev] [openssl.org #4501] bug in BN_mod_word
In-Reply-To: <CAO1trb0h1N=JmqJEx+Mq0pxfKxSn=Ve-E-o+0vJPFuYXDXrxVA@mail.gmail.com>
References: <RT-Ticket-4501@openssl.org>
 <CAO1trb2WYS_cm_qoUAnsKO34=x8E3846EEGL=8mBdwN_eRnfNw@mail.gmail.com>
 <rt-4.0.19-23362-1464216654-578.4501-6-0@openssl.org>
 <CAO1trb0h1N=JmqJEx+Mq0pxfKxSn=Ve-E-o+0vJPFuYXDXrxVA@mail.gmail.com>
Message-ID: <rt-4.0.19-13038-1464374053-1147.4501-6-0@openssl.org>

Hi Matt!
in connected file test.

Peter Chernyshev/


2016-05-26 2:50 GMT+04:00, Matt Caswell via RT <rt at openssl.org>:
> On Thu Apr 07 11:44:09 2016, peter.chernyshev at gmail.com wrote:
>> ?????? ????!
>> ????????? ?????????? BN_mod_word
>> BN_ULONG BN_mod_word(const BIGNUM *a, BN_ULONG w);
>>
>> ???????? ??????? ?? 64 ??? ?????? ??? ????????? w>2^32, ???? ?????????
>> ???
>> BN_ULONG (64 ????).
>>
>> ????
>>
>> Hello!
>> BN part program
>>
>> BN_ULONG BN_mod_word (const BIGNUM * a, BN_ULONG w);
>>
>> does not work properly on 64-bit machine with some w> 2 ^ 32, although
>> declared as BN_ULONG (64 bits).
>
> Hello
>
> Do you have a test case for this that demonstrates this problem?
>
> Thanks
>
> Matt
>
> --
> Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4501
> Please log in as guest with password guest if prompted
>
>

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: BN_mod_word_test.rtf
Type: application/rtf
Size: 2354 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20160527/488b3b57/attachment.rtf>

From matt at openssl.org  Sat May 28 18:36:46 2016
From: matt at openssl.org (Matt Caswell)
Date: Sat, 28 May 2016 19:36:46 +0100
Subject: [openssl-dev] [openssl.org #4255] OpenSSL-1.1.0-pre2 failures
	using MinGW-W64
In-Reply-To: <1464450254.13504095.7wfr99ne@frv39.fwdcdn.com>
References: <RT-Ticket-4255@openssl.org>
 <1453060954.186021958.y9vnrjtk@frv39.fwdcdn.com>
 <rt-4.0.19-5500-1462883800-449.4255-6-0@openssl.org>
 <rt-4.0.19-18315-1464360320-408.4255-6-0@openssl.org>
 <1464360684.730620638.affeo51d@frv39.fwdcdn.com>
 <574861D4.3000001@openssl.org>
 <1464450254.13504095.7wfr99ne@frv39.fwdcdn.com>
Message-ID: <5749E53E.20003@openssl.org>



On 28/05/16 16:49, sav_ix at ukr.net wrote:
>  
> 
> --- ???????? ????????? ---
> ?? ????: "Matt Caswell" <matt at openssl.org>
> ????: 27 ??? 2016, 18:03:50
> 
>     > 2. Results for some tests using MSVC there are:
>     > 
>     > skipped: TLSProxy isn't usable on MSWin32
>     > 
>     > Since PR:
>     > Fix intermittent windows failures in TLSProxy tests
>     > https://github.com/openssl/openssl/commit/cb2e10f257a464c6b475b321dd9e4769df84dbf6
>     > 
>     > already pushed to master, does it make sense to enable that tests for
>     > MSVC builds? I can open such issue on GitHub, if needed.
> 
>     No, I already tried it. There are yet more issues which only seem to
>     affect the MSVC build that I haven't tracked down yet.
> 
> 
> Just tested OpenSSL build using Mingw-w64, and all test passes without
> looping. But some of test failed during run.
> 
> Could you tell, is this known/expected behavior and is there any issue
> related to it?

No - it is not expected. On my machine all tests are passing
consistently. Which tests are failing? Is it consistently always failing
in the same place? Please raise this as a new issue.

Matt


From rt at openssl.org  Sun May 29 17:41:46 2016
From: rt at openssl.org (Rich Salz via RT)
Date: Sun, 29 May 2016 17:41:46 +0000
Subject: [openssl-dev] [openssl.org #4010] [PATCH] Fix #include order in
	rand.h for Windows
In-Reply-To: <CANt7B+d4L4wMMGWXPE57yaPhVF1D3rkFhiQHGCy-JKeWEadcMg@mail.gmail.com>
References: <RT-Ticket-4010@openssl.org>
 <CANt7B+d4L4wMMGWXPE57yaPhVF1D3rkFhiQHGCy-JKeWEadcMg@mail.gmail.com>
Message-ID: <rt-4.0.19-13038-1464543706-325.4010-6-0@openssl.org>

Fixed by a recent (hours ago :) overhaul of the windows RAND implementation.
Thanks for your patience.

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


From rt at openssl.org  Sun May 29 17:53:43 2016
From: rt at openssl.org (Rich Salz via RT)
Date: Sun, 29 May 2016 17:53:43 +0000
Subject: [openssl-dev] [openssl.org #2722] ssleay_rand_add and
	ssleay_rand_bytes donot work stably in low resource environment
In-Reply-To: <BAY171-W11240BFB33D9BE2EE3A534BA8620@phx.gbl>
References: <RT-Ticket-2722@openssl.org>
 <45B4FCB86DB61C44ABB382ED5A4736865A6BE97690@APJ1XCHEVSPIN32.SYMC.SYMANTEC.COM>
 <BAY171-W11240BFB33D9BE2EE3A534BA8620@phx.gbl>
Message-ID: <rt-4.0.19-18315-1464544423-348.2722-6-0@openssl.org>

This was fixed some time ago, at least by making EVP_MD_CTX opaque. The return
values of the new and update routine are checked. Thanks!

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


From rt at openssl.org  Sun May 29 17:54:28 2016
From: rt at openssl.org (Rich Salz via RT)
Date: Sun, 29 May 2016 17:54:28 +0000
Subject: [openssl-dev] [openssl.org #3159] [Bug with PATCH] Null pointer
	dereference in ssleay_rand_bytes() and etc.
In-Reply-To: <E774C81546D66E429BF56B1474C7EBBA012CE2E1AC@SEAEMBX01.olympus.F5Net.com>
References: <RT-Ticket-3159@openssl.org>
 <E774C81546D66E429BF56B1474C7EBBA012CE2E1AC@SEAEMBX01.olympus.F5Net.com>
Message-ID: <rt-4.0.19-18315-1464544468-1708.3159-6-0@openssl.org>

Same as RT 2722, same fix.

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


From rt at openssl.org  Sun May 29 17:56:15 2016
From: rt at openssl.org (Rich Salz via RT)
Date: Sun, 29 May 2016 17:56:15 +0000
Subject: [openssl-dev] [openssl.org #3626] Entropy on Win discounts
	CryptGenRandom length
In-Reply-To: <SNT152-W264B9B8C4E2E4E2C8E3DFBB8790@phx.gbl>
References: <RT-Ticket-3626@openssl.org>
 <SNT152-W264B9B8C4E2E4E2C8E3DFBB8790@phx.gbl>
Message-ID: <rt-4.0.19-18315-1464544575-1623.3626-6-0@openssl.org>

Fixed with the recent updates to windows RAND implementation that always and
only calls CryptGenRandom (no heap-walking, screen-reading, etc.)

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


From rt at openssl.org  Sun May 29 17:57:41 2016
From: rt at openssl.org (Rich Salz via RT)
Date: Sun, 29 May 2016 17:57:41 +0000
Subject: [openssl-dev] [openssl.org #3828] OpenSSL random number generator
	initialization causes a deadlock on Windows
In-Reply-To: <483562A2.3000402@lysator.liu.se>
References: <RT-Ticket-3828@openssl.org> <483562A2.3000402@lysator.liu.se>
Message-ID: <rt-4.0.19-13038-1464544661-1135.3828-6-0@openssl.org>

Fixed by recent update to Windows RAND implementation.
We only call CryptGenRandom. We don't walk the heap, read the screen, watch the
mouse, or anything else any more.

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


From rt at openssl.org  Sun May 29 18:19:40 2016
From: rt at openssl.org (Rich Salz via RT)
Date: Sun, 29 May 2016 18:19:40 +0000
Subject: [openssl-dev] [openssl.org #3509] Bug: RANDFILE environment
	variable not honored when RANDFILE is set in config file
In-Reply-To: <1974898249.3056558.1409337576815.JavaMail.zimbra@zimbra.com>
References: <RT-Ticket-3509@openssl.org>
 <1974898249.3056558.1409337576815.JavaMail.zimbra@zimbra.com>
Message-ID: <rt-4.0.19-13038-1464545980-1424.3509-6-0@openssl.org>

Sorry for the delay in responding. The syntax $ENV::foo means use the config
file value for "foo" if getenv("foo") returns NULL.
So, this is workng as designed (and at least in 1.1 as documented)

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


From rt at openssl.org  Sun May 29 18:48:04 2016
From: rt at openssl.org (=?UTF-8?B?S2ltIEdyw6RzbWFu?= via RT)
Date: Sun, 29 May 2016 18:48:04 +0000
Subject: [openssl-dev] [openssl.org #4010] [PATCH] Fix #include order in
	rand.h for Windows
In-Reply-To: <CANt7B+fLgfPBwXeOrzJUP2Dv6O_C9MhDfG_tErdA4+qghOm_uA@mail.gmail.com>
References: <RT-Ticket-4010@openssl.org>
 <CANt7B+d4L4wMMGWXPE57yaPhVF1D3rkFhiQHGCy-JKeWEadcMg@mail.gmail.com>
 <rt-4.0.19-13038-1464543706-325.4010-6-0@openssl.org>
 <CANt7B+fLgfPBwXeOrzJUP2Dv6O_C9MhDfG_tErdA4+qghOm_uA@mail.gmail.com>
Message-ID: <rt-4.0.19-13038-1464547684-507.4010-6-0@openssl.org>

Hi Rich,

Thanks! We're just integrating the latest released openssl, maybe we
should wait a while longer and get this too :-)

Cheers,
- Kim

On Sun, May 29, 2016 at 7:41 PM, Rich Salz via RT <rt at openssl.org> wrote:
> Fixed by a recent (hours ago :) overhaul of the windows RAND implementation.
> Thanks for your patience.
>
> --
> Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4010
> Please log in as guest with password guest if prompted
>


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


From rt at openssl.org  Sun May 29 21:49:23 2016
From: rt at openssl.org (g1pi@libero.it via RT)
Date: Sun, 29 May 2016 21:49:23 +0000
Subject: [openssl-dev] [openssl.org #4546] bug: misleading docs for
	EVP_*{Cipher, Encrypt, Decrypt}Final() functions in release branch
In-Reply-To: <20160529212142.GA32264@bell>
References: <RT-Ticket-4546@openssl.org> <20160529212142.GA32264@bell>
Message-ID: <rt-4.0.19-18315-1464558563-122.4546-21-0@openssl.org>

More than 14 years ago, on Wed May 15 18:49:25 2002, Dr. Stephen Henson
committed a change to crypto/evp/evp_enc.c that made the EVP_*Final()
functions identical to the corresponding *_ex() functions.

In 2014, Rich Salz fixed the doc on the master branch with commit
538860a3ce0b9fd142a7f1a62e597cccb74475d3.  However, the docs for the
current release branch (1.0.2) have not been updated, and still carry
misleading information:
https://www.openssl.org/docs/man1.0.2/crypto/EVP_CipherFinal.html

Whoever relies on the manual without reading the openssl source code, and
uses the EVP_*Final() functions without calling EVP_CIPHER_CTX_cleanup()
afterwards, is subject to leak memory and probably leave encryption keys
floating in RAM, waiting for a bug elsewhere to spill them.

Would you mind merging commit 538860a3ce0b9fd142a7f1a62e597cccb74475d3
into the 1.0.2 stable branch?

Best regards,
	g


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


From rt at openssl.org  Mon May 30 04:55:32 2016
From: rt at openssl.org (noloader@gmail.com via RT)
Date: Mon, 30 May 2016 04:55:32 +0000
Subject: [openssl-dev] [openssl.org #4547] Changing function
	CRYPTO_num_locks() to "#define CRYPTO_num_locks() (0)" breaks
	compiles
In-Reply-To: <CAH8yC8nP2xydd7KpTj+h=6Abuk7KFn38EBf4a_uq2DBSFEnkmA@mail.gmail.com>
References: <RT-Ticket-4547@openssl.org>
 <CAH8yC8nP2xydd7KpTj+h=6Abuk7KFn38EBf4a_uq2DBSFEnkmA@mail.gmail.com>
Message-ID: <rt-4.0.19-18315-1464584132-1089.4547-21-0@openssl.org>

Also see http://stackoverflow.com/q/37517730


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


From rt at openssl.org  Mon May 30 14:36:19 2016
From: rt at openssl.org (Rich Salz via RT)
Date: Mon, 30 May 2016 14:36:19 +0000
Subject: [openssl-dev] [openssl.org #4547] Changing function
	CRYPTO_num_locks() to "#define CRYPTO_num_locks() (0)" breaks
	compiles
In-Reply-To: <CAH8yC8nP2xydd7KpTj+h=6Abuk7KFn38EBf4a_uq2DBSFEnkmA@mail.gmail.com>
References: <RT-Ticket-4547@openssl.org>
 <CAH8yC8nP2xydd7KpTj+h=6Abuk7KFn38EBf4a_uq2DBSFEnkmA@mail.gmail.com>
Message-ID: <rt-4.0.19-26106-1464618979-129.4547-6-0@openssl.org>

BOOST has work (perhaps a lot) to do to support 1.1 In particular, their ASIO
stuff needs to be reworked to use the new ASYNC stuff, and papering over
compile-time differences are most likely going to lead to semantic mismatches,
dogs and cats living together, and crashes and coredumps oh my.

Closing this ticket.

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


From rt at openssl.org  Mon May 30 18:56:17 2016
From: rt at openssl.org (Rich Salz via RT)
Date: Mon, 30 May 2016 18:56:17 +0000
Subject: [openssl-dev] [openssl.org #3502] nameConstraints bypass bug
In-Reply-To: <53F7A00F.6090801@av8n.com>
References: <RT-Ticket-3502@openssl.org> <53F7A00F.6090801@av8n.com>
Message-ID: <rt-4.0.19-26078-1464634577-865.3502-6-0@openssl.org>

The existing code is working as designed and is basically correct.

If there is no altname and there is a CN, we cannot assume that the CN is a
hostname. Yes, for WebPKI this is true, but WebPKI has deprecated
cn-as-hostname for more than a decade and mandated SAN names.

For example, in validating a cert chain for s/mime, suppose we have a
certificate chain which includes name constraints on DNS (say restricting it to
.foo.com) and the EE certificate has no subject alternative name. Do we reject
the chain because "Fred Bloggs" violates name constraints? Clearly, no.

Leaving this open because we might be able to do some hueristics/hacks to
determine when the CN "should be" a DNS name. But the workaround is to use SAN.

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


From rt at openssl.org  Mon May 30 19:22:03 2016
From: rt at openssl.org (Matt Caswell via RT)
Date: Mon, 30 May 2016 19:22:03 +0000
Subject: [openssl-dev] [openssl.org #4189] PR #512: Clean up Windows RNG
In-Reply-To: <56778878.20505@dancingdragon.be>
References: <RT-Ticket-4189@openssl.org> <56778878.20505@dancingdragon.be>
Message-ID: <rt-4.0.19-26106-1464636123-1489.4189-6-0@openssl.org>

On Mon Dec 21 11:07:24 2015, dragon at dancingdragon.be wrote:
> https://github.com/openssl/openssl/pull/512
>
> This PR removes all of the dangerous Windows entropy gathering routines
> in favor of standard CryptGenRandom calls, as was discussed in the
> "Improving OpenSSL default RNG" thread on openssl-dev. This fixes
> common, repeatable crashes that happen when running openssl under the VS
> debugger.

For the record this became this pull request and has now been merged:

https://github.com/openssl/openssl/pull/1079

Closing this ticket.

Matt

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


From openssl-users at dukhovni.org  Mon May 30 19:25:52 2016
From: openssl-users at dukhovni.org (Viktor Dukhovni)
Date: Mon, 30 May 2016 19:25:52 +0000
Subject: [openssl-dev] [openssl.org #3502] nameConstraints bypass bug
In-Reply-To: <rt-4.0.19-26078-1464634577-865.3502-6-0@openssl.org>
References: <RT-Ticket-3502@openssl.org> <53F7A00F.6090801@av8n.com>
 <rt-4.0.19-26078-1464634577-865.3502-6-0@openssl.org>
Message-ID: <20160530192552.GS3300@mournblade.imrryr.org>

On Mon, May 30, 2016 at 06:56:17PM +0000, Rich Salz via RT wrote:

> If there is no altname and there is a CN, we cannot assume that the CN is a
> hostname. Yes, for WebPKI this is true, but WebPKI has deprecated
> cn-as-hostname for more than a decade and mandated SAN names.

OpenSSL master supports internal host name checks via SSL_add1_host(),
X509_VERIFY_PARAM_set1_host(), or (less recommended) X509_check_host().
Various flags modify the behaviour of the built-in name checks:

	SSL_set_hostflags(3)
	X509_VERIFY_PARAM_set_hostflags(3)

In particular, we support the X509_CHECK_FLAG_ALWAYS_CHECK_SUBJECT
flag to make it possible to always consider the subject CN even
when DNS SANs are present.  That flag is off by default and should
not be used:

    https://tools.ietf.org/html/rfc6125#section-6.3

      Security Warning: A client MUST NOT seek a match for a reference
      identifier of CN-ID if the presented identifiers include a DNS-ID,
      SRV-ID, URI-ID, or any application-specific identifier types
      supported by the client.

Should there perhaps also be a new

    X509_CHECK_FLAG_NEVER_CHECK_SUBJECT

flag that would ask us to never match the subject CN against DNS
reference identifiers?  And what should the default behaviour be?
(Should the new flag be on by default, requiring an explicit call
to SSL_set_hostflags(3) or X509_VERIFY_PARAM_set_hostflags(3) to
override the flag?)

-- 
	Viktor.

From rt at openssl.org  Mon May 30 19:59:03 2016
From: rt at openssl.org (Kurt Roeckx via RT)
Date: Mon, 30 May 2016 19:59:03 +0000
Subject: [openssl-dev] [openssl.org #4548] s390x build problem
In-Reply-To: <20160530195815.GA18832@roeckx.be>
References: <RT-Ticket-4548@openssl.org> <20160530195815.GA18832@roeckx.be>
Message-ID: <rt-4.0.19-26078-1464638343-1596.4548-21-0@openssl.org>

Hi,

I'm getting:
crypto/chacha/chacha-s390x.S: Assembler messages:
crypto/chacha/chacha-s390x.S:7: Error: Unrecognized opcode: `clgije'


A full build log is available on:
https://buildd.debian.org/status/fetch.php?pkg=openssl&arch=s390x&ver=1.1.0~pre5-1&stamp=1464594754


Kurt


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


From rt at openssl.org  Mon May 30 20:00:42 2016
From: rt at openssl.org (Kurt Roeckx via RT)
Date: Mon, 30 May 2016 20:00:42 +0000
Subject: [openssl-dev] [openssl.org #4549] powerpc test problem: missing
	symbols
In-Reply-To: <20160530200039.GB18832@roeckx.be>
References: <RT-Ticket-4549@openssl.org> <20160530200039.GB18832@roeckx.be>
Message-ID: <rt-4.0.19-26078-1464638442-1946.4549-21-0@openssl.org>

Hi,

I'm seeing this on powerpc:
../test/recipes/01-test_ordinals.t ......... ok

#   Failed test 'check that there are no missing symbols in libcrypto.so'
#   at ../test/recipes/01-test_symbol_presence.t line 112.
# Looks like you failed 1 test of 4.
../test/recipes/01-test_symbol_presence.t .. 
Dubious, test returned 1 (wstat 256, 0x100)
Failed 1/4 subtests 

I a full log is at:
https://buildd.debian.org/status/fetch.php?pkg=openssl&arch=powerpc&ver=1.1.0~pre5-1&stamp=1464595346

If I find time I'll try to look in the the real cause.


Kurt


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


From rt at openssl.org  Mon May 30 20:08:51 2016
From: rt at openssl.org (Kurt Roeckx via RT)
Date: Mon, 30 May 2016 20:08:51 +0000
Subject: [openssl-dev] [openssl.org #4550] hppa assembler problem
In-Reply-To: <20160530200848.GC18832@roeckx.be>
References: <RT-Ticket-4550@openssl.org> <20160530200848.GC18832@roeckx.be>
Message-ID: <rt-4.0.19-26078-1464638931-234.4550-21-0@openssl.org>

Hi,

I'm getting assembler errors on hppa that look like:
crypto/aes/aes-parisc.s: Assembler messages:
crypto/aes/aes-parisc.s:3: Error: unknown pseudo-op: `.subspa'
crypto/aes/aes-parisc.s:7: Error: Unknown opcode: `aes_encrypt'
crypto/aes/aes-parisc.s:11: Error: Missing function name for .PROC
crypto/aes/aes-parisc.s:12: Error: Missing function name for .PROC

I'm guessing I'm doing something wrong, but hppa never had
assembler enabled in Debian before.

The configuration I use is:
my $debian_cflags = `dpkg-buildflags --get CFLAGS` .  `dpkg-buildflags --get CPPFLAGS` . "-Wa,--noexecstack -Wall";
$debian_cflags =~ s/\n/ /g;
my $debian_ldflags = `dpkg-buildflags --get LDFLAGS`;
$debian_ldflags =~ s/\n/ /g;


%targets = (
       "debian" => {
               cflags => $debian_cflags,
               lflags => add($debian_ldflags, "-pthread"),
       },
[...]
       "debian-hppa" => {
               inherit_from => [ "linux-generic32", "debian", asm("parisc11_asm") ],
       },

Is that assembler supposed to work?  Is it the right assembler that
I'm using?

A full log can bee seen at:
buildd.debian.org/status/fetch.php?pkg=openssl&arch=hppa&ver=1.1.0~pre5-1&stamp=1464595947


Kurt


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


From rt at openssl.org  Mon May 30 20:23:35 2016
From: rt at openssl.org (Andy Polyakov via RT)
Date: Mon, 30 May 2016 20:23:35 +0000
Subject: [openssl-dev] [openssl.org #4548] s390x build problem
In-Reply-To: <0f31bcda-3c71-4ae2-7130-33b3a1d0d0e1@openssl.org>
References: <RT-Ticket-4548@openssl.org> <20160530195815.GA18832@roeckx.be>
 <rt-4.0.19-26078-1464638343-1596.4548-21-0@openssl.org>
 <0f31bcda-3c71-4ae2-7130-33b3a1d0d0e1@openssl.org>
Message-ID: <rt-4.0.19-26078-1464639815-375.4548-6-0@openssl.org>

> I'm getting:
> crypto/chacha/chacha-s390x.S: Assembler messages:
> crypto/chacha/chacha-s390x.S:7: Error: Unrecognized opcode: `clgije'
> 
> 
> A full build log is available on:
> https://buildd.debian.org/status/fetch.php?pkg=openssl&arch=s390x&ver=1.1.0~pre5-1&stamp=1464594754

It's overly easy to get carried away if you have access to single
system. Double-check attached.



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

-------------- next part --------------
commit fbaecaa94021294f4dd3f399338d076af284f787
Author: Andy Polyakov <appro at openssl.org>
Date:   Mon May 30 22:16:31 2016 +0200

    chacha/asm/chacha-s390x.pl: improve portability.
    
    cl[g]ije is an extension instruction, there is no real reason to
    limit ourselves to specific processors.

diff --git a/crypto/chacha/asm/chacha-s390x.pl b/crypto/chacha/asm/chacha-s390x.pl
index c7a2692..867594f 100755
--- a/crypto/chacha/asm/chacha-s390x.pl
+++ b/crypto/chacha/asm/chacha-s390x.pl
@@ -147,7 +147,8 @@ $code.=<<___;
 .type	ChaCha20_ctr32,\@function
 .align	32
 ChaCha20_ctr32:
-	cl${g}ije	$len,0,.Lno_data	# $len==0?
+	cl${g}fi	$len,0
+	je	.Lno_data	# $len==0?
 	a${g}hi	$len,-64
 	l${g}hi	%r1,-$frame
 	stm${g}	%r6,%r15,`6*$SIZE_T`($sp)

From rt at openssl.org  Mon May 30 20:37:56 2016
From: rt at openssl.org (Andy Polyakov via RT)
Date: Mon, 30 May 2016 20:37:56 +0000
Subject: [openssl-dev] [openssl.org #4550] hppa assembler problem
In-Reply-To: <caa3f596-0a11-daa7-1204-9458b44bdefb@openssl.org>
References: <RT-Ticket-4550@openssl.org> <20160530200848.GC18832@roeckx.be>
 <rt-4.0.19-26078-1464638931-234.4550-21-0@openssl.org>
 <caa3f596-0a11-daa7-1204-9458b44bdefb@openssl.org>
Message-ID: <rt-4.0.19-26078-1464640676-427.4550-6-0@openssl.org>

> I'm getting assembler errors on hppa that look like:
> crypto/aes/aes-parisc.s: Assembler messages:
> crypto/aes/aes-parisc.s:3: Error: unknown pseudo-op: `.subspa'
> crypto/aes/aes-parisc.s:7: Error: Unknown opcode: `aes_encrypt'
> crypto/aes/aes-parisc.s:11: Error: Missing function name for .PROC
> crypto/aes/aes-parisc.s:12: Error: Missing function name for .PROC
> 
> I'm guessing I'm doing something wrong, but hppa never had
> assembler enabled in Debian before.
> 
> The configuration I use is:
> my $debian_cflags = `dpkg-buildflags --get CFLAGS` .  `dpkg-buildflags --get CPPFLAGS` . "-Wa,--noexecstack -Wall";
> $debian_cflags =~ s/\n/ /g;
> my $debian_ldflags = `dpkg-buildflags --get LDFLAGS`;
> $debian_ldflags =~ s/\n/ /g;
> 
> 
> %targets = (
>        "debian" => {
>                cflags => $debian_cflags,
>                lflags => add($debian_ldflags, "-pthread"),
>        },
> [...]
>        "debian-hppa" => {
>                inherit_from => [ "linux-generic32", "debian", asm("parisc11_asm") ],
>        },
> 
> Is that assembler supposed to work?  Is it the right assembler that
> I'm using?

PA-RISC assembly modules were tested *only* on HP-UX. While it works
with GNU assembler, it's still one for HP-UX. Special thing about it is
that run-time format is not ELF, and supposedly that's what those
failing directives are about. I mean they are meant to make sense to
specifically HP-UX assemblers. I suppose it means that Linux support
would require extra work, adapting all modules to recognize additional
"perlasm flavour". It's not unlike that it's not about simple
decorations, ABI-specific adjustments might be required too... I don't
think I've actually seen PA-RISC ELF calling convention...



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


From kurt at roeckx.be  Mon May 30 21:13:37 2016
From: kurt at roeckx.be (Kurt Roeckx)
Date: Mon, 30 May 2016 23:13:37 +0200
Subject: [openssl-dev] [openssl.org #4550] hppa assembler problem
In-Reply-To: <rt-4.0.19-26078-1464640676-427.4550-6-0@openssl.org>
References: <RT-Ticket-4550@openssl.org> <20160530200848.GC18832@roeckx.be>
 <rt-4.0.19-26078-1464638931-234.4550-21-0@openssl.org>
 <caa3f596-0a11-daa7-1204-9458b44bdefb@openssl.org>
 <rt-4.0.19-26078-1464640676-427.4550-6-0@openssl.org>
Message-ID: <20160530211337.GA19883@roeckx.be>

On Mon, May 30, 2016 at 08:37:56PM +0000, Andy Polyakov via RT wrote:
> > I'm getting assembler errors on hppa that look like:
> > crypto/aes/aes-parisc.s: Assembler messages:
> > crypto/aes/aes-parisc.s:3: Error: unknown pseudo-op: `.subspa'
> > crypto/aes/aes-parisc.s:7: Error: Unknown opcode: `aes_encrypt'
> > crypto/aes/aes-parisc.s:11: Error: Missing function name for .PROC
> > crypto/aes/aes-parisc.s:12: Error: Missing function name for .PROC
> > 
> > I'm guessing I'm doing something wrong, but hppa never had
> > assembler enabled in Debian before.
> > 
> > The configuration I use is:
> > my $debian_cflags = `dpkg-buildflags --get CFLAGS` .  `dpkg-buildflags --get CPPFLAGS` . "-Wa,--noexecstack -Wall";
> > $debian_cflags =~ s/\n/ /g;
> > my $debian_ldflags = `dpkg-buildflags --get LDFLAGS`;
> > $debian_ldflags =~ s/\n/ /g;
> > 
> > 
> > %targets = (
> >        "debian" => {
> >                cflags => $debian_cflags,
> >                lflags => add($debian_ldflags, "-pthread"),
> >        },
> > [...]
> >        "debian-hppa" => {
> >                inherit_from => [ "linux-generic32", "debian", asm("parisc11_asm") ],
> >        },
> > 
> > Is that assembler supposed to work?  Is it the right assembler that
> > I'm using?
> 
> PA-RISC assembly modules were tested *only* on HP-UX. While it works
> with GNU assembler, it's still one for HP-UX. Special thing about it is
> that run-time format is not ELF, and supposedly that's what those
> failing directives are about. I mean they are meant to make sense to
> specifically HP-UX assemblers. I suppose it means that Linux support
> would require extra work, adapting all modules to recognize additional
> "perlasm flavour". It's not unlike that it's not about simple
> decorations, ABI-specific adjustments might be required too... I don't
> think I've actually seen PA-RISC ELF calling convention...

Then I suggest you forget about it.  hppa isn't officially in
Debian anymore, I'll just drop the assembler support.


Kurt


From rt at openssl.org  Mon May 30 21:13:48 2016
From: rt at openssl.org (Kurt Roeckx via RT)
Date: Mon, 30 May 2016 21:13:48 +0000
Subject: [openssl-dev] [openssl.org #4550] hppa assembler problem
In-Reply-To: <20160530211337.GA19883@roeckx.be>
References: <RT-Ticket-4550@openssl.org> <20160530200848.GC18832@roeckx.be>
 <rt-4.0.19-26078-1464638931-234.4550-21-0@openssl.org>
 <caa3f596-0a11-daa7-1204-9458b44bdefb@openssl.org>
 <rt-4.0.19-26078-1464640676-427.4550-6-0@openssl.org>
 <20160530211337.GA19883@roeckx.be>
Message-ID: <rt-4.0.19-26078-1464642828-939.4550-6-0@openssl.org>

On Mon, May 30, 2016 at 08:37:56PM +0000, Andy Polyakov via RT wrote:
> > I'm getting assembler errors on hppa that look like:
> > crypto/aes/aes-parisc.s: Assembler messages:
> > crypto/aes/aes-parisc.s:3: Error: unknown pseudo-op: `.subspa'
> > crypto/aes/aes-parisc.s:7: Error: Unknown opcode: `aes_encrypt'
> > crypto/aes/aes-parisc.s:11: Error: Missing function name for .PROC
> > crypto/aes/aes-parisc.s:12: Error: Missing function name for .PROC
> > 
> > I'm guessing I'm doing something wrong, but hppa never had
> > assembler enabled in Debian before.
> > 
> > The configuration I use is:
> > my $debian_cflags = `dpkg-buildflags --get CFLAGS` .  `dpkg-buildflags --get CPPFLAGS` . "-Wa,--noexecstack -Wall";
> > $debian_cflags =~ s/\n/ /g;
> > my $debian_ldflags = `dpkg-buildflags --get LDFLAGS`;
> > $debian_ldflags =~ s/\n/ /g;
> > 
> > 
> > %targets = (
> >        "debian" => {
> >                cflags => $debian_cflags,
> >                lflags => add($debian_ldflags, "-pthread"),
> >        },
> > [...]
> >        "debian-hppa" => {
> >                inherit_from => [ "linux-generic32", "debian", asm("parisc11_asm") ],
> >        },
> > 
> > Is that assembler supposed to work?  Is it the right assembler that
> > I'm using?
> 
> PA-RISC assembly modules were tested *only* on HP-UX. While it works
> with GNU assembler, it's still one for HP-UX. Special thing about it is
> that run-time format is not ELF, and supposedly that's what those
> failing directives are about. I mean they are meant to make sense to
> specifically HP-UX assemblers. I suppose it means that Linux support
> would require extra work, adapting all modules to recognize additional
> "perlasm flavour". It's not unlike that it's not about simple
> decorations, ABI-specific adjustments might be required too... I don't
> think I've actually seen PA-RISC ELF calling convention...

Then I suggest you forget about it.  hppa isn't officially in
Debian anymore, I'll just drop the assembler support.


Kurt


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


From rt at openssl.org  Mon May 30 21:28:06 2016
From: rt at openssl.org (Andy Polyakov via RT)
Date: Mon, 30 May 2016 21:28:06 +0000
Subject: [openssl-dev] [openssl.org #4549] powerpc test problem: missing
	symbols
In-Reply-To: <77236419-5c66-8055-4b86-9ce9c7c4cef6@openssl.org>
References: <RT-Ticket-4549@openssl.org> <20160530200039.GB18832@roeckx.be>
 <rt-4.0.19-26078-1464638442-1946.4549-21-0@openssl.org>
 <77236419-5c66-8055-4b86-9ce9c7c4cef6@openssl.org>
Message-ID: <rt-4.0.19-26106-1464643686-1787.4549-6-0@openssl.org>

> I'm seeing this on powerpc:
> ../test/recipes/01-test_ordinals.t ......... ok
> 
> #   Failed test 'check that there are no missing symbols in libcrypto.so'
> #   at ../test/recipes/01-test_symbol_presence.t line 112.
> # Looks like you failed 1 test of 4.
> ../test/recipes/01-test_symbol_presence.t .. 
> Dubious, test returned 1 (wstat 256, 0x100)
> Failed 1/4 subtests 
> 
> I a full log is at:
> https://buildd.debian.org/status/fetch.php?pkg=openssl&arch=powerpc&ver=1.1.0~pre5-1&stamp=1464595346
> 
> If I find time I'll try to look in the the real cause.

For what it's worth I can't reproduce problem on Fedora or RedHat.



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


From rt at openssl.org  Mon May 30 22:32:38 2016
From: rt at openssl.org (John Denker via RT)
Date: Mon, 30 May 2016 22:32:38 +0000
Subject: [openssl-dev] [openssl.org #3502] nameConstraints bypass bug
In-Reply-To: <574CBDEE.1030308@av8n.com>
References: <RT-Ticket-3502@openssl.org> <53F7A00F.6090801@av8n.com>
 <rt-4.0.19-26078-1464634577-865.3502-6-0@openssl.org>
 <574CBDEE.1030308@av8n.com>
Message-ID: <rt-4.0.19-26106-1464647558-1722.3502-6-0@openssl.org>

I'm glad to see some discussion of this issue.
Note that other implementations treated this as
a bug and fixed it a long time ago.

On 05/30/2016 11:56 AM, Rich Salz wrote:

> WebPKI has deprecated
> cn-as-hostname for more than a decade and mandated SAN names.

Well, maybe that is the Right Answer?

I'm not sure what "deprecated" and "mandated" mean in
the openssl context.  If openssl actually de-implemented
CN-as-hostname and actually mandated SAN, that would
solve the nameConstraints bypass bug in grand style.

> Leaving this open because we might be able to do some hueristics/hacks to
> determine when the CN "should be" a DNS name.

How about this for a heuristic:  If nameConstraints are
in effect, then the validator MUST NOT accept the CN as
a DNS name.  This seems like the least the validator
could do, in light of the aforementioned deprecation.

This seems unlikely to generate false alarms, since any
issuer who uses nameConstraints should be savvy enough 
to not rely on CN-as-hostname to the exclusion of SANs.

  Optionally a CN that satisfies the nameConstraints could
  be tolerated, insofar as it is deprecated but harmless.

>  But the workaround is to use SAN.

That workaround is not specific enough to solve the 
security problem.  Note the contrast:
 -- As it stands, good guys are /allowed/ to use SAN.
 -- The problem is not solved until bad guys are
  /required/ to use SAN;
 ... or more to the point, required to not use anything
  but SAN;
 ... or even more to the point, required to not use
  anything that bypasses the nameConstraints.

The crucial word there is "required".


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


From hanno at hboeck.de  Mon May 30 23:38:16 2016
From: hanno at hboeck.de (Hanno =?UTF-8?B?QsO2Y2s=?=)
Date: Tue, 31 May 2016 09:38:16 +1000
Subject: [openssl-dev] dead links in openssl docs
Message-ID: <20160531093816.1a2c9f8e@pc1>

Hi,

https://www.openssl.org/docs/manmaster/apps/s_client.html
has a link to
https://www.openssl.org/docs/manmaster/apps/SSL_CONF_cmd.html

the latter doesn't exist.

Seems the correct URL is:
https://www.openssl.org/docs/manmaster/ssl/SSL_CONF_cmd.html

I assume these are somehow autogenerated.

-- 
Hanno B?ck
https://hboeck.de/

mail/jabber: hanno at hboeck.de
GPG: BBB51E42
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20160531/5e4e6bc6/attachment.sig>

From rsalz at akamai.com  Tue May 31 02:02:09 2016
From: rsalz at akamai.com (Salz, Rich)
Date: Tue, 31 May 2016 02:02:09 +0000
Subject: [openssl-dev] dead links in openssl docs
In-Reply-To: <20160531093816.1a2c9f8e@pc1>
References: <20160531093816.1a2c9f8e@pc1>
Message-ID: <8b20c6a80f0f4d6284997bd824af481a@usma1ex-dag1mb1.msg.corp.akamai.com>


> https://www.openssl.org/docs/manmaster/apps/s_client.html
> has a link to
> https://www.openssl.org/docs/manmaster/apps/SSL_CONF_cmd.html
> 
> the latter doesn't exist.
> 
> Seems the correct URL is:
> https://www.openssl.org/docs/manmaster/ssl/SSL_CONF_cmd.html
> 
> I assume these are somehow autogenerated.

Yes.  https://github.com/openssl/web/blob/master/bin/mk-manpages


From rt at openssl.org  Tue May 31 02:06:41 2016
From: rt at openssl.org (Salz, Rich via RT)
Date: Tue, 31 May 2016 02:06:41 +0000
Subject: [openssl-dev] [openssl.org #3502] nameConstraints bypass bug
In-Reply-To: <d05a342bbd484780a2eb7199c0292323@usma1ex-dag1mb1.msg.corp.akamai.com>
References: <RT-Ticket-3502@openssl.org> <53F7A00F.6090801@av8n.com>
 <rt-4.0.19-26078-1464634577-865.3502-6-0@openssl.org>
 <574CBDEE.1030308@av8n.com>
 <rt-4.0.19-26106-1464647558-1722.3502-6-0@openssl.org>
 <d05a342bbd484780a2eb7199c0292323@usma1ex-dag1mb1.msg.corp.akamai.com>
Message-ID: <rt-4.0.19-15649-1464660401-33.3502-6-0@openssl.org>

> Note that other implementations treated this as a bug and fixed it a long time
> ago.

What other implementations, and what did they do?  Always treating a CN as a DNS name?  We can't.

> I'm not sure what "deprecated" and "mandated" mean in the openssl
> context.  If openssl actually de-implemented CN-as-hostname and actually
> mandated SAN, that would solve the nameConstraints bypass bug in grand
> style.

Applications can do that now by setting the right flag, as Viktor pointed out.  I think it's too late to make the default change for 1.1

> How about this for a heuristic:  If nameConstraints are in effect, then the
> validator MUST NOT accept the CN as a DNS name.  This seems like the least
> the validator could do, in light of the aforementioned deprecation.

Probably.
 
>  -- The problem is not solved until bad guys are
>   /required/ to use SAN;

Applications can make that happen now.

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


From openssl-users at dukhovni.org  Tue May 31 02:38:42 2016
From: openssl-users at dukhovni.org (Viktor Dukhovni)
Date: Mon, 30 May 2016 22:38:42 -0400
Subject: [openssl-dev] [openssl.org #3502] nameConstraints bypass bug
In-Reply-To: <rt-4.0.19-15649-1464660401-33.3502-6-0@openssl.org>
References: <RT-Ticket-3502@openssl.org> <53F7A00F.6090801@av8n.com>
 <rt-4.0.19-26078-1464634577-865.3502-6-0@openssl.org>
 <574CBDEE.1030308@av8n.com>
 <rt-4.0.19-26106-1464647558-1722.3502-6-0@openssl.org>
 <d05a342bbd484780a2eb7199c0292323@usma1ex-dag1mb1.msg.corp.akamai.com>
 <rt-4.0.19-15649-1464660401-33.3502-6-0@openssl.org>
Message-ID: <220AE37A-AE37-4C68-8144-FCE8982E620D@dukhovni.org>


> On May 30, 2016, at 10:06 PM, Salz, Rich via RT <rt at openssl.org> wrote:
> 
>> I'm not sure what "deprecated" and "mandated" mean in the openssl
>> context.  If openssl actually de-implemented CN-as-hostname and actually
>> mandated SAN, that would solve the nameConstraints bypass bug in grand
>> style.
> 
> Applications can do that now by setting the right flag, as Viktor pointed out.  I think it's too late to make the default change for 1.1

Well, to be fair, I was proposing a new flag.  We don't yet have a flag to
suppress processing of CN in the absence of DNS-ID SANs.

-- 
	Viktor.


From rt at openssl.org  Tue May 31 02:38:47 2016
From: rt at openssl.org (Viktor Dukhovni via RT)
Date: Tue, 31 May 2016 02:38:47 +0000
Subject: [openssl-dev] [openssl.org #3502] nameConstraints bypass bug
In-Reply-To: <220AE37A-AE37-4C68-8144-FCE8982E620D@dukhovni.org>
References: <RT-Ticket-3502@openssl.org> <53F7A00F.6090801@av8n.com>
 <rt-4.0.19-26078-1464634577-865.3502-6-0@openssl.org>
 <574CBDEE.1030308@av8n.com>
 <rt-4.0.19-26106-1464647558-1722.3502-6-0@openssl.org>
 <d05a342bbd484780a2eb7199c0292323@usma1ex-dag1mb1.msg.corp.akamai.com>
 <rt-4.0.19-15649-1464660401-33.3502-6-0@openssl.org>
 <220AE37A-AE37-4C68-8144-FCE8982E620D@dukhovni.org>
Message-ID: <rt-4.0.19-15649-1464662327-64.3502-6-0@openssl.org>


> On May 30, 2016, at 10:06 PM, Salz, Rich via RT <rt at openssl.org> wrote:
> 
>> I'm not sure what "deprecated" and "mandated" mean in the openssl
>> context.  If openssl actually de-implemented CN-as-hostname and actually
>> mandated SAN, that would solve the nameConstraints bypass bug in grand
>> style.
> 
> Applications can do that now by setting the right flag, as Viktor pointed out.  I think it's too late to make the default change for 1.1

Well, to be fair, I was proposing a new flag.  We don't yet have a flag to
suppress processing of CN in the absence of DNS-ID SANs.

-- 
	Viktor.


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


From brian at briansmith.org  Tue May 31 02:54:01 2016
From: brian at briansmith.org (Brian Smith)
Date: Mon, 30 May 2016 16:54:01 -1000
Subject: [openssl-dev] [openssl.org #3502] nameConstraints bypass bug
In-Reply-To: <rt-4.0.19-15649-1464660401-33.3502-6-0@openssl.org>
References: <RT-Ticket-3502@openssl.org> <53F7A00F.6090801@av8n.com>
 <rt-4.0.19-26078-1464634577-865.3502-6-0@openssl.org>
 <574CBDEE.1030308@av8n.com>
 <rt-4.0.19-26106-1464647558-1722.3502-6-0@openssl.org>
 <d05a342bbd484780a2eb7199c0292323@usma1ex-dag1mb1.msg.corp.akamai.com>
 <rt-4.0.19-15649-1464660401-33.3502-6-0@openssl.org>
Message-ID: <CAFewVt6JxRkKorW=Om8vZqD=dJpomYdROVr4hhZWV+Q_6MJeOg@mail.gmail.com>

Salz, Rich via RT <rt at openssl.org> wrote:

> > Note that other implementations treated this as a bug and fixed it a
> long time
> > ago.
>
> What other implementations, and what did they do?  Always treating a CN as
> a DNS name?  We can't.
>

As one example, mozilla::pkix treats the CN as a dNSName/iPAddress iif
there is no subjectAltName extension and iif the CN is a valid
dNSNa/iPAddress syntactically.


> Applications can do that now by setting the right flag, as Viktor pointed
> out.  I think it's too late to make the default change for 1.1
>

The important thing is: What happens when applications use the default
settings? If the default settings are "don't consider the subject CN for
name constraint processing, but do consider it for name validation" then
that's obviously wrong and dangerous.

Besides that, there needs to be a way to make name constraint processing
consistent with name validation. That means that if name validation is
configured (by default or with a switch) to look at subject CNs then the
name constraints need to be configurable to do the same. Name validation
and name constraint validation go hand-in-hand.


> > How about this for a heuristic:  If nameConstraints are in effect, then
> the
> > validator MUST NOT accept the CN as a DNS name.  This seems like the
> least
> > the validator could do, in light of the aforementioned deprecation.
>
> Probably.
>

If the validator has that much information then it should be simple for it
to keep the state in sync. But, often (usually?) certificate chain
validation and certificate name validation are done in separate steps by
applications, and it's difficult or impossible to keep things in sync in
that case.


> >  -- The problem is not solved until bad guys are
> >   /required/ to use SAN;
>
> Applications can make that happen now.


Again, what matters is less what applications *can* do and more what
applications *actually* do. I suspect that most applications are having the
wrong, dangerous, thing happen. In fact, that is almost definitely the
case, considering that many applications are doing their own name
validation (and thus almost definitely looking at the subject CN as that is
historically how it is done), as OpenSSL didn't provide a name validation
API until recently.

So, I agree with the others that OpenSSL is broken in this respect.

Cheers,
Brian
-- 
https://briansmith.org/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20160530/0e516707/attachment.html>

From rt at openssl.org  Tue May 31 02:54:13 2016
From: rt at openssl.org (Brian Smith via RT)
Date: Tue, 31 May 2016 02:54:13 +0000
Subject: [openssl-dev] [openssl.org #3502] nameConstraints bypass bug
In-Reply-To: <CAFewVt6JxRkKorW=Om8vZqD=dJpomYdROVr4hhZWV+Q_6MJeOg@mail.gmail.com>
References: <RT-Ticket-3502@openssl.org> <53F7A00F.6090801@av8n.com>
 <rt-4.0.19-26078-1464634577-865.3502-6-0@openssl.org>
 <574CBDEE.1030308@av8n.com>
 <rt-4.0.19-26106-1464647558-1722.3502-6-0@openssl.org>
 <d05a342bbd484780a2eb7199c0292323@usma1ex-dag1mb1.msg.corp.akamai.com>
 <rt-4.0.19-15649-1464660401-33.3502-6-0@openssl.org>
 <CAFewVt6JxRkKorW=Om8vZqD=dJpomYdROVr4hhZWV+Q_6MJeOg@mail.gmail.com>
Message-ID: <rt-4.0.19-15649-1464663253-193.3502-6-0@openssl.org>

Salz, Rich via RT <rt at openssl.org> wrote:

> > Note that other implementations treated this as a bug and fixed it a
> long time
> > ago.
>
> What other implementations, and what did they do?  Always treating a CN as
> a DNS name?  We can't.
>

As one example, mozilla::pkix treats the CN as a dNSName/iPAddress iif
there is no subjectAltName extension and iif the CN is a valid
dNSNa/iPAddress syntactically.


> Applications can do that now by setting the right flag, as Viktor pointed
> out.  I think it's too late to make the default change for 1.1
>

The important thing is: What happens when applications use the default
settings? If the default settings are "don't consider the subject CN for
name constraint processing, but do consider it for name validation" then
that's obviously wrong and dangerous.

Besides that, there needs to be a way to make name constraint processing
consistent with name validation. That means that if name validation is
configured (by default or with a switch) to look at subject CNs then the
name constraints need to be configurable to do the same. Name validation
and name constraint validation go hand-in-hand.


> > How about this for a heuristic:  If nameConstraints are in effect, then
> the
> > validator MUST NOT accept the CN as a DNS name.  This seems like the
> least
> > the validator could do, in light of the aforementioned deprecation.
>
> Probably.
>

If the validator has that much information then it should be simple for it
to keep the state in sync. But, often (usually?) certificate chain
validation and certificate name validation are done in separate steps by
applications, and it's difficult or impossible to keep things in sync in
that case.


> >  -- The problem is not solved until bad guys are
> >   /required/ to use SAN;
>
> Applications can make that happen now.


Again, what matters is less what applications *can* do and more what
applications *actually* do. I suspect that most applications are having the
wrong, dangerous, thing happen. In fact, that is almost definitely the
case, considering that many applications are doing their own name
validation (and thus almost definitely looking at the subject CN as that is
historically how it is done), as OpenSSL didn't provide a name validation
API until recently.

So, I agree with the others that OpenSSL is broken in this respect.

Cheers,
Brian
-- 
https://briansmith.org/

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


From openssl-users at dukhovni.org  Tue May 31 03:58:23 2016
From: openssl-users at dukhovni.org (Viktor Dukhovni)
Date: Tue, 31 May 2016 03:58:23 +0000
Subject: [openssl-dev] [openssl.org #3502] nameConstraints bypass bug
In-Reply-To: <rt-4.0.19-15649-1464663253-193.3502-6-0@openssl.org>
References: <RT-Ticket-3502@openssl.org> <53F7A00F.6090801@av8n.com>
 <rt-4.0.19-26078-1464634577-865.3502-6-0@openssl.org>
 <574CBDEE.1030308@av8n.com>
 <rt-4.0.19-26106-1464647558-1722.3502-6-0@openssl.org>
 <d05a342bbd484780a2eb7199c0292323@usma1ex-dag1mb1.msg.corp.akamai.com>
 <rt-4.0.19-15649-1464660401-33.3502-6-0@openssl.org>
 <CAFewVt6JxRkKorW=Om8vZqD=dJpomYdROVr4hhZWV+Q_6MJeOg@mail.gmail.com>
 <rt-4.0.19-15649-1464663253-193.3502-6-0@openssl.org>
Message-ID: <20160531035823.GU3300@mournblade.imrryr.org>

On Tue, May 31, 2016 at 02:54:13AM +0000, Brian Smith via RT wrote:

> > Applications can do that now by setting the right flag, as Viktor pointed
> > out.  I think it's too late to make the default change for 1.1
> 
> The important thing is: What happens when applications use the default
> settings? If the default settings are "don't consider the subject CN for
> name constraint processing, but do consider it for name validation" then
> that's obviously wrong and dangerous.

As of OpenSSL 1.0.2, we provide built-in name check support.  When
the built-in routines are enabled, we know whether the application
has asked us to check for DNS names (and which ones).

The built-in checks do accept CN-ID as a fallback in the absence
of DNS-IDs.  The name constraint code could make use of this to
apply name constraints to the CN-ID when we'll also be doing the
hostname checks on the CN-ID.

Now, not all (likely only a minority of) applications delegate name
checks to OpenSSL.  It is more difficult to protect applications
that do their own name checks.  If the sole name in the subject DN
is a valid DNS hostname, we could apply name constraints.  If it
is instead "Joe User", that won't look like a DNS name, and we
could ignore it.  That would be a bit of a hack, but it is not
clear that we can do any better when we have no idea what name
checks if any the application intends to perform.

Name constraints in the X.509v3 PKI have not worked well, and are
rarely used.  The attack requires a issuing CA to be willing to
issue certificates beyond its constraints, that would be quite
noticeable and rather unwise.  So I think this is not a major
problem.  We should probably make a reasonable effort to address
this, but the urgency is I think low.

-- 
	Viktor.

From rt at openssl.org  Tue May 31 04:41:03 2016
From: rt at openssl.org (John Denker via RT)
Date: Tue, 31 May 2016 04:41:03 +0000
Subject: [openssl-dev] [openssl.org #3502] nameConstraints bypass bug
In-Reply-To: <574D1448.5030301@av8n.com>
References: <RT-Ticket-3502@openssl.org> <53F7A00F.6090801@av8n.com>
 <rt-4.0.19-26078-1464634577-865.3502-6-0@openssl.org>
 <574CBDEE.1030308@av8n.com>
 <d05a342bbd484780a2eb7199c0292323@usma1ex-dag1mb1.msg.corp.akamai.com>
 <rt-4.0.19-15649-1464660401-33.3502-6-0@openssl.org>
 <CAFewVt6JxRkKorW=Om8vZqD=dJpomYdROVr4hhZWV+Q_6MJeOg@mail.gmail.com>
 <rt-4.0.19-15649-1464663253-193.3502-6-0@openssl.org>
 <20160531035823.GU3300@mournblade.imrryr.org> <574D1448.5030301@av8n.com>
Message-ID: <rt-4.0.19-15649-1464669663-524.3502-6-0@openssl.org>

On 05/30/2016 08:58 PM, Viktor Dukhovni wrote:

> Name constraints in the X.509v3 PKI have not worked well, and are
> rarely used.  The attack requires a issuing CA to be willing to
> issue certificates beyond its constraints, that would be quite
> noticeable and rather unwise.  So I think this is not a major
> problem.  We should probably make a reasonable effort to address
> this, but the urgency is I think low.

The priority may be higher than that, because of something
that has not yet been mentioned in this discussion:

  The nameConstraints protect the issuing CA, not just
  the relying parties.

Here's the scenario:  I persuade 1000 of my closest friends
to accept my mumble.com CA as a trusted root.  I offer them
the assurance that:
  The root cert is name-constrained, and therefore affects
  only their interactions with *.mumble.com, so it's
  not very dangerous.     [1]

The first problem is that if openssl does not implement
nameConstraints properly, my assertion [1] is false.

This leads to a second problem:  My cert-issuing machine
becomes a much juicier target.  If anybody pwns my machine,
then /every/ cert-based activity of /every one/ of my friends
is compromised, via the nameConstraints bypass bug.

The problem does not revolve around me intentionally doing
something unwise;  it involves a bad guy stealing from me
and then doing something nasty.

So it seems the priority / prevalence argument is at best
circular:  People would use the feature a lot more if they
could trust it to do the right thing.

As Fred Smith once said, you don't judge the importance or
the optimal size of the proposed bridge according to the
number of people seen driving across the river before the
bridge is built.


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


From brian at briansmith.org  Tue May 31 06:43:36 2016
From: brian at briansmith.org (Brian Smith)
Date: Mon, 30 May 2016 20:43:36 -1000
Subject: [openssl-dev] [openssl.org #3502] nameConstraints bypass bug
In-Reply-To: <20160531035823.GU3300@mournblade.imrryr.org>
References: <RT-Ticket-3502@openssl.org> <53F7A00F.6090801@av8n.com>
 <rt-4.0.19-26078-1464634577-865.3502-6-0@openssl.org>
 <574CBDEE.1030308@av8n.com>
 <rt-4.0.19-26106-1464647558-1722.3502-6-0@openssl.org>
 <d05a342bbd484780a2eb7199c0292323@usma1ex-dag1mb1.msg.corp.akamai.com>
 <rt-4.0.19-15649-1464660401-33.3502-6-0@openssl.org>
 <CAFewVt6JxRkKorW=Om8vZqD=dJpomYdROVr4hhZWV+Q_6MJeOg@mail.gmail.com>
 <rt-4.0.19-15649-1464663253-193.3502-6-0@openssl.org>
 <20160531035823.GU3300@mournblade.imrryr.org>
Message-ID: <CAFewVt4S6e4JrWOAYYyhMAgofAgt6NKcTq2i+htT+uFxWYL79g@mail.gmail.com>

On Mon, May 30, 2016 at 5:58 PM, Viktor Dukhovni <openssl-users at dukhovni.org
> wrote:

> Name constraints in the X.509v3 PKI have not worked well, and are
> rarely used.  The attack requires a issuing CA to be willing to
> issue certificates beyond its constraints, that would be quite
> noticeable and rather unwise.  So I think this is not a major
> problem.  We should probably make a reasonable effort to address
> this, but the urgency is I think low.
>

Not too long ago, there were changes to the CABForum rules about
certificates to make it easier for any website to get a CA certificates
constrained to its domain name. There were some problems with the loosening
of the rules, and Apple has been slow to implement name constraints, so not
many websites are taking advantage of them. But, soon, I am hopeful, and I
expect, that it will soon be as easy to get name-constrained CA certificate
as it is to get a wildcard certificates now. In fact, it is really
important for the security of many (smaller and medium-sized) websites that
this become possible, because this would make HPKP work much better and
reduce risks relative to wildcard certificates.

In particular, we should be designing things based on the assumption that
in the next few years, the owner of briansmith.org can get a CA certificate
with name constraint of dNSName=briansmith.org. Then the owner of
briansmith.org will be able to put Subject={CN=google.com} in his
certificates if he feels like it. And, we shouldn't even expect such
certificates to be revoked because they will be harmless to anybody that
does validation correctly (i.e. by either ignoring the subject CN or by
applying name constraints to the subject CN).

Is such a nuanced thing something that application developers can really be
expected to deal with on their own? I doubt it.

Cheers,
Brian
-- 
https://briansmith.org/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20160530/aeea61ca/attachment-0001.html>

From dni.grosu at gmail.com  Tue May 31 07:38:17 2016
From: dni.grosu at gmail.com (danigrosu)
Date: Tue, 31 May 2016 00:38:17 -0700 (MST)
Subject: [openssl-dev] openssl.cnf causes Segmentation fault
Message-ID: <1464680297852-66453.post@n7.nabble.com>

Hi everyone. 

My intention is to modify the openssl.cnf file in order to add a new RSA
ENGINE, dynamicaly. 
I have found the /etc/ssl/openssl.cnf file and after my modifications it
looks like this: 

#############################openssl.cnf ########################### 
# 
# OpenSSL example configuration file. 
# This is mostly being used for generation of certificate requests. 
# 


openssl_conf = openssl_def 


# This definition stops the following lines choking if HOME isn't 
# defined. 
HOME	= . 
RANDFILE	= $ENV::HOME/.rnd 


## other lines 
#----------------------------------unmodified------------------------------------- 
## end of other lines 


ess_cert_id_chain	= no	# Must the ESS cert id chain be included? 
                                # (optional, default: no) 
                                
[openssl_def] 
engines = engine_section 

[engine_section] 

foo = gpu_section 

[gpu_section] 
dynamic_path =
/usr/lib/x86_64-linux-gnu/openssl-1.0.0/engines/librsax_gpu.so 
engine_id = rsax_gpu 
default_algorithms = ALL 
init = 1 
########################end of file################################ 


The problem is that if i try the command 
"openssl engine", it results in a "Segmentation fault (core dumped)" 

I am struggling with this for a while. 
OpenSSL 1.0.1f 6 Jan 2014, Ubuntu 14.04 

Best regards, 
Dani Grosu



--
View this message in context: http://openssl.6102.n7.nabble.com/openssl-cnf-causes-Segmentation-fault-tp66453.html
Sent from the OpenSSL - Dev mailing list archive at Nabble.com.

From rt at openssl.org  Tue May 31 13:29:39 2016
From: rt at openssl.org (Matt Caswell via RT)
Date: Tue, 31 May 2016 13:29:39 +0000
Subject: [openssl-dev] [openssl.org #4149] [PATCH] ssl_set_pkey()
	unnecessarily updates certificates
In-Reply-To: <794E9936-04FF-45C6-8906-82F0B1BC2DCB@akamai.com>
References: <RT-Ticket-4149@openssl.org>
 <794E9936-04FF-45C6-8906-82F0B1BC2DCB@akamai.com>
Message-ID: <rt-4.0.19-15649-1464701379-596.4149-6-0@openssl.org>

Steve fixed this via commit f72f00d495.

Closing.

Matt

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


From rt at openssl.org  Tue May 31 13:31:36 2016
From: rt at openssl.org (Short, Todd via RT)
Date: Tue, 31 May 2016 13:31:36 +0000
Subject: [openssl-dev] [openssl.org #4149] Resolved: [PATCH]
	ssl_set_pkey() unnecessarily updates certificates
In-Reply-To: <7330B063-667D-4B58-9A41-CE39E6950CA7@akamai.com>
References: <RT-Ticket-4149@openssl.org>
 <rt-4.0.19-15649-1464701380-1387.4149-10-0@openssl.org>
 <7330B063-667D-4B58-9A41-CE39E6950CA7@akamai.com>
Message-ID: <rt-4.0.19-26078-1464701496-107.4149-6-0@openssl.org>

I also closed out GH478 (which was a fix for RT4149).
--
-Todd Short
// tshort at akamai.com<mailto:tshort at akamai.com>
// "One if by land, two if by sea, three if by the Internet."

On May 31, 2016, at 9:29 AM, Matt Caswell via RT <rt at openssl.org<mailto:rt at openssl.org>> wrote:

According to our records, your request has been resolved. If you have any
further questions or concerns, please respond to this message.

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



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


From rt at openssl.org  Tue May 31 13:33:34 2016
From: rt at openssl.org (Salz, Rich via RT)
Date: Tue, 31 May 2016 13:33:34 +0000
Subject: [openssl-dev] [openssl.org #3502] nameConstraints bypass bug
In-Reply-To: <4a5af20c345349c58c12aee87201fb1b@usma1ex-dag1mb1.msg.corp.akamai.com>
References: <RT-Ticket-3502@openssl.org> <53F7A00F.6090801@av8n.com>
 <rt-4.0.19-26078-1464634577-865.3502-6-0@openssl.org>
 <574CBDEE.1030308@av8n.com>
 <rt-4.0.19-15649-1464660401-33.3502-6-0@openssl.org>
 <CAFewVt6JxRkKorW=Om8vZqD=dJpomYdROVr4hhZWV+Q_6MJeOg@mail.gmail.com>
 <rt-4.0.19-15649-1464663253-193.3502-6-0@openssl.org>
 <20160531035823.GU3300@mournblade.imrryr.org>
 <CAFewVt4S6e4JrWOAYYyhMAgofAgt6NKcTq2i+htT+uFxWYL79g@mail.gmail.com>
 <4a5af20c345349c58c12aee87201fb1b@usma1ex-dag1mb1.msg.corp.akamai.com>
Message-ID: <rt-4.0.19-15649-1464701614-1327.3502-6-0@openssl.org>

I completely agree that nameconstraints are going to become a bigger deal, likely in the next 12-24 months, and certainly during the peak usage time of OpenSSL 1.1



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


From openssl-users at dukhovni.org  Tue May 31 13:40:05 2016
From: openssl-users at dukhovni.org (Viktor Dukhovni)
Date: Tue, 31 May 2016 09:40:05 -0400
Subject: [openssl-dev] [openssl.org #3502] nameConstraints bypass bug
In-Reply-To: <CAFewVt4S6e4JrWOAYYyhMAgofAgt6NKcTq2i+htT+uFxWYL79g@mail.gmail.com>
References: <RT-Ticket-3502@openssl.org> <53F7A00F.6090801@av8n.com>
 <rt-4.0.19-26078-1464634577-865.3502-6-0@openssl.org>
 <574CBDEE.1030308@av8n.com>
 <rt-4.0.19-26106-1464647558-1722.3502-6-0@openssl.org>
 <d05a342bbd484780a2eb7199c0292323@usma1ex-dag1mb1.msg.corp.akamai.com>
 <rt-4.0.19-15649-1464660401-33.3502-6-0@openssl.org>
 <CAFewVt6JxRkKorW=Om8vZqD=dJpomYdROVr4hhZWV+Q_6MJeOg@mail.gmail.com>
 <rt-4.0.19-15649-1464663253-193.3502-6-0@openssl.org>
 <20160531035823.GU3300@mournblade.imrryr.org>
 <CAFewVt4S6e4JrWOAYYyhMAgofAgt6NKcTq2i+htT+uFxWYL79g@mail.gmail.com>
Message-ID: <EDEC9AF8-1882-432D-AEAD-88A759A739BB@dukhovni.org>


> On May 31, 2016, at 2:43 AM, Brian Smith <brian at briansmith.org> wrote:
> 
> Not too long ago, there were changes to the CABForum rules about certificates to make it easier for any website to get a CA certificates constrained to its domain name. There were some problems with the loosening of the rules, and Apple has been slow to implement name constraints, so not many websites are taking advantage of them. But, soon, I am hopeful, and I expect, that it will soon be as easy to get name-constrained CA certificate as it is to get a wildcard certificates now. In fact, it is really important for the security of many (smaller and medium-sized) websites that this become possible, because this would make HPKP work much better and reduce risks relative to wildcard certificates.
> 
> In particular, we should be designing things based on the assumption that in the next few years, the owner of briansmith.org can get a CA certificate with name constraint of dNSName=briansmith.org. Then the owner of briansmith.org will be able to put Subject={CN=google.com} in his certificates if he feels like it. And, we shouldn't even expect such certificates to be revoked because they will be harmless to anybody that does validation correctly (i.e. by either ignoring the subject CN or by applying name constraints to the subject CN).

Well, if this becomes reality, it puts the final nail in the coffin of OpenSSL
versions prior to 1.0.2.  These don't have built-in name checks, and 0.9.8 and
1.0.0 are no longer supported, but are still used on some legacy systems.

For 1.0.2 and 1.1.0 it is possible to "align" the behaviour of nameConstraints
with the built-in name checks for applications that use the built-in name checks.

The ad-hoc --- apply nameConstraints if the CN is a valid DNS name --- approach
could perhaps be of some use with 1.0.1.  I might note that RFC 6125 says that
CN-ID is only applicable when the subject DN has exactly one CN component, but
various applications have historically chosen either the first, last or any CN
component in an ad-hoc manner.  Sot is also not clear what OpenSSL should do
when there are multiple CNs.

-- 
	Viktor.

From uri at ll.mit.edu  Tue May 31 13:54:59 2016
From: uri at ll.mit.edu (Blumenthal, Uri - 0553 - MITLL)
Date: Tue, 31 May 2016 13:54:59 +0000
Subject: [openssl-dev] [openssl.org #3502] nameConstraints bypass bug
In-Reply-To: <CAFewVt6JxRkKorW=Om8vZqD=dJpomYdROVr4hhZWV+Q_6MJeOg@mail.gmail.com>
References: <RT-Ticket-3502@openssl.org> <53F7A00F.6090801@av8n.com>
 <rt-4.0.19-26078-1464634577-865.3502-6-0@openssl.org>
 <574CBDEE.1030308@av8n.com>
 <rt-4.0.19-26106-1464647558-1722.3502-6-0@openssl.org>
 <d05a342bbd484780a2eb7199c0292323@usma1ex-dag1mb1.msg.corp.akamai.com>
 <rt-4.0.19-15649-1464660401-33.3502-6-0@openssl.org>
 <CAFewVt6JxRkKorW=Om8vZqD=dJpomYdROVr4hhZWV+Q_6MJeOg@mail.gmail.com>
Message-ID: <D3730F8C.2CD4D%uri@ll.mit.edu>

>> What other implementations, and what did they do?  Always treating a CN as a
>> DNS name?  We can't.
> 
> As one example, mozilla::pkix treats the CN as a dNSName/iPAddress iif there
> is no subjectAltName extension and iif the CN is a valid dNSNa/iPAddress
> syntactically.

That approach seems wrong.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20160531/88c5d918/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4324 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20160531/88c5d918/attachment.bin>

From rt at openssl.org  Tue May 31 13:55:12 2016
From: rt at openssl.org (Blumenthal, Uri - 0553 - MITLL via RT)
Date: Tue, 31 May 2016 13:55:12 +0000
Subject: [openssl-dev] [openssl.org #3502] nameConstraints bypass bug
In-Reply-To: <D3730F8C.2CD4D%uri@ll.mit.edu>
References: <RT-Ticket-3502@openssl.org> <53F7A00F.6090801@av8n.com>
 <rt-4.0.19-26078-1464634577-865.3502-6-0@openssl.org>
 <574CBDEE.1030308@av8n.com>
 <rt-4.0.19-26106-1464647558-1722.3502-6-0@openssl.org>
 <d05a342bbd484780a2eb7199c0292323@usma1ex-dag1mb1.msg.corp.akamai.com>
 <rt-4.0.19-15649-1464660401-33.3502-6-0@openssl.org>
 <CAFewVt6JxRkKorW=Om8vZqD=dJpomYdROVr4hhZWV+Q_6MJeOg@mail.gmail.com>
 <D3730F8C.2CD4D%uri@ll.mit.edu>
Message-ID: <rt-4.0.19-26078-1464702912-1604.3502-6-0@openssl.org>

>> What other implementations, and what did they do?  Always treating a CN as a
>> DNS name?  We can't.
> 
> As one example, mozilla::pkix treats the CN as a dNSName/iPAddress iif there
> is no subjectAltName extension and iif the CN is a valid dNSNa/iPAddress
> syntactically.

That approach seems wrong.



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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4324 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20160531/d6b8f5db/attachment-0001.bin>

From uri at ll.mit.edu  Tue May 31 14:07:41 2016
From: uri at ll.mit.edu (Blumenthal, Uri - 0553 - MITLL)
Date: Tue, 31 May 2016 14:07:41 +0000
Subject: [openssl-dev] Does OpenSSL support ECC-based S/MIME as defined in
	RFC 5753?
Message-ID: <D37312E7.2CD57%uri@ll.mit.edu>

Does OpenSSL support ECC-based S/MIME as defined in RFC 5753?

I was trying to create an encrypted S/MIME message using OpenSSL-1.0.2h,
and got the following:

$ openssl smime -encrypt -aes128 -inform SMIME -in Cyph_Bot_test.eml
-outform SMIME -out Cyph_Bot_test.smime.eml -subject SMIME_ECC
~/Documents/Certs/me_mouse_yubi_9d_.pem
Error creating PKCS#7 structure
140735083847760:error:21082096:PKCS7
routines:PKCS7_RECIP_INFO_set:encryption not supported for this key
type:pk7_lib.c:542:
140735083847760:error:21073078:PKCS7 routines:PKCS7_encrypt:error adding
recipient:pk7_smime.c:503:
$ openssl version
OpenSSL 1.0.2h  3 May 2016
$


The problem seems to be related to this code in pk7_lib.c:

533:    if (!pkey || !pkey->ameth || !pkey->ameth->pkey_ctrl) {
534:     PKCS7err(PKCS7_F_PKCS7_RECIP_INFO_SET,
535:              PKCS7_R_ENCRYPTION_NOT_SUPPORTED_FOR_THIS_KEY_TYPE);
536:     goto err;
537:    }
538:
539:    ret = pkey->ameth->pkey_ctrl(pkey, ASN1_PKEY_CTRL_PKCS7_ENCRYPT,
0, p7i);
540:    if (ret == -2) {
541:     PKCS7err(PKCS7_F_PKCS7_RECIP_INFO_SET,
542:             PKCS7_R_ENCRYPTION_NOT_SUPPORTED_FOR_THIS_KEY_TYPE);
543:     goto err;
544:    }


Note: EC keys cannot ?encrypt? - they can only ?derive?.
-- 
Regards,
Uri Blumenthal
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4324 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20160531/99dc3dec/attachment.bin>

From openssl-users at dukhovni.org  Tue May 31 14:20:56 2016
From: openssl-users at dukhovni.org (Viktor Dukhovni)
Date: Tue, 31 May 2016 10:20:56 -0400
Subject: [openssl-dev] [openssl.org #3502] nameConstraints bypass bug
In-Reply-To: <D3730F8C.2CD4D%uri@ll.mit.edu>
References: <RT-Ticket-3502@openssl.org> <53F7A00F.6090801@av8n.com>
 <rt-4.0.19-26078-1464634577-865.3502-6-0@openssl.org>
 <574CBDEE.1030308@av8n.com>
 <rt-4.0.19-26106-1464647558-1722.3502-6-0@openssl.org>
 <d05a342bbd484780a2eb7199c0292323@usma1ex-dag1mb1.msg.corp.akamai.com>
 <rt-4.0.19-15649-1464660401-33.3502-6-0@openssl.org>
 <CAFewVt6JxRkKorW=Om8vZqD=dJpomYdROVr4hhZWV+Q_6MJeOg@mail.gmail.com>
 <D3730F8C.2CD4D%uri@ll.mit.edu>
Message-ID: <1F001782-88D0-4ACF-A78D-563820684DD3@dukhovni.org>


> On May 31, 2016, at 9:54 AM, Blumenthal, Uri - 0553 - MITLL <uri at ll.mit.edu> wrote:
> 
>> As one example, mozilla::pkix treats the CN as a dNSName/iPAddress iif there is no subjectAltName extension and iif the CN is a valid dNSNa/iPAddress syntactically.
> 
> That approach seems wrong.

Could you explain your point in more detail than putting "wrong"
in bold text? Though ad-hoc, it seems about the best one can do,
absent additional information.

-- 
	Viktor.


From uri at ll.mit.edu  Tue May 31 14:49:05 2016
From: uri at ll.mit.edu (Blumenthal, Uri - 0553 - MITLL)
Date: Tue, 31 May 2016 14:49:05 +0000
Subject: [openssl-dev] [openssl.org #3502] nameConstraints bypass bug
In-Reply-To: <1F001782-88D0-4ACF-A78D-563820684DD3@dukhovni.org>
References: <RT-Ticket-3502@openssl.org> <53F7A00F.6090801@av8n.com>
 <rt-4.0.19-26078-1464634577-865.3502-6-0@openssl.org>
 <574CBDEE.1030308@av8n.com>
 <rt-4.0.19-26106-1464647558-1722.3502-6-0@openssl.org>
 <d05a342bbd484780a2eb7199c0292323@usma1ex-dag1mb1.msg.corp.akamai.com>
 <rt-4.0.19-15649-1464660401-33.3502-6-0@openssl.org>
 <CAFewVt6JxRkKorW=Om8vZqD=dJpomYdROVr4hhZWV+Q_6MJeOg@mail.gmail.com>
 <D3730F8C.2CD4D%uri@ll.mit.edu>
 <1F001782-88D0-4ACF-A78D-563820684DD3@dukhovni.org>
Message-ID: <D3731C1F.2CD65%uri@ll.mit.edu>

>>On May 31, 2016, at 9:54 AM, Blumenthal, Uri - 0553 - MITLL
>><uri at ll.mit.edu> wrote:
>> 
>>> As one example, mozilla::pkix treats the CN as a dNSName/iPAddress iif
>>>there is no subjectAltName extension and iif the CN is a valid
>>>dNSNa/iPAddress syntactically.
>> 
>> That approach seems wrong.
>
>Could you explain your point in more detail than putting "wrong"
>in bold text? Though ad-hoc, it seems about the best one can do,
>absent additional information.

IMHO allowing CN to be interpreted as a DNS name would open a new attack
surface by making more name collisions (between people and host names)
possible.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4324 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20160531/d804e8b2/attachment.bin>

From openssl-users at dukhovni.org  Tue May 31 15:03:32 2016
From: openssl-users at dukhovni.org (Viktor Dukhovni)
Date: Tue, 31 May 2016 15:03:32 +0000
Subject: [openssl-dev] [openssl.org #3502] nameConstraints bypass bug
In-Reply-To: <D3731C1F.2CD65%uri@ll.mit.edu>
References: <53F7A00F.6090801@av8n.com>
 <rt-4.0.19-26078-1464634577-865.3502-6-0@openssl.org>
 <574CBDEE.1030308@av8n.com>
 <rt-4.0.19-26106-1464647558-1722.3502-6-0@openssl.org>
 <d05a342bbd484780a2eb7199c0292323@usma1ex-dag1mb1.msg.corp.akamai.com>
 <rt-4.0.19-15649-1464660401-33.3502-6-0@openssl.org>
 <CAFewVt6JxRkKorW=Om8vZqD=dJpomYdROVr4hhZWV+Q_6MJeOg@mail.gmail.com>
 <D3730F8C.2CD4D%uri@ll.mit.edu>
 <1F001782-88D0-4ACF-A78D-563820684DD3@dukhovni.org>
 <D3731C1F.2CD65%uri@ll.mit.edu>
Message-ID: <20160531150332.GV3300@mournblade.imrryr.org>

On Tue, May 31, 2016 at 02:49:05PM +0000, Blumenthal, Uri - 0553 - MITLL wrote:

> >Could you explain your point in more detail than putting "wrong"
> >in bold text? Though ad-hoc, it seems about the best one can do,
> >absent additional information.
> 
> IMHO allowing CN to be interpreted as a DNS name would open a new attack
> surface by making more name collisions (between people and host names)
> possible.

That genie is already out of the bottle, see RFC6125 references
upthread.  What's under discussion is extending DNS nameConstraints
to the CN, *given* that it is already often used in name checks.

Nobody is proposing using CN in name checks where it is not already
in use.

-- 
	Viktor.

From rt at openssl.org  Tue May 31 15:34:30 2016
From: rt at openssl.org (John Denker via RT)
Date: Tue, 31 May 2016 15:34:30 +0000
Subject: [openssl-dev] [openssl.org #3502] nameConstraints bypass bug
In-Reply-To: <574DAEFD.10208@av8n.com>
References: <RT-Ticket-3502@openssl.org> <53F7A00F.6090801@av8n.com>
 <rt-4.0.19-26078-1464634577-865.3502-6-0@openssl.org>
 <574CBDEE.1030308@av8n.com>
 <rt-4.0.19-15649-1464660401-33.3502-6-0@openssl.org>
 <CAFewVt6JxRkKorW=Om8vZqD=dJpomYdROVr4hhZWV+Q_6MJeOg@mail.gmail.com>
 <rt-4.0.19-15649-1464663253-193.3502-6-0@openssl.org>
 <20160531035823.GU3300@mournblade.imrryr.org> <574D1448.5030301@av8n.com>
 <574DAEFD.10208@av8n.com>
Message-ID: <rt-4.0.19-15649-1464708870-294.3502-6-0@openssl.org>

Here's a set of obvious questions:
  -- What is the current design?
       Is there a concise-and-complete statement somewhere?
  -- What are the design constraints?
       What is it that openssl MUST do?
       What is it that openssl MUST NOT do?
  -- What information is available?
  -- What critical information is not available,
   and why not?

I mention this because I read things like "deprecated"
and "working as designed" ... referring to the same
features AFAICT.  Also I read "the best one can do,
absent additional information" and it makes me wonder.

In particular, at some point one could consider
changing the design to obtain additional info.  For
starters, one could imagine an interface that says
in effect:
  int isOK = this_site_sent_me_this_webPKI_cert(sitename, cert, ...);

The point is that when this interface is used, we don't
need to worry about CN="Joe Bloggs" s/mime issues.  We
know it's supposed to be a webPKI cert and anything else
MUST be rejected.
  -- For that matter, in this context, nowadays the CN 
   SHOULD be ignored completely in favor of SANs.
  -- Especially when there are nameConstraints or other
   v3 features in the cert, I would suggest the CN MUST
   be ignored in favor of SANs.
  ++ More generally, the interface should demand whatever
   information is needed in order to make an intelligent
   decision.

==================

As a sidelight, not important but amusing, one might wonder:
What is it supposed to mean when a name-constrained CA issues
a CN="Joe Bloggs" certificate?  Why would anyone want to rely
on such a cert?  Before we decide this is working as designed,
it might be nice to take a close look at the design.

In any case, I would suggest that the s/mime tail should not
be allowed to wag the webPKI dog.


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


From rt at openssl.org  Tue May 31 16:21:13 2016
From: rt at openssl.org (ajai.mathew@wipro.com via RT)
Date: Tue, 31 May 2016 16:21:13 +0000
Subject: [openssl-dev] [openssl.org #4551] TCP re-transmissions are seen for
	every transfer with the Openssl version OpenSSL 1.0.2g
In-Reply-To: <HK2PR03MB14420C858F278F041589FD82E9460@HK2PR03MB1442.apcprd03.prod.outlook.com>
References: <RT-Ticket-4551@openssl.org>
 <HK2PR03MB14420C858F278F041589FD82E9460@HK2PR03MB1442.apcprd03.prod.outlook.com>
Message-ID: <rt-4.0.19-16357-1464711673-1553.4551-21-0@openssl.org>

Hi,
We are facing  an issue from the OpenSSL 1.0.2g ,after upgraded from OpenSSL 1.0.0s . [Linux version 2.6.24]
When a https file transfer started with a Windows 7 application, we notice many TCP re-transmission request from Linux and finally the file transfer getting failed.
we are yet to get the OpenSSL logs for this issue. But would like to ask if any similar issues were reported
And the issue resolved by reverting to the old version OpenSSL 1.0.0s .

Thanks
Ajai

[cid:image001.png at 01D1BB78.D4CD29A0]
The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain proprietary, confidential or privileged information. If you are not the intended recipient, you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately and destroy all copies of this message and any attachments. WARNING: Computer viruses can be transmitted via email. The recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email. www.wipro.com

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 89488 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20160531/cdd4b681/attachment-0001.png>

From rt at openssl.org  Tue May 31 16:22:43 2016
From: rt at openssl.org (Rich Salz via RT)
Date: Tue, 31 May 2016 16:22:43 +0000
Subject: [openssl-dev] [openssl.org #4551] TCP re-transmissions are seen for
	every transfer with the Openssl version OpenSSL 1.0.2g
In-Reply-To: <HK2PR03MB14420C858F278F041589FD82E9460@HK2PR03MB1442.apcprd03.prod.outlook.com>
References: <RT-Ticket-4551@openssl.org>
 <HK2PR03MB14420C858F278F041589FD82E9460@HK2PR03MB1442.apcprd03.prod.outlook.com>
Message-ID: <rt-4.0.19-15649-1464711763-1736.4551-6-0@openssl.org>

Asking general support issues != a bug :)
Closing this. Please discuss on the mailing lists.

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


From rt at openssl.org  Tue May 31 16:24:58 2016
From: rt at openssl.org (Rich Salz via RT)
Date: Tue, 31 May 2016 16:24:58 +0000
Subject: [openssl-dev] [openssl.org #3738] [PATCH] tell make running
	subcommands are make based
In-Reply-To: <1425797389-3813-1-git-send-email-vapier@gentoo.org>
References: <RT-Ticket-3738@openssl.org>
 <1425797389-3813-1-git-send-email-vapier@gentoo.org>
Message-ID: <rt-4.0.19-26078-1464711898-1685.3738-6-0@openssl.org>

In 1.1 this is fixed by a rewrite of the build system.
In 1.0.2, we don't mandate/require Posix and I have portability concerns about
this so we won't do it, sorry.

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


From steve at openssl.org  Tue May 31 16:32:24 2016
From: steve at openssl.org (Dr. Stephen Henson)
Date: Tue, 31 May 2016 16:32:24 +0000
Subject: [openssl-dev] Does OpenSSL support ECC-based S/MIME as defined
 in RFC 5753?
In-Reply-To: <D37312E7.2CD57%uri@ll.mit.edu>
References: <D37312E7.2CD57%uri@ll.mit.edu>
Message-ID: <20160531163224.GA16774@openssl.org>

On Tue, May 31, 2016, Blumenthal, Uri - 0553 - MITLL wrote:

> Does OpenSSL support ECC-based S/MIME as defined in RFC 5753?
> 
> I was trying to create an encrypted S/MIME message using OpenSSL-1.0.2h,
> and got the following:
> 
> $ openssl smime -encrypt -aes128 -inform SMIME -in Cyph_Bot_test.eml
> -outform SMIME -out Cyph_Bot_test.smime.eml -subject SMIME_ECC
> ~/Documents/Certs/me_mouse_yubi_9d_.pem
> Error creating PKCS#7 structure
> 140735083847760:error:21082096:PKCS7
> routines:PKCS7_RECIP_INFO_set:encryption not supported for this key
> type:pk7_lib.c:542:
> 140735083847760:error:21073078:PKCS7 routines:PKCS7_encrypt:error adding
> recipient:pk7_smime.c:503:
> $ openssl version
> OpenSSL 1.0.2h  3 May 2016
> $
> 

The smime utility uses PKCS#7 which doesn't support anything other than RSA
for the enveloped data type.

Use the cms utility instead.

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

From rt at openssl.org  Tue May 31 16:37:51 2016
From: rt at openssl.org (Rich Salz via RT)
Date: Tue, 31 May 2016 16:37:51 +0000
Subject: [openssl-dev] [openssl.org #4164] bctest and pod2mantest missing in
	openssl-1.0.2e
In-Reply-To: <EC9672E89207934EA8D83C42CD41BCA16D8CD8A3@N060XBOXP36.kroger.com>
References: <RT-Ticket-4164@openssl.org>
 <EC9672E89207934EA8D83C42CD41BCA16D8CD8A3@N060XBOXP36.kroger.com>
Message-ID: <rt-4.0.19-16357-1464712671-1797.4164-6-0@openssl.org>

I see both test/bctest and util/pod2mantest. Not sure why you didn't ...

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


From rt at openssl.org  Tue May 31 16:49:23 2016
From: rt at openssl.org (Rich Salz via RT)
Date: Tue, 31 May 2016 16:49:23 +0000
Subject: [openssl-dev] [openssl.org #4456] Fedora 1,
	i386: error: field `next_timeout` has incomplete type
In-Reply-To: <CAH8yC8nYG+fSJktLqgkKtgDyFk0Os=UiP52WmcnkYSCyxs-RSw@mail.gmail.com>
References: <RT-Ticket-4456@openssl.org>
 <CAH8yC8nYG+fSJktLqgkKtgDyFk0Os=UiP52WmcnkYSCyxs-RSw@mail.gmail.com>
Message-ID: <rt-4.0.19-26078-1464713363-604.4456-6-0@openssl.org>

Re-Ping Jeff to take a look and see if things are fixed now.

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


From rt at openssl.org  Tue May 31 17:00:39 2016
From: rt at openssl.org (Rich Salz via RT)
Date: Tue, 31 May 2016 17:00:39 +0000
Subject: [openssl-dev] [openssl.org #4473] Compile errors when compiling
	with C++ compiler
In-Reply-To: <CAH8yC8=Nax-gnOSwuxDBmWYn29TqM+YHEnwdsbH35pnC8dZC_g@mail.gmail.com>
References: <RT-Ticket-4473@openssl.org>
 <CAH8yC8=Nax-gnOSwuxDBmWYn29TqM+YHEnwdsbH35pnC8dZC_g@mail.gmail.com>
Message-ID: <rt-4.0.19-16357-1464714039-1299.4473-6-0@openssl.org>

So this got tagged with the 1.1 milestone. What exactly is there for us to do
here?
The header files without 'extern "C"' are all okay, they just have
pre-processor directives in them.

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


From rt at openssl.org  Tue May 31 17:11:24 2016
From: rt at openssl.org (Rich Salz via RT)
Date: Tue, 31 May 2016 17:11:24 +0000
Subject: [openssl-dev] [openssl.org #4480] Ubuntu 14 (x86_64): Compile
	errors and warnings when using "no-asm -ansi"
In-Reply-To: <CAH8yC8n1Ec4pQmXnbg93EBOxCVeu+Xa+04x6o5+SEVL1yNVcJg@mail.gmail.com>
References: <RT-Ticket-4480@openssl.org>
 <CAH8yC8n1Ec4pQmXnbg93EBOxCVeu+Xa+04x6o5+SEVL1yNVcJg@mail.gmail.com>
Message-ID: <rt-4.0.19-16357-1464714683-1624.4480-6-0@openssl.org>

I am confused; what is left to be done here?

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


From rt at openssl.org  Tue May 31 17:14:13 2016
From: rt at openssl.org (Rich Salz via RT)
Date: Tue, 31 May 2016 17:14:13 +0000
Subject: [openssl-dev] [openssl.org #4487] Dirty compile under Windows 7 and
	MSVC 2012 (four to six non-trivial)
In-Reply-To: <CAH8yC8=mtwS__x=x=eMa8+fxfKit+vihbuaz4zP1axq8q_XBLA@mail.gmail.com>
References: <RT-Ticket-4487@openssl.org>
 <CAH8yC8=mtwS__x=x=eMa8+fxfKit+vihbuaz4zP1axq8q_XBLA@mail.gmail.com>
Message-ID: <rt-4.0.19-26078-1464714853-1992.4487-6-0@openssl.org>

We fixed the naming issue for unlink et al. Can this ticket be closed?

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


From rt at openssl.org  Tue May 31 17:15:47 2016
From: rt at openssl.org (Rich Salz via RT)
Date: Tue, 31 May 2016 17:15:47 +0000
Subject: [openssl-dev] [openssl.org #4502] CT todos
In-Reply-To: <E89029DF-8351-4917-AC3B-FAF8C849378D@dukhovni.org>
References: <RT-Ticket-4502@openssl.org>
 <E89029DF-8351-4917-AC3B-FAF8C849378D@dukhovni.org>
Message-ID: <rt-4.0.19-15649-1464714947-103.4502-6-0@openssl.org>

I do not understand what should be done for this ticket. Call me stupid :)

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


From rt at openssl.org  Tue May 31 17:18:42 2016
From: rt at openssl.org (Rich Salz via RT)
Date: Tue, 31 May 2016 17:18:42 +0000
Subject: [openssl-dev] [openssl.org #2378] Bug report: interoperability
	problem
In-Reply-To: <201011201422.24919.eric@bureau-cornavin.com>
References: <RT-Ticket-2378@openssl.org>
 <201011201422.24919.eric@bureau-cornavin.com>
Message-ID: <rt-4.0.19-16357-1464715122-1335.2378-6-0@openssl.org>

No, PRINTABLESTRING and UTF8STRING are not the same.
This old mail thread might be useful:
http://openssl.6102.n7.nabble.com/utf8string-vs-printablestring-mismatch-in-certificate-checking-td25810.html

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


From rt at openssl.org  Tue May 31 17:21:24 2016
From: rt at openssl.org (Rich Salz via RT)
Date: Tue, 31 May 2016 17:21:24 +0000
Subject: [openssl-dev] [openssl.org #4550] hppa assembler problem
In-Reply-To: <20160530200848.GC18832@roeckx.be>
References: <RT-Ticket-4550@openssl.org> <20160530200848.GC18832@roeckx.be>
Message-ID: <rt-4.0.19-16357-1464715284-875.4550-6-0@openssl.org>

Per Kurt, closing this as asm isn't supported on that platform variant.

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


From rt at openssl.org  Tue May 31 17:49:09 2016
From: rt at openssl.org (Richard Levitte via RT)
Date: Tue, 31 May 2016 17:49:09 +0000
Subject: [openssl-dev] [openssl.org #4473] Compile errors when compiling
	with C++ compiler
In-Reply-To: <rt-4.0.19-16357-1464714039-175.4473-6-0@openssl.org>
References: <RT-Ticket-4473@openssl.org>
 <CAH8yC8=Nax-gnOSwuxDBmWYn29TqM+YHEnwdsbH35pnC8dZC_g@mail.gmail.com>
 <rt-4.0.19-16357-1464714039-175.4473-6-0@openssl.org>
Message-ID: <rt-4.0.19-15649-1464716949-1634.4473-6-0@openssl.org>

We have rejected it a number of times. Doing so again. Please do not respond to
this ticket again.

On Tue May 31 17:00:39 2016, rsalz wrote:
> So this got tagged with the 1.1 milestone. What exactly is there for
> us to do
> here?
> The header files without 'extern "C"' are all okay, they just have
> pre-processor directives in them.


--
Richard Levitte
levitte at openssl.org

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


From rt at openssl.org  Tue May 31 17:52:48 2016
From: rt at openssl.org (Richard Levitte via RT)
Date: Tue, 31 May 2016 17:52:48 +0000
Subject: [openssl-dev] [openssl.org #4487] Dirty compile under Windows 7 and
	MSVC 2012 (four to six non-trivial)
In-Reply-To: <rt-4.0.19-26078-1464714852-76.4487-6-0@openssl.org>
References: <RT-Ticket-4487@openssl.org>
 <CAH8yC8=mtwS__x=x=eMa8+fxfKit+vihbuaz4zP1axq8q_XBLA@mail.gmail.com>
 <rt-4.0.19-26078-1464714852-76.4487-6-0@openssl.org>
Message-ID: <rt-4.0.19-15649-1464717168-872.4487-6-0@openssl.org>

On Tue May 31 17:14:12 2016, rsalz wrote:
> We fixed the naming issue for unlink et al. Can this ticket be closed?

I'll do another check, just to make sure.

--
Richard Levitte
levitte at openssl.org

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


From rt at openssl.org  Tue May 31 17:56:37 2016
From: rt at openssl.org (Rich Salz via RT)
Date: Tue, 31 May 2016 17:56:37 +0000
Subject: [openssl-dev] [openssl.org #4539] Documentation - Cipher names
	changed between 1.0.2 & 1.1.0-pre
In-Reply-To: <8DC50C7F6B759747ADDC8B292F116D7C22537B64@MX102CL02.corp.emc.com>
References: <RT-Ticket-4539@openssl.org>
 <8DC50C7F6B759747ADDC8B292F116D7C22537B64@MX102CL02.corp.emc.com>
Message-ID: <rt-4.0.19-16357-1464717397-1515.4539-6-0@openssl.org>

Added a sub-section to ciphers.pod in commit 6d1e770. Thanks.

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


From rt at openssl.org  Tue May 31 17:58:19 2016
From: rt at openssl.org (Viktor Dukhovni via RT)
Date: Tue, 31 May 2016 17:58:19 +0000
Subject: [openssl-dev] [openssl.org #4502] CT todos
In-Reply-To: <0878DBA5-9969-4171-8904-7ED80F4C9258@dukhovni.org>
References: <RT-Ticket-4502@openssl.org>
 <E89029DF-8351-4917-AC3B-FAF8C849378D@dukhovni.org>
 <rt-4.0.19-15649-1464714947-103.4502-6-0@openssl.org>
 <0878DBA5-9969-4171-8904-7ED80F4C9258@dukhovni.org>
Message-ID: <rt-4.0.19-16357-1464717499-1106.4502-6-0@openssl.org>


> On May 31, 2016, at 1:15 PM, Rich Salz via RT <rt at openssl.org> wrote:
> 
> I do not understand what should be done for this ticket. Call me stupid :)

I took care of the requisite changes already. Feel free to close the ticket.

-- 
	Viktor.


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


From rt at openssl.org  Tue May 31 18:00:43 2016
From: rt at openssl.org (Rich Salz via RT)
Date: Tue, 31 May 2016 18:00:43 +0000
Subject: [openssl-dev] [openssl.org #4502] CT todos
In-Reply-To: <E89029DF-8351-4917-AC3B-FAF8C849378D@dukhovni.org>
References: <RT-Ticket-4502@openssl.org>
 <E89029DF-8351-4917-AC3B-FAF8C849378D@dukhovni.org>
Message-ID: <rt-4.0.19-15649-1464717643-1161.4502-6-0@openssl.org>

Viktor did the work. Whether or not I'm stupid is a separate ticket :)

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


From rt at openssl.org  Tue May 31 18:04:39 2016
From: rt at openssl.org (Rich Salz via RT)
Date: Tue, 31 May 2016 18:04:39 +0000
Subject: [openssl-dev] [openssl.org #4457] apps/apps.c and apps/ocsp.c needs
	<sys/select.h> for fd_set
In-Reply-To: <CAH8yC8n=bCZL-n9mOkCZMUSHZtcksvKy4X_bqVC9b2SU5W7XSQ@mail.gmail.com>
References: <RT-Ticket-4457@openssl.org>
 <CAH8yC8n=bCZL-n9mOkCZMUSHZtcksvKy4X_bqVC9b2SU5W7XSQ@mail.gmail.com>
Message-ID: <rt-4.0.19-16357-1464717879-672.4457-6-0@openssl.org>

Is this *literally* a Fedora 1 machine? If so, then I'm inclined to close this
as it went end-of-life more than 12 years ago.

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


From rt at openssl.org  Tue May 31 18:22:29 2016
From: rt at openssl.org (Richard Levitte via RT)
Date: Tue, 31 May 2016 18:22:29 +0000
Subject: [openssl-dev] [openssl.org #4457] apps/apps.c and apps/ocsp.c needs
	<sys/select.h> for fd_set
In-Reply-To: <rt-4.0.19-16357-1464717879-1206.4457-6-0@openssl.org>
References: <RT-Ticket-4457@openssl.org>
 <CAH8yC8n=bCZL-n9mOkCZMUSHZtcksvKy4X_bqVC9b2SU5W7XSQ@mail.gmail.com>
 <rt-4.0.19-16357-1464717879-1206.4457-6-0@openssl.org>
Message-ID: <rt-4.0.19-16357-1464718949-756.4457-6-0@openssl.org>

On Tue May 31 18:04:39 2016, rsalz wrote:
> Is this *literally* a Fedora 1 machine? If so, then I'm inclined to
> close this
> as it went end-of-life more than 12 years ago.

On the other hand, according to The Open Group, sys/select.h should be included
to get select() and all things belonging with it (except timeval).

http://pubs.opengroup.org/onlinepubs/9699919799/functions/select.html

So this is a bigger issue than just Fedora 1, we're just lucky that most
platforms still have select() in unistd.h as well...

--
Richard Levitte
levitte at openssl.org

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


From rt at openssl.org  Tue May 31 18:25:43 2016
From: rt at openssl.org (Rich Salz via RT)
Date: Tue, 31 May 2016 18:25:43 +0000
Subject: [openssl-dev] [openssl.org #4364] [PATCH] ASN1_get_object should
	not accept large universal tags.
In-Reply-To: <CAF8qwaACmi+HWR0BPcQSR780_QTeQmDJHo1rEdp7oXrmPyi-vw@mail.gmail.com>
References: <RT-Ticket-4364@openssl.org>
 <CAF8qwaACmi+HWR0BPcQSR780_QTeQmDJHo1rEdp7oXrmPyi-vw@mail.gmail.com>
Message-ID: <rt-4.0.19-16357-1464719143-324.4364-6-0@openssl.org>

Fixed slightly differently by Steve. Closing.

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


From rt at openssl.org  Tue May 31 18:26:56 2016
From: rt at openssl.org (Salz, Rich via RT)
Date: Tue, 31 May 2016 18:26:56 +0000
Subject: [openssl-dev] [openssl.org #4457] apps/apps.c and apps/ocsp.c
	needs <sys/select.h> for fd_set
In-Reply-To: <3e00210e06de47828ce3d50d747ba838@usma1ex-dag1mb1.msg.corp.akamai.com>
References: <RT-Ticket-4457@openssl.org>
 <CAH8yC8n=bCZL-n9mOkCZMUSHZtcksvKy4X_bqVC9b2SU5W7XSQ@mail.gmail.com>
 <rt-4.0.19-16357-1464717879-1206.4457-6-0@openssl.org>
 <rt-4.0.19-16357-1464718949-756.4457-6-0@openssl.org>
 <3e00210e06de47828ce3d50d747ba838@usma1ex-dag1mb1.msg.corp.akamai.com>
Message-ID: <rt-4.0.19-15649-1464719216-871.4457-6-0@openssl.org>

Since it 'just works' for now, maybe remove the 1.1 milestone?


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


From rt at openssl.org  Tue May 31 18:31:38 2016
From: rt at openssl.org (Rich Salz via RT)
Date: Tue, 31 May 2016 18:31:38 +0000
Subject: [openssl-dev] [openssl.org #4479] OS X 10.8 (x86_64): Compile
	errors when using "no-asm -ansi"
In-Reply-To: <CAH8yC8=accG9AXR5eMY8pmAZDMyqXjdPabcY5s4RBXHuBhkg6Q@mail.gmail.com>
References: <RT-Ticket-4479@openssl.org>
 <CAH8yC8=accG9AXR5eMY8pmAZDMyqXjdPabcY5s4RBXHuBhkg6Q@mail.gmail.com>
Message-ID: <rt-4.0.19-15649-1464719498-589.4479-6-0@openssl.org>

So what is left to do here, or should this ticket be closed?

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


From rt at openssl.org  Tue May 31 18:32:51 2016
From: rt at openssl.org (Richard Levitte via RT)
Date: Tue, 31 May 2016 18:32:51 +0000
Subject: [openssl-dev] [openssl.org #4457] apps/apps.c and apps/ocsp.c needs
	<sys/select.h> for fd_set
In-Reply-To: <rt-4.0.19-15649-1464719216-1936.4457-6-0@openssl.org>
References: <RT-Ticket-4457@openssl.org>
 <CAH8yC8n=bCZL-n9mOkCZMUSHZtcksvKy4X_bqVC9b2SU5W7XSQ@mail.gmail.com>
 <rt-4.0.19-16357-1464717879-1206.4457-6-0@openssl.org>
 <rt-4.0.19-16357-1464718949-756.4457-6-0@openssl.org>
 <3e00210e06de47828ce3d50d747ba838@usma1ex-dag1mb1.msg.corp.akamai.com>
 <rt-4.0.19-15649-1464719216-1936.4457-6-0@openssl.org>
Message-ID: <rt-4.0.19-16357-1464719571-488.4457-6-0@openssl.org>

On Tue May 31 18:26:56 2016, rsalz at akamai.com wrote:
> Since it 'just works' for now, maybe remove the 1.1 milestone?
>
I agree. Making it post-1.1.0

--
Richard Levitte
levitte at openssl.org

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


From kurt at roeckx.be  Tue May 31 19:33:51 2016
From: kurt at roeckx.be (Kurt Roeckx)
Date: Tue, 31 May 2016 21:33:51 +0200
Subject: [openssl-dev] [openssl.org #4551] TCP re-transmissions are seen
 for every transfer with the Openssl version OpenSSL 1.0.2g
In-Reply-To: <rt-4.0.19-16357-1464711673-1553.4551-21-0@openssl.org>
References: <RT-Ticket-4551@openssl.org>
 <HK2PR03MB14420C858F278F041589FD82E9460@HK2PR03MB1442.apcprd03.prod.outlook.com>
 <rt-4.0.19-16357-1464711673-1553.4551-21-0@openssl.org>
Message-ID: <20160531193351.GA4386@roeckx.be>

On Tue, May 31, 2016 at 04:21:13PM +0000, ajai.mathew at wipro.com via RT wrote:
> Hi,
> We are facing  an issue from the OpenSSL 1.0.2g ,after upgraded from OpenSSL 1.0.0s . [Linux version 2.6.24]
> When a https file transfer started with a Windows 7 application, we notice many TCP re-transmission request from Linux and finally the file transfer getting failed.
> we are yet to get the OpenSSL logs for this issue. But would like to ask if any similar issues were reported
> And the issue resolved by reverting to the old version OpenSSL 1.0.0s .

My guess is that there is a firewall that has a problem with TLS
1.2 or the size of the packet being sent.


Kurt


From rt at openssl.org  Tue May 31 20:37:20 2016
From: rt at openssl.org (David-E Young via RT)
Date: Tue, 31 May 2016 20:37:20 +0000
Subject: [openssl-dev] [openssl.org #4552] Bug report: hex string is too
	long, problem in set_hex()?
In-Reply-To: <197FCD85F35D40418691DE629CC3460B0109E077@UCUSDC1PWXMR002.us.db.com>
References: <RT-Ticket-4552@openssl.org>
 <197FCD85F35D40418691DE629CC3460B0109E077@UCUSDC1PWXMR002.us.db.com>
Message-ID: <rt-4.0.19-15649-1464727039-127.4552-21-0@openssl.org>

Classification: Public
OS: SUSE Linux Enterprise Server 11 SP2  (x86_64)
OpenSSL: versions 1.0.1m, 1.1.0-pre5

Using this command sequence:

echo WuNhPwuWAOiG86RfO4A5jITR9WZ+kF1L+iBgGPQJ4dEJk8Sxiqb014bJsEGDbCfk | $ssl/bin/openssl enc -aes128 -d -a -iv 57fd56a7e47b9482096ab4707ca9d383 -K 617364696f69636a61736f3932336b3b0a

we get different behavior between version 1.0.1m and later versions. With version 1.0.1m the above sequence works fine. Using later versions, including 1.1.0-pre5, we get:

hex string is too long
invalid hex key value

The trouble is in set_hex():

static int set_hex(char *in, unsigned char *out, int size)
{
    ...
    if (n > (size * 2)) {
       // hex string is too long
    ...
    }
}

If the size multiplier is changed to, say, 4, then the problem goes away with no apparent ill effects. Reading the code for set_hex() and its caller, it does not appear that the size multiplier is related to a buffer size or some other limitation.

I've read that the "hex string is too long" issue is a bug in OpenSSL that was supposed to be fixed in the 1.0.2 branch, but that appears not to be the case. Please let us know if we've missed something or if this issue is in fact an OpenSSL bug.

Kind Regards,

David



---
This communication may contain confidential and/or privileged information. If you are not the intended recipient (or have received this communication in error) please notify the sender immediately and destroy this communication. Any unauthorized copying, disclosure or distribution of the material in this communication is strictly forbidden.

Deutsche Bank does not render legal or tax advice, and the information contained in this communication should not be regarded as such.

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


From rt at openssl.org  Tue May 31 20:45:08 2016
From: rt at openssl.org (Salz, Rich via RT)
Date: Tue, 31 May 2016 20:45:08 +0000
Subject: [openssl-dev] [openssl.org #4552] Bug report: hex string is too
	long, problem in set_hex()?
In-Reply-To: <4de633d071a9495b9eda0dd71ef007a7@usma1ex-dag1mb1.msg.corp.akamai.com>
References: <RT-Ticket-4552@openssl.org>
 <197FCD85F35D40418691DE629CC3460B0109E077@UCUSDC1PWXMR002.us.db.com>
 <rt-4.0.19-15649-1464727039-127.4552-21-0@openssl.org>
 <4de633d071a9495b9eda0dd71ef007a7@usma1ex-dag1mb1.msg.corp.akamai.com>
Message-ID: <rt-4.0.19-15649-1464727508-488.4552-6-0@openssl.org>

> If the size multiplier is changed to, say, 4, then the problem goes away with
> no apparent ill effects. Reading the code for set_hex() and its caller, it does
> not appear that the size multiplier is related to a buffer size or some other
> limitation.

Yes it is, it's the size of the buffer to hold the converted text->binary string.  Changing the multiplier will overwrite data buffers.

There was a bug where it got the size calculation wrong, I think.  But this is not a bug as reported.


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


From rt at openssl.org  Tue May 31 20:54:15 2016
From: rt at openssl.org (David-E Young via RT)
Date: Tue, 31 May 2016 20:54:15 +0000
Subject: [openssl-dev] [openssl.org #4552] Bug report: hex string is too
	long, problem in set_hex()?
In-Reply-To: <197FCD85F35D40418691DE629CC3460B0109E094@UCUSDC1PWXMR002.us.db.com>
References: <RT-Ticket-4552@openssl.org>
 <197FCD85F35D40418691DE629CC3460B0109E077@UCUSDC1PWXMR002.us.db.com>
 <rt-4.0.19-15649-1464727039-127.4552-21-0@openssl.org>
 <4de633d071a9495b9eda0dd71ef007a7@usma1ex-dag1mb1.msg.corp.akamai.com>
 <rt-4.0.19-15649-1464727508-488.4552-6-0@openssl.org>
 <197FCD85F35D40418691DE629CC3460B0109E094@UCUSDC1PWXMR002.us.db.com>
Message-ID: <rt-4.0.19-26078-1464728054-1737.4552-6-0@openssl.org>

Classification: Public

Hello. Thanks for responding so quickly. Could you perhaps then tell us why the difference in behavior between version 1.0.1m and later versions, and why we would get "hex string is too long"?

Kind Regards,

David

-----Original Message-----
From: Salz, Rich via RT [mailto:rt at openssl.org]
Sent: Tuesday, May 31, 2016 4:45 PM
To: David-E Young
Cc: openssl-dev at openssl.org
Subject: RE: [openssl-dev] [openssl.org #4552] Bug report: hex string is too long, problem in set_hex()?

> If the size multiplier is changed to, say, 4, then the problem goes
> away with no apparent ill effects. Reading the code for set_hex() and
> its caller, it does not appear that the size multiplier is related to
> a buffer size or some other limitation.

Yes it is, it's the size of the buffer to hold the converted text->binary string.  Changing the multiplier will overwrite data buffers.

There was a bug where it got the size calculation wrong, I think.  But this is not a bug as reported.


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



---
This communication may contain confidential and/or privileged information. If you are not the intended recipient (or have received this communication in error) please notify the sender immediately and destroy this communication. Any unauthorized copying, disclosure or distribution of the material in this communication is strictly forbidden.

Deutsche Bank does not render legal or tax advice, and the information contained in this communication should not be regarded as such.

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


From rt at openssl.org  Tue May 31 21:04:12 2016
From: rt at openssl.org (Rich Salz via RT)
Date: Tue, 31 May 2016 21:04:12 +0000
Subject: [openssl-dev] [openssl.org #4552] Bug report: hex string is too
	long, problem in set_hex()?
In-Reply-To: <197FCD85F35D40418691DE629CC3460B0109E077@UCUSDC1PWXMR002.us.db.com>
References: <RT-Ticket-4552@openssl.org>
 <197FCD85F35D40418691DE629CC3460B0109E077@UCUSDC1PWXMR002.us.db.com>
Message-ID: <rt-4.0.19-15649-1464728652-262.4552-6-0@openssl.org>

As I said, I think there was a bug in previous versions that got the 'too long'
check wrong. The command line that you posted is in error. There are two extra
characters. As the message says :)

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


From rt at openssl.org  Tue May 31 21:08:19 2016
From: rt at openssl.org (Richard Levitte via RT)
Date: Tue, 31 May 2016 21:08:19 +0000
Subject: [openssl-dev] [openssl.org #4552] Bug report: hex string is too
	long, problem in set_hex()?
In-Reply-To: <197FCD85F35D40418691DE629CC3460B0109E077@UCUSDC1PWXMR002.us.db.com>
References: <RT-Ticket-4552@openssl.org>
 <197FCD85F35D40418691DE629CC3460B0109E077@UCUSDC1PWXMR002.us.db.com>
Message-ID: <rt-4.0.19-16357-1464728899-1828.4552-6-0@openssl.org>

That hex key string looks off. It seems to include an ending \n (0a), which I
suspect is because at an earlier time, someone forgot to peal off the ending
linefeed. Take away the endine 0a and I'm sure things will be fine.

The 'set_hex' check is exactly the same in the 1.0.1, 1.0.2 and upcoming 1.1.0
series, so I'm pretty sure *that* part is a red herring.

Why 1.0.1 accepts a too long hex string is a good question, but it's too late
in its life cycle to bother.

Cheers,
Richard

On Tue May 31 20:37:19 2016, david-e.young at db.com wrote:
> Classification: Public
> OS: SUSE Linux Enterprise Server 11 SP2 (x86_64)
> OpenSSL: versions 1.0.1m, 1.1.0-pre5
>
> Using this command sequence:
>
> echo WuNhPwuWAOiG86RfO4A5jITR9WZ+kF1L+iBgGPQJ4dEJk8Sxiqb014bJsEGDbCfk
> | $ssl/bin/openssl enc -aes128 -d -a -iv
> 57fd56a7e47b9482096ab4707ca9d383 -K 617364696f69636a61736f3932336b3b0a
>
> we get different behavior between version 1.0.1m and later versions.
> With version 1.0.1m the above sequence works fine. Using later
> versions, including 1.1.0-pre5, we get:
>
> hex string is too long
> invalid hex key value
>
> The trouble is in set_hex():
>
> static int set_hex(char *in, unsigned char *out, int size)
> {
> ...
> if (n > (size * 2)) {
> // hex string is too long
> ...
> }
> }
>
> If the size multiplier is changed to, say, 4, then the problem goes
> away with no apparent ill effects. Reading the code for set_hex() and
> its caller, it does not appear that the size multiplier is related to
> a buffer size or some other limitation.
>
> I've read that the "hex string is too long" issue is a bug in OpenSSL
> that was supposed to be fixed in the 1.0.2 branch, but that appears
> not to be the case. Please let us know if we've missed something or if
> this issue is in fact an OpenSSL bug.
>
> Kind Regards,
>
> David
>
>
>
> ---
> This communication may contain confidential and/or privileged
> information. If you are not the intended recipient (or have received
> this communication in error) please notify the sender immediately and
> destroy this communication. Any unauthorized copying, disclosure or
> distribution of the material in this communication is strictly
> forbidden.
>
> Deutsche Bank does not render legal or tax advice, and the information
> contained in this communication should not be regarded as such.


--
Richard Levitte
levitte at openssl.org

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