From matt at openssl.org  Mon Mar  2 11:41:57 2020
From: matt at openssl.org (Matt Caswell)
Date: Mon, 2 Mar 2020 11:41:57 +0000
Subject: Deprecations
In-Reply-To: <6E8285B0-6B87-4EEF-9314-2715A63C15A9@oracle.com>
References: <20200221080639.GA2050170@roeckx.be>
 <417398bc-7558-7a39-28ce-a6e80106b494@openssl.org>
 <20200221221717.GA2169205@roeckx.be>
 <04c2b422-8bf8-9072-1553-c4af498cf9c9@openssl.org>
 <20200221231808.GA2169191@roeckx.be>
 <8d400997-3071-fe48-a3fc-05282c8ffaca@openssl.org>
 <20200221235117.GA2196588@roeckx.be> <87pne77xsz.wl-levitte@openssl.org>
 <75655BAA-8F6C-49FF-808F-814BA70AE856@dukhovni.org>
 <6618F74F-DB2E-44C9-A594-81F05A25356D@oracle.com>
 <6E8285B0-6B87-4EEF-9314-2715A63C15A9@oracle.com>
Message-ID: <e7d96ebe-756d-712e-9d04-40769d9a018b@openssl.org>



On 28/02/2020 23:43, Dr Paul Dale wrote:
> Any suggestions for a consensus on this thread?

I think we can probably agree that:

- Command option deprecations should be handled better
- We should look at whether we can resurrect some of the "old" commands
(possibly by writing them as wrappers for genpkey, pkey and pkeyutl)

I am slightly concerned that the latter option (rewriting as wrappers)
may turn into a big black hole of effort. It *might* be easier to just
rewrite them as-is to use EVP. Whichever approach we take, I don't think
this should be a goal for alpha1.

Matt

> 
> Pauli
> --?
> Dr Paul Dale | Distinguished Architect | Cryptographic Foundations?
> Phone +61 7 3031 7217
> Oracle Australia
> 
> 
> 
> 
>> On 24 Feb 2020, at 5:08 pm, Dr Paul Dale <paul.dale at oracle.com
>> <mailto:paul.dale at oracle.com>> wrote:
>>
>> Most of the conversions to using PKEY were straightforward. ?One
>> didn?t require any changes (dsa but my memory is suspect). ?One seemed
>> quite difficult. ?Some I didn?t check.
>>
>> Modifying the commands so that they continue to work and print (to
>> stderr) an alternative pkey based command might be workable too.
>>
>>
>> Pauli
>> --?
>> Dr Paul Dale | Distinguished Architect | Cryptographic Foundations?
>> Phone +61 7 3031 7217
>> Oracle Australia
>>
>>
>>
>>
>>> On 24 Feb 2020, at 5:53 am, Viktor Dukhovni
>>> <openssl-users at dukhovni.org <mailto:openssl-users at dukhovni.org>> wrote:
>>>
>>>> On Feb 22, 2020, at 4:53 AM, Richard Levitte <levitte at openssl.org
>>>> <mailto:levitte at openssl.org>> wrote:
>>>>
>>>> Something that could be done is to take all those aged commands and
>>>> rewrite them as wrappers for genpkey, pkey and pkeyutl. ?Simply create
>>>> and populate a new argv and call genpkey_main(), pkey_main() or
>>>> pkeyutl_main().
>>>
>>> Agreed, that sounds quite reasonable at first blush, and could be
>>> fantastic
>>> if it can be made to work (no immediate obstacles come to mind).
>>>
>>> -- 
>>> Viktor.
>>>
>>
> 

From paul.dale at oracle.com  Mon Mar  2 12:15:56 2020
From: paul.dale at oracle.com (Dr Paul Dale)
Date: Mon, 2 Mar 2020 22:15:56 +1000
Subject: Deprecations
In-Reply-To: <e7d96ebe-756d-712e-9d04-40769d9a018b@openssl.org>
References: <20200221080639.GA2050170@roeckx.be>
 <417398bc-7558-7a39-28ce-a6e80106b494@openssl.org>
 <20200221221717.GA2169205@roeckx.be>
 <04c2b422-8bf8-9072-1553-c4af498cf9c9@openssl.org>
 <20200221231808.GA2169191@roeckx.be>
 <8d400997-3071-fe48-a3fc-05282c8ffaca@openssl.org>
 <20200221235117.GA2196588@roeckx.be> <87pne77xsz.wl-levitte@openssl.org>
 <75655BAA-8F6C-49FF-808F-814BA70AE856@dukhovni.org>
 <6618F74F-DB2E-44C9-A594-81F05A25356D@oracle.com>
 <6E8285B0-6B87-4EEF-9314-2715A63C15A9@oracle.com>
 <e7d96ebe-756d-712e-9d04-40769d9a018b@openssl.org>
Message-ID: <33501661-6797-430B-8657-1CE3C91E5F2D@oracle.com>

I've started working on moving some of the old commands forward using PKEY calls.  My intention is for them to still print out a deprecated message when run but for them to not actually be removed by the no-deprecated configure option.

Having them print equivalent pkey command looks to be somewhat problematic.  There isn?t a 1:1 conversion and some of the legacy options simply aren?t supported.


I?m hoping to have a preliminary PR up later this week.


Pauli
-- 
Dr Paul Dale | Distinguished Architect | Cryptographic Foundations 
Phone +61 7 3031 7217
Oracle Australia




> On 2 Mar 2020, at 9:41 pm, Matt Caswell <matt at openssl.org> wrote:
> 
> 
> 
> On 28/02/2020 23:43, Dr Paul Dale wrote:
>> Any suggestions for a consensus on this thread?
> 
> I think we can probably agree that:
> 
> - Command option deprecations should be handled better
> - We should look at whether we can resurrect some of the "old" commands
> (possibly by writing them as wrappers for genpkey, pkey and pkeyutl)
> 
> I am slightly concerned that the latter option (rewriting as wrappers)
> may turn into a big black hole of effort. It *might* be easier to just
> rewrite them as-is to use EVP. Whichever approach we take, I don't think
> this should be a goal for alpha1.
> 
> Matt
> 
>> 
>> Pauli
>> -- 
>> Dr Paul Dale | Distinguished Architect | Cryptographic Foundations 
>> Phone +61 7 3031 7217
>> Oracle Australia
>> 
>> 
>> 
>> 
>>> On 24 Feb 2020, at 5:08 pm, Dr Paul Dale <paul.dale at oracle.com
>>> <mailto:paul.dale at oracle.com>> wrote:
>>> 
>>> Most of the conversions to using PKEY were straightforward.  One
>>> didn?t require any changes (dsa but my memory is suspect).  One seemed
>>> quite difficult.  Some I didn?t check.
>>> 
>>> Modifying the commands so that they continue to work and print (to
>>> stderr) an alternative pkey based command might be workable too.
>>> 
>>> 
>>> Pauli
>>> -- 
>>> Dr Paul Dale | Distinguished Architect | Cryptographic Foundations 
>>> Phone +61 7 3031 7217
>>> Oracle Australia
>>> 
>>> 
>>> 
>>> 
>>>> On 24 Feb 2020, at 5:53 am, Viktor Dukhovni
>>>> <openssl-users at dukhovni.org <mailto:openssl-users at dukhovni.org>> wrote:
>>>> 
>>>>> On Feb 22, 2020, at 4:53 AM, Richard Levitte <levitte at openssl.org
>>>>> <mailto:levitte at openssl.org>> wrote:
>>>>> 
>>>>> Something that could be done is to take all those aged commands and
>>>>> rewrite them as wrappers for genpkey, pkey and pkeyutl.  Simply create
>>>>> and populate a new argv and call genpkey_main(), pkey_main() or
>>>>> pkeyutl_main().
>>>> 
>>>> Agreed, that sounds quite reasonable at first blush, and could be
>>>> fantastic
>>>> if it can be made to work (no immediate obstacles come to mind).
>>>> 
>>>> -- 
>>>> Viktor.
>>>> 
>>> 
>> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-project/attachments/20200302/ea099eb1/attachment.html>

From paul.dale at oracle.com  Tue Mar  3 09:21:46 2020
From: paul.dale at oracle.com (Dr Paul Dale)
Date: Tue, 3 Mar 2020 19:21:46 +1000
Subject: Face to face
Message-ID: <5E89729A-9139-4336-97AD-1E58E5C00F1E@oracle.com>

I propose that we don?t have either an OMC or OTC face to face meeting at ICMC.
Travel restrictions and the availability list make it look unlikely.

Instead, I?d suggest a video conference for both.

This will probably require some kind of vote (for both).


Any suggestions as to date and time.


Pauli
-- 
Dr Paul Dale | Distinguished Architect | Cryptographic Foundations 
Phone +61 7 3031 7217
Oracle Australia




-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-project/attachments/20200303/e026e64d/attachment.html>

From mark at openssl.org  Tue Mar  3 15:15:30 2020
From: mark at openssl.org (Mark J Cox)
Date: Tue, 3 Mar 2020 15:15:30 +0000
Subject: My next step in handling stale PRs
Message-ID: <CABU6YOZ8HFajHypPAiRyVmUbyg6AWscN0QVaSvApQvTRikAqrw@mail.gmail.com>

We have over 50 PRs that are in the state where they are held
requiring a CLA, and stale (over 30 days since any comments).  My
intention is to have my script ping all these PRs with a comment like
this:

openssl-machine: This PR has the label "hold: cla required" and is
stale: it has not been updated in X days.   Note that this PR may be
automatically closed in the future if no CLA is provided.  For CLA
help see https://www.openssl.org/policies/cla.html

In another month we can decide it we want to autoclose them (note that
any comment, label change, etc, made to the PR after the above will
reset the timer and take it out of the list of possible ones to close)

I'll run it later in the week to give people a chance to voice any
comments or concerns.

Mark

From Matthias.St.Pierre at ncp-e.com  Tue Mar  3 16:34:20 2020
From: Matthias.St.Pierre at ncp-e.com (Dr. Matthias St. Pierre)
Date: Tue, 3 Mar 2020 16:34:20 +0000
Subject: My next step in handling stale PRs
In-Reply-To: <CABU6YOZ8HFajHypPAiRyVmUbyg6AWscN0QVaSvApQvTRikAqrw@mail.gmail.com>
References: <CABU6YOZ8HFajHypPAiRyVmUbyg6AWscN0QVaSvApQvTRikAqrw@mail.gmail.com>
Message-ID: <c00b000ad9e14f55b8d0674284e7c257@Ex13.ncp.local>

Hi Mark,

your proposal sounds reasonable, and I let me take the opportunity to pay a compliment to your bot,
he is doing a great job :-).

I have just a tiny little nit: since the sender is clearly identified as "openssl-machine", it is not necessary
to add a special prefix to the text of the message to indicate the message was automated. In fact, the
"ready-to-merge" reminder, which started it all, doesn't have a prefix.  But recently you started to
add various prefixes like "Automated Ping:" and now "openssl-machine:". I'd prefer if the messages
were consistently without a prefix, because they only distract from the gist of the message IMHO,
in particular consistency junkies like me.

Matthias



From mark at openssl.org  Tue Mar  3 16:49:04 2020
From: mark at openssl.org (Mark J Cox)
Date: Tue, 3 Mar 2020 16:49:04 +0000
Subject: My next step in handling stale PRs
In-Reply-To: <c00b000ad9e14f55b8d0674284e7c257@Ex13.ncp.local>
References: <CABU6YOZ8HFajHypPAiRyVmUbyg6AWscN0QVaSvApQvTRikAqrw@mail.gmail.com>
 <c00b000ad9e14f55b8d0674284e7c257@Ex13.ncp.local>
Message-ID: <CABU6YOasW7KA1dC7EPaqrT3hdcb7jE7udUEqb7u0=CNr20PVgQ@mail.gmail.com>

> But recently you started to
> add various prefixes like "Automated Ping:" and now "openssl-machine:". I'd prefer if the messages
> were consistently without a prefix, because they only distract from the gist of the message IMHO,
> in particular consistency junkies like me.

openssl-machine: was just my reminder prefix to run this as
openssl-machine and not me, but it's a fair point on the automated
ping and future consistency.  People may even pay more attention if
they don't realise it was a python script hassling them.

Thanks, Mark

From shane.lontis at oracle.com  Wed Mar  4 03:47:20 2020
From: shane.lontis at oracle.com (SHANE LONTIS)
Date: Wed, 4 Mar 2020 13:47:20 +1000
Subject: Should FIPS_mode() and FIPS_mode_set() be updated, deprecated, or
 completely removed..
Message-ID: <0ADB4066-ED31-456F-B2E7-AB9312F38092@oracle.com>

FIPS_mode() and FIPS_mode_set() are functions that were used by the old FOM.

In OpenSSL_111 they were stripped down to do almost nothing
i.e:-

int FIPS_mode(void)      
{      
    /* This version of the library does not support FIPS mode. */      
    return 0;      
}

int FIPS_mode_set(int on)      
{
if (r == 0)      
    return 1;    

CRYPTOerr(0, CRYPTO_R_FIPS_MODE_NOT_SUPPORTED); 
return 0;      
}

The original plan for these API?s is listed in the design document for 3.0
i.e- the set would - set the global property and then do a fetch of a particular algorithm (this is problematic in itself since the algorithm may not exist for a 3rd party fips provider which could just implement a single algorithm).
And FIPS_mode() would just return true if the global property for fips was set.

This got some pushback and after discussion with a few other otc members - it was decided that the functions should be deprecated since it would be confusing to a user because there are multiple library contexts allowed each with their own fips property that can be changed at
any time.

This is done in https://github.com/openssl/openssl/pull/11075 <https://github.com/openssl/openssl/pull/11075> and there is a related discussion in the comments.

This PR has also been rejected the deprecation and discusses
- FIPS_mode_set() function could be completely removed.
- FIPS_mode() - query using the default library context OR completely remove.

I have no issue with both functions being deleted as they no longer really mean the same thing as they did before.
Each library context has its own default properties - so querying FIPS_mode() could only return what the default library context?s fips properties are - it doesnt mean every library context is in fips mode, or even that the fips module is loaded. 
If the functions are removed then it may require a OMC vote since this could be viewed as a breaking change..

Does anyone have any thoughts on this?

Regards
Shane
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-project/attachments/20200304/b9aa0184/attachment.html>

From tmraz at redhat.com  Wed Mar  4 08:15:55 2020
From: tmraz at redhat.com (Tomas Mraz)
Date: Wed, 04 Mar 2020 09:15:55 +0100
Subject: Should FIPS_mode() and FIPS_mode_set() be updated, deprecated,
 or completely removed..
