OpenSSL version 1.1.1f published

2020-03-31 Thread OpenSSL
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256


   OpenSSL version 1.1.1f 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.1.1f 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.1.1-notes.html

   OpenSSL 1.1.1f 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.1.1f.tar.gz
  Size: 9792828
  SHA1 checksum: 238e001ea1fbf19ede43e36209c37c1a636bb51f
  SHA256 checksum: 
186c6bfe6ecfba7a5b48c47f8a1673d0f3b0e5ba2e25602dd23b629975da3f35

   The checksums were calculated using the following commands:

openssl sha1 openssl-1.1.1f.tar.gz
openssl sha256 openssl-1.1.1f.tar.gz

   Yours,

   The OpenSSL Project Team.

-BEGIN PGP SIGNATURE-

iQEzBAEBCAAdFiEEhlersmDwVrHlGQg52cTSbQ5gRJEFAl6DNO8ACgkQ2cTSbQ5g
RJFAHAf/c5tRSC8FNTAwXj8pEniovI/XeIHgyJG37mKXt2V5ziXwCaJCTs6Tdvth
b7nGgcqHWmqTdDlYdOzhexWOESfCTEhipmh1E9wHX/fntadHn0LwzfXBIbE6CsW5
ksn2bXXHTLuY3E8GWzmdcDDZ6sjsAYCsfE6rnJqgPKl8+XqZsjlrMBLc1iXa7pvR
CMNmJ5ITo98OlqtFRsmR0G7nXCwm4NLGCv9DojfR5gfyoUWZZXInyZZ3RReZEwoH
fGRObO3/5E80+TxFJda8uDM0dSHUPzXJ7JA+h+uQRG+PGwXe4R8jZ8BJfjfVvmuk
d72zRaRwkGrHvCo93S8xI8W2jBAqHQ==
=TvT8
-END PGP SIGNATURE-


Re: 1.1.1f

2020-03-29 Thread Bernd Edlinger
Aehm, do you remember the PR #9864
were we (not me, I did approve, but I was unable to get a second approval)
failed to approve the PR, so the author just closed his PR
and went fishing instead.

I think we need to revive that PR somehow.

That is IMHO a security relevant issue when you
cannot use the correct prefix with spaces, as they
are in Windows.

Can that one at least considered for inclusion?


Thanks
Bernd.

On 3/26/20 9:13 PM, Bernd Edlinger wrote:
> 
> 
> 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 <mailto: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 >>>>>> <mailto:openssl-project-boun...@openssl.org>> *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 <mailto: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
>>>>>>> <
>>>>>
>>> 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

2020-03-27 Thread Matt Caswell
There seems to be broad support for a 1.1.1f release. Unless I hear an
OMC objection I will formally announce this tomorrow.

Matt

On 27/03/2020 00:10, Viktor Dukhovni wrote:
> 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.
> 


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

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

2020-03-26 Thread Matt Caswell



On 26/03/2020 20:13, Bernd Edlinger wrote:
> 
> 
> 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,

We waited 6 months to release 1.1.1e. This issue wasn't caused by moving
too quickly.

Matt


> 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 <mailto: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 >>>>>> <mailto:openssl-project-boun...@openssl.org>> *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 <mailto: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
>>>>>>> <
>>>>>
>>> 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

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

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?

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 <mailto: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 >>>>> <mailto:openssl-project-boun...@openssl.org>> *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 <mailto: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
>>>>>> <
>>>>
>> 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

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 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 <mailto: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  >>>> <mailto:openssl-project-boun...@openssl.org>> *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 <mailto: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
> >>>> <
> >>
> 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

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 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 <mailto: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 >>> <mailto:openssl-project-boun...@openssl.org>> *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 <mailto: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
>>>> <
>> 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

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, 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 <mailto: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  >> <mailto:openssl-project-boun...@openssl.org>> *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 <mailto: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
> >> <
> 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

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

Matt

> --
> -Todd Short
> // tsh...@akamai.com <mailto: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 > <mailto:openssl-project-boun...@openssl.org>> *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 <mailto: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
>> 
>> <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

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. 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 
> <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 
> 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 
> <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



smime.p7s
Description: S/MIME cryptographic signature


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

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

Matthias



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

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

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

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

slow down?


> Matt
> 


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

Thoughts?

Matt