Re: 1.1.1f

2020-03-26 Thread Viktor Dukhovni
On Thu, Mar 26, 2020 at 11:33:40PM +, Matt Caswell wrote: > On 26/03/2020 23:15, Viktor Dukhovni wrote: > > On Thu, Mar 26, 2020 at 09:13:32PM +0100, Bernd Edlinger wrote: > > > >> we got into this situation because everything moves so quickly, > >> why does everyone here think we should

Re: 1.1.1f

2020-03-26 Thread Matt Caswell
On 26/03/2020 23:15, Viktor Dukhovni wrote: > On Thu, Mar 26, 2020 at 09:13:32PM +0100, Bernd Edlinger wrote: > >> we got into this situation because everything moves so quickly, >> why does everyone here think we should move even faster now? >> >> What is the reason for this? > > We've

Re: 1.1.1f

2020-03-26 Thread Viktor Dukhovni
On Thu, Mar 26, 2020 at 09:13:32PM +0100, Bernd Edlinger wrote: > we got into this situation because everything moves so quickly, > why does everyone here think we should move even faster now? > > What is the reason for this? We've published a bug-fix release (1.1.1e) that's liable to cause

Re: 1.1.1f

2020-03-26 Thread Bernd Edlinger
On 3/26/20 9:10 PM, Tim Hudson wrote: > We don't guarantee constant time. > #11411 does, I don't see why we hurry so much for 1.1.1f we got into this situation because everything moves so quickly, why does everyone here think we should move even faster now? What is the reason for this?

Re: 1.1.1f

2020-03-26 Thread Tim Hudson
We don't guarantee constant time. Tim. On Fri, 27 Mar 2020, 5:41 am Bernd Edlinger, wrote: > So I disagree, it is a bug when it is not constant time. > > > On 3/26/20 8:26 PM, Tim Hudson wrote: > > +1 for a release - and soon - and without bundling any more changes. The > > circumstances

Re: 1.1.1f

2020-03-26 Thread Bernd Edlinger
So I disagree, it is a bug when it is not constant time. On 3/26/20 8:26 PM, Tim Hudson wrote: > +1 for a release - and soon - and without bundling any more changes. The > circumstances justify getting this fix out. But I also think we need to > keep improvements that aren't bug fixes out of

Re: 1.1.1f

2020-03-26 Thread Tim Hudson
+1 for a release - and soon - and without bundling any more changes. The circumstances justify getting this fix out. But I also think we need to keep improvements that aren't bug fixes out of stable branches. Tim. On Fri, 27 Mar 2020, 3:12 am Matt Caswell, wrote: > On 26/03/2020 15:14, Short,

Re: 1.1.1f

2020-03-26 Thread Matt Caswell
On 26/03/2020 15:14, Short, Todd wrote: > This type of API-braking change should be reserved for something like > 3.0, not a patch release. > > Despite it being a "incorrect", it is expected behavior. > Right - but the question now is not whether we should revert it (it has been reverted) - but

Re: 1.1.1f

2020-03-26 Thread Short, Todd
This type of API-braking change should be reserved for something like 3.0, not a patch release. Despite it being a "incorrect", it is expected behavior. -- -Todd Short // tsh...@akamai.com // “One if by land, two if by sea, three if by the Internet." > On Mar 26, 2020, at 11:03 AM, Dr.

Re: Improving X.509 certificate validation errors

2020-03-26 Thread Martin Ukrop
Hi Ben, Yes, a reply after a few weeks is still very useful, thanks! You are right about the point that every library has an "expired" code, though I start to see other differences. The number of errors itself wildly differ – OpenSSL has over 75 of certificate-related errors, while GnuTLS has

Re: 1.1.1f

2020-03-26 Thread Bernd Edlinger
On 3/26/20 3:14 PM, Matt Caswell wrote: > The EOF issue (https://github.com/openssl/openssl/issues/11378) has > resulted in us reverting the original EOF change in the 1.1.1 branch > (https://github.com/openssl/openssl/pull/11400). > > Given that this seems to have broken quite a bit of stuff, I

RE: 1.1.1f

2020-03-26 Thread Dr. Matthias St. Pierre
> Please also consider reverting the change for the 3.0 alpha release as well, > see Daniel Stenbergs comment > https://github.com/openssl/openssl/issues/11378#issuecomment-603730581 Never mind my last comment. I noticed a lot of discussion has been going on in issue #11378 and I was not quite

RE: 1.1.1f

2020-03-26 Thread Dr. Matthias St. Pierre
I agree, go ahead. Please also consider reverting the change for the 3.0 alpha release as well, see Daniel Stenbergs comment https://github.com/openssl/openssl/issues/11378#issuecomment-603730581 Matthias From: openssl-project On Behalf Of Dmitry Belyavsky Sent: Thursday, March 26, 2020

Re: 1.1.1f

2020-03-26 Thread Dmitry Belyavsky
On Thu, Mar 26, 2020 at 5:14 PM Matt Caswell wrote: > The EOF issue (https://github.com/openssl/openssl/issues/11378) has > resulted in us reverting the original EOF change in the 1.1.1 branch > (https://github.com/openssl/openssl/pull/11400). > > Given that this seems to have broken quite a bit

Re: 1.1.1f

2020-03-26 Thread Tomas Mraz
On Thu, 2020-03-26 at 14:14 +, Matt Caswell wrote: > The EOF issue (https://github.com/openssl/openssl/issues/11378) has > resulted in us reverting the original EOF change in the 1.1.1 branch > (https://github.com/openssl/openssl/pull/11400). > > Given that this seems to have broken quite a

Re: 1.1.1f

2020-03-26 Thread Bernd Edlinger
On 3/26/20 3:14 PM, Matt Caswell wrote: > The EOF issue (https://github.com/openssl/openssl/issues/11378) has > resulted in us reverting the original EOF change in the 1.1.1 branch > (https://github.com/openssl/openssl/pull/11400). > > Given that this seems to have broken quite a bit of stuff,

1.1.1f

2020-03-26 Thread Matt Caswell
The EOF issue (https://github.com/openssl/openssl/issues/11378) has resulted in us reverting the original EOF change in the 1.1.1 branch (https://github.com/openssl/openssl/pull/11400). Given that this seems to have broken quite a bit of stuff, I propose that we do a 1.1.1f soon (possibly next

Re: Improving X.509 certificate validation errors

2020-03-26 Thread Kurt Roeckx
On Wed, Mar 25, 2020 at 10:21:36PM -0700, Benjamin Kaduk wrote: > I tihnk it's an interesting idea. To me, perhaps the most valuable part > would be to accumulate a corpus of certificates/chains that are malformed > or fail to validate due to a wide variety of errors, almost akin to a > fuzzing