In-Reply-To: <0ADB4066-ED31-456F-B2E7-AB9312F38092@oracle.com>
References: <0ADB4066-ED31-456F-B2E7-AB9312F38092@oracle.com>
Message-ID: <95053150f7fcc41cf08bcf122992b698f012fb39.camel@redhat.com>

On Wed, 2020-03-04 at 13:47 +1000, SHANE LONTIS wrote:
> FIPS_mode() and FIPS_mode_set() are functions that were used by the
> old FOM.
> 
> In OpenSSL_111 they were stripped down to do almost nothing
> i.e:-
> 
> int FIPS_mode(void)      
>  {      
>      /* This version of the library does not support FIPS mode. */   
>   
>      return 0;      
>  }
> 
>  int FIPS_mode_set(int on)      
>  {
>  if (r == 0)      
>     return 1;    
> 
>  CRYPTOerr(0, CRYPTO_R_FIPS_MODE_NOT_SUPPORTED); 
>  return 0;      
> }
> 
> The original plan for these API?s is listed in the design document
> for 3.0
> i.e- the set would - set the global property and then do a fetch of a
> particular algorithm (this is problematic in itself since the
> algorithm may not exist for a 3rd party fips provider which could
> just implement a single algorithm).
> And FIPS_mode() would just return true if the global property for
> fips was set.
> 
> This got some pushback and after discussion with a few other otc
> members - it was decided that the functions should be deprecated
> since it would be confusing to a user because there are multiple
> library contexts allowed each with their own fips property that can
> be changed at
> any time.
> 
> This is done in https://github.com/openssl/openssl/pull/11075 and
> there is a related discussion in the comments.
> 
> This PR has also been rejected the deprecation and discusses
> - FIPS_mode_set() function could be completely removed.
> - FIPS_mode() - query using the default library context OR completely
> remove.
> 
> I have no issue with both functions being deleted as they no longer
> really mean the same thing as they did before.
> Each library context has its own default properties - so querying
> FIPS_mode() could only return what the default library context?s fips
> properties are - it doesnt mean every library context is in fips
> mode, or even that the fips module is loaded. 
> If the functions are removed then it may require a OMC vote since
> this could be viewed as a breaking change..

I believe that making these function return an error unconditionally is
a breaking change as well and for that reason I prefer removing them
completely or actually removing the FIPS_mode_set() and making the
FIPS_mode() to query the fips properties of the default context.

As for the use-cases the FIPS_mode() call has in the applications I
know of this implementation would be completely OK. If the call is
removed these applications would call the
EVP_default_properties_is_fips_enabled on the default context anyway.
The applications do not call FIPS_mode() to query for the FIPS
compliance but they use it to change their behavior i.e. prefer or
select different algorithms to be used.

The current implementation in the PR - unconditionally returning error
- is completely useless. It would make some (not much) sense if we
aimed for ABI compatibility with 3.0 however that is definitely not the
case so the only reasonable thing is to either try to emulate the
behavior as much as possible or remove completely so the users of the
API would know immediately that they have to be changed.

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



From matt at openssl.org  Wed Mar  4 10:18:17 2020
From: matt at openssl.org (Matt Caswell)
Date: Wed, 4 Mar 2020 10:18:17 +0000
Subject: Should FIPS_mode() and FIPS_mode_set() be updated, deprecated, or
 completely removed..
In-Reply-To: <95053150f7fcc41cf08bcf122992b698f012fb39.camel@redhat.com>
References: <0ADB4066-ED31-456F-B2E7-AB9312F38092@oracle.com>
 <95053150f7fcc41cf08bcf122992b698f012fb39.camel@redhat.com>
Message-ID: <48edc2df-8ca8-ab6b-28b9-034dfc3b4ebe@openssl.org>



On 04/03/2020 08:15, Tomas Mraz wrote:
> The current implementation in the PR - unconditionally returning error
> - is completely useless. It would make some (not much) sense if we
> aimed for ABI compatibility with 3.0 however that is definitely not the
> case so the only reasonable thing is to either try to emulate the
> behavior as much as possible or remove completely so the users of the
> API would know immediately that they have to be changed.
> 

I don't have a strong view, but I think I tend to agree that removal is
the better option. 3.0 *is* a major release and we've never guaranteed
that there will be *no* breaking changes at all. We've only aimed for
most applications that work in 1.1.1 not having to change. Since these
functions exist in 1.1.1, but always fail, it seems reasonable to think
that very few 1.1.1 application actually call them. If there are any
that do so, then they probably need to re-examine their code anyway to
confirm what the behaviour should be with 3.0.

If we remove them then we should have some good documentation somewhere
that explains what people should do instead.

I also think this will probably need an OMC vote.

Matt

From tmraz at redhat.com  Wed Mar  4 10:32:34 2020
From: tmraz at redhat.com (Tomas Mraz)
Date: Wed, 04 Mar 2020 11:32:34 +0100
Subject: Should FIPS_mode() and FIPS_mode_set() be updated, deprecated,
 or completely removed..
In-Reply-To: <48edc2df-8ca8-ab6b-28b9-034dfc3b4ebe@openssl.org>
References: <0ADB4066-ED31-456F-B2E7-AB9312F38092@oracle.com>
 <95053150f7fcc41cf08bcf122992b698f012fb39.camel@redhat.com>
 <48edc2df-8ca8-ab6b-28b9-034dfc3b4ebe@openssl.org>
Message-ID: <1a148cd695319e248303ca7d8cc0ae685231ecb0.camel@redhat.com>

On Wed, 2020-03-04 at 10:18 +0000, Matt Caswell wrote:
> 
> On 04/03/2020 08:15, Tomas Mraz wrote:
> > The current implementation in the PR - unconditionally returning
> > error
> > - is completely useless. It would make some (not much) sense if we
> > aimed for ABI compatibility with 3.0 however that is definitely not
> > the
> > case so the only reasonable thing is to either try to emulate the
> > behavior as much as possible or remove completely so the users of
> > the
> > API would know immediately that they have to be changed.
> > 
> 
> I don't have a strong view, but I think I tend to agree that removal
> is
> the better option. 3.0 *is* a major release and we've never
> guaranteed
> that there will be *no* breaking changes at all. We've only aimed for
> most applications that work in 1.1.1 not having to change. Since
> these
> functions exist in 1.1.1, but always fail, it seems reasonable to
> think
> that very few 1.1.1 application actually call them.

But they do not fail always - the FIPS_mode_set just works fine if you
do not use it to actually enable the FIPS mode and FIPS_mode always
returns 0 (without error). And that is fine because there is no FIPS
module in 1.1.1. But of course this behavior would not be fine with
3.0, it would be completely confusing.

>  If there are any
> that do so, then they probably need to re-examine their code anyway
> to
> confirm what the behaviour should be with 3.0.

Exactly.

> If we remove them then we should have some good documentation
> somewhere
> that explains what people should do instead.

+1

> I also think this will probably need an OMC vote.
> 
> Matt
-- 
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.]



From nic.tuv at gmail.com  Wed Mar  4 11:15:51 2020
From: nic.tuv at gmail.com (Nicola Tuveri)
Date: Wed, 4 Mar 2020 12:15:51 +0100
Subject: Face to face
In-Reply-To: <5E89729A-9139-4336-97AD-1E58E5C00F1E@oracle.com>
References: <5E89729A-9139-4336-97AD-1E58E5C00F1E@oracle.com>
Message-ID: <CANm5x_MKUfRu8nuMpmLtgPXBcOdTRT-TOzEhMhraDCkFc3anZA@mail.gmail.com>

I would like to propose as a date for the OTC meeting somewhere close to
the projected release date for 3.0alpha1.

Ideally it would be nice if OMC and OTC could coordinate the dates to be
close enough to ease the discussion of agenda items that might require
coordination between OMC and OTC.

My rationale for proposing a date next to the alpha1 release is:
- there might be open items for the release process that might benefit from
the attention of the whole OTC and be expedited with f2f discussions
- OMC and OTC might have items to discuss in both directions regarding the
final stages of the 3.0 release roadmap and the milestones for alpha2,
alpha3,  beta1

---

Regarding time for the OTC meeting, I would personally prefer during the
week.
Considering that the bulk of OTC members seem to be distributed between
Europe and Australia, would 7:00 (AM) UTC be a suitable time?

Keep in mind that dates between 29.03 and 05.04 happen to be between
daylight saving time changes in Europe and Australia, so using 31.03 as the
tentative date for the meeting 7:00 AM UTC would mean [0]:
- 8 AM in London
- 9 AM in Berlin/Brussels/Prague/Stockholm
- 5 PM in Brisbane

Nicola

[0]: http://j.mp/39oYWhw

On Tue, 3 Mar 2020 at 10:22, Dr Paul Dale <paul.dale at oracle.com> wrote:

> I propose that we don?t have either an OMC or OTC face to face meeting at
> ICMC.
> Travel restrictions and the availability list make it look unlikely.
>
> Instead, I?d suggest a video conference for both.
>
> This will probably require some kind of vote (for both).
>
>
> Any suggestions as to date and time.
>
>
> Pauli
> --
> Dr Paul Dale | Distinguished Architect | Cryptographic Foundations
> Phone +61 7 3031 7217
> Oracle Australia
>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-project/attachments/20200304/5e61dc5f/attachment.html>

From kurt at roeckx.be  Wed Mar  4 19:15:30 2020
From: kurt at roeckx.be (Kurt Roeckx)
Date: Wed, 4 Mar 2020 20:15:30 +0100
Subject: Deprecations
In-Reply-To: <e7d96ebe-756d-712e-9d04-40769d9a018b@openssl.org>
References: <20200221221717.GA2169205@roeckx.be>
 <04c2b422-8bf8-9072-1553-c4af498cf9c9@openssl.org>
 <20200221231808.GA2169191@roeckx.be>
 <8d400997-3071-fe48-a3fc-05282c8ffaca@openssl.org>
 <20200221235117.GA2196588@roeckx.be>
 <87pne77xsz.wl-levitte@openssl.org>
 <75655BAA-8F6C-49FF-808F-814BA70AE856@dukhovni.org>
 <6618F74F-DB2E-44C9-A594-81F05A25356D@oracle.com>
 <6E8285B0-6B87-4EEF-9314-2715A63C15A9@oracle.com>
 <e7d96ebe-756d-712e-9d04-40769d9a018b@openssl.org>
Message-ID: <20200304191530.GA3184467@roeckx.be>

On Mon, Mar 02, 2020 at 11:41:57AM +0000, Matt Caswell wrote:
> 
> 
> On 28/02/2020 23:43, Dr Paul Dale wrote:
> > Any suggestions for a consensus on this thread?
> 
> I think we can probably agree that:
> 
> - Command option deprecations should be handled better
> - We should look at whether we can resurrect some of the "old" commands
> (possibly by writing them as wrappers for genpkey, pkey and pkeyutl)

What about at least pointing to the alternative function in the
documentation?


Kurt


From matt at openssl.org  Wed Mar  4 19:59:42 2020
From: matt at openssl.org (Matt Caswell)
Date: Wed, 4 Mar 2020 19:59:42 +0000
Subject: Deprecations
In-Reply-To: <20200304191530.GA3184467@roeckx.be>
References: <20200221221717.GA2169205@roeckx.be>
 <04c2b422-8bf8-9072-1553-c4af498cf9c9@openssl.org>
 <20200221231808.GA2169191@roeckx.be>
 <8d400997-3071-fe48-a3fc-05282c8ffaca@openssl.org>
 <20200221235117.GA2196588@roeckx.be> <87pne77xsz.wl-levitte@openssl.org>
 <75655BAA-8F6C-49FF-808F-814BA70AE856@dukhovni.org>
 <6618F74F-DB2E-44C9-A594-81F05A25356D@oracle.com>
 <6E8285B0-6B87-4EEF-9314-2715A63C15A9@oracle.com>
 <e7d96ebe-756d-712e-9d04-40769d9a018b@openssl.org>
 <20200304191530.GA3184467@roeckx.be>
Message-ID: <38c3d422-a3c8-5299-b9ae-da3e22415489@openssl.org>



On 04/03/2020 19:15, Kurt Roeckx wrote:
> On Mon, Mar 02, 2020 at 11:41:57AM +0000, Matt Caswell wrote:
>>
>>
>> On 28/02/2020 23:43, Dr Paul Dale wrote:
>>> Any suggestions for a consensus on this thread?
>>
>> I think we can probably agree that:
>>
>> - Command option deprecations should be handled better
>> - We should look at whether we can resurrect some of the "old" commands
>> (possibly by writing them as wrappers for genpkey, pkey and pkeyutl)
> 
> What about at least pointing to the alternative function in the
> documentation?

Yes, we should do that. Pauli is currently investigating the possibility
of rewriting the old commands using EVP:

https://github.com/openssl/openssl/pull/11225

Matt

From paul.dale at oracle.com  Wed Mar  4 22:48:49 2020
From: paul.dale at oracle.com (Dr Paul Dale)
Date: Thu, 5 Mar 2020 08:48:49 +1000
Subject: Deprecations
In-Reply-To: <20200304191530.GA3184467@roeckx.be>
References: <20200221221717.GA2169205@roeckx.be>
 <04c2b422-8bf8-9072-1553-c4af498cf9c9@openssl.org>
 <20200221231808.GA2169191@roeckx.be>
 <8d400997-3071-fe48-a3fc-05282c8ffaca@openssl.org>
 <20200221235117.GA2196588@roeckx.be> <87pne77xsz.wl-levitte@openssl.org>
 <75655BAA-8F6C-49FF-808F-814BA70AE856@dukhovni.org>
 <6618F74F-DB2E-44C9-A594-81F05A25356D@oracle.com>
 <6E8285B0-6B87-4EEF-9314-2715A63C15A9@oracle.com>
 <e7d96ebe-756d-712e-9d04-40769d9a018b@openssl.org>
 <20200304191530.GA3184467@roeckx.be>
Message-ID: <8DA4BE05-EEFD-4136-9F5F-232E5E7CB05B@oracle.com>

Unless I?ve missed something, the documentation should specify the alternatives.  Mostly these are one to one, but in one case it is one to two (and there both are listed).
With the caveat that I might not have got every place or detail correct.

Moreover, the deprecated commands print something to the effect of: "The command dsa is deprecated. Use ?pkey? instead." when executed.


Pauli
-- 
Dr Paul Dale | Distinguished Architect | Cryptographic Foundations 
Phone +61 7 3031 7217
Oracle Australia




