Re: 1.1.1f

[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 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 more
> > problems than it fixes.  In such cases a closely-timed "fixup" (oops)
> > release is expected.  One that only reverts the (two) problem
> > EOF-handling commits.
> 
> Actually a partial revert of one of them is sufficient to resolve the
> problem.

Yes, probably so.  I took a sledge-hammer to the problem, and since the
second commit depended on the first, I reverted both.  If you leave
the pre-requisites for the second commit in place, and just remove
the changed error handling, then indeed that may also work.

-- 
Viktor.

Re: 1.1.1f

[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 published a bug-fix release (1.1.1e) that's liable to cause more
> problems than it fixes.  In such cases a closely-timed "fixup" (oops)
> release is expected.  One that only reverts the (two) problem
> EOF-handling commits.

Actually a partial revert of one of them is sufficient to resolve the
problem.

Matt

>  Further bug-fixes can be queued for later
> releases, or deferred to a major release as appropriate.
> 

Re: 1.1.1f

[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 more
problems than it fixes.  In such cases a closely-timed "fixup" (oops)
release is expected.  One that only reverts the (two) problem
EOF-handling commits.  Further bug-fixes can be queued for later
releases, or deferred to a major release as appropriate.

-- 
Viktor.

Re: 1.1.1f

[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?

Bernd.

> 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 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, 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 whether this should trigger a 1.1.1f release soon?

 Matt

> --
> -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. Matthias St. Pierre
>> mailto:matthias.st.pie...@ncp-e.com>>
>> wrote:
>>
>> 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
>> <

>> https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_openssl_openssl_issues_11378-23issuecomment-2D603730581=DwMGaQ=96ZbZZcaMF4w0F4jpN6LZg=QBEcQsqoUDdk1Q26CzlzNPPUkKYWIh1LYsiHAwmtRik=87AtfQDFl1z9cdRP12QeRUizmgnW6ejbufNT40Gip4Q=djWoIIXyggxwOfbwrmYGrSJdR5tWm06IdzY9x9tDxkA=
>
>>
>> Matthias
>>
>>
>> *From**:* openssl-project > > *On Behalf Of *Dmitry
>> Belyavsky
>> *Sent:* Thursday, March 26, 2020 3:48 PM
>> *To:* Matt Caswell mailto:m...@openssl.org>>
>> *Cc:* openssl-project@openssl.org >>
>> *Subject:* Re: 1.1.1f
>>
>>
>> On Thu, Mar 26, 2020 at 5:14 PM Matt Caswell > > wrote:
>>
>> The EOF issue (https://github.com/openssl/openssl/issues/11378
>> <

>> https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_openssl_openssl_issues_11378=DwMGaQ=96ZbZZcaMF4w0F4jpN6LZg=QBEcQsqoUDdk1Q26CzlzNPPUkKYWIh1LYsiHAwmtRik=87AtfQDFl1z9cdRP12QeRUizmgnW6ejbufNT40Gip4Q=MAiLjfGJWaKvnBvqnM4fcyvGVfUyj9CDANO_vh4wfco=
> )
>> has
>> resulted in us reverting the original EOF change in the 1.1.1
>> branch
>> (https://github.com/openssl/openssl/pull/11400
>> <

>> https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_openssl_openssl_pull_11400=DwMGaQ=96ZbZZcaMF4w0F4jpN6LZg=QBEcQsqoUDdk1Q26CzlzNPPUkKYWIh1LYsiHAwmtRik=87AtfQDFl1z9cdRP12QeRUizmgnW6ejbufNT40Gip4Q=3hBU2pt84DQlrY1dCnSn9x1ah1gSzH6NEO_bNRH-6DE=
> ).
>>
>> Given that this seems to have broken quite a bit of stuff, I
>> propose
>> that we do a 1.1.1f soon (possibly next Tuesday - 31st March).
>>
>> Thoughts?
>>
>>
>> I strongly support this idea.
>>
>> --
>> SY, Dmitry Belyavsky
>

>>>
>>
> 

Re: 1.1.1f

[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 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, 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 whether this should trigger a 1.1.1f release soon?
> >>
> >> Matt
> >>
> >>> --
> >>> -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. Matthias St. Pierre
>  mailto:matthias.st.pie...@ncp-e.com>>
>  wrote:
> 
>  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
>  <
> >>
> https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_openssl_openssl_issues_11378-23issuecomment-2D603730581=DwMGaQ=96ZbZZcaMF4w0F4jpN6LZg=QBEcQsqoUDdk1Q26CzlzNPPUkKYWIh1LYsiHAwmtRik=87AtfQDFl1z9cdRP12QeRUizmgnW6ejbufNT40Gip4Q=djWoIIXyggxwOfbwrmYGrSJdR5tWm06IdzY9x9tDxkA=
> >>>
> 
>  Matthias
> 
> 
>  *From**:* openssl-project   > *On Behalf Of *Dmitry
>  Belyavsky
>  *Sent:* Thursday, March 26, 2020 3:48 PM
>  *To:* Matt Caswell mailto:m...@openssl.org>>
>  *Cc:* openssl-project@openssl.org  >
>  *Subject:* Re: 1.1.1f
> 
> 
>  On Thu, Mar 26, 2020 at 5:14 PM Matt Caswell   > wrote:
> 
>  The EOF issue (https://github.com/openssl/openssl/issues/11378
>  <
> >>
> https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_openssl_openssl_issues_11378=DwMGaQ=96ZbZZcaMF4w0F4jpN6LZg=QBEcQsqoUDdk1Q26CzlzNPPUkKYWIh1LYsiHAwmtRik=87AtfQDFl1z9cdRP12QeRUizmgnW6ejbufNT40Gip4Q=MAiLjfGJWaKvnBvqnM4fcyvGVfUyj9CDANO_vh4wfco=
> >>> )
>  has
>  resulted in us reverting the original EOF change in the 1.1.1
> branch
>  (https://github.com/openssl/openssl/pull/11400
>  <
> >>
> https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_openssl_openssl_pull_11400=DwMGaQ=96ZbZZcaMF4w0F4jpN6LZg=QBEcQsqoUDdk1Q26CzlzNPPUkKYWIh1LYsiHAwmtRik=87AtfQDFl1z9cdRP12QeRUizmgnW6ejbufNT40Gip4Q=3hBU2pt84DQlrY1dCnSn9x1ah1gSzH6NEO_bNRH-6DE=
> >>> ).
> 
>  Given that this seems to have broken quite a bit of stuff, I
> propose
>  that we do a 1.1.1f soon (possibly next Tuesday - 31st March).
> 
>  Thoughts?
> 
> 
>  I strongly support this idea.
> 
>  --
>  SY, Dmitry Belyavsky
> >>>
> >>
> >
>

Re: 1.1.1f

[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 stable branches.
> 
> Tim.
> 
> On Fri, 27 Mar 2020, 3:12 am Matt Caswell,  wrote:
> 
>> 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 whether this should trigger a 1.1.1f release soon?
>>
>> Matt
>>
>>> --
>>> -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. Matthias St. Pierre
 mailto:matthias.st.pie...@ncp-e.com>>
 wrote:

 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
 <
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_openssl_openssl_issues_11378-23issuecomment-2D603730581=DwMGaQ=96ZbZZcaMF4w0F4jpN6LZg=QBEcQsqoUDdk1Q26CzlzNPPUkKYWIh1LYsiHAwmtRik=87AtfQDFl1z9cdRP12QeRUizmgnW6ejbufNT40Gip4Q=djWoIIXyggxwOfbwrmYGrSJdR5tWm06IdzY9x9tDxkA=
>>>

 Matthias


 *From**:* openssl-project >>> > *On Behalf Of *Dmitry
 Belyavsky
 *Sent:* Thursday, March 26, 2020 3:48 PM
 *To:* Matt Caswell mailto:m...@openssl.org>>
 *Cc:* openssl-project@openssl.org 
 *Subject:* Re: 1.1.1f


 On Thu, Mar 26, 2020 at 5:14 PM Matt Caswell >>> > wrote:

 The EOF issue (https://github.com/openssl/openssl/issues/11378
 <
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_openssl_openssl_issues_11378=DwMGaQ=96ZbZZcaMF4w0F4jpN6LZg=QBEcQsqoUDdk1Q26CzlzNPPUkKYWIh1LYsiHAwmtRik=87AtfQDFl1z9cdRP12QeRUizmgnW6ejbufNT40Gip4Q=MAiLjfGJWaKvnBvqnM4fcyvGVfUyj9CDANO_vh4wfco=
>>> )
 has
 resulted in us reverting the original EOF change in the 1.1.1 branch
 (https://github.com/openssl/openssl/pull/11400
 <
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_openssl_openssl_pull_11400=DwMGaQ=96ZbZZcaMF4w0F4jpN6LZg=QBEcQsqoUDdk1Q26CzlzNPPUkKYWIh1LYsiHAwmtRik=87AtfQDFl1z9cdRP12QeRUizmgnW6ejbufNT40Gip4Q=3hBU2pt84DQlrY1dCnSn9x1ah1gSzH6NEO_bNRH-6DE=
>>> ).

 Given that this seems to have broken quite a bit of stuff, I propose
 that we do a 1.1.1f soon (possibly next Tuesday - 31st March).

 Thoughts?


 I strongly support this idea.

 --
 SY, Dmitry Belyavsky
>>>
>>
> 

Re: 1.1.1f

[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, 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 whether this should trigger a 1.1.1f release soon?
>
> Matt
>
> > --
> > -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. Matthias St. Pierre
> >> mailto:matthias.st.pie...@ncp-e.com>>
> >> wrote:
> >>
> >> 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
> >> <
> https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_openssl_openssl_issues_11378-23issuecomment-2D603730581=DwMGaQ=96ZbZZcaMF4w0F4jpN6LZg=QBEcQsqoUDdk1Q26CzlzNPPUkKYWIh1LYsiHAwmtRik=87AtfQDFl1z9cdRP12QeRUizmgnW6ejbufNT40Gip4Q=djWoIIXyggxwOfbwrmYGrSJdR5tWm06IdzY9x9tDxkA=
> >
> >>
> >> Matthias
> >>
> >>
> >> *From**:* openssl-project  >> > *On Behalf Of *Dmitry
> >> Belyavsky
> >> *Sent:* Thursday, March 26, 2020 3:48 PM
> >> *To:* Matt Caswell mailto:m...@openssl.org>>
> >> *Cc:* openssl-project@openssl.org 
> >> *Subject:* Re: 1.1.1f
> >>
> >>
> >> On Thu, Mar 26, 2020 at 5:14 PM Matt Caswell  >> > wrote:
> >>
> >> The EOF issue (https://github.com/openssl/openssl/issues/11378
> >> <
> https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_openssl_openssl_issues_11378=DwMGaQ=96ZbZZcaMF4w0F4jpN6LZg=QBEcQsqoUDdk1Q26CzlzNPPUkKYWIh1LYsiHAwmtRik=87AtfQDFl1z9cdRP12QeRUizmgnW6ejbufNT40Gip4Q=MAiLjfGJWaKvnBvqnM4fcyvGVfUyj9CDANO_vh4wfco=
> >)
> >> has
> >> resulted in us reverting the original EOF change in the 1.1.1 branch
> >> (https://github.com/openssl/openssl/pull/11400
> >> <
> https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_openssl_openssl_pull_11400=DwMGaQ=96ZbZZcaMF4w0F4jpN6LZg=QBEcQsqoUDdk1Q26CzlzNPPUkKYWIh1LYsiHAwmtRik=87AtfQDFl1z9cdRP12QeRUizmgnW6ejbufNT40Gip4Q=3hBU2pt84DQlrY1dCnSn9x1ah1gSzH6NEO_bNRH-6DE=
> >).
> >>
> >> Given that this seems to have broken quite a bit of stuff, I propose
> >> that we do a 1.1.1f soon (possibly next Tuesday - 31st March).
> >>
> >> Thoughts?
> >>
> >>
> >> I strongly support this idea.
> >>
> >> --
> >> SY, Dmitry Belyavsky
> >
>

Re: 1.1.1f

[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 whether this should trigger a 1.1.1f release soon?

Matt

> --
> -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. Matthias St. Pierre
>> mailto:matthias.st.pie...@ncp-e.com>>
>> wrote:
>>
>> 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 3:48 PM
>> *To:* Matt Caswell mailto:m...@openssl.org>>
>> *Cc:* openssl-project@openssl.org 
>> *Subject:* Re: 1.1.1f
>>  
>>  
>> 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 of stuff, I propose
>> that we do a 1.1.1f soon (possibly next Tuesday - 31st March).
>>
>> Thoughts?
>>
>>  
>> I strongly support this idea.
>>  
>> -- 
>> SY, Dmitry Belyavsky
> 

Re: 1.1.1f

[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. Matthias St. Pierre 
>  wrote:
> 
> 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 3:48 PM
> To: Matt Caswell 
> Cc: openssl-project@openssl.org
> Subject: Re: 1.1.1f
>  
>  
> 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 of stuff, I propose
> that we do a 1.1.1f soon (possibly next Tuesday - 31st March).
> 
> Thoughts?
>  
> I strongly support this idea.
>  
> -- 
> SY, Dmitry Belyavsky



smime.p7s
Description: S/MIME cryptographic signature

Re: Improving X.509 certificate validation errors

[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 only about 18 and Botan about 40.
Hearing developer opinions helps me do it in a way useful for you. I
understand big, replied-on, open-source projects are sensitive about
changes. Though I believe at least updating the documentation should be
harmless (the details on the error message in OpenSSL docs sometimes just
restate the message). I'll open a separate issue/WiP pull request when we
have specific propositions.

PS: @Kurt, thanks for the pointer to Frankencert, it did not cross my radar
yet.

Martin.

On Thu, 26 Mar 2020 at 10:28, Kurt Roeckx  wrote:

> 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 corpus.  I'd also be curious (though I'm not entirely sure how
> > large a practical impact it would have) to perform a clustering analysis
> > across different X.509 implementations and see if different
> implementations
> > produce different distributions of errors.  (That is, we might expect
> each
> > implementation to have an error for "not valid yet", "expired", "missing
> > required ASN.1 field", etc.; each implementation will have a different
> > error string, of course, but if we group all certificates that produce
> the
> > same error with the same implementation together, we have a bunch of
> > different clusters.  Repeating the clustering across all implementations
> > lets us compare the different distributions, and examine certificates
> that
> > end up in a different cluster in different implementations.)
>
> That's what frankencert did.
>
>
> Kurt
>
>

Re: 1.1.1f

[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 propose
> that we do a 1.1.1f soon (possibly next Tuesday - 31st March).
> 
> Thoughts?
> 

How about adding #11411 constant time AES no-asm support then?
that should be safe, as it is something that is not enabled by default.

> Matt
> 

RE: 1.1.1f

[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 up-to-date.

Matthias

RE: 1.1.1f

[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 3:48 PM
To: Matt Caswell 
Cc: openssl-project@openssl.org
Subject: Re: 1.1.1f


On Thu, Mar 26, 2020 at 5:14 PM Matt Caswell 
mailto:m...@openssl.org>> 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 propose
that we do a 1.1.1f soon (possibly next Tuesday - 31st March).

Thoughts?

I strongly support this idea.

--
SY, Dmitry Belyavsky

Re: 1.1.1f

[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 of stuff, I propose
> that we do a 1.1.1f soon (possibly next Tuesday - 31st March).
>
> Thoughts?
>

I strongly support this idea.

-- 
SY, Dmitry Belyavsky

Re: 1.1.1f

[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 bit of stuff, I propose
> that we do a 1.1.1f soon (possibly next Tuesday - 31st March).
> 
> Thoughts?

I think my opinion is clear from the discussions in GitHub. But for the
record: Yes, I agree with it, unless we know of anything major just
ahead.

-- 
Tomáš Mráz
No matter how far down the wrong road you've gone, turn back.
  Turkish proverb
[You'll know whether the road is wrong if you carefully listen to your
conscience.]

Re: 1.1.1f

[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 propose
> that we do a 1.1.1f soon (possibly next Tuesday - 31st March).
> 
> Thoughts?
> 

slow down?


> Matt
> 

1.1.1f

[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 Tuesday - 31st March).

Thoughts?

Matt

Re: Improving X.509 certificate validation errors

[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 corpus.  I'd also be curious (though I'm not entirely sure how
> large a practical impact it would have) to perform a clustering analysis
> across different X.509 implementations and see if different implementations
> produce different distributions of errors.  (That is, we might expect each
> implementation to have an error for "not valid yet", "expired", "missing
> required ASN.1 field", etc.; each implementation will have a different
> error string, of course, but if we group all certificates that produce the
> same error with the same implementation together, we have a bunch of
> different clusters.  Repeating the clustering across all implementations
> lets us compare the different distributions, and examine certificates that
> end up in a different cluster in different implementations.)

That's what frankencert did.


Kurt