From matt at openssl.org  Thu Jan  2 12:14:49 2020
From: matt at openssl.org (Matt Caswell)
Date: Thu, 2 Jan 2020 12:14:49 +0000
Subject: Monthly Status Report (December)
Message-ID: <f450dba3-9e72-352c-3495-bfa63a8b9ca6@openssl.org>

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

- Deprecated the AES_ige_*() functions
- Continued work on the PR to move constant time padding checks out of
libssl
- Significant additional work on the PR to fix issues with
SSL_get_servername()
- Backported RSA_get0_pss_params() to 1.1.1
- Reviewed a large number of old issues in conjunction with Richard Levitte
- Co-ordinated and issued security advisory for CVE-2019-1551
- Fixed EVP_PKEY_set1_DH() to correctly handle X9.42 DH keys
- Created PR to deprecate the low level AES functions
- Performed the 1.0.2u release
- Fixed no-dh and no-dsa
- PR to fix the Travis builds

Matt

From matt at openssl.org  Fri Jan  3 15:20:36 2020
From: matt at openssl.org (Matt Caswell)
Date: Fri, 3 Jan 2020 15:20:36 +0000
Subject: OTC up and running
Message-ID: <a5485f11-6eeb-89eb-4200-c3246f1856af@openssl.org>

The OpenSSL Technical Commmittee is now up and running.

The required bylaws changes have been approved and you can read the
updated bylaws here:

https://www.openssl.org/policies/omc-bylaws.html

We've also updated various other policies to take account of these
changes. The change that will most obviously be noticed is that github
PRs now require an OTC sign off instead of an OMC sign off.

I've just pushed a new page to the website listing the OTC members:

https://www.openssl.org/community/otc.html

As well as familiar OMC names I'd like to welcome on to the OTC Tomas
Mraz (@t8m), Matthias St. Pierre (@mspncp) and Nicola Tuveri (@romen).
Congratulations to all of them!

Finally we also have a new committer! Or is that an old committer?
Anyway Mark Cox (one of the founder members of OpenSSL and an OMC
member) now has committer status (and is also on the OTC).

Matt


From rsalz at akamai.com  Fri Jan  3 15:58:54 2020
From: rsalz at akamai.com (Salz, Rich)
Date: Fri, 3 Jan 2020 15:58:54 +0000
Subject: FW: Coverity Scan: Analysis completed for OpenSSL-1.0.2
In-Reply-To: <5e0ec64123f80_82b2ac5a47a0f5036692@appnode-2.mail>
References: <5e0ec64123f80_82b2ac5a47a0f5036692@appnode-2.mail>
Message-ID: <45FC988C-176B-4547-AF44-573949619DE0@akamai.com>

Someone should turn off 1.0.2 :)

?On 1/2/20, 11:48 PM, "scan-admin at coverity.com" <scan-admin at coverity.com> wrote:

    
        Your request for analysis of OpenSSL-1.0.2 has been completed successfully.
        The results are available at https://u2389337.ct.sendgrid.net/wf/click?upn=08onrYu34A-2BWcWUl-2F-2BfV0V05UPxvVjWch-2Bd2MGckcRakUl6QyjujEohY7rPpoYUEOo3rtGjiQZqYPGgcjfkiXQ-3D-3D_19DGMz38yO7VfzGQuXkecdlEmzBoDG4v8Dvyanv-2F1I2lW0-2BZw7MZMuFrG0u27bOOxjy4p8-2F84zVh7dDZIZNmMsRKAX6NxkpAdv-2BDwIY-2FvlUX-2FkDt3qaNtfzW2FsKugnrtUYdN8FPN16BhlPQAKsnJcvvEMj-2Fb0c4tYaht8-2ByOH4JE66wyaq-2BVXPkmQLp8GqxY61EIKDPvbif6rmn-2Fj-2BuXx2h4n6K6oS9JMdL-2B5Ft-2FQGIOh64FWXD2sq0PHMNzo4k
    
        Build ID: 286891
    
        Analysis Summary:
           New defects found: 0
           Defects eliminated: 0
    
    


From matt at openssl.org  Mon Jan  6 12:30:52 2020
From: matt at openssl.org (Matt Caswell)
Date: Mon, 6 Jan 2020 12:30:52 +0000
Subject: OTC up and running
In-Reply-To: <a5485f11-6eeb-89eb-4200-c3246f1856af@openssl.org>
References: <a5485f11-6eeb-89eb-4200-c3246f1856af@openssl.org>
Message-ID: <98adecf7-346b-bb0a-0dc3-e09a7c09e2e3@openssl.org>



On 03/01/2020 15:20, Matt Caswell wrote:
> The OpenSSL Technical Commmittee is now up and running.
> 
> The required bylaws changes have been approved and you can read the
> updated bylaws here:
> 
> https://www.openssl.org/policies/omc-bylaws.html
> 
> We've also updated various other policies to take account of these
> changes. The change that will most obviously be noticed is that github
> PRs now require an OTC sign off instead of an OMC sign off.
> 
> I've just pushed a new page to the website listing the OTC members:
> 
> https://www.openssl.org/community/otc.html
> 
> As well as familiar OMC names I'd like to welcome on to the OTC Tomas
> Mraz (@t8m), Matthias St. Pierre (@mspncp) and Nicola Tuveri (@romen).
> Congratulations to all of them!

Welcome and congratulations also go to Shane Lontis (@slontis).

Matt


> 
> Finally we also have a new committer! Or is that an old committer?
> Anyway Mark Cox (one of the founder members of OpenSSL and an OMC
> member) now has committer status (and is also on the OTC).
> 
> Matt
> 

From paul.dale at oracle.com  Mon Jan  6 23:57:55 2020
From: paul.dale at oracle.com (Dr Paul Dale)
Date: Tue, 7 Jan 2020 09:57:55 +1000
Subject: Legacy Provider
Message-ID: <B47E7E33-DCD1-4271-A30C-59599F6CCBA6@oracle.com>

The refactoring/FIPS work needs the question resolved about loading the legacy provider or not by default.  We?ve been through this before on the project list [1] and in at least one PR [2].

I expect that its resolution will require an OMC vote.

Regardless of the outcome, the current intention is that the low level direct access functions (e.g. IDEA_encrypt) will continue to work (albeit deprecated), only the EVP access will go (again, by default).


Before the vote is called, are there any additional thoughts from the past six months?


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


[1] https://mta.openssl.org/pipermail/openssl-project/2019-July/001492.html
[2] https://github.com/openssl/openssl/pull/9373



From matt at openssl.org  Tue Jan  7 11:13:21 2020
From: matt at openssl.org (Matt Caswell)
Date: Tue, 7 Jan 2020 11:13:21 +0000
Subject: 3.0 release timeline proposal
Message-ID: <fe4f3315-f17e-2463-258d-9120a129dc2a@openssl.org>

Hi all

Myself, Paul, Shane, Richard and Nicola had a conf call today to discuss
the outstanding tasks and effort required to get us to a final release.

We've previously said this about that timeline:

"We are now not expecting code completion to occur until the end of Q2
2020 with a final release in early Q4 2020."
(https://www.openssl.org/blog/blog/2019/11/07/3.0-update/)


With that in mind we came up with the following proposal for a release
timetable which we think is a challenging but achievable timeline:

alpha1, 2020-03-31: Basic functionality plus basic FIPS module
alpha2, 2020-04-21: Complete external provider support (serialization,
support for new algs, support for providers which only include
operations in a class)
alpha3, 2020-05-21: Almost there (aiming to test the API completeness
before beta1 freezes it)
beta1, 2020-06-02: Code complete (API stable, feature freeze)
betaN: Other beta TBD
Final: 2020 early Q4

The idea here is to set some intermediate deadlines to focus attention
on the final remaining tasks, with a series of 3 alphas prior to the
first beta release where each alpha release comes approximately every 3
weeks. We can have some flexibility to adjust this timetable if we think
it is necessary (such as by including an additional alpha release if
required).

Please let me know your thoughts. This would probably need to go to an
OMC vote to get approved.

Matt

From beldmit at gmail.com  Tue Jan  7 13:00:13 2020
From: beldmit at gmail.com (Dmitry Belyavsky)
Date: Tue, 7 Jan 2020 16:00:13 +0300
Subject: 3.0 release timeline proposal
In-Reply-To: <fe4f3315-f17e-2463-258d-9120a129dc2a@openssl.org>
References: <fe4f3315-f17e-2463-258d-9120a129dc2a@openssl.org>
Message-ID: <CADqLbzKMsQSsQSmCGOk8v0iQdriM4qLfuPFJDhzn-hoe6kUvxw@mail.gmail.com>

When does the feature freeze happen?
I'm interested in publishing as much GOST support as possible.

On Tue, 7 Jan 2020, 14:13 Matt Caswell, <matt at openssl.org> wrote:

> Hi all
>
> Myself, Paul, Shane, Richard and Nicola had a conf call today to discuss
> the outstanding tasks and effort required to get us to a final release.
>
> We've previously said this about that timeline:
>
> "We are now not expecting code completion to occur until the end of Q2
> 2020 with a final release in early Q4 2020."
> (https://www.openssl.org/blog/blog/2019/11/07/3.0-update/)
>
>
> With that in mind we came up with the following proposal for a release
> timetable which we think is a challenging but achievable timeline:
>
> alpha1, 2020-03-31: Basic functionality plus basic FIPS module
> alpha2, 2020-04-21: Complete external provider support (serialization,
> support for new algs, support for providers which only include
> operations in a class)
> alpha3, 2020-05-21: Almost there (aiming to test the API completeness
> before beta1 freezes it)
> beta1, 2020-06-02: Code complete (API stable, feature freeze)
> betaN: Other beta TBD
> Final: 2020 early Q4
>
> The idea here is to set some intermediate deadlines to focus attention
> on the final remaining tasks, with a series of 3 alphas prior to the
> first beta release where each alpha release comes approximately every 3
> weeks. We can have some flexibility to adjust this timetable if we think
> it is necessary (such as by including an additional alpha release if
> required).
>
> Please let me know your thoughts. This would probably need to go to an
> OMC vote to get approved.
>
> Matt
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-project/attachments/20200107/4c70a009/attachment.html>

From matt at openssl.org  Tue Jan  7 13:05:34 2020
From: matt at openssl.org (Matt Caswell)
Date: Tue, 7 Jan 2020 13:05:34 +0000
Subject: 3.0 release timeline proposal
In-Reply-To: <CADqLbzKMsQSsQSmCGOk8v0iQdriM4qLfuPFJDhzn-hoe6kUvxw@mail.gmail.com>
References: <fe4f3315-f17e-2463-258d-9120a129dc2a@openssl.org>
 <CADqLbzKMsQSsQSmCGOk8v0iQdriM4qLfuPFJDhzn-hoe6kUvxw@mail.gmail.com>
Message-ID: <a0ac883c-70bb-4146-886b-90f6489250d5@openssl.org>



On 07/01/2020 13:00, Dmitry Belyavsky wrote:
> When does the feature freeze happen?
> I'm interested in publishing as much GOST support as possible. 

According to my proposal feature freeze would happen on release of
beta1, i.e. 2020-06-02.

Matt


> 
> On Tue, 7 Jan 2020, 14:13 Matt Caswell, <matt at openssl.org
> <mailto:matt at openssl.org>> wrote:
> 
>     Hi all
> 
>     Myself, Paul, Shane, Richard and Nicola had a conf call today to discuss
>     the outstanding tasks and effort required to get us to a final release.
> 
>     We've previously said this about that timeline:
> 
>     "We are now not expecting code completion to occur until the end of Q2
>     2020 with a final release in early Q4 2020."
>     (https://www.openssl.org/blog/blog/2019/11/07/3.0-update/)
> 
> 
>     With that in mind we came up with the following proposal for a release
>     timetable which we think is a challenging but achievable timeline:
> 
>     alpha1, 2020-03-31: Basic functionality plus basic FIPS module
>     alpha2, 2020-04-21: Complete external provider support (serialization,
>     support for new algs, support for providers which only include
>     operations in a class)
>     alpha3, 2020-05-21: Almost there (aiming to test the API completeness
>     before beta1 freezes it)
>     beta1, 2020-06-02: Code complete (API stable, feature freeze)
>     betaN: Other beta TBD
>     Final: 2020 early Q4
> 
>     The idea here is to set some intermediate deadlines to focus attention
>     on the final remaining tasks, with a series of 3 alphas prior to the
>     first beta release where each alpha release comes approximately every 3
>     weeks. We can have some flexibility to adjust this timetable if we think
>     it is necessary (such as by including an additional alpha release if
>     required).
> 
>     Please let me know your thoughts. This would probably need to go to an
>     OMC vote to get approved.
> 
>     Matt
> 

From beldmit at gmail.com  Tue Jan  7 13:26:11 2020
From: beldmit at gmail.com (Dmitry Belyavsky)
Date: Tue, 7 Jan 2020 16:26:11 +0300
Subject: 3.0 release timeline proposal
In-Reply-To: <a0ac883c-70bb-4146-886b-90f6489250d5@openssl.org>
References: <fe4f3315-f17e-2463-258d-9120a129dc2a@openssl.org>
 <CADqLbzKMsQSsQSmCGOk8v0iQdriM4qLfuPFJDhzn-hoe6kUvxw@mail.gmail.com>
 <a0ac883c-70bb-4146-886b-90f6489250d5@openssl.org>
Message-ID: <CADqLbzKNn94FSMxJZpGuCk6KTv4o=cPD6vLf4DUntu3vmv8MQw@mail.gmail.com>

Many thanks!

Got it, and I think this should be directly written.

On Tue, 7 Jan 2020, 16:05 Matt Caswell, <matt at openssl.org> wrote:

>
>
> On 07/01/2020 13:00, Dmitry Belyavsky wrote:
> > When does the feature freeze happen?
> > I'm interested in publishing as much GOST support as possible.
>
> According to my proposal feature freeze would happen on release of
> beta1, i.e. 2020-06-02.
>
> Matt
>
>
> >
> > On Tue, 7 Jan 2020, 14:13 Matt Caswell, <matt at openssl.org
> > <mailto:matt at openssl.org>> wrote:
> >
> >     Hi all
> >
> >     Myself, Paul, Shane, Richard and Nicola had a conf call today to
> discuss
> >     the outstanding tasks and effort required to get us to a final
> release.
> >
> >     We've previously said this about that timeline:
> >
> >     "We are now not expecting code completion to occur until the end of
> Q2
> >     2020 with a final release in early Q4 2020."
> >     (https://www.openssl.org/blog/blog/2019/11/07/3.0-update/)
> >
> >
> >     With that in mind we came up with the following proposal for a
> release
> >     timetable which we think is a challenging but achievable timeline:
> >
> >     alpha1, 2020-03-31: Basic functionality plus basic FIPS module
> >     alpha2, 2020-04-21: Complete external provider support
> (serialization,
> >     support for new algs, support for providers which only include
> >     operations in a class)
> >     alpha3, 2020-05-21: Almost there (aiming to test the API completeness
> >     before beta1 freezes it)
> >     beta1, 2020-06-02: Code complete (API stable, feature freeze)
> >     betaN: Other beta TBD
> >     Final: 2020 early Q4
> >
> >     The idea here is to set some intermediate deadlines to focus
> attention
> >     on the final remaining tasks, with a series of 3 alphas prior to the
> >     first beta release where each alpha release comes approximately
> every 3
> >     weeks. We can have some flexibility to adjust this timetable if we
> think
> >     it is necessary (such as by including an additional alpha release if
> >     required).
> >
> >     Please let me know your thoughts. This would probably need to go to
> an
> >     OMC vote to get approved.
> >
> >     Matt
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-project/attachments/20200107/0713b03f/attachment-0001.html>

From matt at openssl.org  Tue Jan  7 13:35:25 2020
From: matt at openssl.org (Matt Caswell)
Date: Tue, 7 Jan 2020 13:35:25 +0000
Subject: 3.0 release timeline proposal
In-Reply-To: <CADqLbzKNn94FSMxJZpGuCk6KTv4o=cPD6vLf4DUntu3vmv8MQw@mail.gmail.com>
References: <fe4f3315-f17e-2463-258d-9120a129dc2a@openssl.org>
 <CADqLbzKMsQSsQSmCGOk8v0iQdriM4qLfuPFJDhzn-hoe6kUvxw@mail.gmail.com>
 <a0ac883c-70bb-4146-886b-90f6489250d5@openssl.org>
 <CADqLbzKNn94FSMxJZpGuCk6KTv4o=cPD6vLf4DUntu3vmv8MQw@mail.gmail.com>
Message-ID: <693b4771-6250-fd6c-3e94-326317543590@openssl.org>



On 07/01/2020 13:26, Dmitry Belyavsky wrote:
> Many thanks!
> 
> Got it, and I think this should be directly written. 

It was!!

beta1, 2020-06-02: Code complete (API stable, feature freeze)


Matt


> 
> On Tue, 7 Jan 2020, 16:05 Matt Caswell, <matt at openssl.org
> <mailto:matt at openssl.org>> wrote:
> 
> 
> 
>     On 07/01/2020 13:00, Dmitry Belyavsky wrote:
>     > When does the feature freeze happen?
>     > I'm interested in publishing as much GOST support as possible.
> 
>     According to my proposal feature freeze would happen on release of
>     beta1, i.e. 2020-06-02.
> 
>     Matt
> 
> 
>     >
>     > On Tue, 7 Jan 2020, 14:13 Matt Caswell, <matt at openssl.org
>     <mailto:matt at openssl.org>
>     > <mailto:matt at openssl.org <mailto:matt at openssl.org>>> wrote:
>     >
>     >? ? ?Hi all
>     >
>     >? ? ?Myself, Paul, Shane, Richard and Nicola had a conf call today
>     to discuss
>     >? ? ?the outstanding tasks and effort required to get us to a final
>     release.
>     >
>     >? ? ?We've previously said this about that timeline:
>     >
>     >? ? ?"We are now not expecting code completion to occur until the
>     end of Q2
>     >? ? ?2020 with a final release in early Q4 2020."
>     >? ? ?(https://www.openssl.org/blog/blog/2019/11/07/3.0-update/)
>     >
>     >
>     >? ? ?With that in mind we came up with the following proposal for a
>     release
>     >? ? ?timetable which we think is a challenging but achievable timeline:
>     >
>     >? ? ?alpha1, 2020-03-31: Basic functionality plus basic FIPS module
>     >? ? ?alpha2, 2020-04-21: Complete external provider support
>     (serialization,
>     >? ? ?support for new algs, support for providers which only include
>     >? ? ?operations in a class)
>     >? ? ?alpha3, 2020-05-21: Almost there (aiming to test the API
>     completeness
>     >? ? ?before beta1 freezes it)
>     >? ? ?beta1, 2020-06-02: Code complete (API stable, feature freeze)
>     >? ? ?betaN: Other beta TBD
>     >? ? ?Final: 2020 early Q4
>     >
>     >? ? ?The idea here is to set some intermediate deadlines to focus
>     attention
>     >? ? ?on the final remaining tasks, with a series of 3 alphas prior
>     to the
>     >? ? ?first beta release where each alpha release comes
>     approximately every 3
>     >? ? ?weeks. We can have some flexibility to adjust this timetable
>     if we think
>     >? ? ?it is necessary (such as by including an additional alpha
>     release if
>     >? ? ?required).
>     >
>     >? ? ?Please let me know your thoughts. This would probably need to
>     go to an
>     >? ? ?OMC vote to get approved.
>     >
>     >? ? ?Matt
>     >
> 

From beldmit at gmail.com  Tue Jan  7 13:46:10 2020
From: beldmit at gmail.com (Dmitry Belyavsky)
Date: Tue, 7 Jan 2020 16:46:10 +0300
Subject: 3.0 release timeline proposal
In-Reply-To: <693b4771-6250-fd6c-3e94-326317543590@openssl.org>
References: <fe4f3315-f17e-2463-258d-9120a129dc2a@openssl.org>
 <CADqLbzKMsQSsQSmCGOk8v0iQdriM4qLfuPFJDhzn-hoe6kUvxw@mail.gmail.com>
 <a0ac883c-70bb-4146-886b-90f6489250d5@openssl.org>
 <CADqLbzKNn94FSMxJZpGuCk6KTv4o=cPD6vLf4DUntu3vmv8MQw@mail.gmail.com>
 <693b4771-6250-fd6c-3e94-326317543590@openssl.org>
Message-ID: <CADqLbz+=t_j5jQPeh3Ennppm-UspijHJC320670s=ztesLBDqQ@mail.gmail.com>

Sorry. My fault :(

On Tue, 7 Jan 2020, 16:35 Matt Caswell, <matt at openssl.org> wrote:

>
>
> On 07/01/2020 13:26, Dmitry Belyavsky wrote:
> > Many thanks!
> >
> > Got it, and I think this should be directly written.
>
> It was!!
>
> beta1, 2020-06-02: Code complete (API stable, feature freeze)
>
>
> Matt
>
>
> >
> > On Tue, 7 Jan 2020, 16:05 Matt Caswell, <matt at openssl.org
> > <mailto:matt at openssl.org>> wrote:
> >
> >
> >
> >     On 07/01/2020 13:00, Dmitry Belyavsky wrote:
> >     > When does the feature freeze happen?
> >     > I'm interested in publishing as much GOST support as possible.
> >
> >     According to my proposal feature freeze would happen on release of
> >     beta1, i.e. 2020-06-02.
> >
> >     Matt
> >
> >
> >     >
> >     > On Tue, 7 Jan 2020, 14:13 Matt Caswell, <matt at openssl.org
> >     <mailto:matt at openssl.org>
> >     > <mailto:matt at openssl.org <mailto:matt at openssl.org>>> wrote:
> >     >
> >     >     Hi all
> >     >
> >     >     Myself, Paul, Shane, Richard and Nicola had a conf call today
> >     to discuss
> >     >     the outstanding tasks and effort required to get us to a final
> >     release.
> >     >
> >     >     We've previously said this about that timeline:
> >     >
> >     >     "We are now not expecting code completion to occur until the
> >     end of Q2
> >     >     2020 with a final release in early Q4 2020."
> >     >     (https://www.openssl.org/blog/blog/2019/11/07/3.0-update/)
> >     >
> >     >
> >     >     With that in mind we came up with the following proposal for a
> >     release
> >     >     timetable which we think is a challenging but achievable
> timeline:
> >     >
> >     >     alpha1, 2020-03-31: Basic functionality plus basic FIPS module
> >     >     alpha2, 2020-04-21: Complete external provider support
> >     (serialization,
> >     >     support for new algs, support for providers which only include
> >     >     operations in a class)
> >     >     alpha3, 2020-05-21: Almost there (aiming to test the API
> >     completeness
> >     >     before beta1 freezes it)
> >     >     beta1, 2020-06-02: Code complete (API stable, feature freeze)
> >     >     betaN: Other beta TBD
> >     >     Final: 2020 early Q4
> >     >
> >     >     The idea here is to set some intermediate deadlines to focus
> >     attention
> >     >     on the final remaining tasks, with a series of 3 alphas prior
> >     to the
> >     >     first beta release where each alpha release comes
> >     approximately every 3
> >     >     weeks. We can have some flexibility to adjust this timetable
> >     if we think
> >     >     it is necessary (such as by including an additional alpha
> >     release if
> >     >     required).
> >     >
> >     >     Please let me know your thoughts. This would probably need to
> >     go to an
> >     >     OMC vote to get approved.
> >     >
> >     >     Matt
> >     >
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-project/attachments/20200107/f2501ee9/attachment.html>

From matt at openssl.org  Tue Jan  7 16:54:10 2020
From: matt at openssl.org (Matt Caswell)
Date: Tue, 7 Jan 2020 16:54:10 +0000
Subject: 3.0 release timeline proposal
In-Reply-To: <fe4f3315-f17e-2463-258d-9120a129dc2a@openssl.org>
References: <fe4f3315-f17e-2463-258d-9120a129dc2a@openssl.org>
Message-ID: <39a94b67-606c-98b5-18a5-a8ca9d55f4b6@openssl.org>

I converted this proposal into a PR to amend the release strategy.
Please see:

https://github.com/openssl/web/pull/154

Matt


On 07/01/2020 11:13, Matt Caswell wrote:
> Hi all
> 
> Myself, Paul, Shane, Richard and Nicola had a conf call today to discuss
> the outstanding tasks and effort required to get us to a final release.
> 
> We've previously said this about that timeline:
> 
> "We are now not expecting code completion to occur until the end of Q2
> 2020 with a final release in early Q4 2020."
> (https://www.openssl.org/blog/blog/2019/11/07/3.0-update/)
> 
> 
> With that in mind we came up with the following proposal for a release
> timetable which we think is a challenging but achievable timeline:
> 
> alpha1, 2020-03-31: Basic functionality plus basic FIPS module
> alpha2, 2020-04-21: Complete external provider support (serialization,
> support for new algs, support for providers which only include
> operations in a class)
> alpha3, 2020-05-21: Almost there (aiming to test the API completeness
> before beta1 freezes it)
> beta1, 2020-06-02: Code complete (API stable, feature freeze)
> betaN: Other beta TBD
> Final: 2020 early Q4
> 
> The idea here is to set some intermediate deadlines to focus attention
> on the final remaining tasks, with a series of 3 alphas prior to the
> first beta release where each alpha release comes approximately every 3
> weeks. We can have some flexibility to adjust this timetable if we think
> it is necessary (such as by including an additional alpha release if
> required).
> 
> Please let me know your thoughts. This would probably need to go to an
> OMC vote to get approved.
> 
> Matt
> 

From hendrik.brockhaus at siemens.com  Tue Jan  7 17:00:44 2020
From: hendrik.brockhaus at siemens.com (Brockhaus, Hendrik)
Date: Tue, 7 Jan 2020 17:00:44 +0000
Subject: AW: 3.0 release timeline proposal
Message-ID: <AM0PR10MB2402579C186FD3BF4E0CBCE7FE3F0@AM0PR10MB2402.EURPRD10.PROD.OUTLOOK.COM>

Hi Matt

Currently David and Andreas are contributing the mpeylo/cmpossl code. We want to get the complete CMP code upstream OpenSSL v3.0 as soon as possible.
Currently chunk 7 (https://github.com/openssl/openssl/pull/10620) is under review and chunk 8 is available as work-in-progress (https://github.com/mpeylo/cmpossl/pull/201).
Special thanks go to you, Bend and all others in the project for your continuous review effort and discussion!!

Regarding the release timeline I have two questions:
What is the deadline for the last chunk to be merged?
The planning and current status on the contribution is available on https://github.com/mpeylo/cmpossl/wiki. Do you see this timeline as realistic?

Hendrik

> ------------------------------
> 
> Date: Tue, 7 Jan 2020 11:13:21 +0000
> From: Matt Caswell <matt at openssl.org>
> To: "openssl-project at openssl.org" <openssl-project at openssl.org>
> Subject: 3.0 release timeline proposal
> Message-ID: <fe4f3315-f17e-2463-258d-9120a129dc2a at openssl.org>
> Content-Type: text/plain; charset=utf-8
> 
> Hi all
> 
> Myself, Paul, Shane, Richard and Nicola had a conf call today to discuss the
> outstanding tasks and effort required to get us to a final release.
> 
> We've previously said this about that timeline:
> 
> "We are now not expecting code completion to occur until the end of Q2
> 2020 with a final release in early Q4 2020."
> (https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ope
> nssl.org%2Fblog%2Fblog%2F2019%2F11%2F07%2F3.0-
> update%2F&amp;data=02%7C01%7Chendrik.brockhaus%40siemens.com%7C77
> e33a0111644f055dbc08d793753718%7C38ae3bcd95794fd4addab42e1495d55a
> %7C1%7C0%7C637140003954238503&amp;sdata=mkfVH1I2WaOwKwjqPamGZ
> N%2FTAdrmTuH3avswGCVZmhk%3D&amp;reserved=0)
> 
> 
> With that in mind we came up with the following proposal for a release
> timetable which we think is a challenging but achievable timeline:
> 
> alpha1, 2020-03-31: Basic functionality plus basic FIPS module alpha2, 2020-04-
> 21: Complete external provider support (serialization, support for new algs,
> support for providers which only include operations in a class) alpha3, 2020-05-
> 21: Almost there (aiming to test the API completeness before beta1 freezes it)
> beta1, 2020-06-02: Code complete (API stable, feature freeze)
> betaN: Other beta TBD
> Final: 2020 early Q4
> 
> The idea here is to set some intermediate deadlines to focus attention on the
> final remaining tasks, with a series of 3 alphas prior to the first beta release
> where each alpha release comes approximately every 3 weeks. We can have
> some flexibility to adjust this timetable if we think it is necessary (such as by
> including an additional alpha release if required).
> 
> Please let me know your thoughts. This would probably need to go to an OMC
> vote to get approved.
> 
> Matt

From matt at openssl.org  Tue Jan  7 23:43:37 2020
From: matt at openssl.org (Matt Caswell)
Date: Tue, 7 Jan 2020 23:43:37 +0000
Subject: AW: 3.0 release timeline proposal
In-Reply-To: <AM0PR10MB2402579C186FD3BF4E0CBCE7FE3F0@AM0PR10MB2402.EURPRD10.PROD.OUTLOOK.COM>
References: <AM0PR10MB2402579C186FD3BF4E0CBCE7FE3F0@AM0PR10MB2402.EURPRD10.PROD.OUTLOOK.COM>
Message-ID: <0950cd91-0cd1-4663-3095-223563dc9070@openssl.org>



On 07/01/2020 17:00, Brockhaus, Hendrik wrote:
> Hi Matt
> 
> Currently David and Andreas are contributing the mpeylo/cmpossl code. We want to get the complete CMP code upstream OpenSSL v3.0 as soon as possible.
> Currently chunk 7 (https://github.com/openssl/openssl/pull/10620) is under review and chunk 8 is available as work-in-progress (https://github.com/mpeylo/cmpossl/pull/201).
> Special thanks go to you, Bend and all others in the project for your continuous review effort and discussion!!
> 
> Regarding the release timeline I have two questions:
> What is the deadline for the last chunk to be merged?

If my proposed timeline is accepted then the final deadline would be the
beta1 release (2020-06-02). However it would be a good idea to target
one of the earlier alpha releases in order to gain the benefit of any
community feedback on the alpha releases that we might receive.


> The planning and current status on the contribution is available on https://github.com/mpeylo/cmpossl/wiki. Do you see this timeline as realistic?

It looks reasonable to me.

Matt



> 
> Hendrik
> 
>> ------------------------------
>>
>> Date: Tue, 7 Jan 2020 11:13:21 +0000
>> From: Matt Caswell <matt at openssl.org>
>> To: "openssl-project at openssl.org" <openssl-project at openssl.org>
>> Subject: 3.0 release timeline proposal
>> Message-ID: <fe4f3315-f17e-2463-258d-9120a129dc2a at openssl.org>
>> Content-Type: text/plain; charset=utf-8
>>
>> Hi all
>>
>> Myself, Paul, Shane, Richard and Nicola had a conf call today to discuss the
>> outstanding tasks and effort required to get us to a final release.
>>
>> We've previously said this about that timeline:
>>
>> "We are now not expecting code completion to occur until the end of Q2
>> 2020 with a final release in early Q4 2020."
>> (https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ope
>> nssl.org%2Fblog%2Fblog%2F2019%2F11%2F07%2F3.0-
>> update%2F&amp;data=02%7C01%7Chendrik.brockhaus%40siemens.com%7C77
>> e33a0111644f055dbc08d793753718%7C38ae3bcd95794fd4addab42e1495d55a
>> %7C1%7C0%7C637140003954238503&amp;sdata=mkfVH1I2WaOwKwjqPamGZ
>> N%2FTAdrmTuH3avswGCVZmhk%3D&amp;reserved=0)
>>
>>
>> With that in mind we came up with the following proposal for a release
>> timetable which we think is a challenging but achievable timeline:
>>
>> alpha1, 2020-03-31: Basic functionality plus basic FIPS module alpha2, 2020-04-
>> 21: Complete external provider support (serialization, support for new algs,
>> support for providers which only include operations in a class) alpha3, 2020-05-
>> 21: Almost there (aiming to test the API completeness before beta1 freezes it)
>> beta1, 2020-06-02: Code complete (API stable, feature freeze)
>> betaN: Other beta TBD
>> Final: 2020 early Q4
>>
>> The idea here is to set some intermediate deadlines to focus attention on the
>> final remaining tasks, with a series of 3 alphas prior to the first beta release
>> where each alpha release comes approximately every 3 weeks. We can have
>> some flexibility to adjust this timetable if we think it is necessary (such as by
>> including an additional alpha release if required).
>>
>> Please let me know your thoughts. This would probably need to go to an OMC
>> vote to get approved.
>>
>> Matt
> 

From kurt at roeckx.be  Wed Jan  8 20:30:12 2020
From: kurt at roeckx.be (Kurt Roeckx)
Date: Wed, 8 Jan 2020 21:30:12 +0100
Subject: Legacy Provider
In-Reply-To: <B47E7E33-DCD1-4271-A30C-59599F6CCBA6@oracle.com>
References: <B47E7E33-DCD1-4271-A30C-59599F6CCBA6@oracle.com>
Message-ID: <20200108203012.GA3252460@roeckx.be>

On Tue, Jan 07, 2020 at 09:57:55AM +1000, Dr Paul Dale wrote:
> The refactoring/FIPS work needs the question resolved about loading the legacy provider or not by default.  We?ve been through this before on the project list [1] and in at least one PR [2].
> 
> I expect that its resolution will require an OMC vote.

Why OMC and not OTC?



Kurt


From paul.dale at oracle.com  Wed Jan  8 21:49:29 2020
From: paul.dale at oracle.com (Dr Paul Dale)
Date: Thu, 9 Jan 2020 07:49:29 +1000
Subject: Legacy Provider
In-Reply-To: <20200108203012.GA3252460@roeckx.be>
References: <B47E7E33-DCD1-4271-A30C-59599F6CCBA6@oracle.com>
 <20200108203012.GA3252460@roeckx.be>
Message-ID: <F9B007F5-41AA-46FE-B7E6-A498FB14B848@oracle.com>

Kurt,

It?s a policy decision: should we cause pain for users (& Matt) or effectively delay the end for these old/broken algorithms.

Technically it is easy.


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




> On 9 Jan 2020, at 6:30 am, Kurt Roeckx <kurt at roeckx.be> wrote:
> 
> On Tue, Jan 07, 2020 at 09:57:55AM +1000, Dr Paul Dale wrote:
>> The refactoring/FIPS work needs the question resolved about loading the legacy provider or not by default.  We?ve been through this before on the project list [1] and in at least one PR [2].
>> 
>> I expect that its resolution will require an OMC vote.
> 
> Why OMC and not OTC?
> 
> 
> 
> Kurt
> 

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

From paul.dale at oracle.com  Tue Jan 14 11:34:40 2020
From: paul.dale at oracle.com (Dr Paul Dale)
Date: Tue, 14 Jan 2020 21:34:40 +1000
Subject: Legacy provider
Message-ID: <A4B11C4E-C07A-405A-A089-565F059FD095@oracle.com>

The OMC vote is closed.

The vote text being:

The legacy provider should be disabled by default in 3.0

With the clarification that "disabled" in this context means "not loaded?.

The vote passed (two for, one against, four abstain)


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/20200114/3621a9e6/attachment.html>

From matt at openssl.org  Wed Jan 15 09:12:04 2020
From: matt at openssl.org (Matt Caswell)
Date: Wed, 15 Jan 2020 09:12:04 +0000
Subject: 3.0 release timeline proposal
In-Reply-To: <39a94b67-606c-98b5-18a5-a8ca9d55f4b6@openssl.org>
References: <fe4f3315-f17e-2463-258d-9120a129dc2a@openssl.org>
 <39a94b67-606c-98b5-18a5-a8ca9d55f4b6@openssl.org>
Message-ID: <d106aeb5-9938-d74a-46d7-f386e3e71453@openssl.org>

Not much feedback, so I'm assuming everyone is ok with this proposal.

I'm going to start a vote soon with this wording:

"Update the release strategy to the text shown here:
https://github.com/openssl/web/pull/154/commits/959153c7e62865beae9f24364f1c971b149f477a"



Matt




On 07/01/2020 16:54, Matt Caswell wrote:
> I converted this proposal into a PR to amend the release strategy.
> Please see:
> 
> https://github.com/openssl/web/pull/154
> 
> Matt
> 
> 
> On 07/01/2020 11:13, Matt Caswell wrote:
>> Hi all
>>
>> Myself, Paul, Shane, Richard and Nicola had a conf call today to discuss
>> the outstanding tasks and effort required to get us to a final release.
>>
>> We've previously said this about that timeline:
>>
>> "We are now not expecting code completion to occur until the end of Q2
>> 2020 with a final release in early Q4 2020."
>> (https://www.openssl.org/blog/blog/2019/11/07/3.0-update/)
>>
>>
>> With that in mind we came up with the following proposal for a release
>> timetable which we think is a challenging but achievable timeline:
>>
>> alpha1, 2020-03-31: Basic functionality plus basic FIPS module
>> alpha2, 2020-04-21: Complete external provider support (serialization,
>> support for new algs, support for providers which only include
>> operations in a class)
>> alpha3, 2020-05-21: Almost there (aiming to test the API completeness
>> before beta1 freezes it)
>> beta1, 2020-06-02: Code complete (API stable, feature freeze)
>> betaN: Other beta TBD
>> Final: 2020 early Q4
>>
>> The idea here is to set some intermediate deadlines to focus attention
>> on the final remaining tasks, with a series of 3 alphas prior to the
>> first beta release where each alpha release comes approximately every 3
>> weeks. We can have some flexibility to adjust this timetable if we think
>> it is necessary (such as by including an additional alpha release if
>> required).
>>
>> Please let me know your thoughts. This would probably need to go to an
>> OMC vote to get approved.
>>
>> Matt
>>

From kaduk at mit.edu  Wed Jan 15 20:07:54 2020
From: kaduk at mit.edu (Benjamin Kaduk)
Date: Wed, 15 Jan 2020 12:07:54 -0800
Subject: Legacy provider
In-Reply-To: <A4B11C4E-C07A-405A-A089-565F059FD095@oracle.com>
References: <A4B11C4E-C07A-405A-A089-565F059FD095@oracle.com>
Message-ID: <20200115200754.GN30105@kduck.mit.edu>

Hi Pauli,

On Tue, Jan 14, 2020 at 09:34:40PM +1000, Dr Paul Dale wrote:
> The OMC vote is closed.
> 
> The vote text being:
> 
> The legacy provider should be disabled by default in 3.0
> 
> With the clarification that "disabled" in this context means "not loaded?.
> 
> The vote passed (two for, one against, four abstain)

It's good to have a decision here, but I'm kind of worried about the four
abstains -- it's easy for me to leap to a conclusion that the individuals
in question just didn't want to to spend the time to come to a considered
position, even though this issue has substantial potential impact for our
userbase.  I'm trying to not make faulty assumptions, so some greater
clarity on the circumstances would be helpful, if possible.

Thanks,

Ben

From paul.dale at oracle.com  Wed Jan 15 20:57:49 2020
From: paul.dale at oracle.com (Dr Paul Dale)
Date: Thu, 16 Jan 2020 06:57:49 +1000
Subject: Legacy provider
In-Reply-To: <20200115200754.GN30105@kduck.mit.edu>
References: <A4B11C4E-C07A-405A-A089-565F059FD095@oracle.com>
 <20200115200754.GN30105@kduck.mit.edu>
Message-ID: <3316B6C9-5CA7-48DE-9E88-45081953A4FF@oracle.com>

I?m not sure what more I can write.

I proposed the vote text around the time I sent the notification here: no comments.
I created the vote, early in the voting period, the clarification was sought and made.
All OMC members registered their vote and the vote closed early.

The criteria for being valid as per the bylaws <https://www.openssl.org/policies/omc-bylaws.html> was met.  As votes go, this one was quick taking two days of the two weeks.

Abstentions are frequent in votes for a number of reasons.
The reasons each person uses are not revealed and not asked for.


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




> On 16 Jan 2020, at 6:07 am, Benjamin Kaduk <kaduk at mit.edu> wrote:
> 
> Hi Pauli,
> 
> On Tue, Jan 14, 2020 at 09:34:40PM +1000, Dr Paul Dale wrote:
>> The OMC vote is closed.
>> 
>> The vote text being:
>> 
>> The legacy provider should be disabled by default in 3.0
>> 
>> With the clarification that "disabled" in this context means "not loaded?.
>> 
>> The vote passed (two for, one against, four abstain)
> 
> It's good to have a decision here, but I'm kind of worried about the four
> abstains -- it's easy for me to leap to a conclusion that the individuals
> in question just didn't want to to spend the time to come to a considered
> position, even though this issue has substantial potential impact for our
> userbase.  I'm trying to not make faulty assumptions, so some greater
> clarity on the circumstances would be helpful, if possible.
> 
> Thanks,
> 
> Ben

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

From kaduk at mit.edu  Wed Jan 15 21:01:29 2020
From: kaduk at mit.edu (Benjamin Kaduk)
Date: Wed, 15 Jan 2020 13:01:29 -0800
Subject: Legacy provider
In-Reply-To: <3316B6C9-5CA7-48DE-9E88-45081953A4FF@oracle.com>
References: <A4B11C4E-C07A-405A-A089-565F059FD095@oracle.com>
 <20200115200754.GN30105@kduck.mit.edu>
 <3316B6C9-5CA7-48DE-9E88-45081953A4FF@oracle.com>
Message-ID: <20200115210129.GS30105@kduck.mit.edu>

On Thu, Jan 16, 2020 at 06:57:49AM +1000, Dr Paul Dale wrote:
> I?m not sure what more I can write.
> 
> I proposed the vote text around the time I sent the notification here: no comments.
> I created the vote, early in the voting period, the clarification was sought and made.
> All OMC members registered their vote and the vote closed early.
> 
> The criteria for being valid as per the bylaws <https://www.openssl.org/policies/omc-bylaws.html> was met.  As votes go, this one was quick taking two days of the two weeks.
> 
> Abstentions are frequent in votes for a number of reasons.
> The reasons each person uses are not revealed and not asked for.

Thank you for the quick response; I understand there's not anything more to
be said.

-Ben

From openssl-users at dukhovni.org  Wed Jan 15 21:41:05 2020
From: openssl-users at dukhovni.org (Viktor Dukhovni)
Date: Wed, 15 Jan 2020 16:41:05 -0500
Subject: Legacy provider
In-Reply-To: <20200115200754.GN30105@kduck.mit.edu>
References: <A4B11C4E-C07A-405A-A089-565F059FD095@oracle.com>
 <20200115200754.GN30105@kduck.mit.edu>
Message-ID: <F9A32ABC-EA97-4AEC-A050-054E75A409D0@dukhovni.org>

My abstain vote was a carefully considered neutral stance backed
by many paragraphs of rationale.

The gist of which is that given that the decision to load or not
the provider is in the configuration file, the party ultimately
making the decision is whoever packages the software, not the
OpenSSL project.  OS distributions and users will make their own
choices, as they build packages and deploy systems.

Our "default" choice is just a "suggestion".  So the real change
is providing a mechanism to make the choice, the specific choice
we default to is IMHO not that important, and signalling that
the legacy algorithms are best left disabled when possible is
a reasonable outcome.  But, on the other hand we also want to
largely remain compatible with 3.0, and make compile and deploy
easy.  So there is some reason to take the compatible default.

I had the advantage of voting last, knowing that my abstain would
allow the vote to pass...

> On Jan 15, 2020, at 3:07 PM, Benjamin Kaduk <kaduk at mit.edu> wrote:
> 
> It's good to have a decision here, but I'm kind of worried about the four
> abstains -- it's easy for me to leap to a conclusion that the individuals
> in question just didn't want to to spend the time to come to a considered
> position, even though this issue has substantial potential impact for our
> userbase.  I'm trying to not make faulty assumptions, so some greater
> clarity on the circumstances would be helpful, if possible.

-- 
	Viktor.


From levitte at openssl.org  Wed Jan 15 21:56:48 2020
From: levitte at openssl.org (Richard Levitte)
Date: Wed, 15 Jan 2020 22:56:48 +0100
Subject: Legacy provider
In-Reply-To: <20200115200754.GN30105@kduck.mit.edu>
References: <A4B11C4E-C07A-405A-A089-565F059FD095@oracle.com>
 <20200115200754.GN30105@kduck.mit.edu>
Message-ID: <87zheoidsv.wl-levitte@openssl.org>

On Wed, 15 Jan 2020 21:07:54 +0100,
Benjamin Kaduk wrote:
> 
> Hi Pauli,
> 
> On Tue, Jan 14, 2020 at 09:34:40PM +1000, Dr Paul Dale wrote:
> > The OMC vote is closed.
> > 
> > The vote text being:
> > 
> > The legacy provider should be disabled by default in 3.0
> > 
> > With the clarification that "disabled" in this context means "not loaded?.
> > 
> > The vote passed (two for, one against, four abstain)
> 
> It's good to have a decision here, but I'm kind of worried about the four
> abstains -- it's easy for me to leap to a conclusion that the individuals
> in question just didn't want to to spend the time to come to a considered
> position, even though this issue has substantial potential impact for our
> userbase.  I'm trying to not make faulty assumptions, so some greater
> clarity on the circumstances would be helpful, if possible.

This was a vote that I found extremely difficult.  This topic has been
disputed on and off for quite a while, both on github and within the
OMC, and I could never decide between the two sides.  Both have pros
and cons that outweigh each other.

Cheers,
Richard

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

From matt at openssl.org  Thu Jan 16 10:39:45 2020
From: matt at openssl.org (Matt Caswell)
Date: Thu, 16 Jan 2020 10:39:45 +0000
Subject: 3.0 release timeline proposal
In-Reply-To: <d106aeb5-9938-d74a-46d7-f386e3e71453@openssl.org>
References: <fe4f3315-f17e-2463-258d-9120a129dc2a@openssl.org>
 <39a94b67-606c-98b5-18a5-a8ca9d55f4b6@openssl.org>
 <d106aeb5-9938-d74a-46d7-f386e3e71453@openssl.org>
Message-ID: <4679b4f7-1358-3512-c8e5-93c787f3e3df@openssl.org>

This vote has started. I'll report back when we have an answer.

Matt

On 15/01/2020 09:12, Matt Caswell wrote:
> Not much feedback, so I'm assuming everyone is ok with this proposal.
> 
> I'm going to start a vote soon with this wording:
> 
> "Update the release strategy to the text shown here:
> https://github.com/openssl/web/pull/154/commits/959153c7e62865beae9f24364f1c971b149f477a"
> 
> 
> 
> Matt
> 
> 
> 
> 
> On 07/01/2020 16:54, Matt Caswell wrote:
>> I converted this proposal into a PR to amend the release strategy.
>> Please see:
>>
>> https://github.com/openssl/web/pull/154
>>
>> Matt
>>
>>
>> On 07/01/2020 11:13, Matt Caswell wrote:
>>> Hi all
>>>
>>> Myself, Paul, Shane, Richard and Nicola had a conf call today to discuss
>>> the outstanding tasks and effort required to get us to a final release.
>>>
>>> We've previously said this about that timeline:
>>>
>>> "We are now not expecting code completion to occur until the end of Q2
>>> 2020 with a final release in early Q4 2020."
>>> (https://www.openssl.org/blog/blog/2019/11/07/3.0-update/)
>>>
>>>
>>> With that in mind we came up with the following proposal for a release
>>> timetable which we think is a challenging but achievable timeline:
>>>
>>> alpha1, 2020-03-31: Basic functionality plus basic FIPS module
>>> alpha2, 2020-04-21: Complete external provider support (serialization,
>>> support for new algs, support for providers which only include
>>> operations in a class)
>>> alpha3, 2020-05-21: Almost there (aiming to test the API completeness
>>> before beta1 freezes it)
>>> beta1, 2020-06-02: Code complete (API stable, feature freeze)
>>> betaN: Other beta TBD
>>> Final: 2020 early Q4
>>>
>>> The idea here is to set some intermediate deadlines to focus attention
>>> on the final remaining tasks, with a series of 3 alphas prior to the
>>> first beta release where each alpha release comes approximately every 3
>>> weeks. We can have some flexibility to adjust this timetable if we think
>>> it is necessary (such as by including an additional alpha release if
>>> required).
>>>
>>> Please let me know your thoughts. This would probably need to go to an
>>> OMC vote to get approved.
>>>
>>> Matt
>>>

From paul.dale at oracle.com  Fri Jan 17 06:31:06 2020
From: paul.dale at oracle.com (Dr Paul Dale)
Date: Fri, 17 Jan 2020 16:31:06 +1000
Subject: crypt(3)
Message-ID: <2AB95A2B-ED92-4837-90EF-9C9143B33758@oracle.com>

In the deprecation efforts for 3.0, I?ve hit something in the DES code that I?d appreciate input on.

There are two functions (DES_crypt and DES_fcrypt) which implement the old crypt(3) password algorithm.  Once these are deprecated, they will no longer be reachable via EVP.  The confounding point is that they aren?t quite DES ? close but not identical.  I would be surprised if they aren?t still in use for /etc/passwd files on old and/or embedded systems.

I?ve got several choices:
Leave them public and unchanged ? that is, don?t deprecate these two functions yet.
Deprecate them and add KDFs to replace them.
Deprecate them, leave them alone and hope they go away painlessly at some point.

The apps/password.c applet calls these which is how I stumbled over the complication.  I?m fine refactoring this based on the solution chosen.  I?d also be okay with factoring out all the password derivation functions into KDFs if necessary.


Thoughts?  Other alternatives?


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/20200117/dcfb11c2/attachment.html>

From beldmit at gmail.com  Fri Jan 17 07:28:03 2020
From: beldmit at gmail.com (Dmitry Belyavsky)
Date: Fri, 17 Jan 2020 10:28:03 +0300
Subject: crypt(3)
In-Reply-To: <2AB95A2B-ED92-4837-90EF-9C9143B33758@oracle.com>
References: <2AB95A2B-ED92-4837-90EF-9C9143B33758@oracle.com>
Message-ID: <CADqLbz+NPcTAitu9+mXkztbiqOOU3cuK+8xiJE5yOd2EZAsQuA@mail.gmail.com>

Dear Paul,

The KDF variant seems the best one.

On Fri, Jan 17, 2020 at 9:33 AM Dr Paul Dale <paul.dale at oracle.com> wrote:

> In the deprecation efforts for 3.0, I?ve hit something in the DES code
> that I?d appreciate input on.
>
> There are two functions (DES_crypt and DES_fcrypt) which implement the old
> crypt(3) password algorithm.  Once these are deprecated, they will no
> longer be reachable via EVP.  The confounding point is that they aren?t
> quite DES ? close but not identical.  I would be surprised if they aren?t
> still in use for /etc/passwd files on old and/or embedded systems.
>
> I?ve got several choices:
>
>    1. Leave them public and unchanged ? that is, don?t deprecate these
>    two functions yet.
>    2. Deprecate them and add KDFs to replace them.
>    3. Deprecate them, leave them alone and hope they go away painlessly
>    at some point.
>
>
> The apps/password.c applet calls these which is how I stumbled over the
> complication.  I?m fine refactoring this based on the solution chosen.  I?d
> also be okay with factoring out all the password derivation functions into
> KDFs if necessary.
>
>
> Thoughts?  Other alternatives?
>
>
> Pauli
> --
> Dr Paul Dale | Distinguished Architect | Cryptographic Foundations
> Phone +61 7 3031 7217
> Oracle Australia
>
>

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

From openssl-users at dukhovni.org  Fri Jan 17 07:41:01 2020
From: openssl-users at dukhovni.org (Viktor Dukhovni)
Date: Fri, 17 Jan 2020 02:41:01 -0500
Subject: crypt(3)
In-Reply-To: <2AB95A2B-ED92-4837-90EF-9C9143B33758@oracle.com>
References: <2AB95A2B-ED92-4837-90EF-9C9143B33758@oracle.com>
Message-ID: <20200117074101.GQ73491@straasha.imrryr.org>

On Fri, Jan 17, 2020 at 04:31:06PM +1000, Dr Paul Dale wrote:

> There are two functions (DES_crypt and DES_fcrypt) which implement the
> old crypt(3) password algorithm.  Once these are deprecated, they will
> no longer be reachable via EVP.  The confounding point is that they
> aren?t quite DES ? close but not identical.  I would be surprised if
> they aren?t still in use for /etc/passwd files on old and/or embedded
> systems.

Generally speaking, on Unix-like systems that use crypt(3) for
/etc/passwd I'd expect to find a standaline crypt() implementation in
libc, that is independent of OpenSSL.  That is, if your system still
uses crypt() for passwords, you don't need OpenSSL to compute crypt
hashes.

That said, this is experience from general-purpose computers running
Unix-like OSes, not embedded systems, where I have no idea whether
crypt() is popular, and whether it is provided by a port of libcrypto
to that platform.

> I?ve got several choices: Leave them public and unchanged ? that is,
> don?t deprecate these two functions yet.  Deprecate them and add KDFs
> to replace them.  Deprecate them, leave them alone and hope they go
> away painlessly at some point.

I would not expect to find many users of OpenSSL's crypt(), except
internally within OpenSSL itself.

> The apps/password.c applet calls these which is how I stumbled over
> the complication.  I?m fine refactoring this based on the solution
> chosen.  I?d also be okay with factoring out all the password
> derivation functions into KDFs if necessary.
> 
> Thoughts?  Other alternatives?

I don't know enough about embedded systems to speak about what if
anything we need to do for those with respect to crypt().

-- 
    Viktor.

From paul.dale at oracle.com  Fri Jan 17 08:19:40 2020
From: paul.dale at oracle.com (Dr Paul Dale)
Date: Fri, 17 Jan 2020 18:19:40 +1000
Subject: crypt(3)
In-Reply-To: <20200117074101.GQ73491@straasha.imrryr.org>
References: <2AB95A2B-ED92-4837-90EF-9C9143B33758@oracle.com>
 <20200117074101.GQ73491@straasha.imrryr.org>
Message-ID: <B7262C92-B1B2-4632-A178-F32A1261C407@oracle.com>

My experience with embedded systems is that crypt(3) is in the standard library and not accessed via OpenSSL.  Apps/password uses DES_crypt() and password crackers used to use OpenSSL for performance reasons.  Neither seems like a huge deal.  I.e. I can?t think of a good reason to keep them.

Removing these calls will require an OMC vote as a breaking API change.  I?m fine to call one if it seems justified.


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




> On 17 Jan 2020, at 5:41 pm, Viktor Dukhovni <openssl-users at dukhovni.org> wrote:
> 
> On Fri, Jan 17, 2020 at 04:31:06PM +1000, Dr Paul Dale wrote:
> 
>> There are two functions (DES_crypt and DES_fcrypt) which implement the
>> old crypt(3) password algorithm.  Once these are deprecated, they will
>> no longer be reachable via EVP.  The confounding point is that they
>> aren?t quite DES ? close but not identical.  I would be surprised if
>> they aren?t still in use for /etc/passwd files on old and/or embedded
>> systems.
> 
> Generally speaking, on Unix-like systems that use crypt(3) for
> /etc/passwd I'd expect to find a standaline crypt() implementation in
> libc, that is independent of OpenSSL.  That is, if your system still
> uses crypt() for passwords, you don't need OpenSSL to compute crypt
> hashes.
> 
> That said, this is experience from general-purpose computers running
> Unix-like OSes, not embedded systems, where I have no idea whether
> crypt() is popular, and whether it is provided by a port of libcrypto
> to that platform.
> 
>> I?ve got several choices: Leave them public and unchanged ? that is,
>> don?t deprecate these two functions yet.  Deprecate them and add KDFs
>> to replace them.  Deprecate them, leave them alone and hope they go
>> away painlessly at some point.
> 
> I would not expect to find many users of OpenSSL's crypt(), except
> internally within OpenSSL itself.
> 
>> The apps/password.c applet calls these which is how I stumbled over
>> the complication.  I?m fine refactoring this based on the solution
>> chosen.  I?d also be okay with factoring out all the password
>> derivation functions into KDFs if necessary.
>> 
>> Thoughts?  Other alternatives?
> 
> I don't know enough about embedded systems to speak about what if
> anything we need to do for those with respect to crypt().
> 
> -- 
>    Viktor.

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

From levitte at openssl.org  Fri Jan 17 09:21:48 2020
From: levitte at openssl.org (Richard Levitte)
Date: Fri, 17 Jan 2020 10:21:48 +0100
Subject: crypt(3)
In-Reply-To: <B7262C92-B1B2-4632-A178-F32A1261C407@oracle.com>
References: <2AB95A2B-ED92-4837-90EF-9C9143B33758@oracle.com>
 <20200117074101.GQ73491@straasha.imrryr.org>
 <B7262C92-B1B2-4632-A178-F32A1261C407@oracle.com>
Message-ID: <87tv4uigk3.wl-levitte@openssl.org>

I don't really see a reason to actually *remove* them.  Deprecation
should suffice.

Cheers,
Richard

On Fri, 17 Jan 2020 09:19:40 +0100,
Dr Paul Dale wrote:
> 
> 
> My experience with embedded systems is that crypt(3) is in the standard library and not accessed
> via OpenSSL.  Apps/password uses DES_crypt() and password crackers used to use OpenSSL for
> performance reasons.  Neither seems like a huge deal.  I.e. I can?t think of a good reason to keep
> them.
> 
> Removing these calls will require an OMC vote as a breaking API change.  I?m fine to call one if
> it seems justified.
> 
> Pauli
> -- 
> Dr Paul Dale | Distinguished Architect | Cryptographic Foundations 
> Phone +61 7 3031 7217
> Oracle Australia
> 
>     On 17 Jan 2020, at 5:41 pm, Viktor Dukhovni <openssl-users at dukhovni.org> wrote:
>    
>     On Fri, Jan 17, 2020 at 04:31:06PM +1000, Dr Paul Dale wrote:
> 
>         There are two functions (DES_crypt and DES_fcrypt) which implement the
>         old crypt(3) password algorithm.  Once these are deprecated, they will
>         no longer be reachable via EVP.  The confounding point is that they
>         aren?t quite DES ? close but not identical.  I would be surprised if
>         they aren?t still in use for /etc/passwd files on old and/or embedded
>         systems.
> 
>     Generally speaking, on Unix-like systems that use crypt(3) for
>     /etc/passwd I'd expect to find a standaline crypt() implementation in
>     libc, that is independent of OpenSSL.  That is, if your system still
>     uses crypt() for passwords, you don't need OpenSSL to compute crypt
>     hashes.
>    
>     That said, this is experience from general-purpose computers running
>     Unix-like OSes, not embedded systems, where I have no idea whether
>     crypt() is popular, and whether it is provided by a port of libcrypto
>     to that platform.
> 
>         I?ve got several choices: Leave them public and unchanged ? that is,
>         don?t deprecate these two functions yet.  Deprecate them and add KDFs
>         to replace them.  Deprecate them, leave them alone and hope they go
>         away painlessly at some point.
> 
>     I would not expect to find many users of OpenSSL's crypt(), except
>     internally within OpenSSL itself.
> 
>         The apps/password.c applet calls these which is how I stumbled over
>         the complication.  I?m fine refactoring this based on the solution
>         chosen.  I?d also be okay with factoring out all the password
>         derivation functions into KDFs if necessary.
>        
>         Thoughts?  Other alternatives?
> 
>     I don't know enough about embedded systems to speak about what if
>     anything we need to do for those with respect to crypt().
>    
>     --
>        Viktor.
> 
> 
-- 
Richard Levitte         levitte at openssl.org
OpenSSL Project         http://www.openssl.org/~levitte/

From tmraz at redhat.com  Fri Jan 17 09:22:42 2020
From: tmraz at redhat.com (Tomas Mraz)
Date: Fri, 17 Jan 2020 10:22:42 +0100
Subject: crypt(3)
In-Reply-To: <2AB95A2B-ED92-4837-90EF-9C9143B33758@oracle.com>
References: <2AB95A2B-ED92-4837-90EF-9C9143B33758@oracle.com>
Message-ID: <af6231859c6e1ea177dc1bf2a73addbee8b7cabb.camel@redhat.com>

On Fri, 2020-01-17 at 16:31 +1000, Dr Paul Dale wrote:
> In the deprecation efforts for 3.0, I?ve hit something in the DES
> code that I?d appreciate input on.
> 
> There are two functions (DES_crypt and DES_fcrypt) which implement
> the old crypt(3) password algorithm.  Once these are deprecated, they
> will no longer be reachable via EVP.  The confounding point is that
> they aren?t quite DES ? close but not identical.  I would be
> surprised if they aren?t still in use for /etc/passwd files on old
> and/or embedded systems.
> 
> I?ve got several choices:
> Leave them public and unchanged ? that is, don?t deprecate these two
> functions yet.
> Deprecate them and add KDFs to replace them.
> Deprecate them, leave them alone and hope they go away painlessly at
> some point.

As deprecation is NOT a removal and the removal is at least 5 years in
future I think the third option is clearly OK. We could argue about any
other functionality that we deprecate the same way and we would not be
able to deprecate anything.

When we get in time to the point of removal of the functionality
deprecated in 3.0 we might even decide to selectively postpone the
removal of this particular thing although I do not think that would be
necessary. Use of these calls should be really abandoned anyway as the
old crypt() algorithm is totally weak anyway.

-- 
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  Fri Jan 17 10:34:24 2020
From: matt at openssl.org (Matt Caswell)
Date: Fri, 17 Jan 2020 10:34:24 +0000
Subject: crypt(3)
In-Reply-To: <2AB95A2B-ED92-4837-90EF-9C9143B33758@oracle.com>
References: <2AB95A2B-ED92-4837-90EF-9C9143B33758@oracle.com>
Message-ID: <e62c1094-d26d-7045-47e3-93aa48d740ed@openssl.org>



On 17/01/2020 06:31, Dr Paul Dale wrote:
>  1. Leave them public and unchanged ? that is, don?t deprecate these two
>     functions yet.
>  2. Deprecate them and add KDFs to replace them.
>  3. Deprecate them, leave them alone and hope they go away painlessly at
>     some point.

2 is really just and extension of 3 - either way we deprecate them. In 2
we additionally provide a replacement.

I definitely think they *should* be deprecated.

Any replacement would necessarily go in the "legacy" provider I think.
If a replacement is not difficult I would favour that. But I could live
with (2).

Matt

From tmraz at redhat.com  Fri Jan 17 10:42:02 2020
From: tmraz at redhat.com (Tomas Mraz)
Date: Fri, 17 Jan 2020 11:42:02 +0100
Subject: crypt(3)
In-Reply-To: <e62c1094-d26d-7045-47e3-93aa48d740ed@openssl.org>
References: <2AB95A2B-ED92-4837-90EF-9C9143B33758@oracle.com>
 <e62c1094-d26d-7045-47e3-93aa48d740ed@openssl.org>
Message-ID: <4a8a048c2e28cc8c63aaaa1f62decfe07d029b9d.camel@redhat.com>

On Fri, 2020-01-17 at 10:34 +0000, Matt Caswell wrote:
> 
> On 17/01/2020 06:31, Dr Paul Dale wrote:
> >  1. Leave them public and unchanged ? that is, don?t deprecate
> > these two
> >     functions yet.
> >  2. Deprecate them and add KDFs to replace them.
> >  3. Deprecate them, leave them alone and hope they go away
> > painlessly at
> >     some point.
> 
> 2 is really just and extension of 3 - either way we deprecate them.
> In 2
> we additionally provide a replacement.
> 
> I definitely think they *should* be deprecated.
> 
> Any replacement would necessarily go in the "legacy" provider I
> think.
> If a replacement is not difficult I would favour that. But I could
> live
> with (2).

Did you mean (3) here actually?

-- 
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  Fri Jan 17 10:48:46 2020
From: matt at openssl.org (Matt Caswell)
Date: Fri, 17 Jan 2020 10:48:46 +0000
Subject: crypt(3)
In-Reply-To: <4a8a048c2e28cc8c63aaaa1f62decfe07d029b9d.camel@redhat.com>
References: <2AB95A2B-ED92-4837-90EF-9C9143B33758@oracle.com>
 <e62c1094-d26d-7045-47e3-93aa48d740ed@openssl.org>
 <4a8a048c2e28cc8c63aaaa1f62decfe07d029b9d.camel@redhat.com>
Message-ID: <b20af6ce-7a51-f622-a0f5-f4dea426ee30@openssl.org>



On 17/01/2020 10:42, Tomas Mraz wrote:
> On Fri, 2020-01-17 at 10:34 +0000, Matt Caswell wrote:
>>
>> On 17/01/2020 06:31, Dr Paul Dale wrote:
>>>  1. Leave them public and unchanged ? that is, don?t deprecate
>>> these two
>>>     functions yet.
>>>  2. Deprecate them and add KDFs to replace them.
>>>  3. Deprecate them, leave them alone and hope they go away
>>> painlessly at
>>>     some point.
>>
>> 2 is really just and extension of 3 - either way we deprecate them.
>> In 2
>> we additionally provide a replacement.
>>
>> I definitely think they *should* be deprecated.
>>
>> Any replacement would necessarily go in the "legacy" provider I
>> think.
>> If a replacement is not difficult I would favour that. But I could
>> live
>> with (2).
> 
> Did you mean (3) here actually?
> 

Sorry - yes - that's what I meant!

I would prefer us to deprecate and add a replacement (option 2). But I
could live with just deprecating (option 3).

Matt

From kurt at roeckx.be  Fri Jan 17 20:35:00 2020
From: kurt at roeckx.be (Kurt Roeckx)
Date: Fri, 17 Jan 2020 21:35:00 +0100
Subject: crypt(3)
In-Reply-To: <2AB95A2B-ED92-4837-90EF-9C9143B33758@oracle.com>
References: <2AB95A2B-ED92-4837-90EF-9C9143B33758@oracle.com>
Message-ID: <20200117203500.GA743205@roeckx.be>

On Fri, Jan 17, 2020 at 04:31:06PM +1000, Dr Paul Dale wrote:
> I?ve got several choices:
> Leave them public and unchanged ? that is, don?t deprecate these two functions yet.
> Deprecate them and add KDFs to replace them.
> Deprecate them, leave them alone and hope they go away painlessly at some point.

I really see no point in adding something that we at the same time
would like to remove. Just deprecate it.


Kurt


From levitte at openssl.org  Fri Jan 17 20:53:42 2020
From: levitte at openssl.org (Richard Levitte)
Date: Fri, 17 Jan 2020 21:53:42 +0100
Subject: crypt(3)
In-Reply-To: <20200117203500.GA743205@roeckx.be>
References: <2AB95A2B-ED92-4837-90EF-9C9143B33758@oracle.com>
 <20200117203500.GA743205@roeckx.be>
Message-ID: <744C5FBB-4F3B-4DFF-9A74-4A419C1A749E@openssl.org>

Right. Such a KDF could be implemented elsewhere, as a separate project.

Cheers
Richard


Kurt Roeckx <kurt at roeckx.be> skrev: (17 januari 2020 21:35:00 CET)
>On Fri, Jan 17, 2020 at 04:31:06PM +1000, Dr Paul Dale wrote:
>> I?ve got several choices:
>> Leave them public and unchanged ? that is, don?t deprecate these two
>functions yet.
>> Deprecate them and add KDFs to replace them.
>> Deprecate them, leave them alone and hope they go away painlessly at
>some point.
>
>I really see no point in adding something that we at the same time
>would like to remove. Just deprecate it.
>
>
>Kurt

-- 
Richard by mobile

From paul.dale at oracle.com  Fri Jan 17 23:27:03 2020
From: paul.dale at oracle.com (Dr Paul Dale)
Date: Sat, 18 Jan 2020 09:27:03 +1000
Subject: crypt(3)
In-Reply-To: <744C5FBB-4F3B-4DFF-9A74-4A419C1A749E@openssl.org>
References: <2AB95A2B-ED92-4837-90EF-9C9143B33758@oracle.com>
 <20200117203500.GA743205@roeckx.be>
 <744C5FBB-4F3B-4DFF-9A74-4A419C1A749E@openssl.org>
Message-ID: <D9730742-12B5-49A7-BBD0-70DBD96D2959@oracle.com>

Okay, it looks like the consensus is option 3 ? deprecate and forget.

As far as I can tell, they are only used (by us) in one place outside of libcrypto, so that will deprecate as well.


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




> On 18 Jan 2020, at 6:53 am, Richard Levitte <levitte at openssl.org> wrote:
> 
> Right. Such a KDF could be implemented elsewhere, as a separate project.
> 
> Cheers
> Richard
> 
> 
> Kurt Roeckx <kurt at roeckx.be> skrev: (17 januari 2020 21:35:00 CET)
>> On Fri, Jan 17, 2020 at 04:31:06PM +1000, Dr Paul Dale wrote:
>>> I?ve got several choices:
>>> Leave them public and unchanged ? that is, don?t deprecate these two
>> functions yet.
>>> Deprecate them and add KDFs to replace them.
>>> Deprecate them, leave them alone and hope they go away painlessly at
>> some point.
>> 
>> I really see no point in adding something that we at the same time
>> would like to remove. Just deprecate it.
>> 
>> 
>> Kurt
> 
> -- 
> Richard by mobile

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

From paul.dale at oracle.com  Sat Jan 18 00:47:04 2020
From: paul.dale at oracle.com (Dr Paul Dale)
Date: Sat, 18 Jan 2020 10:47:04 +1000
Subject: crypt(3)
In-Reply-To: <08128F55-F641-43C6-9E8C-49F034954023@oracle.com>
References: <2AB95A2B-ED92-4837-90EF-9C9143B33758@oracle.com>
 <20200117203500.GA743205@roeckx.be>
 <744C5FBB-4F3B-4DFF-9A74-4A419C1A749E@openssl.org>
 <D9730742-12B5-49A7-BBD0-70DBD96D2959@oracle.com>
 <08128F55-F641-43C6-9E8C-49F034954023@oracle.com>
Message-ID: <EFE2FD86-04D4-49FC-9217-B9128A89D57A@oracle.com>

Could the people who work with distros confirm this default choice or suggest what they use please?


Thanks,

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




> On 18 Jan 2020, at 10:05 am, Dr Paul Dale <paul.dale at oracle.com> wrote:
> 
> I?ve made the deprecation changes to the password application.
> 
> The default has been changed from crypt to the BSD MD5 algorithm.
> 
> Pauli
> -- 
> Dr Paul Dale | Distinguished Architect | Cryptographic Foundations 
> Phone +61 7 3031 7217
> Oracle Australia
> 
> 
> 
> 
>> On 18 Jan 2020, at 9:27 am, Dr Paul Dale <paul.dale at oracle.com <mailto:paul.dale at oracle.com>> wrote:
>> 
>> Okay, it looks like the consensus is option 3 ? deprecate and forget.
>> 
>> As far as I can tell, they are only used (by us) in one place outside of libcrypto, so that will deprecate as well.
>> 
>> 
>> Pauli
>> -- 
>> Dr Paul Dale | Distinguished Architect | Cryptographic Foundations 
>> Phone +61 7 3031 7217
>> Oracle Australia
>> 
>> 
>> 
>> 
>>> On 18 Jan 2020, at 6:53 am, Richard Levitte <levitte at openssl.org <mailto:levitte at openssl.org>> wrote:
>>> 
>>> Right. Such a KDF could be implemented elsewhere, as a separate project.
>>> 
>>> Cheers
>>> Richard
>>> 
>>> 
>>> Kurt Roeckx <kurt at roeckx.be <mailto:kurt at roeckx.be>> skrev: (17 januari 2020 21:35:00 CET)
>>>> On Fri, Jan 17, 2020 at 04:31:06PM +1000, Dr Paul Dale wrote:
>>>>> I?ve got several choices:
>>>>> Leave them public and unchanged ? that is, don?t deprecate these two
>>>> functions yet.
>>>>> Deprecate them and add KDFs to replace them.
>>>>> Deprecate them, leave them alone and hope they go away painlessly at
>>>> some point.
>>>> 
>>>> I really see no point in adding something that we at the same time
>>>> would like to remove. Just deprecate it.
>>>> 
>>>> 
>>>> Kurt
>>> 
>>> -- 
>>> Richard by mobile
>> 
> 

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

From kurt at roeckx.be  Sat Jan 18 14:28:59 2020
From: kurt at roeckx.be (Kurt Roeckx)
Date: Sat, 18 Jan 2020 15:28:59 +0100
Subject: crypt(3)
In-Reply-To: <EFE2FD86-04D4-49FC-9217-B9128A89D57A@oracle.com>
References: <2AB95A2B-ED92-4837-90EF-9C9143B33758@oracle.com>
 <20200117203500.GA743205@roeckx.be>
 <744C5FBB-4F3B-4DFF-9A74-4A419C1A749E@openssl.org>
 <D9730742-12B5-49A7-BBD0-70DBD96D2959@oracle.com>
 <08128F55-F641-43C6-9E8C-49F034954023@oracle.com>
 <EFE2FD86-04D4-49FC-9217-B9128A89D57A@oracle.com>
Message-ID: <20200118142859.GA57592@roeckx.be>

On Sat, Jan 18, 2020 at 10:47:04AM +1000, Dr Paul Dale wrote:
> Could the people who work with distros confirm this default choice or suggest what they use please?

I'm not sure what you're asking, but crypt() has moved on from
using DES like 20 years ago, see crypt(5).


Kurt


From paul.dale at oracle.com  Sun Jan 19 01:45:07 2020
From: paul.dale at oracle.com (Dr Paul Dale)
Date: Sun, 19 Jan 2020 11:45:07 +1000
Subject: crypt(3)
In-Reply-To: <20200118142859.GA57592@roeckx.be>
References: <2AB95A2B-ED92-4837-90EF-9C9143B33758@oracle.com>
 <20200117203500.GA743205@roeckx.be>
 <744C5FBB-4F3B-4DFF-9A74-4A419C1A749E@openssl.org>
 <D9730742-12B5-49A7-BBD0-70DBD96D2959@oracle.com>
 <08128F55-F641-43C6-9E8C-49F034954023@oracle.com>
 <EFE2FD86-04D4-49FC-9217-B9128A89D57A@oracle.com>
 <20200118142859.GA57592@roeckx.be>
Message-ID: <DE05CA6B-9031-42A0-B07E-1CD702777003@oracle.com>

I meant ?what default makes the most sense for the passwd command line application??
It was crypt which is deprecated.  Should it be BSD?s MD5?  One of the SHA2 based algorithms?  Or should it produce an error if no algorithm is selected?


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




> On 19 Jan 2020, at 12:28 am, Kurt Roeckx <kurt at roeckx.be> wrote:
> 
> On Sat, Jan 18, 2020 at 10:47:04AM +1000, Dr Paul Dale wrote:
>> Could the people who work with distros confirm this default choice or suggest what they use please?
> 
> I'm not sure what you're asking, but crypt() has moved on from
> using DES like 20 years ago, see crypt(5).
> 
> 
> Kurt
> 

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

From kurt at roeckx.be  Sun Jan 19 11:26:06 2020
From: kurt at roeckx.be (Kurt Roeckx)
Date: Sun, 19 Jan 2020 12:26:06 +0100
Subject: crypt(3)
In-Reply-To: <DE05CA6B-9031-42A0-B07E-1CD702777003@oracle.com>
References: <2AB95A2B-ED92-4837-90EF-9C9143B33758@oracle.com>
 <20200117203500.GA743205@roeckx.be>
 <744C5FBB-4F3B-4DFF-9A74-4A419C1A749E@openssl.org>
 <D9730742-12B5-49A7-BBD0-70DBD96D2959@oracle.com>
 <08128F55-F641-43C6-9E8C-49F034954023@oracle.com>
 <EFE2FD86-04D4-49FC-9217-B9128A89D57A@oracle.com>
 <20200118142859.GA57592@roeckx.be>
 <DE05CA6B-9031-42A0-B07E-1CD702777003@oracle.com>
Message-ID: <20200119112606.GA124356@roeckx.be>

On Sun, Jan 19, 2020 at 11:45:07AM +1000, Dr Paul Dale wrote:
> I meant ?what default makes the most sense for the passwd command line application??
> It was crypt which is deprecated.  Should it be BSD?s MD5?  One of the SHA2 based algorithms?  Or should it produce an error if no algorithm is selected?

I would actually like to go for something modern in that case,
like argon2 (argon2id). We have an open issue
(https://github.com/openssl/openssl/issues/4091) and pull request
(https://github.com/openssl/openssl/pull/9444) for argon2. PHP
seems to have made a format for it that's compatible with crypt():
https://wiki.php.net/rfc/argon2_password_hash_enhancements
But the argon2 RFC hasn't been published yet, so I think that
might need to wait.

The only thing that we support currently that makes sense as a
default is -5 (sha256) and -6 (sha512). I suggest you go with -6.


Kurt


From openssl-users at dukhovni.org  Sun Jan 19 20:22:34 2020
From: openssl-users at dukhovni.org (Viktor Dukhovni)
Date: Sun, 19 Jan 2020 15:22:34 -0500
Subject: crypt(3)
In-Reply-To: <20200119112606.GA124356@roeckx.be>
References: <2AB95A2B-ED92-4837-90EF-9C9143B33758@oracle.com>
 <20200117203500.GA743205@roeckx.be>
 <744C5FBB-4F3B-4DFF-9A74-4A419C1A749E@openssl.org>
 <D9730742-12B5-49A7-BBD0-70DBD96D2959@oracle.com>
 <08128F55-F641-43C6-9E8C-49F034954023@oracle.com>
 <EFE2FD86-04D4-49FC-9217-B9128A89D57A@oracle.com>
 <20200118142859.GA57592@roeckx.be>
 <DE05CA6B-9031-42A0-B07E-1CD702777003@oracle.com>
 <20200119112606.GA124356@roeckx.be>
Message-ID: <20200119202234.GC73491@straasha.imrryr.org>

On Sun, Jan 19, 2020 at 12:26:06PM +0100, Kurt Roeckx wrote:

> The only thing that we support currently that makes sense as a
> default is -5 (sha256) and -6 (sha512). I suggest you go with -6.

I concur, FWIW this is the default password hash for my FreeBSD 12
server, so it is not a Linux-only construct.

-- 
    Viktor.

From openssl at roumenpetrov.info  Sat Jan 18 07:58:04 2020
From: openssl at roumenpetrov.info (Roumen Petrov)
Date: Sat, 18 Jan 2020 09:58:04 +0200
Subject: crypt(3)
In-Reply-To: <2AB95A2B-ED92-4837-90EF-9C9143B33758@oracle.com>
References: <2AB95A2B-ED92-4837-90EF-9C9143B33758@oracle.com>
Message-ID: <8c7a5e91-ac18-4108-df1f-bd03d37c16fa@roumenpetrov.info>

Dr Paul Dale wrote:
> In the deprecation efforts for 3.0, I?ve hit something in the DES code that I?d appreciate input on.
>
> There are two functions (DES_crypt and DES_fcrypt) which implement the old crypt(3) password algorithm.  Once these are deprecated, they will no longer be reachable via EVP.  The confounding point is that they aren?t quite DES ? close but not identical.  I would be surprised if they aren?t still in use for /etc/passwd files on old and/or embedded systems.
>
> [SNIP]
>
> Thoughts?  Other alternatives?

Linux and BSD crypt(3) manual pages refer to crypt library.? Also 
crypt(3) is not only for DES. It has more features. Why to use OpenSSL 
functions then?

Also OpenSSL build now does not remove deprecated function. So package 
manages could decide API level compatibility and in addition to remove 
or not deprecated functions.

Regards,
Roumen Petrov


From rsalz at akamai.com  Sun Jan 19 02:19:41 2020
From: rsalz at akamai.com (Salz, Rich)
Date: Sun, 19 Jan 2020 02:19:41 +0000
Subject: crypt(3)
In-Reply-To: <DE05CA6B-9031-42A0-B07E-1CD702777003@oracle.com>
References: <2AB95A2B-ED92-4837-90EF-9C9143B33758@oracle.com>
 <20200117203500.GA743205@roeckx.be>
 <744C5FBB-4F3B-4DFF-9A74-4A419C1A749E@openssl.org>
 <D9730742-12B5-49A7-BBD0-70DBD96D2959@oracle.com>
 <08128F55-F641-43C6-9E8C-49F034954023@oracle.com>
 <EFE2FD86-04D4-49FC-9217-B9128A89D57A@oracle.com>
 <20200118142859.GA57592@roeckx.be>
 <DE05CA6B-9031-42A0-B07E-1CD702777003@oracle.com>
Message-ID: <C1EAB6CB-2B09-4C22-B185-D798F46CFE4A@akamai.com>

  *   I meant ?what default makes the most sense for the passwd command line application??
  *   It was crypt which is deprecated.  Should it be BSD?s MD5?  One of the SHA2 based algorithms?  Or should it produce an error if no algorithm is selected?

If you change the default, then the program will work differently depending on whether or not no-deprecated is configured.  This means that developers who want to write portable scripts will find it difficult to do so. People who have existing scripts and get a system upgrade could find things broken in a really strange way. This is *not* the same as when the default digest mechanism changed, because it was still available.

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

From openssl at roumenpetrov.info  Sat Jan 18 11:19:25 2020
From: openssl at roumenpetrov.info (Roumen Petrov)
Date: Sat, 18 Jan 2020 13:19:25 +0200
Subject: fips mode and key management
Message-ID: <df7eb660-b67a-4c6c-dbef-2625b8a8d451@roumenpetrov.info>

Hello,

Recently I note that when build is in FIPS_MODE some functionality is 
lost. For instance RSA_{g|s}et_ex_data is not available.

Reading the code I expect that in FIPS mode use of external keys is 
forbidden.
Remark: ex_data is used to store reference information for external keys.

Please confirm that in FIPS mode we could use external keys?


Regards
Roumen Petrov

P.S. If is not allowed this regression to previous FIPS 
releases(validations).
Neither OpenSSL nor Red Hat nor Solaris FIPS validation forbid use of 
"external" keys.


From paul.dale at oracle.com  Tue Jan 21 02:31:33 2020
From: paul.dale at oracle.com (Dr Paul Dale)
Date: Tue, 21 Jan 2020 12:31:33 +1000
Subject: crypt(3)
In-Reply-To: <8c7a5e91-ac18-4108-df1f-bd03d37c16fa@roumenpetrov.info>
References: <2AB95A2B-ED92-4837-90EF-9C9143B33758@oracle.com>
 <8c7a5e91-ac18-4108-df1f-bd03d37c16fa@roumenpetrov.info>
Message-ID: <0614E312-1DD4-4CA5-B138-C68C18B9BDE2@oracle.com>

Thanks for the feedback everyone.


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/20200121/6823e030/attachment-0001.html>

From levitte at openssl.org  Tue Jan 21 09:36:47 2020
From: levitte at openssl.org (Richard Levitte)
Date: Tue, 21 Jan 2020 10:36:47 +0100
Subject: fips mode and key management
In-Reply-To: <df7eb660-b67a-4c6c-dbef-2625b8a8d451@roumenpetrov.info>
References: <df7eb660-b67a-4c6c-dbef-2625b8a8d451@roumenpetrov.info>
Message-ID: <87ftg9m9qo.wl-levitte@openssl.org>

This doesn't affect applications.  Our FIPS module holds its own
keys, but reuse the same structures as libcrypto to hold them
internally, and *there*, the EX_DATA field is irrelevant.
Applications will never get that far in.  The EX_DATA added by the
application is still valid.

I think that the misunderstanding lies in when FIPS_MODE is defined.
It's defined when the FIPS provider module is being built, never
otherwise.

Cheers,
Richard

On Sat, 18 Jan 2020 12:19:25 +0100,
Roumen Petrov wrote:
> 
> Hello,
> 
> Recently I note that when build is in FIPS_MODE some functionality is
> lost. For instance RSA_{g|s}et_ex_data is not available.
> 
> Reading the code I expect that in FIPS mode use of external keys is
> forbidden.
> Remark: ex_data is used to store reference information for external keys.
> 
> Please confirm that in FIPS mode we could use external keys?
> 
> 
> Regards
> Roumen Petrov
> 
> P.S. If is not allowed this regression to previous FIPS
> releases(validations).
> Neither OpenSSL nor Red Hat nor Solaris FIPS validation forbid use of
> "external" keys.
> 
-- 
Richard Levitte         levitte at openssl.org
OpenSSL Project         http://www.openssl.org/~levitte/

From Matthias.St.Pierre at ncp-e.com  Tue Jan 21 12:31:16 2020
From: Matthias.St.Pierre at ncp-e.com (Matthias St. Pierre)
Date: Tue, 21 Jan 2020 13:31:16 +0100
Subject: fips mode and key management
In-Reply-To: <87ftg9m9qo.wl-levitte@openssl.org>
References: <df7eb660-b67a-4c6c-dbef-2625b8a8d451@roumenpetrov.info>
 <87ftg9m9qo.wl-levitte@openssl.org>
Message-ID: <1fd26254-8bfc-03b6-5f4c-2691f920e909@ncp-e.com>

On 21.01.20 10:36, Richard Levitte wrote:
> I think that the misunderstanding lies in when FIPS_MODE is defined.

Reading this sentence it occurred to me that the misunderstanding comes from
the fact that the define is indeed misnamed. The term "FIPS mode" is a relict
from FIPS 2.0, where the OpenSSL 1.0.x library had an API to enable FIPS mode
*at runtime*.

(Note that the *compile time* option to include the FOM was called OPENSSL_FIPS,
not FIPS_MODE. So the misleading name must have crept in only recently.)

> It's defined when the FIPS provider module is being built, never otherwise.

Exactly, in OpenSSL 3.0 the DEFAULT and the FIPS provider are partially built from
the same source files, which is the reason why we need a build time constant to
distinguish those two cases. Maybe the name OSSL_FIPS_PROVIDER would be
more fitting than FIPS_MODE?


 ??? #ifdef OSSL_FIPS_PROVIDER
 ??????? ...
 ??? #endif


Matthias


P.S: Even though it is an internal define, it should have an OSSL_ prefix IMHO.
P.P.S: Optionally, one could also #define an OSSL_DEFAULT_PROVIDER, OSSL_LEGACY_PROVIDER, ...


From Matthias.St.Pierre at ncp-e.com  Tue Jan 21 12:37:39 2020
From: Matthias.St.Pierre at ncp-e.com (Matthias St. Pierre)
Date: Tue, 21 Jan 2020 13:37:39 +0100
Subject: fips mode and key management
In-Reply-To: <1fd26254-8bfc-03b6-5f4c-2691f920e909@ncp-e.com>
References: <df7eb660-b67a-4c6c-dbef-2625b8a8d451@roumenpetrov.info>
 <87ftg9m9qo.wl-levitte@openssl.org>
 <1fd26254-8bfc-03b6-5f4c-2691f920e909@ncp-e.com>
Message-ID: <516bb8df-79d6-30bd-4c18-bf1be82c19c0@ncp-e.com>


BTW: the following build time constant with the remarkably long name seems to be intended for
a related purpose,? but it is currently completely unused?

 ??? Configurations/00-base-templates.conf:? lib_defines???? => [ 'OPENSSL_BUILDING_OPENSSL' ],



From tmraz at redhat.com  Tue Jan 21 14:33:35 2020
From: tmraz at redhat.com (Tomas Mraz)
Date: Tue, 21 Jan 2020 15:33:35 +0100
Subject: fips mode and key management
In-Reply-To: <1fd26254-8bfc-03b6-5f4c-2691f920e909@ncp-e.com>
References: <df7eb660-b67a-4c6c-dbef-2625b8a8d451@roumenpetrov.info>
 <87ftg9m9qo.wl-levitte@openssl.org>
 <1fd26254-8bfc-03b6-5f4c-2691f920e909@ncp-e.com>
Message-ID: <e0c9b46b192f46fa9e916cc1fdd75806b9674bba.camel@redhat.com>

I can only add +1 to what Matthias suggests. Although I know the
meaning of the FIPS_MODE define, for a newcomer it is obviously not
clear what the define really means.

Tomas

On Tue, 2020-01-21 at 13:31 +0100, Matthias St. Pierre wrote:
> On 21.01.20 10:36, Richard Levitte wrote:
> > I think that the misunderstanding lies in when FIPS_MODE is
> > defined.
> 
> Reading this sentence it occurred to me that the misunderstanding
> comes from
> the fact that the define is indeed misnamed. The term "FIPS mode" is
> a relict
> from FIPS 2.0, where the OpenSSL 1.0.x library had an API to enable
> FIPS mode
> *at runtime*.
> 
> (Note that the *compile time* option to include the FOM was called
> OPENSSL_FIPS,
> not FIPS_MODE. So the misleading name must have crept in only
> recently.)
> 
> > It's defined when the FIPS provider module is being built, never
> > otherwise.
> 
> Exactly, in OpenSSL 3.0 the DEFAULT and the FIPS provider are
> partially built from
> the same source files, which is the reason why we need a build time
> constant to
> distinguish those two cases. Maybe the name OSSL_FIPS_PROVIDER would
> be
> more fitting than FIPS_MODE?
> 
> 
>      #ifdef OSSL_FIPS_PROVIDER
>          ...
>      #endif
> 
> 
> Matthias
> 
> 
> P.S: Even though it is an internal define, it should have an OSSL_
> prefix IMHO.
> P.P.S: Optionally, one could also #define an OSSL_DEFAULT_PROVIDER,
> OSSL_LEGACY_PROVIDER, ...
> 
-- 
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 rsalz at akamai.com  Tue Jan 21 15:28:36 2020
From: rsalz at akamai.com (Salz, Rich)
Date: Tue, 21 Jan 2020 15:28:36 +0000
Subject: fips mode and key management
In-Reply-To: <1fd26254-8bfc-03b6-5f4c-2691f920e909@ncp-e.com>
References: <df7eb660-b67a-4c6c-dbef-2625b8a8d451@roumenpetrov.info>
 <87ftg9m9qo.wl-levitte@openssl.org>
 <1fd26254-8bfc-03b6-5f4c-2691f920e909@ncp-e.com>
Message-ID: <77DECA97-93FA-4069-AFD9-665174C28289@akamai.com>

>    distinguish those two cases. Maybe the name OSSL_FIPS_PROVIDER would be
    more fitting than FIPS_MODE?
  

Or perhaps OPENSSL_BUILDING_FIPS, since a couple of PR's already have and use OPENSSL_BUILDING_OPENSSL ...

There's no reason to use OSSL for internal macros.




From Matthias.St.Pierre at ncp-e.com  Tue Jan 21 20:18:18 2020
From: Matthias.St.Pierre at ncp-e.com (Dr. Matthias St. Pierre)
Date: Tue, 21 Jan 2020 20:18:18 +0000
Subject: fips mode and key management
In-Reply-To: <77DECA97-93FA-4069-AFD9-665174C28289@akamai.com>
References: <df7eb660-b67a-4c6c-dbef-2625b8a8d451@roumenpetrov.info>
 <87ftg9m9qo.wl-levitte@openssl.org>
 <1fd26254-8bfc-03b6-5f4c-2691f920e909@ncp-e.com>
 <77DECA97-93FA-4069-AFD9-665174C28289@akamai.com>
Message-ID: <80ffb88f55774d7a8d8a279fc34c0455@Ex13.ncp.local>


> >    distinguish those two cases. Maybe the name OSSL_FIPS_PROVIDER would be
>     more fitting than FIPS_MODE?
> 
> 
> Or perhaps OPENSSL_BUILDING_FIPS, since a couple of PR's already have and use OPENSSL_BUILDING_OPENSSL ...

OPENSSL_BUILDING_OPENSSL is really a remarkably long name.  I hope this does not blow up any commandline
length limits ?. How about using OSSL_LIBRARY library instead? This would fit nicely to OSSL_FIPS_PROVIDER:

    #ifdef OSSL_LIBRARY
        ...
    #endif

    #ifdef OSSL_FIPS_PROVIDER
        ...
    #endif

> There's no reason to use OSSL for internal macros.

But it avoids unnecessary name clashes with system headers. Just today, I saw this collision with Windows headers:

    include/openssl/types.h:74:#  undef OCSP_REQUEST
    include/openssl/types.h:75:#  undef OCSP_RESPONSE

(Yes I know, Window headers are really polluting the global namespace).



From matt at openssl.org  Wed Jan 22 13:01:23 2020
From: matt at openssl.org (Matt Caswell)
Date: Wed, 22 Jan 2020 13:01:23 +0000
Subject: 3.0 release timeline proposal
In-Reply-To: <4679b4f7-1358-3512-c8e5-93c787f3e3df@openssl.org>
References: <fe4f3315-f17e-2463-258d-9120a129dc2a@openssl.org>
 <39a94b67-606c-98b5-18a5-a8ca9d55f4b6@openssl.org>
 <d106aeb5-9938-d74a-46d7-f386e3e71453@openssl.org>
 <4679b4f7-1358-3512-c8e5-93c787f3e3df@openssl.org>
Message-ID: <48c6c2c8-c808-656a-b526-2da6492e866e@openssl.org>



On 16/01/2020 10:39, Matt Caswell wrote:
> This vote has started. I'll report back when we have an answer.

The vote has now finished with these results:

+1: 7
 0: 0
-1: 0

So the vote passed.

Matt



> 
> Matt
> 
> On 15/01/2020 09:12, Matt Caswell wrote:
>> Not much feedback, so I'm assuming everyone is ok with this proposal.
>>
>> I'm going to start a vote soon with this wording:
>>
>> "Update the release strategy to the text shown here:
>> https://github.com/openssl/web/pull/154/commits/959153c7e62865beae9f24364f1c971b149f477a"
>>
>>
>>
>> Matt
>>
>>
>>
>>
>> On 07/01/2020 16:54, Matt Caswell wrote:
>>> I converted this proposal into a PR to amend the release strategy.
>>> Please see:
>>>
>>> https://github.com/openssl/web/pull/154
>>>
>>> Matt
>>>
>>>
>>> On 07/01/2020 11:13, Matt Caswell wrote:
>>>> Hi all
>>>>
>>>> Myself, Paul, Shane, Richard and Nicola had a conf call today to discuss
>>>> the outstanding tasks and effort required to get us to a final release.
>>>>
>>>> We've previously said this about that timeline:
>>>>
>>>> "We are now not expecting code completion to occur until the end of Q2
>>>> 2020 with a final release in early Q4 2020."
>>>> (https://www.openssl.org/blog/blog/2019/11/07/3.0-update/)
>>>>
>>>>
>>>> With that in mind we came up with the following proposal for a release
>>>> timetable which we think is a challenging but achievable timeline:
>>>>
>>>> alpha1, 2020-03-31: Basic functionality plus basic FIPS module
>>>> alpha2, 2020-04-21: Complete external provider support (serialization,
>>>> support for new algs, support for providers which only include
>>>> operations in a class)
>>>> alpha3, 2020-05-21: Almost there (aiming to test the API completeness
>>>> before beta1 freezes it)
>>>> beta1, 2020-06-02: Code complete (API stable, feature freeze)
>>>> betaN: Other beta TBD
>>>> Final: 2020 early Q4
>>>>
>>>> The idea here is to set some intermediate deadlines to focus attention
>>>> on the final remaining tasks, with a series of 3 alphas prior to the
>>>> first beta release where each alpha release comes approximately every 3
>>>> weeks. We can have some flexibility to adjust this timetable if we think
>>>> it is necessary (such as by including an additional alpha release if
>>>> required).
>>>>
>>>> Please let me know your thoughts. This would probably need to go to an
>>>> OMC vote to get approved.
>>>>
>>>> Matt
>>>>
> 

From matt at openssl.org  Fri Jan 31 14:48:12 2020
From: matt at openssl.org (Matt Caswell)
Date: Fri, 31 Jan 2020 14:48:12 +0000
Subject: New Committer
Message-ID: <1b93214e-1053-41c7-6c87-ddffacd3362b@openssl.org>

I'd like to announce that David von Oheimb has joined our team of
committers! David has been particularly active recently with the CMP
contribution - but also has numerous other PRs and commits to his name.

Welcome David!

Matt

From Matthias.St.Pierre at ncp-e.com  Fri Jan 31 15:28:21 2020
From: Matthias.St.Pierre at ncp-e.com (Matthias St. Pierre)
Date: Fri, 31 Jan 2020 16:28:21 +0100
Subject: New Committer
In-Reply-To: <1b93214e-1053-41c7-6c87-ddffacd3362b@openssl.org>
References: <1b93214e-1053-41c7-6c87-ddffacd3362b@openssl.org>
Message-ID: <46218e97-c761-8fff-b0cf-82d66dcf464d@ncp-e.com>

Congratulations, David! And welcome to the team!

Matthias


On 31.01.20 15:48, Matt Caswell wrote:
> I'd like to announce that David von Oheimb has joined our team of
> committers! David has been particularly active recently with the CMP
> contribution - but also has numerous other PRs and commits to his name.
>
> Welcome David!
>
> Matt


From beldmit at gmail.com  Fri Jan 31 15:33:54 2020
From: beldmit at gmail.com (Dmitry Belyavsky)
Date: Fri, 31 Jan 2020 18:33:54 +0300
Subject: New Committer
In-Reply-To: <1b93214e-1053-41c7-6c87-ddffacd3362b@openssl.org>
References: <1b93214e-1053-41c7-6c87-ddffacd3362b@openssl.org>
Message-ID: <CADqLbzK5FybGc4yN-Sh0QsyaJjXgBKqB_09p9RZsQxw1DR=UQA@mail.gmail.com>

Great news!

On Fri, Jan 31, 2020 at 5:48 PM Matt Caswell <matt at openssl.org> wrote:

> I'd like to announce that David von Oheimb has joined our team of
> committers! David has been particularly active recently with the CMP
> contribution - but also has numerous other PRs and commits to his name.
>
> Welcome David!
>
> Matt
>


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

From Matthias.St.Pierre at ncp-e.com  Fri Jan 31 17:07:34 2020
From: Matthias.St.Pierre at ncp-e.com (Matthias St. Pierre)
Date: Fri, 31 Jan 2020 18:07:34 +0100
Subject: Travis in solid red mode again
Message-ID: <9ea7c866-bb13-fff1-a69d-ec08fe4a93ee@ncp-e.com>


After a much to short green period, Travis has turned to solid red mode again:

https://travis-ci.org/openssl/openssl/builds?utm_medium=notification&utm_source=github_status

This fact causes a lot of pain for reviewers, because every failing job needs to be checked manually.
I would be happy to fix some of the failures if I could, but in most cases I have no clue what the problem is,
because I can't reproduce the issue locally. Could we try to fix them in a joint effort?? For your convenience,
I added a summary of all failing jobs of Build #31837 below.

Since this is not the first time that this happens, I think it is overdue that the OTC discusses those constant
build failures and proposes some measures to raise the priority for fixing CI errors. One drastic possibility
would be to allow only CI fixing pull requests to be merged as long as master and the stable branches are red.
But I am sure there is a golden middle way between such an extreme sanction and our current indifference.


Regards,

Matthias



----


Last Successful Build: #31583 (10 days ago!)
https://travis-ci.org/openssl/openssl/builds/639939072?utm_medium=notification&utm_source=github_status

Recent Build: #31837
https://travis-ci.org/openssl/openssl/builds/644238908?utm_medium=notification&utm_source=github_status


SSL TESTS
=========

* https://travis-ci.org/openssl/openssl/jobs/644238919?utm_medium=notification&utm_source=github_status
* https://travis-ci.org/openssl/openssl/jobs/644238926?utm_medium=notification&utm_source=github_status
* https://travis-ci.org/openssl/openssl/jobs/644238929?utm_medium=notification&utm_source=github_status

 >? Test Summary Report
 > -------------------
 >? 80-test_ssl_new.t??????????????? (Wstat: 256 Tests: 30 Failed: 1)
 >??? Failed test:? 4
 >??? Non-zero exit status: 1
 >? 80-test_ssl_old.t??????????????? (Wstat: 256 Tests: 6 Failed: 1)
 >??? Failed test:? 2
 >??? Non-zero exit status: 1



BORINGSSL AND KRB5
==================

* https://travis-ci.org/openssl/openssl/jobs/644238927?utm_medium=notification&utm_source=github_status

 > Test Summary Report
 > -------------------

 > 95-test_external_boringssl.t (Wstat: 256 Tests: 1 Failed: 1)
 >?? Failed test:? 1
 >?? Non-zero exit status: 1
 > 95-test_external_krb5.t???? (Wstat: 256 Tests: 1 Failed: 1)
 >?? Failed test:? 1
 >?? Non-zero exit status: 1



95-test_external_boringssl.t:
-----------------------

 ??? grep 'go.*FAILED' tffff
 ??? go test: FAILED (SSL3-Client-ClientAuth-RSA)
 ??? go test: FAILED (SSL3-Server-ClientAuth-RSA)
 ??? go test: FAILED (ClientAuth-Sign-RSA-SSL3)
 ??? go test: FAILED (ClientAuth-InvalidSignature-RSA-SSL3)
 ??? go test: FAILED (CertificateVerificationSucceed-Server-SSL3-Sync)
 ??? go test: FAILED (CertificateVerificationSucceed-Server-SSL3-Sync-SplitHandshakeRecords)
 ??? go test: FAILED (CertificateVerificationSucceed-Server-SSL3-Sync-PackHandshakeFlight)
 ??? go test: FAILED (CertificateVerificationSucceed-Server-SSL3-Async)
 ??? go test: FAILED (CertificateVerificationSucceed-Server-SSL3-Async-SplitHandshakeRecords)
 ??? go test: FAILED (CertificateVerificationSucceed-Server-SSL3-Async-PackHandshakeFlight)



95-test_external_krb5.t:
-----------------------

 ??? LD_LIBRARY_PATH=`echo -L../../../lib | sed -e "s/-L//g" -e "s/ /:/g"` KRB5_CONFIG=../../../config-files/krb5.conf LC_ALL=C ./t_nfold
 ??? N-fold
 ??????? Input:??? "basch"
 ??????? 192-Fold:???? 1aab6b42 964b98b2 1f8cde2d 2448ba34 55d7862c 9731643f
 ??????? Input:??? "eichin"
 ??????? 192-Fold:???? 65696368 696e4b73 2b4b1b43 da1a5b99 5a58d2c6 d0d2dcca
 ??????? Input:??? "sommerfeld"
 ??????? 192-Fold:???? 2f7a9855 7c6ee4ab adf4e711 92dd442b d4ff5325 a5def75c
 ??????? Input:??? "MASSACHVSETTS INSTITVTE OF TECHNOLOGY"
 ??????? 192-Fold:???? db3b0d8f 0b061e60 3282b308 a5084122 9ad798fa b9540c1b
 ??? RFC tests:

 ??? ...

 ??? Generating random keyblock: . . . OK
 ??? Creating opaque key from keyblock: . . . OK
 ??? Encrypting (c): . . . Failed: Cannot allocate memory <===ALLOC FAILURE==
 ??? Aborted (core dumped)???????????????????????????????????????????????? <===CORE DUMPED==
 ??? Makefile:684: recipe for target 'check-unix' failed
 ??? make[5]: *** [check-unix] Error 134
 ??? make[5]: Leaving directory '/home/travis/build/openssl/openssl/krb5/src/lib/crypto/crypto_tests'
 ??? Makefile:1107: recipe for target 'check-recurse' failed
 ??? make[4]: *** [check-recurse] Error 1
 ??? make[4]: Leaving directory '/home/travis/build/openssl/openssl/krb5/src/lib/crypto'
 ??? Makefile:992: recipe for target 'check-recurse' failed
 ??? make[3]: *** [check-recurse] Error 1
 ??? make[3]: Leaving directory '/home/travis/build/openssl/openssl/krb5/src/lib'
 ??? Makefile:1533: recipe for target 'check-recurse' failed
 ??? make[2]: *** [check-recurse] Error 1
 ??? make[2]: Leaving directory '/home/travis/build/openssl/openssl/krb5/src'
 ??? ../../util/shlib_wrap.sh ../recipes/95-test_external_krb5_data/krb5.sh => 2
 ??? not ok 1 - running krb5 tests





From matt at openssl.org  Fri Jan 31 22:55:34 2020
From: matt at openssl.org (Matt Caswell)
Date: Fri, 31 Jan 2020 22:55:34 +0000
Subject: Travis in solid red mode again
In-Reply-To: <9ea7c866-bb13-fff1-a69d-ec08fe4a93ee@ncp-e.com>
References: <9ea7c866-bb13-fff1-a69d-ec08fe4a93ee@ncp-e.com>
Message-ID: <ca6bfd5d-5545-f2e3-17d5-3647b7cc0d21@openssl.org>



On 31/01/2020 17:07, Matthias St. Pierre wrote:
> 
> After a much to short green period, Travis has turned to solid red mode
> again:
> 
> https://travis-ci.org/openssl/openssl/builds?utm_medium=notification&utm_source=github_status
> 
> 
> This fact causes a lot of pain for reviewers, because every failing job
> needs to be checked manually.
> I would be happy to fix some of the failures if I could, but in most
> cases I have no clue what the problem is,
> because I can't reproduce the issue locally. Could we try to fix them in
> a joint effort?? For your convenience,
> I added a summary of all failing jobs of Build #31837 below.

Trial fix for at least some of these issues in #10989. We'll see what
travis makes of it.

> 
> Since this is not the first time that this happens, I think it is
> overdue that the OTC discusses those constant
> build failures and proposes some measures to raise the priority for
> fixing CI errors. One drastic possibility
> would be to allow only CI fixing pull requests to be merged as long as
> master and the stable branches are red.
> But I am sure there is a golden middle way between such an extreme
> sanction and our current indifference.
> 

Part of the issue is that the master branch travis failures are not
visible in the PRs because the master branch runs the full tests
(including the extended tests), whereas the PRs don't run the extended
tests by default. However running the extended tests takes too long.

Could we add a CI check for PRs that confirms that the target branch is
green in travis?

Matt


> 
> Regards,
> 
> Matthias
> 
> 
> 
> ----
> 
> 
> Last Successful Build: #31583 (10 days ago!)
> https://travis-ci.org/openssl/openssl/builds/639939072?utm_medium=notification&utm_source=github_status
> 
> 
> Recent Build: #31837
> https://travis-ci.org/openssl/openssl/builds/644238908?utm_medium=notification&utm_source=github_status
> 
> 
> 
> SSL TESTS
> =========
> 
> *
> https://travis-ci.org/openssl/openssl/jobs/644238919?utm_medium=notification&utm_source=github_status
> 
> *
> https://travis-ci.org/openssl/openssl/jobs/644238926?utm_medium=notification&utm_source=github_status
> 
> *
> https://travis-ci.org/openssl/openssl/jobs/644238929?utm_medium=notification&utm_source=github_status
> 
> 
>>? Test Summary Report
>> -------------------
>>? 80-test_ssl_new.t??????????????? (Wstat: 256 Tests: 30 Failed: 1)
>>??? Failed test:? 4
>>??? Non-zero exit status: 1
>>? 80-test_ssl_old.t??????????????? (Wstat: 256 Tests: 6 Failed: 1)
>>??? Failed test:? 2
>>??? Non-zero exit status: 1
> 
> 
> 
> BORINGSSL AND KRB5
> ==================
> 
> *
> https://travis-ci.org/openssl/openssl/jobs/644238927?utm_medium=notification&utm_source=github_status
> 
> 
>> Test Summary Report
>> -------------------
> 
>> 95-test_external_boringssl.t (Wstat: 256 Tests: 1 Failed: 1)
>>?? Failed test:? 1
>>?? Non-zero exit status: 1
>> 95-test_external_krb5.t???? (Wstat: 256 Tests: 1 Failed: 1)
>>?? Failed test:? 1
>>?? Non-zero exit status: 1
> 
> 
> 
> 95-test_external_boringssl.t:
> -----------------------
> 
> ??? grep 'go.*FAILED' tffff
> ??? go test: FAILED (SSL3-Client-ClientAuth-RSA)
> ??? go test: FAILED (SSL3-Server-ClientAuth-RSA)
> ??? go test: FAILED (ClientAuth-Sign-RSA-SSL3)
> ??? go test: FAILED (ClientAuth-InvalidSignature-RSA-SSL3)
> ??? go test: FAILED (CertificateVerificationSucceed-Server-SSL3-Sync)
> ??? go test: FAILED
> (CertificateVerificationSucceed-Server-SSL3-Sync-SplitHandshakeRecords)
> ??? go test: FAILED
> (CertificateVerificationSucceed-Server-SSL3-Sync-PackHandshakeFlight)
> ??? go test: FAILED (CertificateVerificationSucceed-Server-SSL3-Async)
> ??? go test: FAILED
> (CertificateVerificationSucceed-Server-SSL3-Async-SplitHandshakeRecords)
> ??? go test: FAILED
> (CertificateVerificationSucceed-Server-SSL3-Async-PackHandshakeFlight)
> 
> 
> 
> 95-test_external_krb5.t:
> -----------------------
> 
> ??? LD_LIBRARY_PATH=`echo -L../../../lib | sed -e "s/-L//g" -e "s/
> /:/g"` KRB5_CONFIG=../../../config-files/krb5.conf LC_ALL=C ./t_nfold
> ??? N-fold
> ??????? Input:??? "basch"
> ??????? 192-Fold:???? 1aab6b42 964b98b2 1f8cde2d 2448ba34 55d7862c 9731643f
> ??????? Input:??? "eichin"
> ??????? 192-Fold:???? 65696368 696e4b73 2b4b1b43 da1a5b99 5a58d2c6 d0d2dcca
> ??????? Input:??? "sommerfeld"
> ??????? 192-Fold:???? 2f7a9855 7c6ee4ab adf4e711 92dd442b d4ff5325 a5def75c
> ??????? Input:??? "MASSACHVSETTS INSTITVTE OF TECHNOLOGY"
> ??????? 192-Fold:???? db3b0d8f 0b061e60 3282b308 a5084122 9ad798fa b9540c1b
> ??? RFC tests:
> 
> ??? ...
> 
> ??? Generating random keyblock: . . . OK
> ??? Creating opaque key from keyblock: . . . OK
> ??? Encrypting (c): . . . Failed: Cannot allocate memory <===ALLOC
> FAILURE==
> ??? Aborted (core
> dumped)???????????????????????????????????????????????? <===CORE DUMPED==
> ??? Makefile:684: recipe for target 'check-unix' failed
> ??? make[5]: *** [check-unix] Error 134
> ??? make[5]: Leaving directory
> '/home/travis/build/openssl/openssl/krb5/src/lib/crypto/crypto_tests'
> ??? Makefile:1107: recipe for target 'check-recurse' failed
> ??? make[4]: *** [check-recurse] Error 1
> ??? make[4]: Leaving directory
> '/home/travis/build/openssl/openssl/krb5/src/lib/crypto'
> ??? Makefile:992: recipe for target 'check-recurse' failed
> ??? make[3]: *** [check-recurse] Error 1
> ??? make[3]: Leaving directory
> '/home/travis/build/openssl/openssl/krb5/src/lib'
> ??? Makefile:1533: recipe for target 'check-recurse' failed
> ??? make[2]: *** [check-recurse] Error 1
> ??? make[2]: Leaving directory
> '/home/travis/build/openssl/openssl/krb5/src'
> ??? ../../util/shlib_wrap.sh
> ../recipes/95-test_external_krb5_data/krb5.sh => 2
> ??? not ok 1 - running krb5 tests
> 
> 
> 
>