> On 5 Mar 2020, at 5:15 am, Kurt Roeckx <kurt at roeckx.be> wrote:
> 
> On Mon, Mar 02, 2020 at 11:41:57AM +0000, Matt Caswell wrote:
>> 
>> 
>> On 28/02/2020 23:43, Dr Paul Dale wrote:
>>> Any suggestions for a consensus on this thread?
>> 
>> I think we can probably agree that:
>> 
>> - Command option deprecations should be handled better
>> - We should look at whether we can resurrect some of the "old" commands
>> (possibly by writing them as wrappers for genpkey, pkey and pkeyutl)
> 
> What about at least pointing to the alternative function in the
> documentation?
> 
> 
> Kurt
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-project/attachments/20200305/398dde83/attachment.html>

From M.Lindner at f5.com  Wed Mar  4 22:55:08 2020
From: M.Lindner at f5.com (Matthew Lindner)
Date: Wed, 4 Mar 2020 22:55:08 +0000
Subject: Deprecations
In-Reply-To: <8DA4BE05-EEFD-4136-9F5F-232E5E7CB05B@oracle.com>
References: <20200221221717.GA2169205@roeckx.be>
 <04c2b422-8bf8-9072-1553-c4af498cf9c9@openssl.org>
 <20200221231808.GA2169191@roeckx.be>
 <8d400997-3071-fe48-a3fc-05282c8ffaca@openssl.org>
 <20200221235117.GA2196588@roeckx.be> <87pne77xsz.wl-levitte@openssl.org>
 <75655BAA-8F6C-49FF-808F-814BA70AE856@dukhovni.org>
 <6618F74F-DB2E-44C9-A594-81F05A25356D@oracle.com>
 <6E8285B0-6B87-4EEF-9314-2715A63C15A9@oracle.com>
 <e7d96ebe-756d-712e-9d04-40769d9a018b@openssl.org>
 <20200304191530.GA3184467@roeckx.be>
 <8DA4BE05-EEFD-4136-9F5F-232E5E7CB05B@oracle.com>
Message-ID: <09F38185-3FFB-446B-AD89-5CF980798231@f5.com>

Shouldn't the deprecation notice that's printed also print the version it was deprecated in?

- Matthew Lindner

On Mar 4, 2020, at 2:48 PM, Dr Paul Dale <paul.dale at oracle.com<mailto:paul.dale at oracle.com>> wrote:


EXTERNAL MAIL: openssl-project-bounces at openssl.org<mailto:openssl-project-bounces at openssl.org>


Unless I?ve missed something, the documentation should specify the alternatives.  Mostly these are one to one, but in one case it is one to two (and there both are listed).
With the caveat that I might not have got every place or detail correct.

Moreover, the deprecated commands print something to the effect of: "The command dsa is deprecated. Use ?pkey? instead." when executed.


Pauli
--
Dr Paul Dale | Distinguished Architect | Cryptographic Foundations
Phone +61 7 3031 7217
Oracle Australia




On 5 Mar 2020, at 5:15 am, Kurt Roeckx <kurt at roeckx.be<mailto:kurt at roeckx.be>> wrote:

On Mon, Mar 02, 2020 at 11:41:57AM +0000, Matt Caswell wrote:


On 28/02/2020 23:43, Dr Paul Dale wrote:
Any suggestions for a consensus on this thread?

I think we can probably agree that:

- Command option deprecations should be handled better
- We should look at whether we can resurrect some of the "old" commands
(possibly by writing them as wrappers for genpkey, pkey and pkeyutl)

What about at least pointing to the alternative function in the
documentation?


Kurt



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-project/attachments/20200304/d207deae/attachment-0001.html>

From paul.dale at oracle.com  Thu Mar  5 00:06:53 2020
From: paul.dale at oracle.com (Dr Paul Dale)
Date: Thu, 5 Mar 2020 10:06:53 +1000
Subject: Deprecations
In-Reply-To: <09F38185-3FFB-446B-AD89-5CF980798231@f5.com>
References: <20200221221717.GA2169205@roeckx.be>
 <04c2b422-8bf8-9072-1553-c4af498cf9c9@openssl.org>
 <20200221231808.GA2169191@roeckx.be>
 <8d400997-3071-fe48-a3fc-05282c8ffaca@openssl.org>
 <20200221235117.GA2196588@roeckx.be> <87pne77xsz.wl-levitte@openssl.org>
 <75655BAA-8F6C-49FF-808F-814BA70AE856@dukhovni.org>
 <6618F74F-DB2E-44C9-A594-81F05A25356D@oracle.com>
 <6E8285B0-6B87-4EEF-9314-2715A63C15A9@oracle.com>
 <e7d96ebe-756d-712e-9d04-40769d9a018b@openssl.org>
 <20200304191530.GA3184467@roeckx.be>
 <8DA4BE05-EEFD-4136-9F5F-232E5E7CB05B@oracle.com>
 <09F38185-3FFB-446B-AD89-5CF980798231@f5.com>
Message-ID: <7616D6DA-3330-45DF-990C-75E64756D41D@oracle.com>

Matthew,

Good idea.  I?ll add it.


Pauli
-- 
Dr Paul Dale | Distinguished Architect | Cryptographic Foundations 
Phone +61 7 3031 7217
Oracle Australia




> On 5 Mar 2020, at 8:55 am, Matthew Lindner <M.Lindner at f5.com> wrote:
> 
> Shouldn't the deprecation notice that's printed also print the version it was deprecated in?
> 
> - Matthew Lindner
> 
>> On Mar 4, 2020, at 2:48 PM, Dr Paul Dale <paul.dale at oracle.com <mailto:paul.dale at oracle.com>> wrote:
>> 
>> EXTERNAL MAIL: openssl-project-bounces at openssl.org <mailto:openssl-project-bounces at openssl.org>
>> 
>> Unless I?ve missed something, the documentation should specify the alternatives.  Mostly these are one to one, but in one case it is one to two (and there both are listed).
>> With the caveat that I might not have got every place or detail correct.
>> 
>> Moreover, the deprecated commands print something to the effect of: "The command dsa is deprecated. Use ?pkey? instead." when executed.
>> 
>> 
>> Pauli
>> -- 
>> Dr Paul Dale | Distinguished Architect | Cryptographic Foundations 
>> Phone +61 7 3031 7217
>> Oracle Australia
>> 
>> 
>> 
>> 
>>> On 5 Mar 2020, at 5:15 am, Kurt Roeckx <kurt at roeckx.be <mailto:kurt at roeckx.be>> wrote:
>>> 
>>> On Mon, Mar 02, 2020 at 11:41:57AM +0000, Matt Caswell wrote:
>>>> 
>>>> 
>>>> On 28/02/2020 23:43, Dr Paul Dale wrote:
>>>>> Any suggestions for a consensus on this thread?
>>>> 
>>>> I think we can probably agree that:
>>>> 
>>>> - Command option deprecations should be handled better
>>>> - We should look at whether we can resurrect some of the "old" commands
>>>> (possibly by writing them as wrappers for genpkey, pkey and pkeyutl)
>>> 
>>> What about at least pointing to the alternative function in the
>>> documentation?
>>> 
>>> 
>>> Kurt
>>> 
>> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-project/attachments/20200305/a776a474/attachment.html>

From rsalz at akamai.com  Thu Mar  5 02:21:22 2020
From: rsalz at akamai.com (Salz, Rich)
Date: Thu, 5 Mar 2020 02:21:22 +0000
Subject: Deprecations
In-Reply-To: <8DA4BE05-EEFD-4136-9F5F-232E5E7CB05B@oracle.com>
References: <20200221221717.GA2169205@roeckx.be>
 <04c2b422-8bf8-9072-1553-c4af498cf9c9@openssl.org>
 <20200221231808.GA2169191@roeckx.be>
 <8d400997-3071-fe48-a3fc-05282c8ffaca@openssl.org>
 <20200221235117.GA2196588@roeckx.be> <87pne77xsz.wl-levitte@openssl.org>
 <75655BAA-8F6C-49FF-808F-814BA70AE856@dukhovni.org>
 <6618F74F-DB2E-44C9-A594-81F05A25356D@oracle.com>
 <6E8285B0-6B87-4EEF-9314-2715A63C15A9@oracle.com>
 <e7d96ebe-756d-712e-9d04-40769d9a018b@openssl.org>
 <20200304191530.GA3184467@roeckx.be>
 <8DA4BE05-EEFD-4136-9F5F-232E5E7CB05B@oracle.com>
Message-ID: <182E584B-0B96-49BC-AC77-E65C425789C3@akamai.com>

>Moreover, the deprecated commands print something to the effect of: "The command dsa is deprecated. Use ?pkey? instead." when executed.

I hope it only does that
                If (isatty(0) && isatty(1) && isatty(2)) {
                                BIO_printf(bio_errerr, ?%s: This command is deprecated, use the \?%s\? command instead.\n?,
                                                prog, ?replacement?);

That is, only if ?interactive and print to stderr
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-project/attachments/20200305/0b82c438/attachment.html>

From mukrop at mail.muni.cz  Thu Mar  5 15:10:10 2020
From: mukrop at mail.muni.cz (Martin Ukrop)
Date: Thu, 5 Mar 2020 16:10:10 +0100
Subject: Improving X.509 certificate validation errors
Message-ID: <CAGSd0m+yj+g2DKPikyM9GtJxoN9DS1TorCBg-6P_n7TZ1ksftw@mail.gmail.com>

Hi,

I?m the lead of a university project investigating (and improving) the
usability of certificate validation errors. Our goal is to simplify the
ecosystem by consolidating the errors and their documentation in one place,
providing replicable example certificates for all validation errors and by
explaining better what the individual errors mean. The project is live at
https://x509errors.org/

Now we are reaching out to library developers and users (you) to ask for
feedback.

Currently, we base the system on OpenSSL errors (as it?s the most common).
We have example certificates for 30+ OpenSSL errors and in-progress mapping
for corresponding errors error for OpenSSL, GnuTLS, Botan and MbedTLS.
In the future, we plan the possibility of web reorganization based on the
other libraries (currently, the web is organized by OpenSSL), adding the
error frequencies based on IP-wide scans and elaborating on the
consequences of individual errors.
Ultimately, we want to propose better (ideally user-tested) errors and
their documentation. (Just recently, we made a survey among 180 developers
regarding their error documentation preference with good reception).

As developers/users of TLS libraries, what do you think of the idea?
* Which part(s) do you find the most/least useful?
* Is there anything you see missing?
* What are your thoughts on unifying the error taxonomy? (a very long-term
goal, if at all possible)

During spring, we would like to start creating pull requests improving the
documentation and error messages in some of the libraries. Would you
welcome such contributions?

For transparency: My PhD is done at Masaryk University (Czech Republic) and
I?m partially supported by Red Hat Czech.

With regards,
Martin.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-project/attachments/20200305/446e7f79/attachment.html>

From levitte at openssl.org  Sat Mar  7 09:01:59 2020
From: levitte at openssl.org (Richard Levitte)
Date: Sat, 07 Mar 2020 10:01:59 +0100
Subject: An OpenSSL cookbook, where and how?
Message-ID: <87zhcs7d2w.wl-levitte@openssl.org>

As part of a documentation effort, more specifically in some
discussions in https://github.com/openssl/openssl/pull/11220 (exact
references below), I've floated the idea that bigger coding examples
should be placed into a cookbook.

My reasoning for this is very simple: example code in reference
manuals should be kept minimal and focused on the functions documented
in that same page.  Anything that start involving too much other
functions becomes a distraction, or will leave you wondering why the
example is in *this* page and not *the other page* that describes
those other functions.  In my mind, this is education 101.

However, it's true that people may want to see more complete examples,
where the interaction between different sets of functions is on
display, and could serve as code to pick and use, more than the quick
minimalistic examples.  A cookbook.

So if we should do this, where do we want that cookbook?  Who keeps it
up to date, and how?  https://wiki.openssl.org/ could be one answer,
but is it the answer we want?

Thoughts welcome!

Cheers,
Richard

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

From levitte at openssl.org  Sat Mar  7 09:03:36 2020
From: levitte at openssl.org (Richard Levitte)
Date: Sat, 07 Mar 2020 10:03:36 +0100
Subject: An OpenSSL cookbook, where and how?
In-Reply-To: <87zhcs7d2w.wl-levitte@openssl.org>
References: <87zhcs7d2w.wl-levitte@openssl.org>
Message-ID: <87y2sc7d07.wl-levitte@openssl.org>

On Sat, 07 Mar 2020 10:01:59 +0100,
Richard Levitte wrote:
> 
> As part of a documentation effort, more specifically in some
> discussions in https://github.com/openssl/openssl/pull/11220 (exact
> references below), I've floated the idea that bigger coding examples
> should be placed into a cookbook.

I forgot the references:

https://github.com/openssl/openssl/pull/11220#discussion_r386751635
https://github.com/openssl/openssl/pull/11220#issuecomment-596060267

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

From paul.dale at oracle.com  Sat Mar  7 11:34:42 2020
From: paul.dale at oracle.com (Dr Paul Dale)
Date: Sat, 7 Mar 2020 21:34:42 +1000
Subject: An OpenSSL cookbook, where and how?
In-Reply-To: <87y2sc7d07.wl-levitte@openssl.org>
References: <87zhcs7d2w.wl-levitte@openssl.org>
 <87y2sc7d07.wl-levitte@openssl.org>
Message-ID: <854BC9DB-388F-44DE-AB3F-87CCD6ADE023@oracle.com>

Might the demos be useful for something like this?
I know they aren?t in great state and could do with better documentation but they seem to fulfil most of the suggested goals.


Pauli
-- 
Dr Paul Dale | Distinguished Architect | Cryptographic Foundations 
Phone +61 7 3031 7217
Oracle Australia




> On 7 Mar 2020, at 7:03 pm, Richard Levitte <levitte at openssl.org> wrote:
> 
> On Sat, 07 Mar 2020 10:01:59 +0100,
> Richard Levitte wrote:
>> 
>> As part of a documentation effort, more specifically in some
>> discussions in https://urldefense.com/v3/__https://github.com/openssl/openssl/pull/11220__;!!GqivPVa7Brio!IKN_xNCo3Vpfv_o5dvd-lE8BpdsZ0Pbcvjkm1_ee4kyvMZYTfI5w5BmcJuDJ7pw$  (exact
>> references below), I've floated the idea that bigger coding examples
>> should be placed into a cookbook.
> 
> I forgot the references:
> 
> https://urldefense.com/v3/__https://github.com/openssl/openssl/pull/11220*discussion_r386751635__;Iw!!GqivPVa7Brio!IKN_xNCo3Vpfv_o5dvd-lE8BpdsZ0Pbcvjkm1_ee4kyvMZYTfI5w5Bmc3tLgiYQ$ 
> https://urldefense.com/v3/__https://github.com/openssl/openssl/pull/11220*issuecomment-596060267__;Iw!!GqivPVa7Brio!IKN_xNCo3Vpfv_o5dvd-lE8BpdsZ0Pbcvjkm1_ee4kyvMZYTfI5w5BmcAjPjGdw$ 
> 
> -- 
> Richard Levitte         levitte at openssl.org
> OpenSSL Project         https://urldefense.com/v3/__http://www.openssl.org/*levitte/__;fg!!GqivPVa7Brio!IKN_xNCo3Vpfv_o5dvd-lE8BpdsZ0Pbcvjkm1_ee4kyvMZYTfI5w5BmcbK3Tc-Y$ 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-project/attachments/20200307/c2066ac4/attachment.html>

From matt at openssl.org  Mon Mar  9 09:34:36 2020
From: matt at openssl.org (Matt Caswell)
Date: Mon, 9 Mar 2020 09:34:36 +0000
Subject: An OpenSSL cookbook, where and how?
In-Reply-To: <87zhcs7d2w.wl-levitte@openssl.org>
References: <87zhcs7d2w.wl-levitte@openssl.org>
Message-ID: <c6e8541a-335c-9288-4e8c-b38d320b924f@openssl.org>



On 07/03/2020 09:01, Richard Levitte wrote:
> As part of a documentation effort, more specifically in some
> discussions in https://github.com/openssl/openssl/pull/11220 (exact
> references below), I've floated the idea that bigger coding examples
> should be placed into a cookbook.
> 
> My reasoning for this is very simple: example code in reference
> manuals should be kept minimal and focused on the functions documented
> in that same page.  Anything that start involving too much other
> functions becomes a distraction, or will leave you wondering why the
> example is in *this* page and not *the other page* that describes
> those other functions.  In my mind, this is education 101.
> 
> However, it's true that people may want to see more complete examples,
> where the interaction between different sets of functions is on
> display, and could serve as code to pick and use, more than the quick
> minimalistic examples.  A cookbook.
> 
> So if we should do this, where do we want that cookbook?  Who keeps it
> up to date, and how?  https://wiki.openssl.org/ could be one answer,
> but is it the answer we want?

I agree we do need to provide this broader "how to" type documentation.
It's a major failing of our current documentation that we don't provide it.

Both the wiki and ossl-book were previous attempts where we've tried to
collect this kind of information in one place.

IMO, for now, the wiki is the best place to put this kind of thing. In
the long term I still dream of getting ossl-book off the ground.


Matt

From matt at openssl.org  Tue Mar 10 16:19:04 2020
From: matt at openssl.org (Matt Caswell)
Date: Tue, 10 Mar 2020 16:19:04 +0000
Subject: Monthly Status Report (February)
Message-ID: <6708903b-bdcd-408c-0c09-5b279f7bdba8@openssl.org>

As well as normal reviews, responding to user queries, wiki user
requests, OMC business, handling security reports, etc., key activities
this month:

- Fixed no-ec builds
- Fixed no-multiblock
- Completed work on moving X25519/X448 to the default provider
- Fixed no-tls1_3
- Fixed no-sm2
- Completed work making libssl provider aware
- Fixed issue with running GOST engine in a no-deprecated build
- Fixed issue where we were attempting to compile AESNI code even if we
weren't AESNI capable
- Completed work to make RSA_ASYM_CIPHER implementation available inside
the FIPS provider
- Fixed no-engine builds
- Attended the RSA Conference 2020
- Prepared for and gave a talk at RSA Conference on OpenSSL and FIPS
- Fixed no-des
- Fixed a mem leak in libssl
- Implemented serializers for X25519/X448
- Introduced the "provider" property
- Contributed to and published the QUIC blog
- Added all the *.d.tmp file to .gitignore


Matt

From matt at openssl.org  Wed Mar 11 15:51:56 2020
From: matt at openssl.org (Matt Caswell)
Date: Wed, 11 Mar 2020 15:51:56 +0000
Subject: Forthcoming OpenSSL release
Message-ID: <4ef7e5e3-c7eb-7b3c-5773-2c244e13baf7@openssl.org>

The OpenSSL project team would like to announce the forthcoming release
of OpenSSL version 1.1.1e.

This release will be made available on Tuesday 17th March 2020 between
1300-1700 UTC. This will contain one LOW severity fix for CVE-2019-1551
previously announced here:
https://www.openssl.org/news/secadv/20191206.txt

Please see the following page for further details of severity levels:
https://www.openssl.org/policies/secpolicy.html

Yours

The OpenSSL Project Team

From matt at openssl.org  Mon Mar 16 08:00:53 2020
From: matt at openssl.org (Matt Caswell)
Date: Mon, 16 Mar 2020 08:00:53 +0000
Subject: Tools repo ownership
In-Reply-To: <3a688ce5-7d3c-f1b0-48cb-7a3385eefe92@openssl.org>
References: <3a688ce5-7d3c-f1b0-48cb-7a3385eefe92@openssl.org>
Message-ID: <a26e58ff-47e1-0f99-c4ed-4f0a41554f2b@openssl.org>

Sorry - I forgot about this vote. It passed:

+1: 6
 0: 0
-1: 0
No vote: 1

Matt

On 19/02/2020 15:06, Matt Caswell wrote:
> Following the discussion in PR 58 [1] about the ownership of the tools
> repo, I've started an OMC vote to see the tools repo split into "tools"
> and "omc-tools", with some tools moving to omc-tools. OMC would have
> commit/approval rights for omc-tools, and the OTC would have
> commit/approval rights for tools.
> 
> I'll report back here once the vote is complete.
> 
> Matt
> 
> [1] https://github.com/openssl/tools/pull/58
> 

From openssl at openssl.org  Tue Mar 17 15:59:54 2020
From: openssl at openssl.org (OpenSSL)
Date: Tue, 17 Mar 2020 15:59:54 +0000
Subject: OpenSSL version 1.1.1e published
Message-ID: <20200317155954.GA16110@openssl.org>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256


   OpenSSL version 1.1.1e 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.1e 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.1e 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.1e.tar.gz
      Size: 9792634
      SHA1 checksum: e7105567d3e7e6353a0110f1adc81f69dbc8f732
      SHA256 checksum: 694f61ac11cb51c9bf73f54e771ff6022b0327a43bbdfa1b2f19de1662a6dcbe

   The checksums were calculated using the following commands:

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

   Yours,

   The OpenSSL Project Team.

-----BEGIN PGP SIGNATURE-----

iQEzBAEBCAAdFiEEhlersmDwVrHlGQg52cTSbQ5gRJEFAl5w3zsACgkQ2cTSbQ5g
RJFdTQf+OeJkXlBCQvdJTv7ky6y7MGesCiMjcQsuFSLlWCHC6k2rNcgrZUH50vOB
E6SH/VPvmreM+TNy95hP2uzGtFkpliIoZHu6NXJSo7QW9svBxzdqo8x7nYN3jhJ1
pEDjfk2vFz2Z/2uzoZdZVe4P8C4O4bFz79UmFUsXNffYcO0mDSih1jrjupASzSJH
0HB68p4lrdoJbiL6KIfGDLS5D+jn6KNU6gHT/6fhCalLQJ1StajpArrXXKrC2apP
YAMTLYH5qxFReobKguOk6RwZnNI2Mdl75qWJ+Wu4PQORPryPeMJ00z82jx6Wv5zF
vWQ4F8zoaiPfUSmyzOJgJQuRwrnNfg==
=1uA3
-----END PGP SIGNATURE-----

From matt at openssl.org  Tue Mar 17 16:16:40 2020
From: matt at openssl.org (Matt Caswell)
Date: Tue, 17 Mar 2020 16:16:40 +0000
Subject: Release done
Message-ID: <d7e127e6-831d-905e-9bec-4028650cd16f@openssl.org>

The release is complete and the repo is unfrozen. Thanks to Paul Yang
for doing the release reviewer role.

Loads of problems this time. Looks like the release scripts need some
adjustment. But through a combination of hacking and swearing at my
computer it went through in the end.

Problems were due to:
- ongoing bug in dorelease.pl which doesn't move the old releases out
the way properly
- Rename of CHANGES/NEWS to CHANGES.md/NEWS.md
- Bug in the script to update the source directory (doesn't seem to like
us only having one active release)
- Some problem (on our side) in the scripts related to purging the CDN
cache. As a consequence I had to purge things "manually" as I found
them, so there may be some pages that are un-purged (in particular I'm
thinking the man pages).

Matt

From Matthias.St.Pierre at ncp-e.com  Tue Mar 17 18:53:12 2020
From: Matthias.St.Pierre at ncp-e.com (Dr. Matthias St. Pierre)
Date: Tue, 17 Mar 2020 18:53:12 +0000
Subject: Release done
In-Reply-To: <d7e127e6-831d-905e-9bec-4028650cd16f@openssl.org>
References: <d7e127e6-831d-905e-9bec-4028650cd16f@openssl.org>
Message-ID: <cce8ad3fc0ec42b1b051db57ef3adc52@Ex13.ncp.local>

> Problems were due to:
> ...
> - Rename of CHANGES/NEWS to CHANGES.md/NEWS.md

Strange....  what exactly was your problem?

I anticipated this problem on the weekend and checked the release scripts.
After some investigation, I came to the conclusion that it wouldn't be a problem
for the OpenSSL_1_1_1-stable branch yet, because the markdown revamping
happened only on master. What did I miss?

Matthias


P.S.: As a byproduct of my investigations I created https://github.com/openssl/tools/pull/64


From matt at openssl.org  Tue Mar 17 19:29:20 2020
From: matt at openssl.org (Matt Caswell)
Date: Tue, 17 Mar 2020 19:29:20 +0000
Subject: Release done
In-Reply-To: <cce8ad3fc0ec42b1b051db57ef3adc52@Ex13.ncp.local>
References: <d7e127e6-831d-905e-9bec-4028650cd16f@openssl.org>
 <cce8ad3fc0ec42b1b051db57ef3adc52@Ex13.ncp.local>
Message-ID: <eb8ee470-a411-bd0d-4490-de71093725bc@openssl.org>



On 17/03/2020 18:53, Dr. Matthias St. Pierre wrote:
>> Problems were due to:
>> ...
>> - Rename of CHANGES/NEWS to CHANGES.md/NEWS.md
> 
> Strange....  what exactly was your problem?

The website is supposed to update itself automatically when we push
stuff, so things like release notes etc get automatically generated.
>From tools/release/README.md:

    Verify that the release notes, which are built from the CHANGES file
    in the release, have been updated. This is done automatically by the
    commit-hook, but if you see a problem, try the following steps:

        cd /var/www/openssl
        sudo -u openssl -H make relupd
        sudo -u openssl ./bin/purge-one-hour

This didn't happen unfortunately. When I ran "make relupd" manually I got:

make: *** No rule to make target
'/var/cache/openssl/checkouts/openssl/CHANGES', needed by
'news/changelog.txt'.  Stop.

That particular make target is related to the *master* CHANGES file
(there are similar targets I think for other branches).

Matt

From Matthias.St.Pierre at ncp-e.com  Tue Mar 17 20:51:45 2020
From: Matthias.St.Pierre at ncp-e.com (Dr. Matthias St. Pierre)
Date: Tue, 17 Mar 2020 20:51:45 +0000
Subject: Release done
In-Reply-To: <eb8ee470-a411-bd0d-4490-de71093725bc@openssl.org>
References: <d7e127e6-831d-905e-9bec-4028650cd16f@openssl.org>
 <cce8ad3fc0ec42b1b051db57ef3adc52@Ex13.ncp.local>
 <eb8ee470-a411-bd0d-4490-de71093725bc@openssl.org>
Message-ID: <c29fad77b57b4f0096c0daf5b48855c7@Ex13.ncp.local>

Unfortunately, the server side hooks are not published anywhere. So I was not able to figure out
that there might be a problem. I should have given you a heads-up nevertheless, sorry for the omission.

Matthias


> -----Original Message-----
> From: Matt Caswell <matt at openssl.org>
> Sent: Tuesday, March 17, 2020 8:29 PM
> To: Dr. Matthias St. Pierre <Matthias.St.Pierre at ncp-e.com>; openssl-project at openssl.org
> Subject: Re: Release done
> 
> 
> 
> On 17/03/2020 18:53, Dr. Matthias St. Pierre wrote:
> >> Problems were due to:
> >> ...
> >> - Rename of CHANGES/NEWS to CHANGES.md/NEWS.md
> >
> > Strange....  what exactly was your problem?
> 
> The website is supposed to update itself automatically when we push
> stuff, so things like release notes etc get automatically generated.
> From tools/release/README.md:
> 
>     Verify that the release notes, which are built from the CHANGES file
>     in the release, have been updated. This is done automatically by the
>     commit-hook, but if you see a problem, try the following steps:
> 
>         cd /var/www/openssl
>         sudo -u openssl -H make relupd
>         sudo -u openssl ./bin/purge-one-hour
> 
> This didn't happen unfortunately. When I ran "make relupd" manually I got:
> 
> make: *** No rule to make target
> '/var/cache/openssl/checkouts/openssl/CHANGES', needed by
> 'news/changelog.txt'.  Stop.
> 
> That particular make target is related to the *master* CHANGES file
> (there are similar targets I think for other branches).
> 
> Matt

From levitte at openssl.org  Tue Mar 17 21:24:01 2020
From: levitte at openssl.org (Richard Levitte)
Date: Tue, 17 Mar 2020 22:24:01 +0100
Subject: Release done
In-Reply-To: <cce8ad3fc0ec42b1b051db57ef3adc52@Ex13.ncp.local>
References: <d7e127e6-831d-905e-9bec-4028650cd16f@openssl.org>
 <cce8ad3fc0ec42b1b051db57ef3adc52@Ex13.ncp.local>
Message-ID: <6AEC9F46-12F0-4701-A9A4-B15DCA95F701@openssl.org>

The problem was running "make relupd" in the web worktree. It assumes CHANGES and NEWS in all branches.
We could have discovered this earlier... ?

"Dr. Matthias St. Pierre" <Matthias.St.Pierre at ncp-e.com> skrev: (17 mars 2020 19:53:12 CET)
>> Problems were due to:
>> ...
>> - Rename of CHANGES/NEWS to CHANGES.md/NEWS.md
>
>Strange....  what exactly was your problem?
>
>I anticipated this problem on the weekend and checked the release
>scripts.
>After some investigation, I came to the conclusion that it wouldn't be
>a problem
>for the OpenSSL_1_1_1-stable branch yet, because the markdown revamping
>happened only on master. What did I miss?
>
>Matthias
>
>
>P.S.: As a byproduct of my investigations I created
>https://github.com/openssl/tools/pull/64

-- 
Skickat fr?n min Android-enhet med K-9 Mail. Urs?kta min f?ordighet.

From beldmit at gmail.com  Fri Mar 20 12:17:48 2020
From: beldmit at gmail.com (Dmitry Belyavsky)
Date: Fri, 20 Mar 2020 15:17:48 +0300
Subject: Deprecating misleading GOST names
Message-ID: <CADqLbzJ4Ds51y5hQW6fzXZ1emJaBxE25iW38cu+0gsiwxrffHQ@mail.gmail.com>

Hello,

I came across wrong naming for some GOST-related stuff in object.txt. As
all this stuff was introduced by me, it's a separate problem.

First, I've erroneously translated the name of the Russian "????????"
algorithm as "grasshopper" instead of transliterating it as 'kuznyechik".
The transliteration has appeared as an official after the changes were
accepted into openssl.

Second, some other algorithm and parameter names were introduced with their
official names instead of reasonable short names. When they are used in the
command line applications, it's very inconvenient.

I'd like to fix these issues in the upcoming 3.0 release, so any ideas
about how to deal with it are welcome. Some of this stuff can be fixed on
the engine level, but it's better to avoid misleading naming.

-- 
SY, Dmitry Belyavsky
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-project/attachments/20200320/8e5ec355/attachment.html>

From hkario at redhat.com  Fri Mar 20 14:59:56 2020
From: hkario at redhat.com (Hubert Kario)
Date: Fri, 20 Mar 2020 15:59:56 +0100
Subject: Deprecating misleading GOST names
In-Reply-To: <CADqLbzJ4Ds51y5hQW6fzXZ1emJaBxE25iW38cu+0gsiwxrffHQ@mail.gmail.com>
References: <CADqLbzJ4Ds51y5hQW6fzXZ1emJaBxE25iW38cu+0gsiwxrffHQ@mail.gmail.com>
Message-ID: <189ff552-c366-433d-b0b5-784e45e97ec4@redhat.com>

On Friday, 20 March 2020 13:17:48 CET, Dmitry Belyavsky wrote:
> Hello,
>
> I came across wrong naming for some GOST-related stuff in object.txt. As
> all this stuff was introduced by me, it's a separate problem.
>
> First, I've erroneously translated the name of the Russian "????????"
> algorithm as "grasshopper" instead of transliterating it as 'kuznyechik".
> The transliteration has appeared as an official after the changes were
> accepted into openssl.
>
> Second, some other algorithm and parameter names were introduced with their
> official names instead of reasonable short names. When they are used in the
> command line applications, it's very inconvenient.
>
> I'd like to fix these issues in the upcoming 3.0 release, so any ideas
> about how to deal with it are welcome. Some of this stuff can be fixed on
> the engine level, but it's better to avoid misleading naming.

how about introducing the new names as aliases and keeping the old ones
active?

(maybe with exception of "kuznyechik", but still support both at the same 
time)
-- 
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purky?ova 115, 612 00  Brno, Czech Republic


From matt at openssl.org  Wed Mar 25 16:38:20 2020
From: matt at openssl.org (Matt Caswell)
Date: Wed, 25 Mar 2020 16:38:20 +0000
Subject: Alpha1 progress
Message-ID: <1e4c3962-f430-30d1-6fbd-8f3c1a5d0b48@openssl.org>

Yesterday a number of us had a teleconference to update our task
tracking for the 3.0 release. The current spreadsheet gives us the
following dates for the various alpha/beta releases:

Alpha1: 2020-04-15
Alpha2: 2020-05-04
Alpha3: 2020-06-10
Beta1:  2020-06-12

Comparing this to the official timeline here:
https://www.openssl.org/policies/releasestrat.html

Which says:

Alpha1: 2020-03-31
Alpha2: 2020-04-21
Alpha3: 2020-05-21
Beta1: 2020-06-02

Until quite recently we were tracking fairly closely to the target
dates, but the last week or so has seen us drift out a bit. As can be
seen from the above we're about 2 weeks out at the moment. This is
primarily due to the key generation work being more complicated and
significant than we had anticipated.

So, right now, it looks to me like we won't be releasing alpha1 next
week as originally planned.

Matt


From kaduk at mit.edu  Thu Mar 26 05:21:36 2020
From: kaduk at mit.edu (Benjamin Kaduk)
Date: Wed, 25 Mar 2020 22:21:36 -0700
Subject: Improving X.509 certificate validation errors
In-Reply-To: <CAGSd0m+yj+g2DKPikyM9GtJxoN9DS1TorCBg-6P_n7TZ1ksftw@mail.gmail.com>
References: <CAGSd0m+yj+g2DKPikyM9GtJxoN9DS1TorCBg-6P_n7TZ1ksftw@mail.gmail.com>
Message-ID: <20200326052136.GF50174@kduck.mit.edu>

Hi Martin,

Hopefully this response is still useful a few weeks later.

On Thu, Mar 05, 2020 at 04:10:10PM +0100, Martin Ukrop wrote:
> Hi,
> 
> I?m the lead of a university project investigating (and improving) the
> usability of certificate validation errors. Our goal is to simplify the
> ecosystem by consolidating the errors and their documentation in one place,
> providing replicable example certificates for all validation errors and by
> explaining better what the individual errors mean. The project is live at
> https://x509errors.org/
> 
> Now we are reaching out to library developers and users (you) to ask for
> feedback.
> 
> Currently, we base the system on OpenSSL errors (as it?s the most common).
> We have example certificates for 30+ OpenSSL errors and in-progress mapping
> for corresponding errors error for OpenSSL, GnuTLS, Botan and MbedTLS.
> In the future, we plan the possibility of web reorganization based on the
> other libraries (currently, the web is organized by OpenSSL), adding the
> error frequencies based on IP-wide scans and elaborating on the
> consequences of individual errors.
> Ultimately, we want to propose better (ideally user-tested) errors and
> their documentation. (Just recently, we made a survey among 180 developers
> regarding their error documentation preference with good reception).
> 
> As developers/users of TLS libraries, what do you think of the idea?
> * Which part(s) do you find the most/least useful?
> * Is there anything you see missing?
> * What are your thoughts on unifying the error taxonomy? (a very long-term
> goal, if at all possible)

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.)
I also like the idea of getting a sense for which types of errors are "most
common", though it will probably require some care to construct the
sample population for the experiment so that the results have interprative
value.  Those results might (depending on what they are) be used as input
to "best practice" guides for (e.g.) making a local PKI.

> During spring, we would like to start creating pull requests improving the
> documentation and error messages in some of the libraries. Would you
> welcome such contributions?

It's probably best to make sure everyone agrees what is meant by
"improving" before doing much writing work; a github issue would be a fine
place to discuss that topic.  I expect that our current error messages are
suboptimal, though we will have to keep in mind during any attempt to
change them that in some cases there will be more value in keeping things
stable than in making them better messages in isolation -- as an
open-source project, it's hard for us to know with confidence which of our
behaviors people are relying on.

-Ben

From kurt at roeckx.be  Thu Mar 26 09:19:53 2020
From: kurt at roeckx.be (Kurt Roeckx)
Date: Thu, 26 Mar 2020 10:19:53 +0100
Subject: Improving X.509 certificate validation errors
In-Reply-To: <20200326052136.GF50174@kduck.mit.edu>
References: <CAGSd0m+yj+g2DKPikyM9GtJxoN9DS1TorCBg-6P_n7TZ1ksftw@mail.gmail.com>
 <20200326052136.GF50174@kduck.mit.edu>
Message-ID: <20200326091953.GA799221@roeckx.be>

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


From matt at openssl.org  Thu Mar 26 14:14:21 2020
From: matt at openssl.org (Matt Caswell)
Date: Thu, 26 Mar 2020 14:14:21 +0000
Subject: 1.1.1f
Message-ID: <c032d68e-9b87-dd0a-fe7f-f64e399cffaf@openssl.org>

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

From bernd.edlinger at hotmail.de  Thu Mar 26 14:16:58 2020
From: bernd.edlinger at hotmail.de (Bernd Edlinger)
Date: Thu, 26 Mar 2020 15:16:58 +0100
Subject: 1.1.1f
In-Reply-To: <c032d68e-9b87-dd0a-fe7f-f64e399cffaf@openssl.org>
References: <c032d68e-9b87-dd0a-fe7f-f64e399cffaf@openssl.org>
Message-ID: <AM6PR03MB5170ADFA1621B4C500E1E77FE4CF0@AM6PR03MB5170.eurprd03.prod.outlook.com>



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
> 

From tmraz at redhat.com  Thu Mar 26 14:31:02 2020
From: tmraz at redhat.com (Tomas Mraz)
Date: Thu, 26 Mar 2020 15:31:02 +0100
Subject: 1.1.1f
In-Reply-To: <c032d68e-9b87-dd0a-fe7f-f64e399cffaf@openssl.org>
References: <c032d68e-9b87-dd0a-fe7f-f64e399cffaf@openssl.org>
Message-ID: <86ee011cb38769026e2007421cb8be004065b7b8.camel@redhat.com>

On Thu, 2020-03-26 at 14:14 +0000, 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.]



From beldmit at gmail.com  Thu Mar 26 14:48:00 2020
From: beldmit at gmail.com (Dmitry Belyavsky)
Date: Thu, 26 Mar 2020 17:48:00 +0300
Subject: 1.1.1f
In-Reply-To: <c032d68e-9b87-dd0a-fe7f-f64e399cffaf@openssl.org>
References: <c032d68e-9b87-dd0a-fe7f-f64e399cffaf@openssl.org>
Message-ID: <CADqLbz+T8JH5Aa3m=9SuowbJpEYOB7af5COthHEzne1KNWkzmA@mail.gmail.com>

On Thu, Mar 26, 2020 at 5:14 PM Matt Caswell <matt at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-project/attachments/20200326/47f3887f/attachment.html>

From Matthias.St.Pierre at ncp-e.com  Thu Mar 26 15:03:41 2020
From: Matthias.St.Pierre at ncp-e.com (Dr. Matthias St. Pierre)
Date: Thu, 26 Mar 2020 15:03:41 +0000
Subject: 1.1.1f
In-Reply-To: <CADqLbz+T8JH5Aa3m=9SuowbJpEYOB7af5COthHEzne1KNWkzmA@mail.gmail.com>
References: <c032d68e-9b87-dd0a-fe7f-f64e399cffaf@openssl.org>
 <CADqLbz+T8JH5Aa3m=9SuowbJpEYOB7af5COthHEzne1KNWkzmA@mail.gmail.com>
Message-ID: <2d7a351466ec4f58b49fabc4a9498f52@Ex13.ncp.local>

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 <openssl-project-bounces at openssl.org> On Behalf Of Dmitry Belyavsky
Sent: Thursday, March 26, 2020 3:48 PM
To: Matt Caswell <matt at openssl.org>
Cc: openssl-project at openssl.org
Subject: Re: 1.1.1f


On Thu, Mar 26, 2020 at 5:14 PM Matt Caswell <matt at openssl.org<mailto:matt at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-project/attachments/20200326/e20e02c6/attachment-0001.html>

From Matthias.St.Pierre at ncp-e.com  Thu Mar 26 15:13:30 2020
From: Matthias.St.Pierre at ncp-e.com (Dr. Matthias St. Pierre)
Date: Thu, 26 Mar 2020 15:13:30 +0000
Subject: 1.1.1f
In-Reply-To: <2d7a351466ec4f58b49fabc4a9498f52@Ex13.ncp.local>
References: <c032d68e-9b87-dd0a-fe7f-f64e399cffaf@openssl.org>
 <CADqLbz+T8JH5Aa3m=9SuowbJpEYOB7af5COthHEzne1KNWkzmA@mail.gmail.com>
 <2d7a351466ec4f58b49fabc4a9498f52@Ex13.ncp.local>
Message-ID: <47a33f7f310b4eaa9a76e8d687c7be3e@Ex13.ncp.local>

> 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-project/attachments/20200326/dfcd5520/attachment-0001.html>

From bernd.edlinger at hotmail.de  Thu Mar 26 16:24:20 2020
From: bernd.edlinger at hotmail.de (Bernd Edlinger)
Date: Thu, 26 Mar 2020 17:24:20 +0100
Subject: 1.1.1f
In-Reply-To: <c032d68e-9b87-dd0a-fe7f-f64e399cffaf@openssl.org>
References: <c032d68e-9b87-dd0a-fe7f-f64e399cffaf@openssl.org>
Message-ID: <AM6PR03MB5170725D5118A7AE4B002BA8E4CF0@AM6PR03MB5170.eurprd03.prod.outlook.com>

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
> 

From mukrop at mail.muni.cz  Thu Mar 26 10:37:33 2020
From: mukrop at mail.muni.cz (Martin Ukrop)
Date: Thu, 26 Mar 2020 11:37:33 +0100
Subject: Improving X.509 certificate validation errors
In-Reply-To: <20200326091953.GA799221@roeckx.be>
References: <CAGSd0m+yj+g2DKPikyM9GtJxoN9DS1TorCBg-6P_n7TZ1ksftw@mail.gmail.com>
 <20200326052136.GF50174@kduck.mit.edu> <20200326091953.GA799221@roeckx.be>
Message-ID: <CAGSd0mKHA81wBw-VABnDgmKL-h_tqF9jFMyD3nd_HbhWT-dOpQ@mail.gmail.com>

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 <kurt at roeckx.be> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-project/attachments/20200326/d32a1ef6/attachment-0001.html>

From tshort at akamai.com  Thu Mar 26 15:14:12 2020
From: tshort at akamai.com (Short, Todd)
Date: Thu, 26 Mar 2020 15:14:12 +0000
Subject: 1.1.1f
In-Reply-To: <2d7a351466ec4f58b49fabc4a9498f52@Ex13.ncp.local>
References: <c032d68e-9b87-dd0a-fe7f-f64e399cffaf@openssl.org>
 <CADqLbz+T8JH5Aa3m=9SuowbJpEYOB7af5COthHEzne1KNWkzmA@mail.gmail.com>
 <2d7a351466ec4f58b49fabc4a9498f52@Ex13.ncp.local>
Message-ID: <C99C6C8E-6E10-4B34-9F1E-F4B91F26E432@akamai.com>

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
// tshort at 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 <Matthias.St.Pierre at 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&d=DwMGaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=QBEcQsqoUDdk1Q26CzlzNPPUkKYWIh1LYsiHAwmtRik&m=87AtfQDFl1z9cdRP12QeRUizmgnW6ejbufNT40Gip4Q&s=djWoIIXyggxwOfbwrmYGrSJdR5tWm06IdzY9x9tDxkA&e=>
>  
> Matthias
>  
>  
> From: openssl-project <openssl-project-bounces at openssl.org> On Behalf Of Dmitry Belyavsky
> Sent: Thursday, March 26, 2020 3:48 PM
> To: Matt Caswell <matt at openssl.org>
> Cc: openssl-project at openssl.org
> Subject: Re: 1.1.1f
>  
>  
> On Thu, Mar 26, 2020 at 5:14 PM Matt Caswell <matt at openssl.org <mailto:matt at 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&d=DwMGaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=QBEcQsqoUDdk1Q26CzlzNPPUkKYWIh1LYsiHAwmtRik&m=87AtfQDFl1z9cdRP12QeRUizmgnW6ejbufNT40Gip4Q&s=MAiLjfGJWaKvnBvqnM4fcyvGVfUyj9CDANO_vh4wfco&e=>) 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&d=DwMGaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=QBEcQsqoUDdk1Q26CzlzNPPUkKYWIh1LYsiHAwmtRik&m=87AtfQDFl1z9cdRP12QeRUizmgnW6ejbufNT40Gip4Q&s=3hBU2pt84DQlrY1dCnSn9x1ah1gSzH6NEO_bNRH-6DE&e=>).
> 
> 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-project/attachments/20200326/7e1adc53/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2991 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-project/attachments/20200326/7e1adc53/attachment-0001.bin>

From matt at openssl.org  Thu Mar 26 17:12:56 2020
From: matt at openssl.org (Matt Caswell)
Date: Thu, 26 Mar 2020 17:12:56 +0000
Subject: 1.1.1f
In-Reply-To: <C99C6C8E-6E10-4B34-9F1E-F4B91F26E432@akamai.com>
References: <c032d68e-9b87-dd0a-fe7f-f64e399cffaf@openssl.org>
 <CADqLbz+T8JH5Aa3m=9SuowbJpEYOB7af5COthHEzne1KNWkzmA@mail.gmail.com>
 <2d7a351466ec4f58b49fabc4a9498f52@Ex13.ncp.local>
 <C99C6C8E-6E10-4B34-9F1E-F4B91F26E432@akamai.com>
Message-ID: <0a52cd16-7e10-e48e-b6eb-4f2436e49186@openssl.org>

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
> // tshort at akamai.com <mailto:tshort at 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
>> <Matthias.St.Pierre at ncp-e.com <mailto:Matthias.St.Pierre at 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&d=DwMGaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=QBEcQsqoUDdk1Q26CzlzNPPUkKYWIh1LYsiHAwmtRik&m=87AtfQDFl1z9cdRP12QeRUizmgnW6ejbufNT40Gip4Q&s=djWoIIXyggxwOfbwrmYGrSJdR5tWm06IdzY9x9tDxkA&e=>
>> ?
>> Matthias
>> ?
>> ?
>> *From**:*?openssl-project <openssl-project-bounces at openssl.org
>> <mailto:openssl-project-bounces at openssl.org>>?*On Behalf Of?*Dmitry
>> Belyavsky
>> *Sent:*?Thursday, March 26, 2020 3:48 PM
>> *To:*?Matt Caswell <matt at openssl.org <mailto:matt at openssl.org>>
>> *Cc:*?openssl-project at openssl.org <mailto:openssl-project at openssl.org>
>> *Subject:*?Re: 1.1.1f
>> ?
>> ?
>> On Thu, Mar 26, 2020 at 5:14 PM Matt Caswell <matt at openssl.org
>> <mailto:matt at 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&d=DwMGaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=QBEcQsqoUDdk1Q26CzlzNPPUkKYWIh1LYsiHAwmtRik&m=87AtfQDFl1z9cdRP12QeRUizmgnW6ejbufNT40Gip4Q&s=MAiLjfGJWaKvnBvqnM4fcyvGVfUyj9CDANO_vh4wfco&e=>)
>>     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&d=DwMGaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=QBEcQsqoUDdk1Q26CzlzNPPUkKYWIh1LYsiHAwmtRik&m=87AtfQDFl1z9cdRP12QeRUizmgnW6ejbufNT40Gip4Q&s=3hBU2pt84DQlrY1dCnSn9x1ah1gSzH6NEO_bNRH-6DE&e=>).
>>
>>     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
> 

From tjh at cryptsoft.com  Thu Mar 26 19:26:55 2020
From: tjh at cryptsoft.com (Tim Hudson)
Date: Fri, 27 Mar 2020 05:26:55 +1000
Subject: 1.1.1f
In-Reply-To: <0a52cd16-7e10-e48e-b6eb-4f2436e49186@openssl.org>
References: <c032d68e-9b87-dd0a-fe7f-f64e399cffaf@openssl.org>
 <CADqLbz+T8JH5Aa3m=9SuowbJpEYOB7af5COthHEzne1KNWkzmA@mail.gmail.com>
 <2d7a351466ec4f58b49fabc4a9498f52@Ex13.ncp.local>
 <C99C6C8E-6E10-4B34-9F1E-F4B91F26E432@akamai.com>
 <0a52cd16-7e10-e48e-b6eb-4f2436e49186@openssl.org>
Message-ID: <CAHEJ-S7hHVCqNY=8fgGVBTGfGmOxQwYiY_LQuQpaAq2UKeLc=w@mail.gmail.com>

+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, <matt at openssl.org> 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
> > // tshort at akamai.com <mailto:tshort at 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
> >> <Matthias.St.Pierre at ncp-e.com <mailto:Matthias.St.Pierre at 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&d=DwMGaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=QBEcQsqoUDdk1Q26CzlzNPPUkKYWIh1LYsiHAwmtRik&m=87AtfQDFl1z9cdRP12QeRUizmgnW6ejbufNT40Gip4Q&s=djWoIIXyggxwOfbwrmYGrSJdR5tWm06IdzY9x9tDxkA&e=
> >
> >>
> >> Matthias
> >>
> >>
> >> *From**:* openssl-project <openssl-project-bounces at openssl.org
> >> <mailto:openssl-project-bounces at openssl.org>> *On Behalf Of *Dmitry
> >> Belyavsky
> >> *Sent:* Thursday, March 26, 2020 3:48 PM
> >> *To:* Matt Caswell <matt at openssl.org <mailto:matt at openssl.org>>
> >> *Cc:* openssl-project at openssl.org <mailto:openssl-project at openssl.org>
> >> *Subject:* Re: 1.1.1f
> >>
> >>
> >> On Thu, Mar 26, 2020 at 5:14 PM Matt Caswell <matt at openssl.org
> >> <mailto:matt at 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&d=DwMGaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=QBEcQsqoUDdk1Q26CzlzNPPUkKYWIh1LYsiHAwmtRik&m=87AtfQDFl1z9cdRP12QeRUizmgnW6ejbufNT40Gip4Q&s=MAiLjfGJWaKvnBvqnM4fcyvGVfUyj9CDANO_vh4wfco&e=
> >)
> >>     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&d=DwMGaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=QBEcQsqoUDdk1Q26CzlzNPPUkKYWIh1LYsiHAwmtRik&m=87AtfQDFl1z9cdRP12QeRUizmgnW6ejbufNT40Gip4Q&s=3hBU2pt84DQlrY1dCnSn9x1ah1gSzH6NEO_bNRH-6DE&e=
> >).
> >>
> >>     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
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-project/attachments/20200327/9fa1286e/attachment.html>

From bernd.edlinger at hotmail.de  Thu Mar 26 19:41:08 2020
From: bernd.edlinger at hotmail.de (Bernd Edlinger)
Date: Thu, 26 Mar 2020 20:41:08 +0100
Subject: 1.1.1f
In-Reply-To: <CAHEJ-S7hHVCqNY=8fgGVBTGfGmOxQwYiY_LQuQpaAq2UKeLc=w@mail.gmail.com>
References: <c032d68e-9b87-dd0a-fe7f-f64e399cffaf@openssl.org>
 <CADqLbz+T8JH5Aa3m=9SuowbJpEYOB7af5COthHEzne1KNWkzmA@mail.gmail.com>
 <2d7a351466ec4f58b49fabc4a9498f52@Ex13.ncp.local>
 <C99C6C8E-6E10-4B34-9F1E-F4B91F26E432@akamai.com>
 <0a52cd16-7e10-e48e-b6eb-4f2436e49186@openssl.org>
 <CAHEJ-S7hHVCqNY=8fgGVBTGfGmOxQwYiY_LQuQpaAq2UKeLc=w@mail.gmail.com>
Message-ID: <AM6PR03MB51706C18875934E64993EE0DE4CF0@AM6PR03MB5170.eurprd03.prod.outlook.com>

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, <matt at openssl.org> 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
>>> // tshort at akamai.com <mailto:tshort at 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
>>>> <Matthias.St.Pierre at ncp-e.com <mailto:Matthias.St.Pierre at 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&d=DwMGaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=QBEcQsqoUDdk1Q26CzlzNPPUkKYWIh1LYsiHAwmtRik&m=87AtfQDFl1z9cdRP12QeRUizmgnW6ejbufNT40Gip4Q&s=djWoIIXyggxwOfbwrmYGrSJdR5tWm06IdzY9x9tDxkA&e=
>>>
>>>>
>>>> Matthias
>>>>
>>>>
>>>> *From**:* openssl-project <openssl-project-bounces at openssl.org
>>>> <mailto:openssl-project-bounces at openssl.org>> *On Behalf Of *Dmitry
>>>> Belyavsky
>>>> *Sent:* Thursday, March 26, 2020 3:48 PM
>>>> *To:* Matt Caswell <matt at openssl.org <mailto:matt at openssl.org>>
>>>> *Cc:* openssl-project at openssl.org <mailto:openssl-project at openssl.org>
>>>> *Subject:* Re: 1.1.1f
>>>>
>>>>
>>>> On Thu, Mar 26, 2020 at 5:14 PM Matt Caswell <matt at openssl.org
>>>> <mailto:matt at 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&d=DwMGaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=QBEcQsqoUDdk1Q26CzlzNPPUkKYWIh1LYsiHAwmtRik&m=87AtfQDFl1z9cdRP12QeRUizmgnW6ejbufNT40Gip4Q&s=MAiLjfGJWaKvnBvqnM4fcyvGVfUyj9CDANO_vh4wfco&e=
>>> )
>>>>     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&d=DwMGaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=QBEcQsqoUDdk1Q26CzlzNPPUkKYWIh1LYsiHAwmtRik&m=87AtfQDFl1z9cdRP12QeRUizmgnW6ejbufNT40Gip4Q&s=3hBU2pt84DQlrY1dCnSn9x1ah1gSzH6NEO_bNRH-6DE&e=
>>> ).
>>>>
>>>>     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
>>>
>>
> 

From tjh at cryptsoft.com  Thu Mar 26 20:10:23 2020
From: tjh at cryptsoft.com (Tim Hudson)
Date: Fri, 27 Mar 2020 06:10:23 +1000
Subject: 1.1.1f
In-Reply-To: <AM6PR03MB51706C18875934E64993EE0DE4CF0@AM6PR03MB5170.eurprd03.prod.outlook.com>
References: <c032d68e-9b87-dd0a-fe7f-f64e399cffaf@openssl.org>
 <CADqLbz+T8JH5Aa3m=9SuowbJpEYOB7af5COthHEzne1KNWkzmA@mail.gmail.com>
 <2d7a351466ec4f58b49fabc4a9498f52@Ex13.ncp.local>
 <C99C6C8E-6E10-4B34-9F1E-F4B91F26E432@akamai.com>
 <0a52cd16-7e10-e48e-b6eb-4f2436e49186@openssl.org>
 <CAHEJ-S7hHVCqNY=8fgGVBTGfGmOxQwYiY_LQuQpaAq2UKeLc=w@mail.gmail.com>
 <AM6PR03MB51706C18875934E64993EE0DE4CF0@AM6PR03MB5170.eurprd03.prod.outlook.com>
Message-ID: <CAHEJ-S7dXEbPKSiw8k_io96P7-BoNSr2d1esOFnbq0Oj0xpaqQ@mail.gmail.com>

We don't guarantee constant time.

Tim.

On Fri, 27 Mar 2020, 5:41 am Bernd Edlinger, <bernd.edlinger at hotmail.de>
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, <matt at openssl.org> 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
> >>> // tshort at akamai.com <mailto:tshort at 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
> >>>> <Matthias.St.Pierre at ncp-e.com <mailto:Matthias.St.Pierre at 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&d=DwMGaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=QBEcQsqoUDdk1Q26CzlzNPPUkKYWIh1LYsiHAwmtRik&m=87AtfQDFl1z9cdRP12QeRUizmgnW6ejbufNT40Gip4Q&s=djWoIIXyggxwOfbwrmYGrSJdR5tWm06IdzY9x9tDxkA&e=
> >>>
> >>>>
> >>>> Matthias
> >>>>
> >>>>
> >>>> *From**:* openssl-project <openssl-project-bounces at openssl.org
> >>>> <mailto:openssl-project-bounces at openssl.org>> *On Behalf Of *Dmitry
> >>>> Belyavsky
> >>>> *Sent:* Thursday, March 26, 2020 3:48 PM
> >>>> *To:* Matt Caswell <matt at openssl.org <mailto:matt at openssl.org>>
> >>>> *Cc:* openssl-project at openssl.org <mailto:openssl-project at openssl.org
> >
> >>>> *Subject:* Re: 1.1.1f
> >>>>
> >>>>
> >>>> On Thu, Mar 26, 2020 at 5:14 PM Matt Caswell <matt at openssl.org
> >>>> <mailto:matt at 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&d=DwMGaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=QBEcQsqoUDdk1Q26CzlzNPPUkKYWIh1LYsiHAwmtRik&m=87AtfQDFl1z9cdRP12QeRUizmgnW6ejbufNT40Gip4Q&s=MAiLjfGJWaKvnBvqnM4fcyvGVfUyj9CDANO_vh4wfco&e=
> >>> )
> >>>>     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&d=DwMGaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=QBEcQsqoUDdk1Q26CzlzNPPUkKYWIh1LYsiHAwmtRik&m=87AtfQDFl1z9cdRP12QeRUizmgnW6ejbufNT40Gip4Q&s=3hBU2pt84DQlrY1dCnSn9x1ah1gSzH6NEO_bNRH-6DE&e=
> >>> ).
> >>>>
> >>>>     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
> >>>
> >>
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-project/attachments/20200327/7d372910/attachment-0001.html>

From bernd.edlinger at hotmail.de  Thu Mar 26 20:13:32 2020
From: bernd.edlinger at hotmail.de (Bernd Edlinger)
Date: Thu, 26 Mar 2020 21:13:32 +0100
Subject: 1.1.1f
In-Reply-To: <CAHEJ-S7dXEbPKSiw8k_io96P7-BoNSr2d1esOFnbq0Oj0xpaqQ@mail.gmail.com>
References: <c032d68e-9b87-dd0a-fe7f-f64e399cffaf@openssl.org>
 <CADqLbz+T8JH5Aa3m=9SuowbJpEYOB7af5COthHEzne1KNWkzmA@mail.gmail.com>
 <2d7a351466ec4f58b49fabc4a9498f52@Ex13.ncp.local>
 <C99C6C8E-6E10-4B34-9F1E-F4B91F26E432@akamai.com>
 <0a52cd16-7e10-e48e-b6eb-4f2436e49186@openssl.org>
 <CAHEJ-S7hHVCqNY=8fgGVBTGfGmOxQwYiY_LQuQpaAq2UKeLc=w@mail.gmail.com>
 <AM6PR03MB51706C18875934E64993EE0DE4CF0@AM6PR03MB5170.eurprd03.prod.outlook.com>
 <CAHEJ-S7dXEbPKSiw8k_io96P7-BoNSr2d1esOFnbq0Oj0xpaqQ@mail.gmail.com>
Message-ID: <AM6PR03MB5170037D0F0A6F1B3CB8F158E4CF0@AM6PR03MB5170.eurprd03.prod.outlook.com>



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, <bernd.edlinger at hotmail.de>
> 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, <matt at openssl.org> 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
>>>>> // tshort at akamai.com <mailto:tshort at 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
>>>>>> <Matthias.St.Pierre at ncp-e.com <mailto:Matthias.St.Pierre at 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&d=DwMGaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=QBEcQsqoUDdk1Q26CzlzNPPUkKYWIh1LYsiHAwmtRik&m=87AtfQDFl1z9cdRP12QeRUizmgnW6ejbufNT40Gip4Q&s=djWoIIXyggxwOfbwrmYGrSJdR5tWm06IdzY9x9tDxkA&e=
>>>>>
>>>>>>
>>>>>> Matthias
>>>>>>
>>>>>>
>>>>>> *From**:* openssl-project <openssl-project-bounces at openssl.org
>>>>>> <mailto:openssl-project-bounces at openssl.org>> *On Behalf Of *Dmitry
>>>>>> Belyavsky
>>>>>> *Sent:* Thursday, March 26, 2020 3:48 PM
>>>>>> *To:* Matt Caswell <matt at openssl.org <mailto:matt at openssl.org>>
>>>>>> *Cc:* openssl-project at openssl.org <mailto:openssl-project at openssl.org
>>>
>>>>>> *Subject:* Re: 1.1.1f
>>>>>>
>>>>>>
>>>>>> On Thu, Mar 26, 2020 at 5:14 PM Matt Caswell <matt at openssl.org
>>>>>> <mailto:matt at 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&d=DwMGaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=QBEcQsqoUDdk1Q26CzlzNPPUkKYWIh1LYsiHAwmtRik&m=87AtfQDFl1z9cdRP12QeRUizmgnW6ejbufNT40Gip4Q&s=MAiLjfGJWaKvnBvqnM4fcyvGVfUyj9CDANO_vh4wfco&e=
>>>>> )
>>>>>>     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&d=DwMGaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=QBEcQsqoUDdk1Q26CzlzNPPUkKYWIh1LYsiHAwmtRik&m=87AtfQDFl1z9cdRP12QeRUizmgnW6ejbufNT40Gip4Q&s=3hBU2pt84DQlrY1dCnSn9x1ah1gSzH6NEO_bNRH-6DE&e=
>>>>> ).
>>>>>>
>>>>>>     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
>>>>>
>>>>
>>>
>>
> 

From openssl-users at dukhovni.org  Thu Mar 26 23:15:37 2020
From: openssl-users at dukhovni.org (Viktor Dukhovni)
Date: Thu, 26 Mar 2020 19:15:37 -0400
Subject: 1.1.1f
In-Reply-To: <AM6PR03MB5170037D0F0A6F1B3CB8F158E4CF0@AM6PR03MB5170.eurprd03.prod.outlook.com>
References: <c032d68e-9b87-dd0a-fe7f-f64e399cffaf@openssl.org>
 <CADqLbz+T8JH5Aa3m=9SuowbJpEYOB7af5COthHEzne1KNWkzmA@mail.gmail.com>
 <2d7a351466ec4f58b49fabc4a9498f52@Ex13.ncp.local>
 <C99C6C8E-6E10-4B34-9F1E-F4B91F26E432@akamai.com>
 <0a52cd16-7e10-e48e-b6eb-4f2436e49186@openssl.org>
 <CAHEJ-S7hHVCqNY=8fgGVBTGfGmOxQwYiY_LQuQpaAq2UKeLc=w@mail.gmail.com>
 <AM6PR03MB51706C18875934E64993EE0DE4CF0@AM6PR03MB5170.eurprd03.prod.outlook.com>
 <CAHEJ-S7dXEbPKSiw8k_io96P7-BoNSr2d1esOFnbq0Oj0xpaqQ@mail.gmail.com>
 <AM6PR03MB5170037D0F0A6F1B3CB8F158E4CF0@AM6PR03MB5170.eurprd03.prod.outlook.com>
Message-ID: <20200326231537.GW68408@straasha.imrryr.org>

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.

From matt at openssl.org  Thu Mar 26 23:21:52 2020
From: matt at openssl.org (Matt Caswell)
Date: Thu, 26 Mar 2020 23:21:52 +0000
Subject: 1.1.1f
In-Reply-To: <AM6PR03MB5170037D0F0A6F1B3CB8F158E4CF0@AM6PR03MB5170.eurprd03.prod.outlook.com>
References: <c032d68e-9b87-dd0a-fe7f-f64e399cffaf@openssl.org>
 <CADqLbz+T8JH5Aa3m=9SuowbJpEYOB7af5COthHEzne1KNWkzmA@mail.gmail.com>
 <2d7a351466ec4f58b49fabc4a9498f52@Ex13.ncp.local>
 <C99C6C8E-6E10-4B34-9F1E-F4B91F26E432@akamai.com>
 <0a52cd16-7e10-e48e-b6eb-4f2436e49186@openssl.org>
 <CAHEJ-S7hHVCqNY=8fgGVBTGfGmOxQwYiY_LQuQpaAq2UKeLc=w@mail.gmail.com>
 <AM6PR03MB51706C18875934E64993EE0DE4CF0@AM6PR03MB5170.eurprd03.prod.outlook.com>
 <CAHEJ-S7dXEbPKSiw8k_io96P7-BoNSr2d1esOFnbq0Oj0xpaqQ@mail.gmail.com>
 <AM6PR03MB5170037D0F0A6F1B3CB8F158E4CF0@AM6PR03MB5170.eurprd03.prod.outlook.com>
Message-ID: <db7fe9b0-e13a-3926-435a-dd03e2f8fe5c@openssl.org>



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, <bernd.edlinger at hotmail.de>
>> 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, <matt at openssl.org> 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
>>>>>> // tshort at akamai.com <mailto:tshort at 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
>>>>>>> <Matthias.St.Pierre at ncp-e.com <mailto:Matthias.St.Pierre at 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&d=DwMGaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=QBEcQsqoUDdk1Q26CzlzNPPUkKYWIh1LYsiHAwmtRik&m=87AtfQDFl1z9cdRP12QeRUizmgnW6ejbufNT40Gip4Q&s=djWoIIXyggxwOfbwrmYGrSJdR5tWm06IdzY9x9tDxkA&e=
>>>>>>
>>>>>>>
>>>>>>> Matthias
>>>>>>>
>>>>>>>
>>>>>>> *From**:* openssl-project <openssl-project-bounces at openssl.org
>>>>>>> <mailto:openssl-project-bounces at openssl.org>> *On Behalf Of *Dmitry
>>>>>>> Belyavsky
>>>>>>> *Sent:* Thursday, March 26, 2020 3:48 PM
>>>>>>> *To:* Matt Caswell <matt at openssl.org <mailto:matt at openssl.org>>
>>>>>>> *Cc:* openssl-project at openssl.org <mailto:openssl-project at openssl.org
>>>>
>>>>>>> *Subject:* Re: 1.1.1f
>>>>>>>
>>>>>>>
>>>>>>> On Thu, Mar 26, 2020 at 5:14 PM Matt Caswell <matt at openssl.org
>>>>>>> <mailto:matt at 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&d=DwMGaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=QBEcQsqoUDdk1Q26CzlzNPPUkKYWIh1LYsiHAwmtRik&m=87AtfQDFl1z9cdRP12QeRUizmgnW6ejbufNT40Gip4Q&s=MAiLjfGJWaKvnBvqnM4fcyvGVfUyj9CDANO_vh4wfco&e=
>>>>>> )
>>>>>>>     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&d=DwMGaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=QBEcQsqoUDdk1Q26CzlzNPPUkKYWIh1LYsiHAwmtRik&m=87AtfQDFl1z9cdRP12QeRUizmgnW6ejbufNT40Gip4Q&s=3hBU2pt84DQlrY1dCnSn9x1ah1gSzH6NEO_bNRH-6DE&e=
>>>>>> ).
>>>>>>>
>>>>>>>     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
>>>>>>
>>>>>
>>>>
>>>
>>
> 

From matt at openssl.org  Thu Mar 26 23:33:40 2020
From: matt at openssl.org (Matt Caswell)
Date: Thu, 26 Mar 2020 23:33:40 +0000
Subject: 1.1.1f
In-Reply-To: <20200326231537.GW68408@straasha.imrryr.org>
References: <c032d68e-9b87-dd0a-fe7f-f64e399cffaf@openssl.org>
 <CADqLbz+T8JH5Aa3m=9SuowbJpEYOB7af5COthHEzne1KNWkzmA@mail.gmail.com>
 <2d7a351466ec4f58b49fabc4a9498f52@Ex13.ncp.local>
 <C99C6C8E-6E10-4B34-9F1E-F4B91F26E432@akamai.com>
 <0a52cd16-7e10-e48e-b6eb-4f2436e49186@openssl.org>
 <CAHEJ-S7hHVCqNY=8fgGVBTGfGmOxQwYiY_LQuQpaAq2UKeLc=w@mail.gmail.com>
 <AM6PR03MB51706C18875934E64993EE0DE4CF0@AM6PR03MB5170.eurprd03.prod.outlook.com>
 <CAHEJ-S7dXEbPKSiw8k_io96P7-BoNSr2d1esOFnbq0Oj0xpaqQ@mail.gmail.com>
 <AM6PR03MB5170037D0F0A6F1B3CB8F158E4CF0@AM6PR03MB5170.eurprd03.prod.outlook.com>
 <20200326231537.GW68408@straasha.imrryr.org>
Message-ID: <2d693516-57dc-b533-2a9c-82ccd734c82c@openssl.org>



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

From openssl-users at dukhovni.org  Fri Mar 27 00:10:02 2020
From: openssl-users at dukhovni.org (Viktor Dukhovni)
Date: Thu, 26 Mar 2020 20:10:02 -0400
Subject: 1.1.1f
In-Reply-To: <2d693516-57dc-b533-2a9c-82ccd734c82c@openssl.org>
References: <CADqLbz+T8JH5Aa3m=9SuowbJpEYOB7af5COthHEzne1KNWkzmA@mail.gmail.com>
 <2d7a351466ec4f58b49fabc4a9498f52@Ex13.ncp.local>
 <C99C6C8E-6E10-4B34-9F1E-F4B91F26E432@akamai.com>
 <0a52cd16-7e10-e48e-b6eb-4f2436e49186@openssl.org>
 <CAHEJ-S7hHVCqNY=8fgGVBTGfGmOxQwYiY_LQuQpaAq2UKeLc=w@mail.gmail.com>
 <AM6PR03MB51706C18875934E64993EE0DE4CF0@AM6PR03MB5170.eurprd03.prod.outlook.com>
 <CAHEJ-S7dXEbPKSiw8k_io96P7-BoNSr2d1esOFnbq0Oj0xpaqQ@mail.gmail.com>
 <AM6PR03MB5170037D0F0A6F1B3CB8F158E4CF0@AM6PR03MB5170.eurprd03.prod.outlook.com>
 <20200326231537.GW68408@straasha.imrryr.org>
 <2d693516-57dc-b533-2a9c-82ccd734c82c@openssl.org>
Message-ID: <20200327001002.GX68408@straasha.imrryr.org>

On Thu, Mar 26, 2020 at 11:33:40PM +0000, 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.

From matt at openssl.org  Fri Mar 27 14:10:18 2020
From: matt at openssl.org (Matt Caswell)
Date: Fri, 27 Mar 2020 14:10:18 +0000
Subject: 1.1.1f
In-Reply-To: <20200327001002.GX68408@straasha.imrryr.org>
References: <CADqLbz+T8JH5Aa3m=9SuowbJpEYOB7af5COthHEzne1KNWkzmA@mail.gmail.com>
 <2d7a351466ec4f58b49fabc4a9498f52@Ex13.ncp.local>
 <C99C6C8E-6E10-4B34-9F1E-F4B91F26E432@akamai.com>
 <0a52cd16-7e10-e48e-b6eb-4f2436e49186@openssl.org>
 <CAHEJ-S7hHVCqNY=8fgGVBTGfGmOxQwYiY_LQuQpaAq2UKeLc=w@mail.gmail.com>
 <AM6PR03MB51706C18875934E64993EE0DE4CF0@AM6PR03MB5170.eurprd03.prod.outlook.com>
 <CAHEJ-S7dXEbPKSiw8k_io96P7-BoNSr2d1esOFnbq0Oj0xpaqQ@mail.gmail.com>
 <AM6PR03MB5170037D0F0A6F1B3CB8F158E4CF0@AM6PR03MB5170.eurprd03.prod.outlook.com>
 <20200326231537.GW68408@straasha.imrryr.org>
 <2d693516-57dc-b533-2a9c-82ccd734c82c@openssl.org>
 <20200327001002.GX68408@straasha.imrryr.org>
Message-ID: <8625e4aa-d5e3-384a-87f0-0b98d46985f7@openssl.org>

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 +0000, 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.
> 

From matt at openssl.org  Sat Mar 28 11:11:49 2020
From: matt at openssl.org (Matt Caswell)
Date: Sat, 28 Mar 2020 11:11:49 +0000
Subject: Forthcoming OpenSSL Release
Message-ID: <1d0128a9-8d8e-a8b9-2949-7404ae287ea8@openssl.org>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

The OpenSSL project team would like to announce the forthcoming release
of OpenSSL version 1.1.1f.

This release will be made available on Tuesday 31st March 2020 between
1200-1600 UTC. This is a bug fix only release.

Yours

The OpenSSL Project Team
-----BEGIN PGP SIGNATURE-----

iQEzBAEBCAAdFiEEhlersmDwVrHlGQg52cTSbQ5gRJEFAl5/MPUACgkQ2cTSbQ5g
RJGnaggAjtB2r56ufZaOUAy7/stpy+Cj7R4Jq+RZb8Ja6c9hU9FwHx5/eESxs1lC
XQKr5RGcPZbIvgoDaFCBVXBswl6Ivhde/MuWLoeoag+sl4TBztx/Aash6YAT78ij
h/NvRcYDn2mcBrclxJckh9sags5ei13d+GWug349X8d7dVdfHooFTBgq0Th4ehfZ
UBaNgQTnqnd/8PD2paGkQtHOr8Qr2TTPH6HyQ5Vlea+x0AzjnAbWjbr/wvu0yuFE
2RqE6RnVy65M+Nx1wIXh1ZJT0EfyN4lqRFYuTWViJVPfPDT61UkIKSbxzRtVWEl8
Pu4T2r9cKHl8kFnuA0kqc0/5/jG2EQ==
=KWO3
-----END PGP SIGNATURE-----

From bernd.edlinger at hotmail.de  Sun Mar 29 06:56:34 2020
From: bernd.edlinger at hotmail.de (Bernd Edlinger)
Date: Sun, 29 Mar 2020 08:56:34 +0200
Subject: 1.1.1f
In-Reply-To: <AM6PR03MB5170037D0F0A6F1B3CB8F158E4CF0@AM6PR03MB5170.eurprd03.prod.outlook.com>
References: <c032d68e-9b87-dd0a-fe7f-f64e399cffaf@openssl.org>
 <CADqLbz+T8JH5Aa3m=9SuowbJpEYOB7af5COthHEzne1KNWkzmA@mail.gmail.com>
 <2d7a351466ec4f58b49fabc4a9498f52@Ex13.ncp.local>
 <C99C6C8E-6E10-4B34-9F1E-F4B91F26E432@akamai.com>
 <0a52cd16-7e10-e48e-b6eb-4f2436e49186@openssl.org>
 <CAHEJ-S7hHVCqNY=8fgGVBTGfGmOxQwYiY_LQuQpaAq2UKeLc=w@mail.gmail.com>
 <AM6PR03MB51706C18875934E64993EE0DE4CF0@AM6PR03MB5170.eurprd03.prod.outlook.com>
 <CAHEJ-S7dXEbPKSiw8k_io96P7-BoNSr2d1esOFnbq0Oj0xpaqQ@mail.gmail.com>
 <AM6PR03MB5170037D0F0A6F1B3CB8F158E4CF0@AM6PR03MB5170.eurprd03.prod.outlook.com>
Message-ID: <AM6PR03MB517090B20571CBC9D4F596CCE4CA0@AM6PR03MB5170.eurprd03.prod.outlook.com>

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, <bernd.edlinger at hotmail.de>
>> 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, <matt at openssl.org> 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
>>>>>> // tshort at akamai.com <mailto:tshort at 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
>>>>>>> <Matthias.St.Pierre at ncp-e.com <mailto:Matthias.St.Pierre at 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&d=DwMGaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=QBEcQsqoUDdk1Q26CzlzNPPUkKYWIh1LYsiHAwmtRik&m=87AtfQDFl1z9cdRP12QeRUizmgnW6ejbufNT40Gip4Q&s=djWoIIXyggxwOfbwrmYGrSJdR5tWm06IdzY9x9tDxkA&e=
>>>>>>
>>>>>>>
>>>>>>> Matthias
>>>>>>>
>>>>>>>
>>>>>>> *From**:* openssl-project <openssl-project-bounces at openssl.org
>>>>>>> <mailto:openssl-project-bounces at openssl.org>> *On Behalf Of *Dmitry
>>>>>>> Belyavsky
>>>>>>> *Sent:* Thursday, March 26, 2020 3:48 PM
>>>>>>> *To:* Matt Caswell <matt at openssl.org <mailto:matt at openssl.org>>
>>>>>>> *Cc:* openssl-project at openssl.org <mailto:openssl-project at openssl.org
>>>>
>>>>>>> *Subject:* Re: 1.1.1f
>>>>>>>
>>>>>>>
>>>>>>> On Thu, Mar 26, 2020 at 5:14 PM Matt Caswell <matt at openssl.org
>>>>>>> <mailto:matt at 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&d=DwMGaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=QBEcQsqoUDdk1Q26CzlzNPPUkKYWIh1LYsiHAwmtRik&m=87AtfQDFl1z9cdRP12QeRUizmgnW6ejbufNT40Gip4Q&s=MAiLjfGJWaKvnBvqnM4fcyvGVfUyj9CDANO_vh4wfco&e=
>>>>>> )
>>>>>>>     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&d=DwMGaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=QBEcQsqoUDdk1Q26CzlzNPPUkKYWIh1LYsiHAwmtRik&m=87AtfQDFl1z9cdRP12QeRUizmgnW6ejbufNT40Gip4Q&s=3hBU2pt84DQlrY1dCnSn9x1ah1gSzH6NEO_bNRH-6DE&e=
>>>>>> ).
>>>>>>>
>>>>>>>     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
>>>>>>
>>>>>
>>>>
>>>
>>

From beldmit at gmail.com  Mon Mar 30 11:32:50 2020
From: beldmit at gmail.com (Dmitry Belyavsky)
Date: Mon, 30 Mar 2020 14:32:50 +0300
Subject: Deprecating misleading GOST names
In-Reply-To: <189ff552-c366-433d-b0b5-784e45e97ec4@redhat.com>
References: <CADqLbzJ4Ds51y5hQW6fzXZ1emJaBxE25iW38cu+0gsiwxrffHQ@mail.gmail.com>
 <189ff552-c366-433d-b0b5-784e45e97ec4@redhat.com>
Message-ID: <CADqLbzJB_givS3r5d3J_26KfC8SzB-b9Rkjg6aGamDCRNjY_2g@mail.gmail.com>

Dear Hubert,

Done:
https://github.com/openssl/openssl/pull/11440

On Fri, Mar 20, 2020 at 6:27 PM Hubert Kario <hkario at redhat.com> wrote:

> On Friday, 20 March 2020 13:17:48 CET, Dmitry Belyavsky wrote:
> > Hello,
> >
> > I came across wrong naming for some GOST-related stuff in object.txt. As
> > all this stuff was introduced by me, it's a separate problem.
> >
> > First, I've erroneously translated the name of the Russian "????????"
> > algorithm as "grasshopper" instead of transliterating it as 'kuznyechik".
> > The transliteration has appeared as an official after the changes were
> > accepted into openssl.
> >
> > Second, some other algorithm and parameter names were introduced with
> their
> > official names instead of reasonable short names. When they are used in
> the
> > command line applications, it's very inconvenient.
> >
> > I'd like to fix these issues in the upcoming 3.0 release, so any ideas
> > about how to deal with it are welcome. Some of this stuff can be fixed on
> > the engine level, but it's better to avoid misleading naming.
>
> how about introducing the new names as aliases and keeping the old ones
> active?
>
> (maybe with exception of "kuznyechik", but still support both at the same
> time)
> --
> Regards,
> Hubert Kario
> Senior Quality Engineer, QE BaseOS Security team
> Web: www.cz.redhat.com
> Red Hat Czech s.r.o., Purky?ova 115, 612 00  Brno, Czech Republic
>
>

-- 
SY, Dmitry Belyavsky
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-project/attachments/20200330/d2878b51/attachment.html>

From rsalz at akamai.com  Mon Mar 30 15:09:54 2020
From: rsalz at akamai.com (Salz, Rich)
Date: Mon, 30 Mar 2020 15:09:54 +0000
Subject: CI build timeouts
Message-ID: <4973535F-1DD6-4A0E-92DB-6D9894640467@akamai.com>

It?s time to disable that build, isn?t it?
It?s timing out *AFTER AN HOUR*

From: Tom?? Mr?z <notifications at github.com>
Reply-To: openssl/openssl <reply+ABX6FFGLPADWGZAVDZG2GYF4RXNENEVBNHHCGLPWJY at reply.github.com>
Date: Monday, March 30, 2020 at 9:51 AM
To: openssl/openssl <openssl at noreply.github.com>
Cc: Subscribed <subscribed at noreply.github.com>
Subject: Re: [openssl/openssl] [crypto/ec] blind coordinates in ec_wNAF_mul for robustness (#11439)


The CI failure doesn't really make sense to me.

That's just an usual timeout unrelated to this PR.

?
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub<https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_openssl_openssl_pull_11439-23issuecomment-2D606011445&d=DwMCaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=4LM0GbR0h9Fvx86FtsKI-w&m=RILRQqoh1kxJ6nftwOZyCnUVIOSjfc_TLaZmkG1sOxQ&s=38VA97PZvS7gmMEmXRwftSkB3YiG89ol2R9btbtr6Ak&e=>, or unsubscribe<https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_notifications_unsubscribe-2Dauth_ABX6FFB6XSEBQEKC3FAVO7TRKCPUNANCNFSM4LWQHFNQ&d=DwMCaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=4LM0GbR0h9Fvx86FtsKI-w&m=RILRQqoh1kxJ6nftwOZyCnUVIOSjfc_TLaZmkG1sOxQ&s=0aQNc42coYbNnBuGSMaGlSXQF0Q_pvovOYotKBvU9tU&e=>.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-project/attachments/20200330/a38df443/attachment.html>

From shane.lontis at oracle.com  Mon Mar 30 21:13:37 2020
From: shane.lontis at oracle.com (SHANE LONTIS)
Date: Tue, 31 Mar 2020 07:13:37 +1000
Subject: CI build timeouts
In-Reply-To: <4973535F-1DD6-4A0E-92DB-6D9894640467@akamai.com>
References: <4973535F-1DD6-4A0E-92DB-6D9894640467@akamai.com>
Message-ID: <F0EF1C7B-CD73-4F18-9FD4-DE66651F1AB5@oracle.com>

Disabling memory leak checking doesn?t sound like a great idea..

> On 31 Mar 2020, at 1:09 am, Salz, Rich <rsalz at akamai.com> wrote:
> 
> It?s time to disable that build, isn?t it?
> It?s timing out *AFTER AN HOUR*
>  
> From: Tom?? Mr?z <notifications at github.com <mailto:notifications at github.com>>
> Reply-To: openssl/openssl <reply+ABX6FFGLPADWGZAVDZG2GYF4RXNENEVBNHHCGLPWJY at reply.github.com <mailto:reply+ABX6FFGLPADWGZAVDZG2GYF4RXNENEVBNHHCGLPWJY at reply.github.com>>
> Date: Monday, March 30, 2020 at 9:51 AM
> To: openssl/openssl <openssl at noreply.github.com <mailto:openssl at noreply.github.com>>
> Cc: Subscribed <subscribed at noreply.github.com <mailto:subscribed at noreply.github.com>>
> Subject: Re: [openssl/openssl] [crypto/ec] blind coordinates in ec_wNAF_mul for robustness (#11439)
>  
>> The CI failure doesn't really make sense to me.
> That's just an usual timeout unrelated to this PR.
> ?
> You are receiving this because you are subscribed to this thread.
> Reply to this email directly, view it on GitHub <https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_openssl_openssl_pull_11439-23issuecomment-2D606011445&d=DwMCaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=4LM0GbR0h9Fvx86FtsKI-w&m=RILRQqoh1kxJ6nftwOZyCnUVIOSjfc_TLaZmkG1sOxQ&s=38VA97PZvS7gmMEmXRwftSkB3YiG89ol2R9btbtr6Ak&e=>, or unsubscribe <https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_notifications_unsubscribe-2Dauth_ABX6FFB6XSEBQEKC3FAVO7TRKCPUNANCNFSM4LWQHFNQ&d=DwMCaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=4LM0GbR0h9Fvx86FtsKI-w&m=RILRQqoh1kxJ6nftwOZyCnUVIOSjfc_TLaZmkG1sOxQ&s=0aQNc42coYbNnBuGSMaGlSXQF0Q_pvovOYotKBvU9tU&e=>.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-project/attachments/20200331/bfd17b74/attachment-0001.html>

From bernd.edlinger at hotmail.de  Tue Mar 31 09:43:54 2020
From: bernd.edlinger at hotmail.de (Bernd Edlinger)
Date: Tue, 31 Mar 2020 11:43:54 +0200
Subject: Please have a look at this PR
Message-ID: <AM6PR03MB5170953C3E730EA385472963E4C80@AM6PR03MB5170.eurprd03.prod.outlook.com>

As discussed in the meeting today,

I'd like to have my PR
Remove x86/x86_64 BSAES and AES_ASM support #9677

be approved soon, as it is holding up other
work I plan to do.


Thanks
Bernd.

From matt at openssl.org  Tue Mar 31 10:06:59 2020
From: matt at openssl.org (Matt Caswell)
Date: Tue, 31 Mar 2020 11:06:59 +0100
Subject: Critical Path and Dependencies for Alpha1
Message-ID: <e21dd24c-31df-73e9-ce6c-4d6057906ecf@openssl.org>

Please see attached for what I believe is the critical path as well as
the key dependencies for Alpha 1. Please let me know of any errors or
omissions.

Matt
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Alpha1CriticalPathAndDependencies.png
Type: image/png
Size: 73426 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-project/attachments/20200331/daa3c53a/attachment-0001.png>

From openssl at openssl.org  Tue Mar 31 12:57:30 2020
From: openssl at openssl.org (OpenSSL)
Date: Tue, 31 Mar 2020 12:57:30 +0000
Subject: OpenSSL version 1.1.1f published
Message-ID: <20200331125730.GA13462@openssl.org>

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

From rsalz at akamai.com  Mon Mar 30 21:16:15 2020
From: rsalz at akamai.com (Salz, Rich)
Date: Mon, 30 Mar 2020 21:16:15 -0000
Subject: CI build timeouts
In-Reply-To: <F0EF1C7B-CD73-4F18-9FD4-DE66651F1AB5@oracle.com>
References: <4973535F-1DD6-4A0E-92DB-6D9894640467@akamai.com>
 <F0EF1C7B-CD73-4F18-9FD4-DE66651F1AB5@oracle.com>
Message-ID: <2BCF1452-C9D7-4FA2-90D4-6034F39D4674@akamai.com>

  *   Disabling memory leak checking doesn?t sound like a great idea..

On that one platform, no?


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-project/attachments/20200330/2285d8e0/attachment-0001.html>