From paul.dale at oracle.com  Mon Jan  1 22:51:36 2018
From: paul.dale at oracle.com (Paul Dale)
Date: Mon, 1 Jan 2018 14:51:36 -0800 (PST)
Subject: [openssl-project] As per vote, the project list is created
In-Reply-To: <20171222.154817.100546507567267849.levitte@openssl.org>
References: <20171222.093842.494904828507959326.levitte@openssl.org>
 <20171222105738.GA17869@roeckx.be>
 <20171222.154817.100546507567267849.levitte@openssl.org>
Message-ID: <7ce371db-4487-4bab-a415-61ee1b122337@default>

A concurrent update for the mailing list page: https://www.openssl.org/community/mailinglists.html too?

Pauli
-- 
Oracle
Dr Paul Dale | Cryptographer | Network Security & Encryption 
Phone +61 7 3031 7217
Oracle Australia

-----Original Message-----
From: Richard Levitte [mailto:levitte at openssl.org] 
Sent: Saturday, 23 December 2017 12:48 AM
To: openssl-project at openssl.org
Subject: Re: [openssl-project] As per vote, the project list is created

In message <20171222105738.GA17869 at roeckx.be> on Fri, 22 Dec 2017 11:57:38 +0100, Kurt Roeckx <kurt at roeckx.be> said:

kurt> You should probably announce this new list more widely

Agreed.  Wasn't someone going to make a blog post about it?  Or was that just a general "we should" where noone actually said "I will"?
For if no one feels they've taken that on, I will ;-)

-- 
Richard Levitte         levitte at openssl.org
OpenSSL Project         http://www.openssl.org/~levitte/
_______________________________________________
openssl-project mailing list
openssl-project at openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project

From matt at openssl.org  Tue Jan  2 17:02:38 2018
From: matt at openssl.org (Matt Caswell)
Date: Tue, 2 Jan 2018 17:02:38 +0000
Subject: [openssl-project] Monthly Status Report (December)
Message-ID: <ecdcbc44-6fe5-411a-29ce-881d3c52412e@openssl.org>

An OMC vote was recently held (during the f2f last month) regarding
monthly status reports from fellows:

"topic: OpenSSL fellows to mail openssl-project with a monthly status
report by the 7th day of the following month."

This passed with 7 in favour, 1 abstention, 0 against, and 0 no votes.

No specific format was defined so I've just gone with a bullet point
list of my key activities. If there is other info people want to see
then let me know.

As well as normal reviews, responding to user queries, wiki user
requests, etc., key activities this month:

- Owned the work associated with CVE-2017-3737 (Read/write after SSL
object in error state)
- Managed the release of OpenSSL 1.0.2n
- Fixed review issues and pushed draft-22 support
- Fixed numerous run-checker failures
- Backported SSL_OP_NO_RENEGOTIATION to 1.1.0 (awaiting review)
- Overhauled libssl error handling
- Attended the London face-2-face meeting
- Pushed some commits to the openssl-book repository and created some
PRs for new chapter content
- Significant work on X448/Ed448 (PR 4829). Currently de-prioritised to
focus on other more important 1.1.1 work following f2f meeting. Will
come back to this later.
- Working behind the scenes on TLSv1.3 server side stateless cookie
mechanism (PR 4435)
- Pushed changes required for TLSv1.3 TCP Fast Open support
- Created draft 1.1.1 release timetable for discussion



Matt

From rsalz at akamai.com  Tue Jan  2 20:42:31 2018
From: rsalz at akamai.com (Salz, Rich)
Date: Tue, 2 Jan 2018 20:42:31 +0000
Subject: [openssl-project] As per vote, the project list is created
In-Reply-To: <7ce371db-4487-4bab-a415-61ee1b122337@default>
References: <20171222.093842.494904828507959326.levitte@openssl.org>
 <20171222105738.GA17869@roeckx.be>
 <20171222.154817.100546507567267849.levitte@openssl.org>
 <7ce371db-4487-4bab-a415-61ee1b122337@default>
Message-ID: <9613CAF7-E255-4DD7-B71C-13C98EBE369F@akamai.com>

I wrote a draft blog post.  If anyone on the OMC wants to edit and put their name on it, or suggest edits and I post it, that?s fine with me.

On 1/1/18, 7:30 PM, "Paul Dale" <paul.dale at oracle.com> wrote:

    A concurrent update for the mailing list page: https://www.openssl.org/community/mailinglists.html too?
    
    Pauli
    -- 
    Oracle
    Dr Paul Dale | Cryptographer | Network Security & Encryption 
    Phone +61 7 3031 7217
    Oracle Australia
    
    -----Original Message-----
    From: Richard Levitte [mailto:levitte at openssl.org] 
    Sent: Saturday, 23 December 2017 12:48 AM
    To: openssl-project at openssl.org
    Subject: Re: [openssl-project] As per vote, the project list is created
    
    In message <20171222105738.GA17869 at roeckx.be> on Fri, 22 Dec 2017 11:57:38 +0100, Kurt Roeckx <kurt at roeckx.be> said:
    
    kurt> You should probably announce this new list more widely
    
    Agreed.  Wasn't someone going to make a blog post about it?  Or was that just a general "we should" where noone actually said "I will"?
    For if no one feels they've taken that on, I will ;-)
    
    -- 
    Richard Levitte         levitte at openssl.org
    OpenSSL Project         http://www.openssl.org/~levitte/
    _______________________________________________
    openssl-project mailing list
    openssl-project at openssl.org
    https://mta.openssl.org/mailman/listinfo/openssl-project
    _______________________________________________
    openssl-project mailing list
    openssl-project at openssl.org
    https://mta.openssl.org/mailman/listinfo/openssl-project
    

-------------- next part --------------
An embedded message was scrubbed...
From: Rich Salz <rsalz at openssl.org>
Subject: [openssl-omc] [blog]  master update
Date: Tue, 2 Jan 2018 20:41:12 +0000
Size: 12584
URL: <http://mta.openssl.org/pipermail/openssl-project/attachments/20180102/f056f9f0/attachment-0001.mht>

From tjh at cryptsoft.com  Tue Jan  2 21:20:37 2018
From: tjh at cryptsoft.com (Tim Hudson)
Date: Wed, 3 Jan 2018 07:20:37 +1000
Subject: [openssl-project] As per vote, the project list is created
In-Reply-To: <9613CAF7-E255-4DD7-B71C-13C98EBE369F@akamai.com>
References: <20171222.093842.494904828507959326.levitte@openssl.org>
 <20171222105738.GA17869@roeckx.be>
 <20171222.154817.100546507567267849.levitte@openssl.org>
 <7ce371db-4487-4bab-a415-61ee1b122337@default>
 <9613CAF7-E255-4DD7-B71C-13C98EBE369F@akamai.com>
Message-ID: <CAHEJ-S7LLWh_BUn1YyhQQqr1e8eTaRhn+4JVSARXdYrMr=L15g@mail.gmail.com>

I've added some edits to make it align more closely with the discussion and
correct a couple of items.

I think it should go out from the OMC as a whole - which does mean that
everyone should view it - and if we are sending as OMC then it should be on
the basis of a vote (so we are not placing words in the mouths of people
who haven't read and approved the wording).

I also wouldn't have sent the draft blog post to the public as yet ...

Tim.



On Wed, Jan 3, 2018 at 6:42 AM, Salz, Rich <rsalz at akamai.com> wrote:

> I wrote a draft blog post.  If anyone on the OMC wants to edit and put
> their name on it, or suggest edits and I post it, that?s fine with me.
>
> On 1/1/18, 7:30 PM, "Paul Dale" <paul.dale at oracle.com> wrote:
>
>     A concurrent update for the mailing list page:
> https://www.openssl.org/community/mailinglists.html too?
>
>     Pauli
>     --
>     Oracle
>     Dr Paul Dale | Cryptographer | Network Security & Encryption
>     Phone +61 7 3031 7217
>     Oracle Australia
>
>     -----Original Message-----
>     From: Richard Levitte [mailto:levitte at openssl.org]
>     Sent: Saturday, 23 December 2017 12:48 AM
>     To: openssl-project at openssl.org
>     Subject: Re: [openssl-project] As per vote, the project list is created
>
>     In message <20171222105738.GA17869 at roeckx.be> on Fri, 22 Dec 2017
> 11:57:38 +0100, Kurt Roeckx <kurt at roeckx.be> said:
>
>     kurt> You should probably announce this new list more widely
>
>     Agreed.  Wasn't someone going to make a blog post about it?  Or was
> that just a general "we should" where noone actually said "I will"?
>     For if no one feels they've taken that on, I will ;-)
>
>     --
>     Richard Levitte         levitte at openssl.org
>     OpenSSL Project         http://www.openssl.org/~levitte/
>     _______________________________________________
>     openssl-project mailing list
>     openssl-project at openssl.org
>     https://mta.openssl.org/mailman/listinfo/openssl-project
>     _______________________________________________
>     openssl-project mailing list
>     openssl-project at openssl.org
>     https://mta.openssl.org/mailman/listinfo/openssl-project
>
>
>
>
> ---------- Forwarded message ----------
> From: Rich Salz <rsalz at openssl.org>
> To: <openssl-omc at openssl.org>
> Cc:
> Bcc:
> Date: Tue, 2 Jan 2018 20:41:12 +0000
> Subject: [openssl-omc] [blog] master update
> The branch master has been updated
>        via  90a4eb9e289be237bc80dc5393d32e79b2d7b001 (commit)
>       from  0c536ced1e9bb1684ddf60af42e236dd69d3dd52 (commit)
>
>
> - Log -----------------------------------------------------------------
> commit 90a4eb9e289be237bc80dc5393d32e79b2d7b001
> Author: Rich Salz <rsalz at akamai.com>
> Date:   Tue Jan 2 15:39:37 2018 -0500
>
>     Draft of F2F blog post
>
> -----------------------------------------------------------------------
>
> Summary of changes:
>  source/_posts/2018-01-04-f2f-email-etc.markdown | 130
> ++++++++++++++++++++++++
>  1 file changed, 130 insertions(+)
>  create mode 100644 source/_posts/2018-01-04-f2f-email-etc.markdown
>
> diff --git a/source/_posts/2018-01-04-f2f-email-etc.markdown
> b/source/_posts/2018-01-04-f2f-email-etc.markdown
> new file mode 100644
> index 0000000..c62a133
> --- /dev/null
> +++ b/source/_posts/2018-01-04-f2f-email-etc.markdown
> @@ -0,0 +1,130 @@
> +---
> +layout: post
> +title: "Another Face to Face: Email changes and crypto policy"
> +date: 2018-01-04 1:00
> +comments: true
> +author: "???"
> +published: false
> +---
> +
> +The OpenSSL OMC met last month for a two-day face-to-face meeting, and
> +like previous F2F meetings, most of the team was present and we got a
> +great deal of issues addressed.  This blog posts talks about some of them,
> +and most of the others will get their own blog posts, or notices, later.
> +
> +One of the overall threads of the meeting was about increasing the
> +transparency of the project.  By default, everything should be done in
> +public.  We decided to try some major changes to email and such.
> +
> +<!-- more -->
> +
> +## Security Releases
> +
> +First, a short item. We are changing our release schedule so that unless
> +there are extenuating circumstances, security releases will go out on
> +Tuesday, with the pre-notification being the previous Tuesday. We don't
> see
> +a need to have people ready to sacrifice their weekend every time a new
> CVE
> +comes out (see our
> +<a href="https://www.openssl.org/policies/secpolicy.html">security
> policy</a>
> +for details).
> +
> +On the other hand, a Heartbleed-style vulnerability that has known
> exploits
> +would a good example of an extenuating circumstance.
> +
> +## Online communication
> +
> +We created a new mailing list,
> +<a href="https://mta.openssl.org/mailman/listinfo/openssl-project
> ">openssl-project</a>,
> +that is for discussions about the governance and policies of OpenSSL.
> +Anyone can join this list.  Initially, only members of the OMC and
> committers
> +will be able to post; everyone else will be moderated.
> +At first glance, this seems to go against our goal of more transparency.
> +We want this to be a useful list for the project members to communicate in
> +public -- like many Parliaments, for example, where debate is public but
> the
> +public doesn't speak.
> +
> +Still, not everyone is completely comfortable with this, and some have
> said
> +that they will basically approve any posting held for moderation.
> +It's an experiment, and if we can open the list for public posting,
> without
> +getting drowned out, we'll do so.  Note that all OMC vote results will be
> +posted here, as will initial discussions about vote topics.  One
> important item
> +that will be discussed on this list is planning for upcoming releases.
> +Also, our paid fellows will be posting monthly status reports there.
> +
> +We decided to increase our use of GitHub. In addition to asking that all
> +bug reports and enhancement requests be reported as issues, we now want
> all
> +major code proposals to be discussed as issues before a large pull request
> +shows up. This will let the community discuss the feature, offer input on
> +design and such, before having code to look at.  We hope this will let us
> +all first look at the bigger picture, before getting bogged down in the
> +weeds of line-by-line code reviews.
> +
> +We are going to close the openssl-dev mailing list. The distinction
> between
> +openssl-dev and openssl-users was often unclear, and the changes described
> +above will make that situation worse. GitHub issues are the way
> +most projects work these days, and with the creation of openssl-project it
> +should be much more clear how and when to use the openssl-users mailing
> +list.
> +
> +If our expectations are wrong, of course, we'll fix or revert these
> +changes.
> +
> +## Cryptography Policies
> +
> +Part of our discussions were about our mission.
> +
> +- What security properties are we trying to provide our users?
> +- Do we see ourselves as responsbile for keeping the ecosystem secure?
> +- Are we a TLS toolkit or a "it's all there" crypto toolkit?
> +- And so on...
> +
> +While discussing these questions, we came up with a few policy decisions.
> +These apply to all new cryptography, and in a future release we will
> address
> +the existing source.
> +
> +- Insecure configuration options will not be enabled by default but must
> +be enabled by a compile-time switch. We had already started to do this by
> +disabling SSLv2 and small keys. A recent change is that "multi-prime RSA"
> +will enforce a maximum number of prime factors by default.  In the future,
> +it's possible we'll increase the minimum key sizes for a variety of
> algorithms.
> +
> +- It must be possible to disable all new algorithms at compile-time.
> +When we extend that existing code, we'll probably skip cases that are
> known
> +to not work. Building OpenSSL without SHA will break libssl, so it's not
> worth
> +spending time on that.
> +
> +- The EVP interface is the primary interface for calling crypto
> operations.
> +All new algorithms should only provide this API.
> +In a future release, existing API's like ``AES_encrypt`` will be provided
> +with a compatibility layer, perhaps separately, that wraps the EVP API.
> +
> +- All algorithms and protocols should be recognized by a national or
> +international standards body. That is somewhat vague, but the important
> +point is that we are implementors, not cryptographers, and will defer
> +judgement to experts.
> +
> +- The DEFAULT value for the cipher string is not the same as ALL.
> +That is, while many ciphers will be available to the libraries, they will
> +not be enabled at the TLS layer unless specified at run-time.
> +This brought up the point that the syntax of the cipher string cannot
> +support the things people need it to do, including "cipher classes,"
> +custom keywords, and site-wide configurations.
> +
> +## Roadmap
> +
> +We remain committed to having TLS 1.3 be the main feature for our next
> +release. Of course we must wait for the IETF to finish it. We'll again
> +point out that this is version 1.1.1, and you should get your applications
> +ready by porting to 1.1.0 now.
> +
> +We reviewed the status of our license-change work. We'll post an update in
> +a couple of weeks, but our goal is to change the license with this next
> +release.
> +
> +We also decided that the primary focus of the next feature release will be
> +FIPS. We know that FIPS is very important to some, not all, members of our
> +community and we are committed to addressing this. We don't have much more
> +information to share, and we know there has been some confusion and
> +misleading communication out there. But we do want to make this strong,
> +definitive statement: OpenSSL will implement a FIPS solution, and we
> expect
> +it will be much faster than previous timetables.
>
>
> _______________________________________________
> openssl-project mailing list
> openssl-project at openssl.org
> https://mta.openssl.org/mailman/listinfo/openssl-project
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-project/attachments/20180103/a930de66/attachment.html>

From kurt at roeckx.be  Tue Jan  2 21:52:11 2018
From: kurt at roeckx.be (Kurt Roeckx)
Date: Tue, 2 Jan 2018 22:52:11 +0100
Subject: [openssl-project] As per vote, the project list is created
In-Reply-To: <9613CAF7-E255-4DD7-B71C-13C98EBE369F@akamai.com>
References: <20171222.093842.494904828507959326.levitte@openssl.org>
 <20171222105738.GA17869@roeckx.be>
 <20171222.154817.100546507567267849.levitte@openssl.org>
 <7ce371db-4487-4bab-a415-61ee1b122337@default>
 <9613CAF7-E255-4DD7-B71C-13C98EBE369F@akamai.com>
Message-ID: <20180102215211.GA6252@roeckx.be>

On Tue, Jan 02, 2018 at 08:42:31PM +0000, Salz, Rich wrote:
> I wrote a draft blog post.  If anyone on the OMC wants to edit and put their name on it, or suggest edits and I post it, that?s fine with me.

I really think we should mail the existing lists about the
creation of that list. I doubt there are many people that read the
blog.


Kurt


From mark at awe.com  Wed Jan  3 13:04:51 2018
From: mark at awe.com (Mark J Cox)
Date: Wed, 3 Jan 2018 13:04:51 +0000
Subject: [openssl-project] As per vote, the project list is created
In-Reply-To: <9613CAF7-E255-4DD7-B71C-13C98EBE369F@akamai.com>
References: <20171222.093842.494904828507959326.levitte@openssl.org>
 <20171222105738.GA17869@roeckx.be>
 <20171222.154817.100546507567267849.levitte@openssl.org>
 <7ce371db-4487-4bab-a415-61ee1b122337@default>
 <9613CAF7-E255-4DD7-B71C-13C98EBE369F@akamai.com>
Message-ID: <CABU6YOaNUGaUf2btHuJP2H-Q=2Dxa0p_pqk+KyaU4npu-k=8xA@mail.gmail.com>

Would be nice to add the group photo, did we get one that worked out ok Richard?

Mark

On Tue, Jan 2, 2018 at 8:42 PM, Salz, Rich <rsalz at akamai.com> wrote:
> I wrote a draft blog post.  If anyone on the OMC wants to edit and put their name on it, or suggest edits and I post it, that?s fine with me.
>
> On 1/1/18, 7:30 PM, "Paul Dale" <paul.dale at oracle.com> wrote:
>
>     A concurrent update for the mailing list page: https://www.openssl.org/community/mailinglists.html too?
>
>     Pauli
>     --
>     Oracle
>     Dr Paul Dale | Cryptographer | Network Security & Encryption
>     Phone +61 7 3031 7217
>     Oracle Australia
>
>     -----Original Message-----
>     From: Richard Levitte [mailto:levitte at openssl.org]
>     Sent: Saturday, 23 December 2017 12:48 AM
>     To: openssl-project at openssl.org
>     Subject: Re: [openssl-project] As per vote, the project list is created
>
>     In message <20171222105738.GA17869 at roeckx.be> on Fri, 22 Dec 2017 11:57:38 +0100, Kurt Roeckx <kurt at roeckx.be> said:
>
>     kurt> You should probably announce this new list more widely
>
>     Agreed.  Wasn't someone going to make a blog post about it?  Or was that just a general "we should" where noone actually said "I will"?
>     For if no one feels they've taken that on, I will ;-)
>
>     --
>     Richard Levitte         levitte at openssl.org
>     OpenSSL Project         http://www.openssl.org/~levitte/
>     _______________________________________________
>     openssl-project mailing list
>     openssl-project at openssl.org
>     https://mta.openssl.org/mailman/listinfo/openssl-project
>     _______________________________________________
>     openssl-project mailing list
>     openssl-project at openssl.org
>     https://mta.openssl.org/mailman/listinfo/openssl-project
>
>
>
>
> ---------- Forwarded message ----------
> From: Rich Salz <rsalz at openssl.org>
> To: <openssl-omc at openssl.org>
> Cc:
> Bcc:
> Date: Tue, 2 Jan 2018 20:41:12 +0000
> Subject: [openssl-omc] [blog] master update
> The branch master has been updated
>        via  90a4eb9e289be237bc80dc5393d32e79b2d7b001 (commit)
>       from  0c536ced1e9bb1684ddf60af42e236dd69d3dd52 (commit)
>
>
> - Log -----------------------------------------------------------------
> commit 90a4eb9e289be237bc80dc5393d32e79b2d7b001
> Author: Rich Salz <rsalz at akamai.com>
> Date:   Tue Jan 2 15:39:37 2018 -0500
>
>     Draft of F2F blog post
>
> -----------------------------------------------------------------------
>
> Summary of changes:
>  source/_posts/2018-01-04-f2f-email-etc.markdown | 130 ++++++++++++++++++++++++
>  1 file changed, 130 insertions(+)
>  create mode 100644 source/_posts/2018-01-04-f2f-email-etc.markdown
>
> diff --git a/source/_posts/2018-01-04-f2f-email-etc.markdown b/source/_posts/2018-01-04-f2f-email-etc.markdown
> new file mode 100644
> index 0000000..c62a133
> --- /dev/null
> +++ b/source/_posts/2018-01-04-f2f-email-etc.markdown
> @@ -0,0 +1,130 @@
> +---
> +layout: post
> +title: "Another Face to Face: Email changes and crypto policy"
> +date: 2018-01-04 1:00
> +comments: true
> +author: "???"
> +published: false
> +---
> +
> +The OpenSSL OMC met last month for a two-day face-to-face meeting, and
> +like previous F2F meetings, most of the team was present and we got a
> +great deal of issues addressed.  This blog posts talks about some of them,
> +and most of the others will get their own blog posts, or notices, later.
> +
> +One of the overall threads of the meeting was about increasing the
> +transparency of the project.  By default, everything should be done in
> +public.  We decided to try some major changes to email and such.
> +
> +<!-- more -->
> +
> +## Security Releases
> +
> +First, a short item. We are changing our release schedule so that unless
> +there are extenuating circumstances, security releases will go out on
> +Tuesday, with the pre-notification being the previous Tuesday. We don't see
> +a need to have people ready to sacrifice their weekend every time a new CVE
> +comes out (see our
> +<a href="https://www.openssl.org/policies/secpolicy.html">security policy</a>
> +for details).
> +
> +On the other hand, a Heartbleed-style vulnerability that has known exploits
> +would a good example of an extenuating circumstance.
> +
> +## Online communication
> +
> +We created a new mailing list,
> +<a href="https://mta.openssl.org/mailman/listinfo/openssl-project">openssl-project</a>,
> +that is for discussions about the governance and policies of OpenSSL.
> +Anyone can join this list.  Initially, only members of the OMC and committers
> +will be able to post; everyone else will be moderated.
> +At first glance, this seems to go against our goal of more transparency.
> +We want this to be a useful list for the project members to communicate in
> +public -- like many Parliaments, for example, where debate is public but the
> +public doesn't speak.
> +
> +Still, not everyone is completely comfortable with this, and some have said
> +that they will basically approve any posting held for moderation.
> +It's an experiment, and if we can open the list for public posting, without
> +getting drowned out, we'll do so.  Note that all OMC vote results will be
> +posted here, as will initial discussions about vote topics.  One important item
> +that will be discussed on this list is planning for upcoming releases.
> +Also, our paid fellows will be posting monthly status reports there.
> +
> +We decided to increase our use of GitHub. In addition to asking that all
> +bug reports and enhancement requests be reported as issues, we now want all
> +major code proposals to be discussed as issues before a large pull request
> +shows up. This will let the community discuss the feature, offer input on
> +design and such, before having code to look at.  We hope this will let us
> +all first look at the bigger picture, before getting bogged down in the
> +weeds of line-by-line code reviews.
> +
> +We are going to close the openssl-dev mailing list. The distinction between
> +openssl-dev and openssl-users was often unclear, and the changes described
> +above will make that situation worse. GitHub issues are the way
> +most projects work these days, and with the creation of openssl-project it
> +should be much more clear how and when to use the openssl-users mailing
> +list.
> +
> +If our expectations are wrong, of course, we'll fix or revert these
> +changes.
> +
> +## Cryptography Policies
> +
> +Part of our discussions were about our mission.
> +
> +- What security properties are we trying to provide our users?
> +- Do we see ourselves as responsbile for keeping the ecosystem secure?
> +- Are we a TLS toolkit or a "it's all there" crypto toolkit?
> +- And so on...
> +
> +While discussing these questions, we came up with a few policy decisions.
> +These apply to all new cryptography, and in a future release we will address
> +the existing source.
> +
> +- Insecure configuration options will not be enabled by default but must
> +be enabled by a compile-time switch. We had already started to do this by
> +disabling SSLv2 and small keys. A recent change is that "multi-prime RSA"
> +will enforce a maximum number of prime factors by default.  In the future,
> +it's possible we'll increase the minimum key sizes for a variety of algorithms.
> +
> +- It must be possible to disable all new algorithms at compile-time.
> +When we extend that existing code, we'll probably skip cases that are known
> +to not work. Building OpenSSL without SHA will break libssl, so it's not worth
> +spending time on that.
> +
> +- The EVP interface is the primary interface for calling crypto operations.
> +All new algorithms should only provide this API.
> +In a future release, existing API's like ``AES_encrypt`` will be provided
> +with a compatibility layer, perhaps separately, that wraps the EVP API.
> +
> +- All algorithms and protocols should be recognized by a national or
> +international standards body. That is somewhat vague, but the important
> +point is that we are implementors, not cryptographers, and will defer
> +judgement to experts.
> +
> +- The DEFAULT value for the cipher string is not the same as ALL.
> +That is, while many ciphers will be available to the libraries, they will
> +not be enabled at the TLS layer unless specified at run-time.
> +This brought up the point that the syntax of the cipher string cannot
> +support the things people need it to do, including "cipher classes,"
> +custom keywords, and site-wide configurations.
> +
> +## Roadmap
> +
> +We remain committed to having TLS 1.3 be the main feature for our next
> +release. Of course we must wait for the IETF to finish it. We'll again
> +point out that this is version 1.1.1, and you should get your applications
> +ready by porting to 1.1.0 now.
> +
> +We reviewed the status of our license-change work. We'll post an update in
> +a couple of weeks, but our goal is to change the license with this next
> +release.
> +
> +We also decided that the primary focus of the next feature release will be
> +FIPS. We know that FIPS is very important to some, not all, members of our
> +community and we are committed to addressing this. We don't have much more
> +information to share, and we know there has been some confusion and
> +misleading communication out there. But we do want to make this strong,
> +definitive statement: OpenSSL will implement a FIPS solution, and we expect
> +it will be much faster than previous timetables.
>
>
> _______________________________________________
> openssl-project mailing list
> openssl-project at openssl.org
> https://mta.openssl.org/mailman/listinfo/openssl-project

From rsalz at akamai.com  Wed Jan  3 13:25:41 2018
From: rsalz at akamai.com (Salz, Rich)
Date: Wed, 3 Jan 2018 13:25:41 +0000
Subject: [openssl-project] As per vote, the project list is created
In-Reply-To: <CAHEJ-S7LLWh_BUn1YyhQQqr1e8eTaRhn+4JVSARXdYrMr=L15g@mail.gmail.com>
References: <20171222.093842.494904828507959326.levitte@openssl.org>
 <20171222105738.GA17869@roeckx.be>
 <20171222.154817.100546507567267849.levitte@openssl.org>
 <7ce371db-4487-4bab-a415-61ee1b122337@default>
 <9613CAF7-E255-4DD7-B71C-13C98EBE369F@akamai.com>
 <CAHEJ-S7LLWh_BUn1YyhQQqr1e8eTaRhn+4JVSARXdYrMr=L15g@mail.gmail.com>
Message-ID: <D2F6850E-A68B-4A5A-81B0-5B72A7D68BE9@akamai.com>

Posting it under the OMC byline is a good idea.  Voting is therefore necessary, albeit slows the process.

I posted it to the same forum we posted the f2f minutes.

From: Tim Hudson <tjh at cryptsoft.com>
Reply-To: "openssl-project at openssl.org" <openssl-project at openssl.org>
Date: Tuesday, January 2, 2018 at 4:20 PM
To: "openssl-project at openssl.org" <openssl-project at openssl.org>
Subject: Re: [openssl-project] As per vote, the project list is created

I've added some edits to make it align more closely with the discussion and correct a couple of items.

I think it should go out from the OMC as a whole - which does mean that everyone should view it - and if we are sending as OMC then it should be on the basis of a vote (so we are not placing words in the mouths of people who haven't read and approved the wording).

I also wouldn't have sent the draft blog post to the public as yet ...

Tim.



On Wed, Jan 3, 2018 at 6:42 AM, Salz, Rich <rsalz at akamai.com<mailto:rsalz at akamai.com>> wrote:
I wrote a draft blog post.  If anyone on the OMC wants to edit and put their name on it, or suggest edits and I post it, that?s fine with me.

On 1/1/18, 7:30 PM, "Paul Dale" <paul.dale at oracle.com<mailto:paul.dale at oracle.com>> wrote:

    A concurrent update for the mailing list page: https://www.openssl.org/community/mailinglists.html<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.openssl.org_community_mailinglists.html&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=4LM0GbR0h9Fvx86FtsKI-w&m=bCenl7PqC9RkkY0AbjQTONSxCY4ZVpQGhvfnOC1PuV8&s=-6BXUnzIYRXox9CT_3Xe9SacmTI0-3rKdyRQgbsZYRY&e=> too?

    Pauli
    --
    Oracle
    Dr Paul Dale | Cryptographer | Network Security & Encryption
    Phone +61 7 3031 7217<tel:%2B61%207%203031%207217>
    Oracle Australia

    -----Original Message-----
    From: Richard Levitte [mailto:levitte at openssl.org<mailto:levitte at openssl.org>]
    Sent: Saturday, 23 December 2017 12:48 AM
    To: openssl-project at openssl.org<mailto:openssl-project at openssl.org>
    Subject: Re: [openssl-project] As per vote, the project list is created

    In message <20171222105738.GA17869 at roeckx.be<mailto:20171222105738.GA17869 at roeckx.be>> on Fri, 22 Dec 2017 11:57:38 +0100, Kurt Roeckx <kurt at roeckx.be<mailto:kurt at roeckx.be>> said:

    kurt> You should probably announce this new list more widely

    Agreed.  Wasn't someone going to make a blog post about it?  Or was that just a general "we should" where noone actually said "I will"?
    For if no one feels they've taken that on, I will ;-)

    --
    Richard Levitte         levitte at openssl.org<mailto:levitte at openssl.org>
    OpenSSL Project         http://www.openssl.org/~levitte/<https://urldefense.proofpoint.com/v2/url?u=http-3A__www.openssl.org_-7Elevitte_&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=4LM0GbR0h9Fvx86FtsKI-w&m=bCenl7PqC9RkkY0AbjQTONSxCY4ZVpQGhvfnOC1PuV8&s=GTur4qcW33Vlkb3WZa6TYRZwxeCybTFRjlBkrafUH3E&e=>
    _______________________________________________
    openssl-project mailing list
    openssl-project at openssl.org<mailto:openssl-project at openssl.org>
    https://mta.openssl.org/mailman/listinfo/openssl-project<https://urldefense.proofpoint.com/v2/url?u=https-3A__mta.openssl.org_mailman_listinfo_openssl-2Dproject&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=4LM0GbR0h9Fvx86FtsKI-w&m=bCenl7PqC9RkkY0AbjQTONSxCY4ZVpQGhvfnOC1PuV8&s=s57Iml_loafNnRSg8V0mTuJ9D03oyUKGmV4gveWO_10&e=>
    _______________________________________________
    openssl-project mailing list
    openssl-project at openssl.org<mailto:openssl-project at openssl.org>
    https://mta.openssl.org/mailman/listinfo/openssl-project<https://urldefense.proofpoint.com/v2/url?u=https-3A__mta.openssl.org_mailman_listinfo_openssl-2Dproject&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=4LM0GbR0h9Fvx86FtsKI-w&m=bCenl7PqC9RkkY0AbjQTONSxCY4ZVpQGhvfnOC1PuV8&s=s57Iml_loafNnRSg8V0mTuJ9D03oyUKGmV4gveWO_10&e=>



---------- Forwarded message ----------
From: Rich Salz <rsalz at openssl.org<mailto:rsalz at openssl.org>>
To: <openssl-omc at openssl.org<mailto:openssl-omc at openssl.org>>
Cc:
Bcc:
Date: Tue, 2 Jan 2018 20:41:12 +0000
Subject: [openssl-omc] [blog] master update
The branch master has been updated
       via  90a4eb9e289be237bc80dc5393d32e79b2d7b001 (commit)
      from  0c536ced1e9bb1684ddf60af42e236dd69d3dd52 (commit)


- Log -----------------------------------------------------------------
commit 90a4eb9e289be237bc80dc5393d32e79b2d7b001
Author: Rich Salz <rsalz at akamai.com<mailto:rsalz at akamai.com>>
Date:   Tue Jan 2 15:39:37 2018 -0500

    Draft of F2F blog post

-----------------------------------------------------------------------

Summary of changes:
 source/_posts/2018-01-04-f2f-email-etc.markdown | 130 ++++++++++++++++++++++++
 1 file changed, 130 insertions(+)
 create mode 100644 source/_posts/2018-01-04-f2f-email-etc.markdown

diff --git a/source/_posts/2018-01-04-f2f-email-etc.markdown b/source/_posts/2018-01-04-f2f-email-etc.markdown
new file mode 100644
index 0000000..c62a133
--- /dev/null
+++ b/source/_posts/2018-01-04-f2f-email-etc.markdown
@@ -0,0 +1,130 @@
+---
+layout: post
+title: "Another Face to Face: Email changes and crypto policy"
+date: 2018-01-04 1:00
+comments: true
+author: "???"
+published: false
+---
+
+The OpenSSL OMC met last month for a two-day face-to-face meeting, and
+like previous F2F meetings, most of the team was present and we got a
+great deal of issues addressed.  This blog posts talks about some of them,
+and most of the others will get their own blog posts, or notices, later.
+
+One of the overall threads of the meeting was about increasing the
+transparency of the project.  By default, everything should be done in
+public.  We decided to try some major changes to email and such.
+
+<!-- more -->
+
+## Security Releases
+
+First, a short item. We are changing our release schedule so that unless
+there are extenuating circumstances, security releases will go out on
+Tuesday, with the pre-notification being the previous Tuesday. We don't see
+a need to have people ready to sacrifice their weekend every time a new CVE
+comes out (see our
+<a href="https://www.openssl.org/policies/secpolicy.html<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.openssl.org_policies_secpolicy.html&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=4LM0GbR0h9Fvx86FtsKI-w&m=bCenl7PqC9RkkY0AbjQTONSxCY4ZVpQGhvfnOC1PuV8&s=Rs8DaMxNIa7kUegk74aQxatTQE08R7LqNIs8tInPChg&e=>">security policy</a>
+for details).
+
+On the other hand, a Heartbleed-style vulnerability that has known exploits
+would a good example of an extenuating circumstance.
+
+## Online communication
+
+We created a new mailing list,
+<a href="https://mta.openssl.org/mailman/listinfo/openssl-project<https://urldefense.proofpoint.com/v2/url?u=https-3A__mta.openssl.org_mailman_listinfo_openssl-2Dproject&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=4LM0GbR0h9Fvx86FtsKI-w&m=bCenl7PqC9RkkY0AbjQTONSxCY4ZVpQGhvfnOC1PuV8&s=s57Iml_loafNnRSg8V0mTuJ9D03oyUKGmV4gveWO_10&e=>">openssl-project</a>,
+that is for discussions about the governance and policies of OpenSSL.
+Anyone can join this list.  Initially, only members of the OMC and committers
+will be able to post; everyone else will be moderated.
+At first glance, this seems to go against our goal of more transparency.
+We want this to be a useful list for the project members to communicate in
+public -- like many Parliaments, for example, where debate is public but the
+public doesn't speak.
+
+Still, not everyone is completely comfortable with this, and some have said
+that they will basically approve any posting held for moderation.
+It's an experiment, and if we can open the list for public posting, without
+getting drowned out, we'll do so.  Note that all OMC vote results will be
+posted here, as will initial discussions about vote topics.  One important item
+that will be discussed on this list is planning for upcoming releases.
+Also, our paid fellows will be posting monthly status reports there.
+
+We decided to increase our use of GitHub. In addition to asking that all
+bug reports and enhancement requests be reported as issues, we now want all
+major code proposals to be discussed as issues before a large pull request
+shows up. This will let the community discuss the feature, offer input on
+design and such, before having code to look at.  We hope this will let us
+all first look at the bigger picture, before getting bogged down in the
+weeds of line-by-line code reviews.
+
+We are going to close the openssl-dev mailing list. The distinction between
+openssl-dev and openssl-users was often unclear, and the changes described
+above will make that situation worse. GitHub issues are the way
+most projects work these days, and with the creation of openssl-project it
+should be much more clear how and when to use the openssl-users mailing
+list.
+
+If our expectations are wrong, of course, we'll fix or revert these
+changes.
+
+## Cryptography Policies
+
+Part of our discussions were about our mission.
+
+- What security properties are we trying to provide our users?
+- Do we see ourselves as responsbile for keeping the ecosystem secure?
+- Are we a TLS toolkit or a "it's all there" crypto toolkit?
+- And so on...
+
+While discussing these questions, we came up with a few policy decisions.
+These apply to all new cryptography, and in a future release we will address
+the existing source.
+
+- Insecure configuration options will not be enabled by default but must
+be enabled by a compile-time switch. We had already started to do this by
+disabling SSLv2 and small keys. A recent change is that "multi-prime RSA"
+will enforce a maximum number of prime factors by default.  In the future,
+it's possible we'll increase the minimum key sizes for a variety of algorithms.
+
+- It must be possible to disable all new algorithms at compile-time.
+When we extend that existing code, we'll probably skip cases that are known
+to not work. Building OpenSSL without SHA will break libssl, so it's not worth
+spending time on that.
+
+- The EVP interface is the primary interface for calling crypto operations.
+All new algorithms should only provide this API.
+In a future release, existing API's like ``AES_encrypt`` will be provided
+with a compatibility layer, perhaps separately, that wraps the EVP API.
+
+- All algorithms and protocols should be recognized by a national or
+international standards body. That is somewhat vague, but the important
+point is that we are implementors, not cryptographers, and will defer
+judgement to experts.
+
+- The DEFAULT value for the cipher string is not the same as ALL.
+That is, while many ciphers will be available to the libraries, they will
+not be enabled at the TLS layer unless specified at run-time.
+This brought up the point that the syntax of the cipher string cannot
+support the things people need it to do, including "cipher classes,"
+custom keywords, and site-wide configurations.
+
+## Roadmap
+
+We remain committed to having TLS 1.3 be the main feature for our next
+release. Of course we must wait for the IETF to finish it. We'll again
+point out that this is version 1.1.1, and you should get your applications
+ready by porting to 1.1.0 now.
+
+We reviewed the status of our license-change work. We'll post an update in
+a couple of weeks, but our goal is to change the license with this next
+release.
+
+We also decided that the primary focus of the next feature release will be
+FIPS. We know that FIPS is very important to some, not all, members of our
+community and we are committed to addressing this. We don't have much more
+information to share, and we know there has been some confusion and
+misleading communication out there. But we do want to make this strong,
+definitive statement: OpenSSL will implement a FIPS solution, and we expect
+it will be much faster than previous timetables.


_______________________________________________
openssl-project mailing list
openssl-project at openssl.org<mailto:openssl-project at openssl.org>
https://mta.openssl.org/mailman/listinfo/openssl-project<https://urldefense.proofpoint.com/v2/url?u=https-3A__mta.openssl.org_mailman_listinfo_openssl-2Dproject&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=4LM0GbR0h9Fvx86FtsKI-w&m=bCenl7PqC9RkkY0AbjQTONSxCY4ZVpQGhvfnOC1PuV8&s=s57Iml_loafNnRSg8V0mTuJ9D03oyUKGmV4gveWO_10&e=>

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

From rsalz at akamai.com  Wed Jan  3 13:27:23 2018
From: rsalz at akamai.com (Salz, Rich)
Date: Wed, 3 Jan 2018 13:27:23 +0000
Subject: [openssl-project] As per vote, the project list is created
In-Reply-To: <20180102215211.GA6252@roeckx.be>
References: <20171222.093842.494904828507959326.levitte@openssl.org>
 <20171222105738.GA17869@roeckx.be>
 <20171222.154817.100546507567267849.levitte@openssl.org>
 <7ce371db-4487-4bab-a415-61ee1b122337@default>
 <9613CAF7-E255-4DD7-B71C-13C98EBE369F@akamai.com>
 <20180102215211.GA6252@roeckx.be>
Message-ID: <5EDA6F80-689C-453A-9EEE-FC8C5C49D34B@akamai.com>

We should definitely post a note when we post a blog entry.

On 1/2/18, 4:52 PM, "Kurt Roeckx" <kurt at roeckx.be> wrote:

    On Tue, Jan 02, 2018 at 08:42:31PM +0000, Salz, Rich wrote:
    > I wrote a draft blog post.  If anyone on the OMC wants to edit and put their name on it, or suggest edits and I post it, that?s fine with me.
    
    I really think we should mail the existing lists about the
    creation of that list. I doubt there are many people that read the
    blog.
    
    
    Kurt
    
    _______________________________________________
    openssl-project mailing list
    openssl-project at openssl.org
    https://mta.openssl.org/mailman/listinfo/openssl-project


From matt at openssl.org  Wed Jan  3 17:16:40 2018
From: matt at openssl.org (Matt Caswell)
Date: Wed, 3 Jan 2018 17:16:40 +0000
Subject: [openssl-project] Red Hat Podcast interview
In-Reply-To: <0a1e2a47-9dc2-e7c9-f47b-8bd7dc0113f2@openssl.org>
References: <0a1e2a47-9dc2-e7c9-f47b-8bd7dc0113f2@openssl.org>
Message-ID: <20ec393d-c789-de4e-0a5e-cdb3eb72bbac@openssl.org>



On 23/12/17 00:40, Matt Caswell wrote:
> FYI, I have been invited to take part in a podcast for Red Hat. They are
> working on a series of episodes one of which will be focused on
> security. They are coming to record the audio in early January. Not sure
> when the episode will be made available but I'll let you know when I
> find out.

I did this interview today. Unfortunately the guy interviewing me wasn't
an IT guy so just had a scripted list of questions which almost all
included the word "heartbleed" :-(

I did my best to talk about some of the good stuff we've done since
then. Not sure how it will turn out.

Matt


From rsalz at akamai.com  Wed Jan  3 19:57:21 2018
From: rsalz at akamai.com (Salz, Rich)
Date: Wed, 3 Jan 2018 19:57:21 +0000
Subject: [openssl-project] Policy update
In-Reply-To: <20171222142850.GA23195@roeckx.be>
References: <20171222142850.GA23195@roeckx.be>
Message-ID: <F158DB5D-4377-4A32-83CD-F594F6682755@akamai.com>

I am less concerned about adding datatypes than I am about adding algorithms and protocols.  It is hard for a user to make themselves less secure by configuring a datatype.

Do you have substantive issues with the decisions? I  agree the wording can be improved.

There is an action item (assigned to me, anyone should feel free to pick it up) to turn the policy declarations into a strawman mission statement.


On 12/22/17, 9:29 AM, "Kurt Roeckx" <kurt at roeckx.be> wrote:

    Hi,
    
    During our face 2 face meeting last week we talked about the
    direction we want to move in, and the policy we'll use to get
    there. This are the current proposals:
    - Insecure configuration options shall not be enabled by default;
      they must be enabled by a compile-time switch. This applies to all
      new contributions and existing code should be addressed at the
      next major (1.2.0) release.
    - All new algorithms must be disableable at compile-time. With the
      exception of known not-to-work when disabled RSA SHA1 MD5 AES,
      existing code should be addressed at the next major (1.2.0)
      release. (PR?s to fix those welcome).
    - All algorithms and protocols should be recognized by a national or
      international standards body. This applies to all new
      contributions and existing code should be addressed at the next
      major (1.2.0) release.
    - The EVP interface should be the primary interface for calling
      crypto operations. All new contributions should only export this
      API and existing code should be addressed at the next major
      (1.2.0) release, and might include a compatibility layer.
    
    I think at least the wording could be improved. For instance, it
    says "All [new] algorithms and protocols must be disableable". I
    assume it means cryptographic algorithms, like AES, SHA2, HMAC, ...
    Does something like CMS and X509 fall under that? It doesn't sound
    like an algorithm to me, and protocol also doesn't seem like the
    correct word. The same goes for the "All algorithms and protocols
    should be [standardised]".
    
    On a related topic, I think there has been a suggestion that we
    should work on not exposing such compile time options in the
    public headers but that applications should do runtime detection
    of the available features instead.
    
    
    Kurt
    
    _______________________________________________
    openssl-project mailing list
    openssl-project at openssl.org
    https://mta.openssl.org/mailman/listinfo/openssl-project


From kurt at roeckx.be  Wed Jan  3 21:10:26 2018
From: kurt at roeckx.be (Kurt Roeckx)
Date: Wed, 3 Jan 2018 22:10:26 +0100
Subject: [openssl-project] Policy update
In-Reply-To: <F158DB5D-4377-4A32-83CD-F594F6682755@akamai.com>
References: <20171222142850.GA23195@roeckx.be>
 <F158DB5D-4377-4A32-83CD-F594F6682755@akamai.com>
Message-ID: <20180103211025.GA10981@roeckx.be>

On Wed, Jan 03, 2018 at 07:57:21PM +0000, Salz, Rich wrote:
> I am less concerned about adding datatypes than I am about adding algorithms and protocols.  It is hard for a user to make themselves less secure by configuring a datatype.

I think we currently support some microsoft encrypted key format
which we reversed engineered, which clearly won't be recognized by
some standards body. But it also says "should". So maybe that can
be an exception?

Which at least makes me wonder when exceptions would be allowed and
how that should be decided. Should we document the exceptions in the
policy, and have the OMC vote on it? Or is that too bureaucratic?
It would at least be clear and something we can point people too.
I guess we can just delay this until it actually comes up.

> Do you have substantive issues with the decisions? I  agree the wording can be improved.

No, I think the wording should just be made clear what we mean
exactly.


Kurt


From rsalz at akamai.com  Wed Jan  3 21:17:09 2018
From: rsalz at akamai.com (Salz, Rich)
Date: Wed, 3 Jan 2018 21:17:09 +0000
Subject: [openssl-project] Policy update
In-Reply-To: <20180103211025.GA10981@roeckx.be>
References: <20171222142850.GA23195@roeckx.be>
 <F158DB5D-4377-4A32-83CD-F594F6682755@akamai.com>
 <20180103211025.GA10981@roeckx.be>
Message-ID: <67F29BBD-2A94-4C61-9DD7-A9084BE72503@akamai.com>

? I think we currently support some microsoft encrypted key format
    which we reversed engineered, which clearly won't be recognized by
    some standards body. But it also says "should". So maybe that can
    be an exception?
    
Well, each item does have an escape hatch saying the existing code base will be addressed in the future.  But you are correct, a private key format could bring up some issues.

? No, I think the wording should just be made clear what we mean
    exactly.

I agree.  


From kurt at roeckx.be  Fri Jan  5 22:53:11 2018
From: kurt at roeckx.be (Kurt Roeckx)
Date: Fri, 5 Jan 2018 23:53:11 +0100
Subject: [openssl-project] Policy update
In-Reply-To: <20171222142850.GA23195@roeckx.be>
References: <20171222142850.GA23195@roeckx.be>
Message-ID: <20180105225310.GA21843@roeckx.be>

On Fri, Dec 22, 2017 at 03:28:50PM +0100, Kurt Roeckx wrote:
> Hi,
> 
> During our face 2 face meeting last week we talked about the
> direction we want to move in, and the policy we'll use to get
> there. This are the current proposals:
> - Insecure configuration options shall not be enabled by default;
>   they must be enabled by a compile-time switch. This applies to all
>   new contributions and existing code should be addressed at the
>   next major (1.2.0) release.
> - All new algorithms must be disableable at compile-time. With the
>   exception of known not-to-work when disabled RSA SHA1 MD5 AES,
>   existing code should be addressed at the next major (1.2.0)
>   release. (PR?s to fix those welcome).
> - All algorithms and protocols should be recognized by a national or
>   international standards body. This applies to all new
>   contributions and existing code should be addressed at the next
>   major (1.2.0) release.

Maybe we should also add wording that we might have other reasons
to not add something and that those are just minimum requirements.

We might also want to add that we see a clear need for (some of) our
users to have it.


Kurt


From rsalz at akamai.com  Sat Jan  6 00:07:53 2018
From: rsalz at akamai.com (Salz, Rich)
Date: Sat, 6 Jan 2018 00:07:53 +0000
Subject: [openssl-project] Policy update
In-Reply-To: <20180105225310.GA21843@roeckx.be>
References: <20171222142850.GA23195@roeckx.be>
 <20180105225310.GA21843@roeckx.be>
Message-ID: <3AD3418C-2BF1-433A-9828-A6AFB56EDBAD@akamai.com>

?     Maybe we should also add wording that we might have other reasons
    to not add something and that those are just minimum requirements.
    

Yes, that?s a good point.  Additions must *at least* meet these requirements.

?     We might also want to add that we see a clear need for (some of) our
    users to have it.
    

Harder  to determine, but I?m not opposed.


From matt at openssl.org  Mon Jan  8 18:29:46 2018
From: matt at openssl.org (Matt Caswell)
Date: Mon, 8 Jan 2018 18:29:46 +0000
Subject: [openssl-project] This week
Message-ID: <1495b3e1-3e06-7a67-77b1-3d9e82a78681@openssl.org>

Tomorrow I will be travelling to the Real World Crypto conference in
Zurich, returning late on Friday. I expect to have internet access in
the hotel while I am away but expect my responses to be slower than
normal during the next few days.

Matt


From kaduk at mit.edu  Mon Jan  8 21:54:54 2018
From: kaduk at mit.edu (Benjamin Kaduk)
Date: Mon, 8 Jan 2018 15:54:54 -0600
Subject: [openssl-project] triaging issues for 1.1.1
Message-ID: <20180108215454.GH25484@kduck.kaduk.org>

I expect to have some time soon to start triaging github issues as
(non-)relevant for 1.1.1.  For isues that are relevant, the 1.1.1
label seems like the right indicator; how should we indicate issues
that are not relevant to 1.1.1?  The '1.2.0' or 'hold' labels could
be used, but it's not entirely clear that either is the best choice.

-Ben

From matt at openssl.org  Mon Jan  8 23:35:54 2018
From: matt at openssl.org (Matt Caswell)
Date: Mon, 8 Jan 2018 23:35:54 +0000
Subject: [openssl-project] triaging issues for 1.1.1
In-Reply-To: <20180108215454.GH25484@kduck.kaduk.org>
References: <20180108215454.GH25484@kduck.kaduk.org>
Message-ID: <9f0fb570-bd9e-5c1e-b103-84d50b51dfd5@openssl.org>

How about we create a "Post 1.1.1" label? I think we did something
similar for the 1.1.0 release.

Matt


On 08/01/18 21:54, Benjamin Kaduk wrote:
> I expect to have some time soon to start triaging github issues as
> (non-)relevant for 1.1.1.  For isues that are relevant, the 1.1.1
> label seems like the right indicator; how should we indicate issues
> that are not relevant to 1.1.1?  The '1.2.0' or 'hold' labels could
> be used, but it's not entirely clear that either is the best choice.
> 
> -Ben
> _______________________________________________
> openssl-project mailing list
> openssl-project at openssl.org
> https://mta.openssl.org/mailman/listinfo/openssl-project
> 

From kaduk at mit.edu  Tue Jan  9 00:18:46 2018
From: kaduk at mit.edu (Benjamin Kaduk)
Date: Mon, 8 Jan 2018 18:18:46 -0600
Subject: [openssl-project] triaging issues for 1.1.1
In-Reply-To: <9f0fb570-bd9e-5c1e-b103-84d50b51dfd5@openssl.org>
References: <20180108215454.GH25484@kduck.kaduk.org>
 <9f0fb570-bd9e-5c1e-b103-84d50b51dfd5@openssl.org>
Message-ID: <20180109001846.GJ25484@kduck.kaduk.org>

Sounds good to me ... label created.  Feel free to repaint the
bikeshed as needed.

-Ben

On Mon, Jan 08, 2018 at 11:35:54PM +0000, Matt Caswell wrote:
> How about we create a "Post 1.1.1" label? I think we did something
> similar for the 1.1.0 release.
> 
> Matt
> 
> 
> On 08/01/18 21:54, Benjamin Kaduk wrote:
> > I expect to have some time soon to start triaging github issues as
> > (non-)relevant for 1.1.1.  For isues that are relevant, the 1.1.1
> > label seems like the right indicator; how should we indicate issues
> > that are not relevant to 1.1.1?  The '1.2.0' or 'hold' labels could
> > be used, but it's not entirely clear that either is the best choice.
> > 
> > -Ben
> > _______________________________________________
> > openssl-project mailing list
> > openssl-project at openssl.org
> > https://mta.openssl.org/mailman/listinfo/openssl-project
> > 
> _______________________________________________
> openssl-project mailing list
> openssl-project at openssl.org
> https://mta.openssl.org/mailman/listinfo/openssl-project

From levitte at openssl.org  Tue Jan  9 02:41:49 2018
From: levitte at openssl.org (Richard Levitte)
Date: Tue, 09 Jan 2018 03:41:49 +0100 (CET)
Subject: [openssl-project] triaging issues for 1.1.1
In-Reply-To: <9f0fb570-bd9e-5c1e-b103-84d50b51dfd5@openssl.org>
References: <20180108215454.GH25484@kduck.kaduk.org>
 <9f0fb570-bd9e-5c1e-b103-84d50b51dfd5@openssl.org>
Message-ID: <20180109.034149.224166968907586177.levitte@openssl.org>

Actually, that's in the Milestones...  but we suck at using those,
sadly...

In message <9f0fb570-bd9e-5c1e-b103-84d50b51dfd5 at openssl.org> on Mon, 8 Jan 2018 23:35:54 +0000, Matt Caswell <matt at openssl.org> said:

matt> How about we create a "Post 1.1.1" label? I think we did something
matt> similar for the 1.1.0 release.
matt> 
matt> Matt
matt> 
matt> 
matt> On 08/01/18 21:54, Benjamin Kaduk wrote:
matt> > I expect to have some time soon to start triaging github issues as
matt> > (non-)relevant for 1.1.1.  For isues that are relevant, the 1.1.1
matt> > label seems like the right indicator; how should we indicate issues
matt> > that are not relevant to 1.1.1?  The '1.2.0' or 'hold' labels could
matt> > be used, but it's not entirely clear that either is the best choice.
matt> > 
matt> > -Ben
matt> > _______________________________________________
matt> > openssl-project mailing list
matt> > openssl-project at openssl.org
matt> > https://mta.openssl.org/mailman/listinfo/openssl-project
matt> > 
matt> _______________________________________________
matt> openssl-project mailing list
matt> openssl-project at openssl.org
matt> https://mta.openssl.org/mailman/listinfo/openssl-project
matt> 

From tjh at cryptsoft.com  Tue Jan  9 07:49:36 2018
From: tjh at cryptsoft.com (Tim Hudson)
Date: Tue, 9 Jan 2018 17:49:36 +1000
Subject: [openssl-project] platforms
Message-ID: <CAHEJ-S6JWVUFHMpjZQOguOqGRdQD792eyO68_n_Px90hM6KKRA@mail.gmail.com>

Given the discussion on PR#5035 it is time to split 10-main.conf into three
groups to match the platform policy and roadmap in my view.

10-primary
20-secondary
30-community
40-unknown
50-deprecated

Most of the current 10-main should move into 40-unknown - that is the
reality of our actual context.

See https://www.openssl.org/policies/platformpolicy.html for the policy and
https://www.openssl.org/policies/roadmap.html where we stated that this
would be completed by the next feature release (i.e. I think that was 1.1.0
at the time but even if we looked from the point of view of "now" that
would be 1.1.1). We missed that timeline.

There should be none of the existing 50-<target> items and I also think
90-team needs some work too - but that is separate from actually splitting
things out into the categories we have already defined.

Does anyone know what platform debug-erbridge is in 90-team?

I also think you need a platform "owner" or "contact" tag ...

Tim.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-project/attachments/20180109/904b9008/attachment.html>

From levitte at openssl.org  Tue Jan  9 09:56:24 2018
From: levitte at openssl.org (Richard Levitte)
Date: Tue, 09 Jan 2018 10:56:24 +0100 (CET)
Subject: [openssl-project] platforms
In-Reply-To: <CAHEJ-S6JWVUFHMpjZQOguOqGRdQD792eyO68_n_Px90hM6KKRA@mail.gmail.com>
References: <CAHEJ-S6JWVUFHMpjZQOguOqGRdQD792eyO68_n_Px90hM6KKRA@mail.gmail.com>
Message-ID: <20180109.105624.1472224252969503988.levitte@openssl.org>

In message <CAHEJ-S6JWVUFHMpjZQOguOqGRdQD792eyO68_n_Px90hM6KKRA at mail.gmail.com> on Tue, 9 Jan 2018 17:49:36 +1000, Tim Hudson <tjh at cryptsoft.com> said:

tjh> Given the discussion on PR#5035 it is time to split 10-main.conf into three groups to match the
tjh> platform policy and roadmap in my view.
tjh> 
tjh> 10-primary
tjh> 20-secondary
tjh> 30-community
tjh> 40-unknown
tjh> 50-deprecated

Arbitrary numbers will always be arbitrary.  We've already started
with new community contributed config targets in the 50 group, why
change that?

Also, there's no real reason to have one big monolithic file per
group.  As you can notice from said 50 group, we've already divided
them in smaller things...  per platform family of sorts, maybe?

So may I suggest that we use the groups 10-49 for stuff "known by us"
(i.e. primary and secondary), 50-89 for "not so known by us"
(i.e. community provided, unknown and deprecated), leaving 00-09 for
base templates (*) and 90-99 for "personal" (i.e. team stuff we choose
to share as well as simply leaving space for those who want to
maintain their own inside their copy of our source)?

Finally, I think we used the term "legacy" rather than "deprecated" at
some point.  Would you mind "legacy"?

tjh> Most of the current 10-main should move into 40-unknown - that is
tjh> the reality of our actual context.

Agreed.

tjh> See https://www.openssl.org/policies/platformpolicy.html for the
tjh> policy and https://www.openssl.org/policies/roadmap.html where we
tjh> stated that this would be completed by the next feature release
tjh> (i.e. I think that was 1.1.0 at the time but even if we looked
tjh> from the point of view of "now" that would be 1.1.1). We missed
tjh> that timeline.

The statements about next feature release were added as off this
commit in openssl-web:

    commit 1bb9590bf583f21dc71b0adf83062f38e589644e
    Author: Rich Salz <rsalz at akamai.com>
    Date:   Mon Oct 24 18:03:32 2016 -0400
    
        Add policy docs from 2016 F2F, per vote.

So this is post 1.1.0 stuff

tjh> There should be none of the existing 50-<target> items and I also
tjh> think 90-team needs some work too - but that is separate from
tjh> actually splitting things out into the categories we have already
tjh> defined.

I disagree about the 50 group, as already mentioned above.

I find 90-team.conf *much* more questionable.  If it were me, I'd toss
the lot of what's in there, with the exception of the "dist" config
target (it's used by the "dist" target in Makefile).

tjh> Does anyone know what platform debug-erbridge is in 90-team?

Not a clue.  Most of the stuff in there can be traced back to what's
in pre-1.1.0 Configure.

I dug a bit, and found that it's this commit:

    commit d7f200779c190ba35cfa4dbd2a82587c938cd243
    Author:     Felix Laurie von Massenbach <felix at erbridge.co.uk>
    AuthorDate: Mon May 26 17:19:06 2014 +0100
    Commit:     Ben Laurie <ben at links.org>
    CommitDate: Sun Jun 1 15:31:26 2014 +0100
    
        Add a new target to Configure for me.
    
tjh> I also think you need a platform "owner" or "contact" tag ...

For primary stuff, that's us (i.e. The Project).
For secondary stuff, that's us (i.e. The Project).
For community stuff, that's the community (*).
For unknown stuff, I don't think we'll be able to, unless a config
target moves to a more active category.
For legacy stuff, I have some serious doubts...

(*) For community, I'm unsure about pinning this one a specific
person.  The commit message will already say (I hope) who provided it,
but that's a shot in the moment and doesn't mean that person is
willing to become The Responsible Person for that config target.  At
some later point in time, someone else may take up the gauntlet and
update some config target, but that's also spur of the moment.  This
is after all the nature of FOSS community development, and I don't
think pinning this on a single (or even a set of) person does anything
good for it.

So I think that in the end, while I can see the temptation for getting
a sense of control, I'd rather not go there.

Cheers,
Richard

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

From tjh at cryptsoft.com  Tue Jan  9 10:06:10 2018
From: tjh at cryptsoft.com (Tim Hudson)
Date: Tue, 9 Jan 2018 10:06:10 +0000
Subject: [openssl-project] platforms
In-Reply-To: <20180109.105624.1472224252969503988.levitte@openssl.org>
References: <CAHEJ-S6JWVUFHMpjZQOguOqGRdQD792eyO68_n_Px90hM6KKRA@mail.gmail.com>
 <20180109.105624.1472224252969503988.levitte@openssl.org>
Message-ID: <CAHEJ-S6q6JaNLps6cwH7yGKTUjt=H51dsHZx+u7-n=p_mX=2kA@mail.gmail.com>

We made and agreed to a set of categories and we should use what we agreed
to - rather than something else.

Introducing different terms I think does not make sense. Using the ones we
have defined does.

Tim.

On 9 Jan. 2018 7:57 pm, "Richard Levitte" <levitte at openssl.org> wrote:

> In message <CAHEJ-S6JWVUFHMpjZQOguOqGRdQD792eyO6
> 8_n_Px90hM6KKRA at mail.gmail.com> on Tue, 9 Jan 2018 17:49:36 +1000, Tim
> Hudson <tjh at cryptsoft.com> said:
>
> tjh> Given the discussion on PR#5035 it is time to split 10-main.conf into
> three groups to match the
> tjh> platform policy and roadmap in my view.
> tjh>
> tjh> 10-primary
> tjh> 20-secondary
> tjh> 30-community
> tjh> 40-unknown
> tjh> 50-deprecated
>
> Arbitrary numbers will always be arbitrary.  We've already started
> with new community contributed config targets in the 50 group, why
> change that?
>
> Also, there's no real reason to have one big monolithic file per
> group.  As you can notice from said 50 group, we've already divided
> them in smaller things...  per platform family of sorts, maybe?
>
> So may I suggest that we use the groups 10-49 for stuff "known by us"
> (i.e. primary and secondary), 50-89 for "not so known by us"
> (i.e. community provided, unknown and deprecated), leaving 00-09 for
> base templates (*) and 90-99 for "personal" (i.e. team stuff we choose
> to share as well as simply leaving space for those who want to
> maintain their own inside their copy of our source)?
>
> Finally, I think we used the term "legacy" rather than "deprecated" at
> some point.  Would you mind "legacy"?
>
> tjh> Most of the current 10-main should move into 40-unknown - that is
> tjh> the reality of our actual context.
>
> Agreed.
>
> tjh> See https://www.openssl.org/policies/platformpolicy.html for the
> tjh> policy and https://www.openssl.org/policies/roadmap.html where we
> tjh> stated that this would be completed by the next feature release
> tjh> (i.e. I think that was 1.1.0 at the time but even if we looked
> tjh> from the point of view of "now" that would be 1.1.1). We missed
> tjh> that timeline.
>
> The statements about next feature release were added as off this
> commit in openssl-web:
>
>     commit 1bb9590bf583f21dc71b0adf83062f38e589644e
>     Author: Rich Salz <rsalz at akamai.com>
>     Date:   Mon Oct 24 18:03:32 2016 -0400
>
>         Add policy docs from 2016 F2F, per vote.
>
> So this is post 1.1.0 stuff
>
> tjh> There should be none of the existing 50-<target> items and I also
> tjh> think 90-team needs some work too - but that is separate from
> tjh> actually splitting things out into the categories we have already
> tjh> defined.
>
> I disagree about the 50 group, as already mentioned above.
>
> I find 90-team.conf *much* more questionable.  If it were me, I'd toss
> the lot of what's in there, with the exception of the "dist" config
> target (it's used by the "dist" target in Makefile).
>
> tjh> Does anyone know what platform debug-erbridge is in 90-team?
>
> Not a clue.  Most of the stuff in there can be traced back to what's
> in pre-1.1.0 Configure.
>
> I dug a bit, and found that it's this commit:
>
>     commit d7f200779c190ba35cfa4dbd2a82587c938cd243
>     Author:     Felix Laurie von Massenbach <felix at erbridge.co.uk>
>     AuthorDate: Mon May 26 17:19:06 2014 +0100
>     Commit:     Ben Laurie <ben at links.org>
>     CommitDate: Sun Jun 1 15:31:26 2014 +0100
>
>         Add a new target to Configure for me.
>
> tjh> I also think you need a platform "owner" or "contact" tag ...
>
> For primary stuff, that's us (i.e. The Project).
> For secondary stuff, that's us (i.e. The Project).
> For community stuff, that's the community (*).
> For unknown stuff, I don't think we'll be able to, unless a config
> target moves to a more active category.
> For legacy stuff, I have some serious doubts...
>
> (*) For community, I'm unsure about pinning this one a specific
> person.  The commit message will already say (I hope) who provided it,
> but that's a shot in the moment and doesn't mean that person is
> willing to become The Responsible Person for that config target.  At
> some later point in time, someone else may take up the gauntlet and
> update some config target, but that's also spur of the moment.  This
> is after all the nature of FOSS community development, and I don't
> think pinning this on a single (or even a set of) person does anything
> good for it.
>
> So I think that in the end, while I can see the temptation for getting
> a sense of control, I'd rather not go there.
>
> Cheers,
> Richard
>
> --
> Richard Levitte         levitte at openssl.org
> OpenSSL Project         http://www.openssl.org/~levitte/
> _______________________________________________
> openssl-project mailing list
> openssl-project at openssl.org
> https://mta.openssl.org/mailman/listinfo/openssl-project
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-project/attachments/20180109/d785354f/attachment-0001.html>

From levitte at openssl.org  Tue Jan  9 10:08:34 2018
From: levitte at openssl.org (Richard Levitte)
Date: Tue, 09 Jan 2018 11:08:34 +0100 (CET)
Subject: [openssl-project] platforms
In-Reply-To: <CAHEJ-S6q6JaNLps6cwH7yGKTUjt=H51dsHZx+u7-n=p_mX=2kA@mail.gmail.com>
References: <CAHEJ-S6JWVUFHMpjZQOguOqGRdQD792eyO68_n_Px90hM6KKRA@mail.gmail.com>
 <20180109.105624.1472224252969503988.levitte@openssl.org>
 <CAHEJ-S6q6JaNLps6cwH7yGKTUjt=H51dsHZx+u7-n=p_mX=2kA@mail.gmail.com>
Message-ID: <20180109.110834.1442617009798122886.levitte@openssl.org>

Ah, I forgot to refresh my reading of platform policy.  Ok then!

In message <CAHEJ-S6q6JaNLps6cwH7yGKTUjt=H51dsHZx+u7-n=p_mX=2kA at mail.gmail.com> on Tue, 9 Jan 2018 10:06:10 +0000, Tim Hudson <tjh at cryptsoft.com> said:

tjh> We made and agreed to a set of categories and we should use what we agreed to - rather than
tjh> something else.
tjh> 
tjh> Introducing different terms I think does not make sense. Using the ones we have defined does.
tjh> 
tjh> Tim.
tjh> 
tjh> On 9 Jan. 2018 7:57 pm, "Richard Levitte" <levitte at openssl.org> wrote:
tjh> 
tjh>  In message
tjh>  <CAHEJ-S6JWVUFHMpjZQOguOqGRdQD792eyO68_n_Px90hM6KKRA at mail.gmail.com> on
tjh>  Tue, 9 Jan 2018 17:49:36 +1000, Tim Hudson <tjh at cryptsoft.com> said:
tjh> 
tjh>  tjh> Given the discussion on PR#5035 it is time to split 10-main.conf into three groups to
tjh>  match the
tjh>  tjh> platform policy and roadmap in my view.
tjh>  tjh>
tjh>  tjh> 10-primary
tjh>  tjh> 20-secondary
tjh>  tjh> 30-community
tjh>  tjh> 40-unknown
tjh>  tjh> 50-deprecated
tjh> 
tjh>  Arbitrary numbers will always be arbitrary. We've already started
tjh>  with new community contributed config targets in the 50 group, why
tjh>  change that?
tjh> 
tjh>  Also, there's no real reason to have one big monolithic file per
tjh>  group. As you can notice from said 50 group, we've already divided
tjh>  them in smaller things... per platform family of sorts, maybe?
tjh> 
tjh>  So may I suggest that we use the groups 10-49 for stuff "known by us"
tjh>  (i.e. primary and secondary), 50-89 for "not so known by us"
tjh>  (i.e. community provided, unknown and deprecated), leaving 00-09 for
tjh>  base templates (*) and 90-99 for "personal" (i.e. team stuff we choose
tjh>  to share as well as simply leaving space for those who want to
tjh>  maintain their own inside their copy of our source)?
tjh> 
tjh>  Finally, I think we used the term "legacy" rather than "deprecated" at
tjh>  some point. Would you mind "legacy"?
tjh> 
tjh>  tjh> Most of the current 10-main should move into 40-unknown - that is
tjh>  tjh> the reality of our actual context.
tjh> 
tjh>  Agreed.
tjh> 
tjh>  tjh> See https://www.openssl.org/policies/platformpolicy.html for the
tjh>  tjh> policy and https://www.openssl.org/policies/roadmap.html where we
tjh>  tjh> stated that this would be completed by the next feature release
tjh>  tjh> (i.e. I think that was 1.1.0 at the time but even if we looked
tjh>  tjh> from the point of view of "now" that would be 1.1.1). We missed
tjh>  tjh> that timeline.
tjh> 
tjh>  The statements about next feature release were added as off this
tjh>  commit in openssl-web:
tjh> 
tjh>  commit 1bb9590bf583f21dc71b0adf83062f38e589644e
tjh>  Author: Rich Salz <rsalz at akamai.com>
tjh>  Date: Mon Oct 24 18:03:32 2016 -0400
tjh> 
tjh>  Add policy docs from 2016 F2F, per vote.
tjh> 
tjh>  So this is post 1.1.0 stuff
tjh> 
tjh>  tjh> There should be none of the existing 50-<target> items and I also
tjh>  tjh> think 90-team needs some work too - but that is separate from
tjh>  tjh> actually splitting things out into the categories we have already
tjh>  tjh> defined.
tjh> 
tjh>  I disagree about the 50 group, as already mentioned above.
tjh> 
tjh>  I find 90-team.conf *much* more questionable. If it were me, I'd toss
tjh>  the lot of what's in there, with the exception of the "dist" config
tjh>  target (it's used by the "dist" target in Makefile).
tjh> 
tjh>  tjh> Does anyone know what platform debug-erbridge is in 90-team?
tjh> 
tjh>  Not a clue. Most of the stuff in there can be traced back to what's
tjh>  in pre-1.1.0 Configure.
tjh> 
tjh>  I dug a bit, and found that it's this commit:
tjh> 
tjh>  commit d7f200779c190ba35cfa4dbd2a82587c938cd243
tjh>  Author: Felix Laurie von Massenbach <felix at erbridge.co.uk>
tjh>  AuthorDate: Mon May 26 17:19:06 2014 +0100
tjh>  Commit: Ben Laurie <ben at links.org>
tjh>  CommitDate: Sun Jun 1 15:31:26 2014 +0100
tjh> 
tjh>  Add a new target to Configure for me.
tjh> 
tjh>  tjh> I also think you need a platform "owner" or "contact" tag ...
tjh> 
tjh>  For primary stuff, that's us (i.e. The Project).
tjh>  For secondary stuff, that's us (i.e. The Project).
tjh>  For community stuff, that's the community (*).
tjh>  For unknown stuff, I don't think we'll be able to, unless a config
tjh>  target moves to a more active category.
tjh>  For legacy stuff, I have some serious doubts...
tjh> 
tjh>  (*) For community, I'm unsure about pinning this one a specific
tjh>  person. The commit message will already say (I hope) who provided it,
tjh>  but that's a shot in the moment and doesn't mean that person is
tjh>  willing to become The Responsible Person for that config target. At
tjh>  some later point in time, someone else may take up the gauntlet and
tjh>  update some config target, but that's also spur of the moment. This
tjh>  is after all the nature of FOSS community development, and I don't
tjh>  think pinning this on a single (or even a set of) person does anything
tjh>  good for it.
tjh> 
tjh>  So I think that in the end, while I can see the temptation for getting
tjh>  a sense of control, I'd rather not go there.
tjh> 
tjh>  Cheers,
tjh>  Richard
tjh> 
tjh>  --
tjh>  Richard Levitte levitte at openssl.org
tjh>  OpenSSL Project http://www.openssl.org/~levitte/
tjh>  _______________________________________________
tjh>  openssl-project mailing list
tjh>  openssl-project at openssl.org
tjh>  https://mta.openssl.org/mailman/listinfo/openssl-project
tjh> 

From levitte at openssl.org  Tue Jan  9 11:37:11 2018
From: levitte at openssl.org (Richard Levitte)
Date: Tue, 09 Jan 2018 12:37:11 +0100 (CET)
Subject: [openssl-project] platforms
In-Reply-To: <20180109.105624.1472224252969503988.levitte@openssl.org>
References: <CAHEJ-S6JWVUFHMpjZQOguOqGRdQD792eyO68_n_Px90hM6KKRA@mail.gmail.com>
 <20180109.105624.1472224252969503988.levitte@openssl.org>
Message-ID: <20180109.123711.78631909482992079.levitte@openssl.org>

In message <20180109.105624.1472224252969503988.levitte at openssl.org> on Tue, 09 Jan 2018 10:56:24 +0100 (CET), Richard Levitte <levitte at openssl.org> said:

levitte> In message <CAHEJ-S6JWVUFHMpjZQOguOqGRdQD792eyO68_n_Px90hM6KKRA at mail.gmail.com> on Tue, 9 Jan 2018 17:49:36 +1000, Tim Hudson <tjh at cryptsoft.com> said:
levitte> 
levitte> tjh> Given the discussion on PR#5035 it is time to split 10-main.conf into three groups to match the
levitte> tjh> platform policy and roadmap in my view.
levitte> tjh> 
levitte> tjh> 10-primary
levitte> tjh> 20-secondary
levitte> tjh> 30-community
levitte> tjh> 40-unknown
levitte> tjh> 50-deprecated
levitte> 
levitte> Arbitrary numbers will always be arbitrary.  We've already started
levitte> with new community contributed config targets in the 50 group, why
levitte> change that?

My proposal, which fits the numbering pattern we've started following
already, it this:

diff --git a/Configurations/README b/Configurations/README
index 9f31dfcd9e..f599610a8e 100644
--- a/Configurations/README
+++ b/Configurations/README
@@ -15,6 +15,30 @@ configuration in diverse ways:
                 information.
 
 
+Naming conventions for config files
+===================================
+
+Config files (*.conf) are named {nn}-{name}.conf, where {nn} is a two
+digit number and {name} is an indicator of what kind of configuration
+can be expected in the file.  The convention for {name} may be refined
+for some number groups.
+
+The number {nn} is somewhat loosely grouped as follows:
+
+00-09  Templates
+10-19  Primary platforms (*)
+20-49  Secondary platforms (*)
+50-69  Community provided platforms (*)
+70-88  Unknown platforms (*)
+89     Deprecated platforms (*)
+90-99  Personal configs (**)
+
+(*) See https://www.openssl.org/policies/platformpolicy.html
+(**) There may be some configs that team members use personally and
+     wish to share.  This also leaves space for those who want to
+     maintain their own configs inside their OpenSSL source checkout
+
+
 Configurations of OpenSSL target platforms
 ==========================================
 


I haven't made a PR from this yet, but am prepared to.

Cheers,
Richard

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

From tjh at cryptsoft.com  Tue Jan  9 12:02:31 2018
From: tjh at cryptsoft.com (Tim Hudson)
Date: Tue, 9 Jan 2018 22:02:31 +1000
Subject: [openssl-project] platforms
In-Reply-To: <20180109.123711.78631909482992079.levitte@openssl.org>
References: <CAHEJ-S6JWVUFHMpjZQOguOqGRdQD792eyO68_n_Px90hM6KKRA@mail.gmail.com>
 <20180109.105624.1472224252969503988.levitte@openssl.org>
 <20180109.123711.78631909482992079.levitte@openssl.org>
Message-ID: <CAHEJ-S5db7Zy_v+jr2MmXqqEjUtWZ=qVwdas=n_Y=sRmafBN0A@mail.gmail.com>

That looks good to me Richard - and it would be nice to see us following
the platform policy and moving configuration definitions into the right
categories.

Tim.


On Tue, Jan 9, 2018 at 9:37 PM, Richard Levitte <levitte at openssl.org> wrote:

> In message <20180109.105624.1472224252969503988.levitte at openssl.org> on
> Tue, 09 Jan 2018 10:56:24 +0100 (CET), Richard Levitte <
> levitte at openssl.org> said:
>
> levitte> In message <CAHEJ-S6JWVUFHMpjZQOguOqGRdQD792eyO6
> 8_n_Px90hM6KKRA at mail.gmail.com> on Tue, 9 Jan 2018 17:49:36 +1000, Tim
> Hudson <tjh at cryptsoft.com> said:
> levitte>
> levitte> tjh> Given the discussion on PR#5035 it is time to split
> 10-main.conf into three groups to match the
> levitte> tjh> platform policy and roadmap in my view.
> levitte> tjh>
> levitte> tjh> 10-primary
> levitte> tjh> 20-secondary
> levitte> tjh> 30-community
> levitte> tjh> 40-unknown
> levitte> tjh> 50-deprecated
> levitte>
> levitte> Arbitrary numbers will always be arbitrary.  We've already started
> levitte> with new community contributed config targets in the 50 group, why
> levitte> change that?
>
> My proposal, which fits the numbering pattern we've started following
> already, it this:
>
> diff --git a/Configurations/README b/Configurations/README
> index 9f31dfcd9e..f599610a8e 100644
> --- a/Configurations/README
> +++ b/Configurations/README
> @@ -15,6 +15,30 @@ configuration in diverse ways:
>                  information.
>
>
> +Naming conventions for config files
> +===================================
> +
> +Config files (*.conf) are named {nn}-{name}.conf, where {nn} is a two
> +digit number and {name} is an indicator of what kind of configuration
> +can be expected in the file.  The convention for {name} may be refined
> +for some number groups.
> +
> +The number {nn} is somewhat loosely grouped as follows:
> +
> +00-09  Templates
> +10-19  Primary platforms (*)
> +20-49  Secondary platforms (*)
> +50-69  Community provided platforms (*)
> +70-88  Unknown platforms (*)
> +89     Deprecated platforms (*)
> +90-99  Personal configs (**)
> +
> +(*) See https://www.openssl.org/policies/platformpolicy.html
> +(**) There may be some configs that team members use personally and
> +     wish to share.  This also leaves space for those who want to
> +     maintain their own configs inside their OpenSSL source checkout
> +
> +
>  Configurations of OpenSSL target platforms
>  ==========================================
>
>
>
> I haven't made a PR from this yet, but am prepared to.
>
> Cheers,
> Richard
>
> --
> Richard Levitte         levitte at openssl.org
> OpenSSL Project         http://www.openssl.org/~levitte/
> _______________________________________________
> openssl-project mailing list
> openssl-project at openssl.org
> https://mta.openssl.org/mailman/listinfo/openssl-project
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-project/attachments/20180109/2bebb62f/attachment.html>

From levitte at openssl.org  Tue Jan  9 12:12:56 2018
From: levitte at openssl.org (Richard Levitte)
Date: Tue, 09 Jan 2018 13:12:56 +0100 (CET)
Subject: [openssl-project] platforms
In-Reply-To: <CAHEJ-S6JWVUFHMpjZQOguOqGRdQD792eyO68_n_Px90hM6KKRA@mail.gmail.com>
References: <CAHEJ-S6JWVUFHMpjZQOguOqGRdQD792eyO68_n_Px90hM6KKRA@mail.gmail.com>
Message-ID: <20180109.131256.1811235214787240284.levitte@openssl.org>

Speaking of platforms, I think we need to discuss what we actually
include in the secondary category.  The platform policy currently
mentions these:

   FreeBSD, Windows (Visual Studio, MinGW), MacOS X and VMS

For Windows and VMS, I know for sure that it follows our definition of
the secondary category (*), but for FreeBSD and MacOS X, I think we
may have lost the people who actively supported them (for FreeBSD,
that was Ben Laurie as far as I recall).

So I think we need a raise of hands, here and now:

1.  Is there anyone currently present on this list that want to take
    on FreeBSD or MacOS X?

2.  Is there anyone currently present on this list that actively
    supports a platform we haven't listed?

Please make yourself known.

Also, come to think of it, for the "owner" and "contact" idea, perhaps
the secondary category would be fitting...

Cheers,
Richard

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

From rsalz at akamai.com  Tue Jan  9 13:38:19 2018
From: rsalz at akamai.com (Salz, Rich)
Date: Tue, 9 Jan 2018 13:38:19 +0000
Subject: [openssl-project] platforms
In-Reply-To: <20180109.131256.1811235214787240284.levitte@openssl.org>
References: <CAHEJ-S6JWVUFHMpjZQOguOqGRdQD792eyO68_n_Px90hM6KKRA@mail.gmail.com>
 <20180109.131256.1811235214787240284.levitte@openssl.org>
Message-ID: <0F215794-575C-403F-B2C6-57855AC1CFF9@akamai.com>

I would take on building on my mac laptop

On 1/9/18, 7:13 AM, "Richard Levitte" <levitte at openssl.org> wrote:

    Speaking of platforms, I think we need to discuss what we actually
    include in the secondary category.  The platform policy currently
    mentions these:
    
       FreeBSD, Windows (Visual Studio, MinGW), MacOS X and VMS
    
    For Windows and VMS, I know for sure that it follows our definition of
    the secondary category (*), but for FreeBSD and MacOS X, I think we
    may have lost the people who actively supported them (for FreeBSD,
    that was Ben Laurie as far as I recall).
    
    So I think we need a raise of hands, here and now:
    
    1.  Is there anyone currently present on this list that want to take
        on FreeBSD or MacOS X?
    
    2.  Is there anyone currently present on this list that actively
        supports a platform we haven't listed?
    
    Please make yourself known.
    
    Also, come to think of it, for the "owner" and "contact" idea, perhaps
    the secondary category would be fitting...
    
    Cheers,
    Richard
    
    -- 
    Richard Levitte         levitte at openssl.org
    OpenSSL Project         http://www.openssl.org/~levitte/
    _______________________________________________
    openssl-project mailing list
    openssl-project at openssl.org
    https://mta.openssl.org/mailman/listinfo/openssl-project
    


From levitte at openssl.org  Tue Jan  9 13:58:05 2018
From: levitte at openssl.org (Richard Levitte)
Date: Tue, 09 Jan 2018 14:58:05 +0100 (CET)
Subject: [openssl-project] platforms
In-Reply-To: <0F215794-575C-403F-B2C6-57855AC1CFF9@akamai.com>
References: <CAHEJ-S6JWVUFHMpjZQOguOqGRdQD792eyO68_n_Px90hM6KKRA@mail.gmail.com>
 <20180109.131256.1811235214787240284.levitte@openssl.org>
 <0F215794-575C-403F-B2C6-57855AC1CFF9@akamai.com>
Message-ID: <20180109.145805.1816532854570448913.levitte@openssl.org>

Cool.  Does that mean the whole set of darwin-* configs, or a subset
of them?  Here's the full list:

darwin-common	(this is a template for the others)
darwin-i386-cc
darwin-ppc-cc
darwin64-ppc-cc
darwin64-x86_64-cc

In message <0F215794-575C-403F-B2C6-57855AC1CFF9 at akamai.com> on Tue, 9 Jan 2018 13:38:19 +0000, "Salz, Rich" <rsalz at akamai.com> said:

rsalz> I would take on building on my mac laptop
rsalz> 
rsalz> On 1/9/18, 7:13 AM, "Richard Levitte" <levitte at openssl.org> wrote:
rsalz> 
rsalz>     Speaking of platforms, I think we need to discuss what we actually
rsalz>     include in the secondary category.  The platform policy currently
rsalz>     mentions these:
rsalz>     
rsalz>        FreeBSD, Windows (Visual Studio, MinGW), MacOS X and VMS
rsalz>     
rsalz>     For Windows and VMS, I know for sure that it follows our definition of
rsalz>     the secondary category (*), but for FreeBSD and MacOS X, I think we
rsalz>     may have lost the people who actively supported them (for FreeBSD,
rsalz>     that was Ben Laurie as far as I recall).
rsalz>     
rsalz>     So I think we need a raise of hands, here and now:
rsalz>     
rsalz>     1.  Is there anyone currently present on this list that want to take
rsalz>         on FreeBSD or MacOS X?
rsalz>     
rsalz>     2.  Is there anyone currently present on this list that actively
rsalz>         supports a platform we haven't listed?
rsalz>     
rsalz>     Please make yourself known.
rsalz>     
rsalz>     Also, come to think of it, for the "owner" and "contact" idea, perhaps
rsalz>     the secondary category would be fitting...
rsalz>     
rsalz>     Cheers,
rsalz>     Richard
rsalz>     
rsalz>     -- 
rsalz>     Richard Levitte         levitte at openssl.org
rsalz>     OpenSSL Project         http://www.openssl.org/~levitte/
rsalz>     _______________________________________________
rsalz>     openssl-project mailing list
rsalz>     openssl-project at openssl.org
rsalz>     https://mta.openssl.org/mailman/listinfo/openssl-project
rsalz>     
rsalz> 
rsalz> _______________________________________________
rsalz> openssl-project mailing list
rsalz> openssl-project at openssl.org
rsalz> https://mta.openssl.org/mailman/listinfo/openssl-project
rsalz> 

From rsalz at akamai.com  Tue Jan  9 15:13:38 2018
From: rsalz at akamai.com (Salz, Rich)
Date: Tue, 9 Jan 2018 15:13:38 +0000
Subject: [openssl-project] platforms
In-Reply-To: <20180109.145805.1816532854570448913.levitte@openssl.org>
References: <CAHEJ-S6JWVUFHMpjZQOguOqGRdQD792eyO68_n_Px90hM6KKRA@mail.gmail.com>
 <20180109.131256.1811235214787240284.levitte@openssl.org>
 <0F215794-575C-403F-B2C6-57855AC1CFF9@akamai.com>
 <20180109.145805.1816532854570448913.levitte@openssl.org>
Message-ID: <95FDE624-F418-4B35-AF3C-3679B87E443B@akamai.com>

; uname -a
Darwin bos-mpu8n 17.3.0 Darwin Kernel Version 17.3.0: Thu Nov  9 18:09:22 PST 2017; root:xnu-4570.31.3~1/RELEASE_X86_64 x86_64

On 1/9/18, 8:58 AM, "Richard Levitte" <levitte at openssl.org> wrote:

    Cool.  Does that mean the whole set of darwin-* configs, or a subset
    of them?  Here's the full list:
    
    darwin-common	(this is a template for the others)
    darwin-i386-cc
    darwin-ppc-cc
    darwin64-ppc-cc
    darwin64-x86_64-cc
    
    In message <0F215794-575C-403F-B2C6-57855AC1CFF9 at akamai.com> on Tue, 9 Jan 2018 13:38:19 +0000, "Salz, Rich" <rsalz at akamai.com> said:
    
    rsalz> I would take on building on my mac laptop
    rsalz> 
    rsalz> On 1/9/18, 7:13 AM, "Richard Levitte" <levitte at openssl.org> wrote:
    rsalz> 
    rsalz>     Speaking of platforms, I think we need to discuss what we actually
    rsalz>     include in the secondary category.  The platform policy currently
    rsalz>     mentions these:
    rsalz>     
    rsalz>        FreeBSD, Windows (Visual Studio, MinGW), MacOS X and VMS
    rsalz>     
    rsalz>     For Windows and VMS, I know for sure that it follows our definition of
    rsalz>     the secondary category (*), but for FreeBSD and MacOS X, I think we
    rsalz>     may have lost the people who actively supported them (for FreeBSD,
    rsalz>     that was Ben Laurie as far as I recall).
    rsalz>     
    rsalz>     So I think we need a raise of hands, here and now:
    rsalz>     
    rsalz>     1.  Is there anyone currently present on this list that want to take
    rsalz>         on FreeBSD or MacOS X?
    rsalz>     
    rsalz>     2.  Is there anyone currently present on this list that actively
    rsalz>         supports a platform we haven't listed?
    rsalz>     
    rsalz>     Please make yourself known.
    rsalz>     
    rsalz>     Also, come to think of it, for the "owner" and "contact" idea, perhaps
    rsalz>     the secondary category would be fitting...
    rsalz>     
    rsalz>     Cheers,
    rsalz>     Richard
    rsalz>     
    rsalz>     -- 
    rsalz>     Richard Levitte         levitte at openssl.org
    rsalz>     OpenSSL Project         http://www.openssl.org/~levitte/
    rsalz>     _______________________________________________
    rsalz>     openssl-project mailing list
    rsalz>     openssl-project at openssl.org
    rsalz>     https://mta.openssl.org/mailman/listinfo/openssl-project
    rsalz>     
    rsalz> 
    rsalz> _______________________________________________
    rsalz> openssl-project mailing list
    rsalz> openssl-project at openssl.org
    rsalz> https://mta.openssl.org/mailman/listinfo/openssl-project
    rsalz> 
    _______________________________________________
    openssl-project mailing list
    openssl-project at openssl.org
    https://mta.openssl.org/mailman/listinfo/openssl-project
    


From openssl-users at dukhovni.org  Tue Jan  9 18:38:18 2018
From: openssl-users at dukhovni.org (Viktor Dukhovni)
Date: Tue, 9 Jan 2018 13:38:18 -0500
Subject: [openssl-project] platforms
In-Reply-To: <20180109.145805.1816532854570448913.levitte@openssl.org>
References: <CAHEJ-S6JWVUFHMpjZQOguOqGRdQD792eyO68_n_Px90hM6KKRA@mail.gmail.com>
 <20180109.131256.1811235214787240284.levitte@openssl.org>
 <0F215794-575C-403F-B2C6-57855AC1CFF9@akamai.com>
 <20180109.145805.1816532854570448913.levitte@openssl.org>
Message-ID: <E3549C14-8F79-478D-8BAF-ECE9AAC573C1@dukhovni.org>



> On Jan 9, 2018, at 8:58 AM, Richard Levitte <levitte at openssl.org> wrote:
> 
> Cool.  Does that mean the whole set of darwin-* configs, or a subset
> of them?  Here's the full list:
> 
> darwin-common	(this is a template for the others)
> darwin-i386-cc
> darwin-ppc-cc
> darwin64-ppc-cc
> darwin64-x86_64-cc

I do my OpenSSL development on a combination of "darwin64-x86_64-cc" and Debian
on x86_64.  I don't have "ppc" and don't bother with i386.

-- 
	Viktor.


From levitte at openssl.org  Tue Jan  9 20:12:14 2018
From: levitte at openssl.org (Richard Levitte)
Date: Tue, 09 Jan 2018 21:12:14 +0100 (CET)
Subject: [openssl-project] Fw: [openssl-commits] Copyright warnings for
	refs/heads/master
Message-ID: <20180109.211214.233877986990647097.levitte@openssl.org>

Right now, there's a post-receive script on our git server that emails
Rich and me with messages such as the attached.  It also checks if any
NEW file lacks a copyright blurb entirely and notifies then as well.

I'm thinking we should make this a VREF (*) that refuses to take a
push, much like the reviewer checking VREF, and that we add a Travis
job that does check these things as well.

What are your thoughts on this?  This will affect the workflow for
each of us, and quite harshly so.  It also means we need to take it
upon ourselves edit the copyright lines ourselves (there's a script
util/openssl-update-copyright that helps), or go back to the author.
(of course, a Travis check will help too...)

Cheers,
Richard

(*) A VREF is a special thing in gitolite, which we use for our git
    repos.  Basically, it's a special variant of the update git hook
    that is used to figure out if a push should be accepted or not,
    all depending on the criteria that VREF has been programmed with.
-------------- next part --------------
An embedded message was scrubbed...
From: <openssl-git at dev.openssl.org>
Subject: [openssl-commits] Copyright warnings for refs/heads/master
Date: Tue, 09 Jan 2018 19:48:09 +0000
Size: 738
URL: <http://mta.openssl.org/pipermail/openssl-project/attachments/20180109/cf81373a/attachment.mht>

From kurt at roeckx.be  Tue Jan  9 20:29:09 2018
From: kurt at roeckx.be (Kurt Roeckx)
Date: Tue, 9 Jan 2018 21:29:09 +0100
Subject: [openssl-project] platforms
In-Reply-To: <20180109.123711.78631909482992079.levitte@openssl.org>
References: <CAHEJ-S6JWVUFHMpjZQOguOqGRdQD792eyO68_n_Px90hM6KKRA@mail.gmail.com>
 <20180109.105624.1472224252969503988.levitte@openssl.org>
 <20180109.123711.78631909482992079.levitte@openssl.org>
Message-ID: <20180109202908.GA6587@roeckx.be>

On Tue, Jan 09, 2018 at 12:37:11PM +0100, Richard Levitte wrote:
> +Naming conventions for config files
> +===================================
> +
> +Config files (*.conf) are named {nn}-{name}.conf, where {nn} is a two
> +digit number and {name} is an indicator of what kind of configuration
> +can be expected in the file.  The convention for {name} may be refined
> +for some number groups.
> +
> +The number {nn} is somewhat loosely grouped as follows:
> +
> +00-09  Templates
> +10-19  Primary platforms (*)
> +20-49  Secondary platforms (*)
> +50-69  Community provided platforms (*)
> +70-88  Unknown platforms (*)
> +89     Deprecated platforms (*)
> +90-99  Personal configs (**)

In Debian I use the attached patch. It's an easy way for me to
override the defaults and be follow the Debian policy. Is that
something that would fall under the community provided?

I'm wondering if there is a reason for the number range. I assume
higher numbers can include lower ones?


Kurt

-------------- next part --------------
A non-text attachment was scrubbed...
Name: debian-targets.patch
Type: text/x-diff
Size: 4028 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-project/attachments/20180109/b94f5d3c/attachment.patch>

From levitte at openssl.org  Tue Jan  9 20:48:58 2018
From: levitte at openssl.org (Richard Levitte)
Date: Tue, 09 Jan 2018 21:48:58 +0100 (CET)
Subject: [openssl-project] platforms
In-Reply-To: <20180109202908.GA6587@roeckx.be>
References: <20180109.105624.1472224252969503988.levitte@openssl.org>
 <20180109.123711.78631909482992079.levitte@openssl.org>
 <20180109202908.GA6587@roeckx.be>
Message-ID: <20180109.214858.1998203021228284816.levitte@openssl.org>

In message <20180109202908.GA6587 at roeckx.be> on Tue, 9 Jan 2018 21:29:09 +0100, Kurt Roeckx <kurt at roeckx.be> said:

kurt> On Tue, Jan 09, 2018 at 12:37:11PM +0100, Richard Levitte wrote:
kurt> > +Naming conventions for config files
kurt> > +===================================
kurt> > +
kurt> > +Config files (*.conf) are named {nn}-{name}.conf, where {nn} is a two
kurt> > +digit number and {name} is an indicator of what kind of configuration
kurt> > +can be expected in the file.  The convention for {name} may be refined
kurt> > +for some number groups.
kurt> > +
kurt> > +The number {nn} is somewhat loosely grouped as follows:
kurt> > +
kurt> > +00-09  Templates
kurt> > +10-19  Primary platforms (*)
kurt> > +20-49  Secondary platforms (*)
kurt> > +50-69  Community provided platforms (*)
kurt> > +70-88  Unknown platforms (*)
kurt> > +89     Deprecated platforms (*)
kurt> > +90-99  Personal configs (**)
kurt> 
kurt> In Debian I use the attached patch. It's an easy way for me to
kurt> override the defaults and be follow the Debian policy. Is that
kurt> something that would fall under the community provided?

I would say that these are packager private configs rather than
something the community at large would benefit from, at least
directly.

Frankly, I think you can expect an answer along the same lines as you
could expect from any upstream project that you'd ask "hey, wanna take
care of debian/ for us?"...

kurt> I'm wondering if there is a reason for the number range. I assume
kurt> higher numbers can include lower ones?

Nope.  Those numbers are for human eyes only, they are not in any way
an attempt to order things for computation.  All of the files are read
by Configure, and the the attributes used are resolved by following
the chain of inherit_from, starting with the name given on the
Configure command line.  Those files could be read backwards and the
result would still be the same.

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

From kurt at roeckx.be  Tue Jan  9 21:01:21 2018
From: kurt at roeckx.be (Kurt Roeckx)
Date: Tue, 9 Jan 2018 22:01:21 +0100
Subject: [openssl-project] platforms
In-Reply-To: <20180109.214858.1998203021228284816.levitte@openssl.org>
References: <20180109.105624.1472224252969503988.levitte@openssl.org>
 <20180109.123711.78631909482992079.levitte@openssl.org>
 <20180109202908.GA6587@roeckx.be>
 <20180109.214858.1998203021228284816.levitte@openssl.org>
Message-ID: <20180109210121.GA10257@roeckx.be>

On Tue, Jan 09, 2018 at 09:48:58PM +0100, Richard Levitte wrote:
> In message <20180109202908.GA6587 at roeckx.be> on Tue, 9 Jan 2018 21:29:09 +0100, Kurt Roeckx <kurt at roeckx.be> said:
> 
> kurt> On Tue, Jan 09, 2018 at 12:37:11PM +0100, Richard Levitte wrote:
> kurt> > +Naming conventions for config files
> kurt> > +===================================
> kurt> > +
> kurt> > +Config files (*.conf) are named {nn}-{name}.conf, where {nn} is a two
> kurt> > +digit number and {name} is an indicator of what kind of configuration
> kurt> > +can be expected in the file.  The convention for {name} may be refined
> kurt> > +for some number groups.
> kurt> > +
> kurt> > +The number {nn} is somewhat loosely grouped as follows:
> kurt> > +
> kurt> > +00-09  Templates
> kurt> > +10-19  Primary platforms (*)
> kurt> > +20-49  Secondary platforms (*)
> kurt> > +50-69  Community provided platforms (*)
> kurt> > +70-88  Unknown platforms (*)
> kurt> > +89     Deprecated platforms (*)
> kurt> > +90-99  Personal configs (**)
> kurt> 
> kurt> In Debian I use the attached patch. It's an easy way for me to
> kurt> override the defaults and be follow the Debian policy. Is that
> kurt> something that would fall under the community provided?
> 
> I would say that these are packager private configs rather than
> something the community at large would benefit from, at least
> directly.

So you suggest I put them in the 90-99 range?

> Frankly, I think you can expect an answer along the same lines as you
> could expect from any upstream project that you'd ask "hey, wanna take
> care of debian/ for us?"...

Debian actually prefer that upstream doesn't contain any debian
directory, and I guess anything specific to Debian.


Kurt


From levitte at openssl.org  Tue Jan  9 21:04:48 2018
From: levitte at openssl.org (Richard Levitte)
Date: Tue, 09 Jan 2018 22:04:48 +0100 (CET)
Subject: [openssl-project] platforms
In-Reply-To: <20180109210121.GA10257@roeckx.be>
References: <20180109202908.GA6587@roeckx.be>
 <20180109.214858.1998203021228284816.levitte@openssl.org>
 <20180109210121.GA10257@roeckx.be>
Message-ID: <20180109.220448.161198044129512541.levitte@openssl.org>

In message <20180109210121.GA10257 at roeckx.be> on Tue, 9 Jan 2018 22:01:21 +0100, Kurt Roeckx <kurt at roeckx.be> said:

kurt> Debian actually prefer that upstream doesn't contain any debian
kurt> directory, and I guess anything specific to Debian.

Ok, so how does that go together with asking this particular project
to include Debian specific configs?

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

From levitte at openssl.org  Tue Jan  9 21:24:48 2018
From: levitte at openssl.org (Richard Levitte)
Date: Tue, 09 Jan 2018 22:24:48 +0100 (CET)
Subject: [openssl-project] platforms
In-Reply-To: <20180109202908.GA6587@roeckx.be>
References: <20180109.105624.1472224252969503988.levitte@openssl.org>
 <20180109.123711.78631909482992079.levitte@openssl.org>
 <20180109202908.GA6587@roeckx.be>
Message-ID: <20180109.222448.1196809330667872194.levitte@openssl.org>

In message <20180109202908.GA6587 at roeckx.be> on Tue, 9 Jan 2018 21:29:09 +0100, Kurt Roeckx <kurt at roeckx.be> said:

kurt> In Debian I use the attached patch. It's an easy way for me to
kurt> override the defaults and be follow the Debian policy. Is that
kurt> something that would fall under the community provided?

So while I can be seen as dismissive of this idea, it does prompt an
interesting discussion that we've had before and that never really got
concluded.  The central question is, what is this "config target" we
keep talking about and not defining very strictly?

One idea is that a config target is something that determines the
unique characteristics of a given combination of operating system,
CPU, toolchain (roughly speaking and top of my head, I may be missing
some axis).  We might possibly have to make a difference between some
versions along one or more of those axes, and in some cases, it might
be wiser to talk about kernels rather than operating systems.  That's
roughly it...  or should be, methinks.

So I'm looking at Debian -- in fact, that's what I'm running on my
laptop and am doing my daily work on -- and thinking that from a
developer's point of view and from the point of view of an OpenSSL
user, that's just another Linux.  And we already have Linux-specific
targets that, as far as I can tell, are working as they should.
That's basically what makes me wonder why we should have config
targets that are specific to *one* Linux distro?

(mind you, if some of those targets are config targets that are
missing entirely in our 'linux-*' range, perhaps the latter need an
update?  If that's the intent, then I do agree that they could, and
possibly should be integrated, after a rename to 'linux-{whatever}')

Cheers,
Richard

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

From openssl-users at dukhovni.org  Tue Jan  9 21:59:34 2018
From: openssl-users at dukhovni.org (Viktor Dukhovni)
Date: Tue, 9 Jan 2018 16:59:34 -0500
Subject: [openssl-project] platforms
In-Reply-To: <20180109.222448.1196809330667872194.levitte@openssl.org>
References: <20180109.105624.1472224252969503988.levitte@openssl.org>
 <20180109.123711.78631909482992079.levitte@openssl.org>
 <20180109202908.GA6587@roeckx.be>
 <20180109.222448.1196809330667872194.levitte@openssl.org>
Message-ID: <0DF89852-9BD1-4B6E-AC79-961750AD2BBA@dukhovni.org>



> On Jan 9, 2018, at 4:24 PM, Richard Levitte <levitte at openssl.org> wrote:
> 
> And we already have Linux-specific
> targets that, as far as I can tell, are working as they should.
> That's basically what makes me wonder why we should have config
> targets that are specific to *one* Linux distro?

Take a look at the Debian OpenSSL package...  It is substantially
different from a generic Linux build.

-- 
	Viktor.


From paul.dale at oracle.com  Tue Jan  9 22:53:14 2018
From: paul.dale at oracle.com (Paul Dale)
Date: Tue, 9 Jan 2018 14:53:14 -0800 (PST)
Subject: [openssl-project] Fw: [openssl-commits] Copyright warnings for
 refs/heads/master
In-Reply-To: <20180109.211214.233877986990647097.levitte@openssl.org>
References: <20180109.211214.233877986990647097.levitte@openssl.org>
Message-ID: <345736cb-7ec5-4183-a745-5cd87259d429@default>

Would it make sense for a commit script to fix errant copyright dates rather than just flagging them and forcing manual intervention?  I'm not suggesting adding missing copyright headers, just fix existing ones.

Failing that could the copyright data check be part of the github checks in the PR?  Better to catch this early rather than late.


Pauli
-- 
Oracle
Dr Paul Dale | Cryptographer | Network Security & Encryption 
Phone +61 7 3031 7217
Oracle Australia

-----Original Message-----
From: Richard Levitte [mailto:levitte at openssl.org] 
Sent: Wednesday, 10 January 2018 6:12 AM
To: openssl-project at openssl.org
Subject: [openssl-project] Fw: [openssl-commits] Copyright warnings for refs/heads/master

Right now, there's a post-receive script on our git server that emails Rich and me with messages such as the attached.  It also checks if any NEW file lacks a copyright blurb entirely and notifies then as well.

I'm thinking we should make this a VREF (*) that refuses to take a push, much like the reviewer checking VREF, and that we add a Travis job that does check these things as well.

What are your thoughts on this?  This will affect the workflow for each of us, and quite harshly so.  It also means we need to take it upon ourselves edit the copyright lines ourselves (there's a script util/openssl-update-copyright that helps), or go back to the author.
(of course, a Travis check will help too...)

Cheers,
Richard

(*) A VREF is a special thing in gitolite, which we use for our git
    repos.  Basically, it's a special variant of the update git hook
    that is used to figure out if a push should be accepted or not,
    all depending on the criteria that VREF has been programmed with.

From kaduk at mit.edu  Wed Jan 10 01:48:53 2018
From: kaduk at mit.edu (Benjamin Kaduk)
Date: Tue, 9 Jan 2018 19:48:53 -0600
Subject: [openssl-project] platforms
In-Reply-To: <20180109.131256.1811235214787240284.levitte@openssl.org>
References: <CAHEJ-S6JWVUFHMpjZQOguOqGRdQD792eyO68_n_Px90hM6KKRA@mail.gmail.com>
 <20180109.131256.1811235214787240284.levitte@openssl.org>
Message-ID: <20180110014852.GA72574@kduck.kaduk.org>

On Tue, Jan 09, 2018 at 01:12:56PM +0100, Richard Levitte wrote:
> Speaking of platforms, I think we need to discuss what we actually
> include in the secondary category.  The platform policy currently
> mentions these:
> 
>    FreeBSD, Windows (Visual Studio, MinGW), MacOS X and VMS
> 
> For Windows and VMS, I know for sure that it follows our definition of
> the secondary category (*), but for FreeBSD and MacOS X, I think we
> may have lost the people who actively supported them (for FreeBSD,
> that was Ben Laurie as far as I recall).
> 
> So I think we need a raise of hands, here and now:
> 
> 1.  Is there anyone currently present on this list that want to take
>     on FreeBSD or MacOS X?

I guess maybe this is overcome by events since I commented on github
already, but I can take FreeBSD (amd64).  I can spin up i386 FreeBSD
in the lead up to new releases but don't normally use it on a
regular basis.

-Ben

From tjh at cryptsoft.com  Wed Jan 10 07:21:34 2018
From: tjh at cryptsoft.com (Tim Hudson)
Date: Wed, 10 Jan 2018 17:21:34 +1000
Subject: [openssl-project] platforms
In-Reply-To: <20180110014852.GA72574@kduck.kaduk.org>
References: <CAHEJ-S6JWVUFHMpjZQOguOqGRdQD792eyO68_n_Px90hM6KKRA@mail.gmail.com>
 <20180109.131256.1811235214787240284.levitte@openssl.org>
 <20180110014852.GA72574@kduck.kaduk.org>
Message-ID: <CAHEJ-S74_mCgmHzUYsmkuv=rrSW-9=gX0nLreARdES_bSeNcow@mail.gmail.com>

Follow on from the discussion in PR#5035, I think we need to add a "status"
definition to the platform which should cover the different contexts:

1) libraries compile
2) apps compile
3) make test passes

We have platforms where we don't compile the apps and we have platforms
where there are issues in the tests - i.e. the library (with or without the
apps) compiles and operates correctly but there is a defect in the tests.
Defects in tests or defects in the apps are different to defects in the
libraries.
The apps not being ported also does not mean the platform is unusable.

That level of differences should be recorded. Perhaps a status for each?

- libcrypto
- libssl
- apps
- tests

For many platforms, the apps and the tests simply don't work or are not
used; and our test automation platform also does not operate for many
platforms.

Tim.


On Wed, Jan 10, 2018 at 11:48 AM, Benjamin Kaduk <kaduk at mit.edu> wrote:

> On Tue, Jan 09, 2018 at 01:12:56PM +0100, Richard Levitte wrote:
> > Speaking of platforms, I think we need to discuss what we actually
> > include in the secondary category.  The platform policy currently
> > mentions these:
> >
> >    FreeBSD, Windows (Visual Studio, MinGW), MacOS X and VMS
> >
> > For Windows and VMS, I know for sure that it follows our definition of
> > the secondary category (*), but for FreeBSD and MacOS X, I think we
> > may have lost the people who actively supported them (for FreeBSD,
> > that was Ben Laurie as far as I recall).
> >
> > So I think we need a raise of hands, here and now:
> >
> > 1.  Is there anyone currently present on this list that want to take
> >     on FreeBSD or MacOS X?
>
> I guess maybe this is overcome by events since I commented on github
> already, but I can take FreeBSD (amd64).  I can spin up i386 FreeBSD
> in the lead up to new releases but don't normally use it on a
> regular basis.
>
> -Ben
> _______________________________________________
> openssl-project mailing list
> openssl-project at openssl.org
> https://mta.openssl.org/mailman/listinfo/openssl-project
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-project/attachments/20180110/b218c247/attachment-0001.html>

From rsalz at akamai.com  Wed Jan 10 17:36:23 2018
From: rsalz at akamai.com (Salz, Rich)
Date: Wed, 10 Jan 2018 17:36:23 +0000
Subject: [openssl-project] FW: [openssl-commits] Copyright warnings for
	refs/heads/master
In-Reply-To: <1515605053.939960.3500.nullmailer@dev.openssl.org>
References: <1515605053.939960.3500.nullmailer@dev.openssl.org>
Message-ID: <3E3E04F3-2733-4447-BE60-B13C614396B2@akamai.com>

This is too too funny.

On 1/10/18, 12:24 PM, "openssl-git at dev.openssl.org" <openssl-git at dev.openssl.org> wrote:

    The following files seem to need a copyright year update:
        util/openssl-update-copyright
    


From kaduk at mit.edu  Wed Jan 10 18:13:29 2018
From: kaduk at mit.edu (Benjamin Kaduk)
Date: Wed, 10 Jan 2018 12:13:29 -0600
Subject: [openssl-project] update on sporadic test failures
Message-ID: <20180110181329.GH72574@kduck.kaduk.org>

I've been running 'make test' in a loop to try to reproduce the
sporadic failures that we've been seeing in the build farms.
Subjectively it seemed like it was easier to reproduce issues on
OpenSSL_1_1_0-stable than master, but I have seen "Dubious, test
returned 1 (wstat 256, 0x100)" on both.

My latest result is not of that form, though; rather, it's an
outright failure:

not ok 13 - Changed record version in TLS1.3

#   Failed test 'Changed record version in TLS1.3'
#   at ../test/recipes/70-test_sslrecords.t line 156.


I'll include the full V=1 output (starting from the end of the
previous subtest) below, in case it is enlightening.  (Needless to
say, this failure is not repeatable; I have only one occurrence in
O(50) runs.)

openssl is confiugred as:
./config --strict-warnings enable-tls1_3

and this is master as of commit
8e403a79b0e679c8df41a9686006c5fe052d79bd.

-Ben



ok 12 - Changed record version in TLS1.2
Server command: ../../util/shlib_wrap.sh ../../apps/openssl s_server -no_comp -rev -engine ossltest -accept 4443 -cert ../../apps/server.pem -cert2 ../../apps/server.pem -naccept 1 -cipher AES128-SHA:TLS13-AES-128-GCM-SHA256
Proxy started on port 4453
Client command: echo test | ../../util/shlib_wrap.sh ../../apps/openssl s_client -engine ossltest -connect localhost:4453
engine "ossltest" set.
engine "ossltest" set.
Using default temp DH parameters
ACCEPT
Connection opened
Received client packet
Packet length = 301
Processing flight 0
 Record 1 (client -> server)
  Content type: HANDSHAKE
  Version: TLS1.0
  Length: 296
  Message type: ClientHello
  Message Length: 292
    Client Version:771
    Session ID Len:32
    Ciphersuite len:62
    Compression Method Len:1
    Extensions Len:157

Forwarded packet length = 301

Received server packet
Packet length = 1543
Processing flight 1
 Record 1 (server -> client)
  Content type: HANDSHAKE
  Version: TLS1.2
  Length: 122
  Message type: ServerHello
  Message Length: 118
    Server Version:771
    Session ID Len:32
    Ciphersuite:4865
    Compression Method:0
    Extensions Len:46
 Record 2 (server -> client)
  Content type: CCS
  Version: TLS1.2
  Length: 1
 Record 3 (server -> client)
  Content type: APPLICATION DATA
  Version: TLS1.2
  Length: 23
  Inner content type: HANDSHAKE
  Message type: EncryptedExtensions
  Message Length: 2
    Extensions Len:0
 Record 4 (server -> client)
  Content type: APPLICATION DATA
  Version: TLS1.2
  Length: 1033
  Inner content type: HANDSHAKE
  Message type: Certificate
  Message Length: 1012
    Context:
    Certificate List Len:1008
    Certificate Len:1003
    Extensions Len:0
 Record 5 (server -> client)
  Content type: APPLICATION DATA
  Version: TLS1.2
  Length: 281
  Inner content type: HANDSHAKE
  Message type: CertificateVerify
  Message Length: 260
    SigAlg:2052
    Signature Len:256
 Record 6 (server -> client)
  Content type: APPLICATION DATA
  Version: TLS1.2
  Length: 53
  Inner content type: HANDSHAKE
  Message type: Finished
  Message Length: 32

Forwarded packet length = 1547

depth=0 C = UK, O = OpenSSL Group, OU = FOR TESTING PURPOSES ONLY, CN = Test Server Cert
verify error:num=20:unable to get local issuer certificate
verify return:1
depth=0 C = UK, O = OpenSSL Group, OU = FOR TESTING PURPOSES ONLY, CN = Test Server Cert
verify error:num=21:unable to verify the first certificate
verify return:1
Received client packet
Packet length = 64
Processing flight 2
 Record 1 (client -> server)
  Content type: CCS
  Version: TLS1.2
  Length: 1
 Record 2 (client -> server)
  Content type: APPLICATION DATA
  Version: TLS1.2
  Length: 53
  Inner content type: HANDSHAKE
  Message type: Finished
  Message Length: 32
CONNECTED(00000003)
---
Certificate chain
 0 s:C = UK, O = OpenSSL Group, OU = FOR TESTING PURPOSES ONLY, CN = Test Server Cert
   i:C = UK, O = OpenSSL Group, OU = FOR TESTING PURPOSES ONLY, CN = OpenSSL Test Intermediate CA
---
Server certificate
-----BEGIN CERTIFICATE-----
MIID5zCCAs+gAwIBAgIJALnu1NlVpZ6zMA0GCSqGSIb3DQEBBQUAMHAxCzAJBgNV
BAYTAlVLMRYwFAYDVQQKDA1PcGVuU1NMIEdyb3VwMSIwIAYDVQQLDBlGT1IgVEVT
VElORyBQVVJQT1NFUyBPTkxZMSUwIwYDVQQDDBxPcGVuU1NMIFRlc3QgSW50ZXJt
ZWRpYXRlIENBMB4XDTExMTIwODE0MDE0OFoXDTIxMTAxNjE0MDE0OFowZDELMAkG
A1UEBhMCVUsxFjAUBgNVBAoMDU9wZW5TU0wgR3JvdXAxIjAgBgNVBAsMGUZPUiBU
RVNUSU5HIFBVUlBPU0VTIE9OTFkxGTAXBgNVBAMMEFRlc3QgU2VydmVyIENlcnQw
ggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDzhPOSNtyyRspmeuUpxfNJ
KCLTuf7g3uQ4zu4iHOmRO5TQci+HhVlLZrHF9XqFXcIP0y4pWDbMSGuiorUmzmfi
R7bfSdI/+qIQt8KXRH6HNG1t8ou0VSvWId5TS5Dq/er5ODUr9OaaDva7EquHIcMv
vPQGuI+OEAcnleVCy9HVEIySrO4P3CNIicnGkwwiAud05yUAq/gPXBC1hTtmlPD7
TVcGVSEiJdvzqqlgv02qedGrkki6GY4S7GjZxrrf7Foc2EP+51LJzwLQx3/JfrCU
41NEWAsu/Sl0tQabXESN+zJ1pDqoZ3uHMgpQjeGiE0olr+YcsSW/tJmiU9OiAr8R
AgMBAAGjgY8wgYwwDAYDVR0TAQH/BAIwADAOBgNVHQ8BAf8EBAMCBeAwLAYJYIZI
AYb4QgENBB8WHU9wZW5TU0wgR2VuZXJhdGVkIENlcnRpZmljYXRlMB0GA1UdDgQW
BBSCvM8AABPR9zklmifnr9LvIBturDAfBgNVHSMEGDAWgBQ2w2yI55X+sL3szj49
hqshgYfa2jANBgkqhkiG9w0BAQUFAAOCAQEAqb1NV0B0/pbpK9Z4/bNjzPQLTRLK
WnSNm/Jh5v0GEUOE/Beg7GNjNrmeNmqxAlpqWz9qoeoFZax+QBpIZYjROU3TS3fp
yLsrnlr0CDQ5R7kCCDGa8dkXxemmpZZLbUCpW2Uoy8sAA4JjN9OtsZY7dvUXFgJ7
vVNTRnI01ghknbtD+2SxSQd3CWF6QhcRMAzZJ1z1cbbwGDDzfvGFPzJ+Sq+zEPds
xoVLLSetCiBc+40ZcDS5dV98h9XD7JMTQfxzA7mNGv73JoZJA6nFgj+ADSlJsY/t
JBv+z1iQRueoh9Qeee+ZbRifPouCB8FDx+AltvHTANdAq0t/K3o+pplMVA==
-----END CERTIFICATE-----
subject=C = UK, O = OpenSSL Group, OU = FOR TESTING PURPOSES ONLY, CN = Test Server Cert

issuer=C = UK, O = OpenSSL Group, OU = FOR TESTING PURPOSES ONLY, CN = OpenSSL Test Intermediate CA

---
No client certificate CA names sent
Peer signing digest: SHA256
Peer signature type: RSA-PSS
Server Temp Key: X25519, 253 bits
---
SSL handshake has read 1547 bytes and written 365 bytes
Verification error: unable to verify the first certificate
---
New, TLSv1.3, Cipher is TLS13-AES-128-GCM-SHA256
Server public key is 2048 bit
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
Early data was not sent
SSL-Session:
    Protocol  : TLSv1.3
    Cipher    : TLS13-AES-128-GCM-SHA256
    Session-ID: 
    Session-ID-ctx: 
    Master-Key: 000102030405060708090A0B0C0D0E0F101112131415161718191A1B1C1D1E1F
    PSK identity: None
    PSK identity hint: None
    SRP username: None
    Start Time: 1515606815
    Timeout   : 7200 (sec)
    Verify return code: 21 (unable to verify the first certificate)
    Extended master secret: no
---

DONE
Forwarded packet length = 65

CONNECTION ESTABLISHED
Protocol version: TLSv1.3
Client cipher list: ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:DHE-RSA-AES256-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES256-SHA:ECDHE-RSA-AES256-SHA:DHE-RSA-AES256-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES128-SHA:DHE-RSA-AES128-SHA:AES256-GCM-SHA384:AES128-GCM-SHA256:TLS13-AES-256-GCM-SHA384:TLS13-CHACHA20-POLY1305-SHA256:TLS13-AES-128-GCM-SHA256:AES256-SHA256:AES128-SHA256:AES256-SHA:AES128-SHA:TLS_EMPTY_RENEGOTIATION_INFO_SCSV
Ciphersuite: TLS13-AES-128-GCM-SHA256
Signature Algorithms: ECDSA+SHA256:ECDSA+SHA384:ECDSA+SHA512:Ed25519:RSA-PSS+SHA256:RSA-PSS+SHA384:RSA-PSS+SHA512:RSA+SHA256:RSA+SHA384:RSA+SHA512:ECDSA+SHA224:ECDSA+SHA1:RSA+SHA224:RSA+SHA1:DSA+SHA224:DSA+SHA1:DSA+SHA256:DSA+SHA384:DSA+SHA512
No peer certificate
Supported Elliptic Groups: X25519:P-256:P-521:P-384
Received server packet
Packet length = 224
Processing flight 3
 Record 1 (server -> client)
  Content type: APPLICATION DATA
  Version: TLS1.2
  Length: 219
  Inner content type: HANDSHAKE
  Message type: NewSessionTicket
  Message Length: 198

Forwarded packet length = 225

Connection closed
Waiting for server process to close: 31948
CONNECTION CLOSED
   1 items in the session cache
   0 client connects (SSL_connect())
   0 client renegotiates (SSL_connect())
   0 client connects that finished
   1 server accepts (SSL_accept())
   0 server renegotiates (SSL_accept())
   1 server accepts that finished
   0 session cache hits
   0 session cache misses
   0 session cache timeouts
   0 callback cache hits
   0 cache full overflows (128 allowed)
Waiting for client process to close: 31949
not ok 13 - Changed record version in TLS1.3

#   Failed test 'Changed record version in TLS1.3'
#   at ../test/recipes/70-test_sslrecords.t line 156.

From matt at openssl.org  Wed Jan 10 19:10:43 2018
From: matt at openssl.org (Matt Caswell)
Date: Wed, 10 Jan 2018 19:10:43 +0000
Subject: [openssl-project] Levchin prize
Message-ID: <04233dcb-0cdd-037f-4dbd-094571a224b6@openssl.org>

I've been in Zurich today to collect the Levchin prize on behalf of the
team. I've put a draft blog post about it in the blog repo.

Please let me have any comments ASAP!!! I plan to make this public in a
couple of hours or so - I think it should go out today (the press
release is already public). I'm also planning to send announcements
pointing at the blog post to -users, -dev and -announce. If anyone
objects please let me know.

I'm particularly pleased with what it says on the trophy:

"For dramatic improvements to the code quality of OpenSSL"

Matt


From levitte at openssl.org  Wed Jan 10 19:32:32 2018
From: levitte at openssl.org (Richard Levitte)
Date: Wed, 10 Jan 2018 20:32:32 +0100 (CET)
Subject: [openssl-project] Levchin prize
In-Reply-To: <04233dcb-0cdd-037f-4dbd-094571a224b6@openssl.org>
References: <04233dcb-0cdd-037f-4dbd-094571a224b6@openssl.org>
Message-ID: <20180110.203232.1082744388269773061.levitte@openssl.org>

In message <04233dcb-0cdd-037f-4dbd-094571a224b6 at openssl.org> on Wed, 10 Jan 2018 19:10:43 +0000, Matt Caswell <matt at openssl.org> said:

matt> I've been in Zurich today to collect the Levchin prize on behalf of the
matt> team. I've put a draft blog post about it in the blog repo.
matt> 
matt> Please let me have any comments ASAP!!! I plan to make this public in a
matt> couple of hours or so - I think it should go out today (the press
matt> release is already public). I'm also planning to send announcements
matt> pointing at the blog post to -users, -dev and -announce. If anyone
matt> objects please let me know.
matt> 
matt> I'm particularly pleased with what it says on the trophy:
matt> 
matt> "For dramatic improvements to the code quality of OpenSSL"

+1 on the blog post

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

From kaduk at mit.edu  Wed Jan 10 19:33:54 2018
From: kaduk at mit.edu (Benjamin Kaduk)
Date: Wed, 10 Jan 2018 13:33:54 -0600
Subject: [openssl-project] update on sporadic test failures
In-Reply-To: <20180110181329.GH72574@kduck.kaduk.org>
References: <20180110181329.GH72574@kduck.kaduk.org>
Message-ID: <20180110193354.GK72574@kduck.kaduk.org>

On Wed, Jan 10, 2018 at 12:13:29PM -0600, Benjamin Kaduk wrote:
> I've been running 'make test' in a loop to try to reproduce the
> sporadic failures that we've been seeing in the build farms.
> Subjectively it seemed like it was easier to reproduce issues on
> OpenSSL_1_1_0-stable than master, but I have seen "Dubious, test
> returned 1 (wstat 256, 0x100)" on both.

And I managed to capture one of these, too.

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

ok 7 - No matching TLSv1.3 sigalgs
Server command: ../../util/shlib_wrap.sh ../../apps/openssl s_server -no_comp -rev -engine ossltest -accept 4443 -cert ../../apps/server.pem -cert2 ../../apps/server.pem -naccept 1 -cipher ECDHE-RSA-AES128-SHA:TLS13-AES-128-GCM-SHA256 -no_tls1_3
Proxy started on port 4453
Client command: echo test | ../../util/shlib_wrap.sh ../../apps/openssl s_client -engine ossltest -connect localhost:4453
engine "ossltest" set.
Connection opened
engine "ossltest" set.
Using default temp DH parameters
ACCEPT
Received client packet
Packet length = 301
Processing flight 0
 Record 1 (client -> server)
  Content type: HANDSHAKE
  Version: TLS1.0
  Length: 296
  Message type: ClientHello
  Message Length: 292
    Client Version:771
    Session ID Len:32
    Ciphersuite len:62
    Compression Method Len:1
    Extensions Len:157

Forwarded packet length = 301

Received server packet
Packet length = 1406
Processing flight 1
 Record 1 (server -> client)
  Content type: HANDSHAKE
  Version: TLS1.2
  Length: 69
  Message type: ServerHello
  Message Length: 65
    Server Version:771
    Session ID Len:0
    Ciphersuite:49171
    Compression Method:0
    Extensions Len:25
 Record 2 (server -> client)
  Content type: HANDSHAKE
  Version: TLS1.2
  Length: 1013
  Message type: Certificate
  Message Length: 1009
    Certificate List Len:1006
    Certificate Len:1003
 Record 3 (server -> client)
  Content type: HANDSHAKE
  Version: TLS1.2
  Length: 300
  Message type: ServerKeyExchange
  Message Length: 296
 Record 4 (server -> client)
  Content type: HANDSHAKE
  Version: TLS1.2
  Length: 4
  Message type: ServerHelloDone
  Message Length: 0

Forwarded packet length = 1406

depth=0 C = UK, O = OpenSSL Group, OU = FOR TESTING PURPOSES ONLY, CN = Test Server Cert
verify error:num=20:unable to get local issuer certificate
verify return:1
depth=0 C = UK, O = OpenSSL Group, OU = FOR TESTING PURPOSES ONLY, CN = Test Server Cert
verify error:num=21:unable to verify the first certificate
verify return:1
Received client packet
Packet length = 121
Processing flight 2
 Record 1 (client -> server)
  Content type: HANDSHAKE
  Version: TLS1.2
  Length: 37
  Message type: ClientKeyExchange
  Message Length: 33
 Record 2 (client -> server)
  Content type: CCS
  Version: TLS1.2
  Length: 1
 Record 3 (client -> server)
  Content type: HANDSHAKE
  Version: TLS1.2
  Length: 68
  Message type: Finished
  Message Length: 12

Forwarded packet length = 121

CONNECTION ESTABLISHED
Protocol version: TLSv1.2
Client cipher list: ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:DHE-RSA-AES256-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES256-SHA:Received server packet
ECDHE-RSA-AES256-SHA:DHE-RSA-AES256-SHA:Packet length = 270
ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES128-SHA:DHE-RSA-AES128-SHA:AES256-GCM-SHA384Processing flight 3
:AES128-GCM-SHA256:TLS13-AES-256-GCM-SHA384:TLS13-CHACHA20-POLY1305-SHA256:TLS13-AES-128-GCM-SHA256:AES256-SHA256:AES128-SHA256 Record 1:AES256-SHA (server -> client)
:AES128-SHA:TLS_EMPTY_RENEGOTIATION_INFO_SCSV
Ciphersuite: ECDHE-RSA-AES128-SHA
Signature Algorithms: ECDSA+SHA256:ECDSA+SHA384:ECDSA+SHA512:Ed25519:RSA-PSS+SHA256:RSA-PSS+SHA384:RSA-PSS+SHA512:RSA+SHA256:RSA+SHA384:RSA+SHA512:ECDSA  Content type: HANDSHAKE
+SHA224:ECDSA  Version: TLS1.2
+SHA1:RSA  Length: 186+SHA224:RSA
+SHA1:DSA+SHA224:DSA+SHA1:DSA+SHA256:DSA+SHA384:DSA+SHA512
No peer certificate
Supported Elliptic Curve Point Formats: uncompressed:ansiX962_compressed_prime:ansiX962_compressed_char2
Supported Elliptic Groups: X25519:P-256:P-521:P-384
  Message type: NewSessionTicket
  Message Length: 182
 Record 2 (server -> client)
  Content type: CCS
  Version: TLS1.2
  Length: 1
 Record 3 (server -> client)
  Content type: HANDSHAKE
  Version: TLS1.2
  Length: 68
  Message type: Finished
  Message Length: 12

Forwarded packet length = 270

CONNECTED(00000003)
---
Certificate chain
 0 s:C = UK, O = OpenSSL Group, OU = FOR TESTING PURPOSES ONLY, CN = Test Server Cert
   i:C = UK, O = OpenSSL Group, OU = FOR TESTING PURPOSES ONLY, CN = OpenSSL Test Intermediate CA
---
Server certificate
-----BEGIN CERTIFICATE-----
MIID5zCCAs+gAwIBAgIJALnu1NlVpZ6zMA0GCSqGSIb3DQEBBQUAMHAxCzAJBgNV
BAYTAlVLMRYwFAYDVQQKDA1PcGVuU1NMIEdyb3VwMSIwIAYDVQQLDBlGT1IgVEVT
VElORyBQVVJQT1NFUyBPTkxZMSUwIwYDVQQDDBxPcGVuU1NMIFRlc3QgSW50ZXJt
ZWRpYXRlIENBMB4XDTExMTIwODE0MDE0OFoXDTIxMTAxNjE0MDE0OFowZDELMAkG
A1UEBhMCVUsxFjAUBgNVBAoMDU9wZW5TU0wgR3JvdXAxIjAgBgNVBAsMGUZPUiBU
RVNUSU5HIFBVUlBPU0VTIE9OTFkxGTAXBgNVBAMMEFRlc3QgU2VydmVyIENlcnQw
ggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDzhPOSNtyyRspmeuUpxfNJ
KCLTuf7g3uQ4zu4iHOmRO5TQci+HhVlLZrHF9XqFXcIP0y4pWDbMSGuiorUmzmfi
R7bfSdI/+qIQt8KXRH6HNG1t8ou0VSvWId5TS5Dq/er5ODUr9OaaDva7EquHIcMv
vPQGuI+OEAcnleVCy9HVEIySrO4P3CNIicnGkwwiAud05yUAq/gPXBC1hTtmlPD7
TVcGVSEiJdvzqqlgv02qedGrkki6GY4S7GjZxrrf7Foc2EP+51LJzwLQx3/JfrCU
41NEWAsu/Sl0tQabXESN+zJ1pDqoZ3uHMgpQjeGiE0olr+YcsSW/tJmiU9OiAr8R
AgMBAAGjgY8wgYwwDAYDVR0TAQH/BAIwADAOBgNVHQ8BAf8EBAMCBeAwLAYJYIZI
AYb4QgENBB8WHU9wZW5TU0wgR2VuZXJhdGVkIENlcnRpZmljYXRlMB0GA1UdDgQW
BBSCvM8AABPR9zklmifnr9LvIBturDAfBgNVHSMEGDAWgBQ2w2yI55X+sL3szj49
hqshgYfa2jANBgkqhkiG9w0BAQUFAAOCAQEAqb1NV0B0/pbpK9Z4/bNjzPQLTRLK
WnSNm/Jh5v0GEUOE/Beg7GNjNrmeNmqxAlpqWz9qoeoFZax+QBpIZYjROU3TS3fp
yLsrnlr0CDQ5R7kCCDGa8dkXxemmpZZLbUCpW2Uoy8sAA4JjN9OtsZY7dvUXFgJ7
vVNTRnI01ghknbtD+2SxSQd3CWF6QhcRMAzZJ1z1cbbwGDDzfvGFPzJ+Sq+zEPds
xoVLLSetCiBc+40ZcDS5dV98h9XD7JMTQfxzA7mNGv73JoZJA6nFgj+ADSlJsY/t
JBv+z1iQRueoh9Qeee+ZbRifPouCB8FDx+AltvHTANdAq0t/K3o+pplMVA==
-----END CERTIFICATE-----
subject=C = UK, O = OpenSSL Group, OU = FOR TESTING PURPOSES ONLY, CN = Test Server Cert

issuer=C = UK, O = OpenSSL Group, OU = FOR TESTING PURPOSES ONLY, CN = OpenSSL Test Intermediate CA

---
No client certificate CA names sent
Peer signing digest: SHA256
Peer signature type: RSA-PSS
Server Temp Key: X25519, 253 bits
---
SSL handshake has read 1676 bytes and written 422 bytes
Verification error: unable to verify the first certificate
---
New, TLSv1.0, Cipher is ECDHE-RSA-AES128-SHA
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
    Protocol  : TLSv1.2
    Cipher    : ECDHE-RSA-AES128-SHA
    Session-ID: 000102030405060708090A0B0C0D0E0F101112131415161718191A1B1C1D1E1F
    Session-ID-ctx: 
    Master-Key: 000102030405060708090A0B0C0D0E0F101112131415161718191A1B1C1D1E1F000102030405060708090A0B0C0D0E0F
    PSK identity: None
    PSK identity hint: None
    SRP username: None
    TLS session ticket lifetime hint: 7200 (seconds)
    TLS session ticket:
    0000 - 01 02 03 04 05 06 07 08-09 0a 0b 0c 0d 0e 0f 10   ................
    0010 - 01 02 03 04 05 06 07 08-09 0a 0b 0c 0d 0e 0f 10   ................
    0020 - 82 48 f7 82 0f 7f 21 bf-f4 19 28 80 63 9f da 52   .H....!...(.c..R
    0030 - 3a 16 a9 85 de 2f 41 96-90 4d f7 f1 b1 11 b8 63   :..../A..M.....c
    0040 - 2d c5 62 f7 e3 da be 90-aa 50 3c 9b e7 ad 41 35   -.b......P<...A5
    0050 - c7 76 8d 18 a6 f7 9a 73-6b 25 4a 90 c7 ca 70 ef   .v.....sk%J...p.
    0060 - 94 de be 7d e8 88 9f 16-57 c3 c6 c5 6c 94 dd c6   ...}....W...l...
    0070 - 18 77 1e ff 26 30 ba 51-f2 dd 37 2e f1 b3 df 0a   .w..&0.Q..7.....
    0080 - 02 db 47 a9 ad eb 1a f0-5d 5e d0 a8 85 ee d0 d2   ..G.....]^......
    0090 - 00 01 02 03 04 05 06 07-08 09 0a 0b 0c 0d 0e 0f   ................
    00a0 - 10 11 12 13 14 15 16 17-18 19 1a 1b 1c 1d 1e 1f   ................

    Start Time: 1515610433
    Timeout   : 7200 (sec)
    Verify return code: 21 (unable to verify the first certificate)
    Extended master secret: yes
---
DONE
Received client packet
Packet length = 57
Processing flight 4
 Record 1 (client -> server)
  Content type: APPLICATION DATA
  Version: TLS1.2
  Length: 52
  [ENCRYPTED APPLICATION DATA]
  [test
]

Forwarded packet length = 57

Received server packet
Packet length = 57
Processing flight 5
 Record 1 (server -> client)
  Content type: APPLICATION DATA
  Version: TLS1.2
  Length: 52
  [ENCRYPTED APPLICATION DATA]
  [tset
]

Forwarded packet length = 57

Connection closed
Waiting for server process to close: 26085
CONNECTION CLOSED
   0 items in the session cache
   0 client connects (SSL_connect())
   0 client renegotiates (SSL_connect())
   0 client connects that finished
   1 server accepts (SSL_accept())
   0 server renegotiates (SSL_accept())
   1 server accepts that finished
   0 session cache hits
   1 session cache misses
   0 session cache timeouts
   0 callback cache hits
   0 cache full overflows (128 allowed)
Waiting for client process to close: 26086
not ok 8 - TLSv1.3 client TLSv1.2 server

#   Failed test 'TLSv1.3 client TLSv1.2 server'
#   at ../test/recipes/70-test_sslsigalgs.t line 119.

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

In the pass-ing test, the last forwarded packet is client->server of
type ALERT (but is still length 57 including record header).

-Ben

From levitte at openssl.org  Wed Jan 10 19:35:09 2018
From: levitte at openssl.org (Richard Levitte)
Date: Wed, 10 Jan 2018 20:35:09 +0100 (CET)
Subject: [openssl-project] Levchin prize
In-Reply-To: <20180110.203232.1082744388269773061.levitte@openssl.org>
References: <04233dcb-0cdd-037f-4dbd-094571a224b6@openssl.org>
 <20180110.203232.1082744388269773061.levitte@openssl.org>
Message-ID: <20180110.203509.257786872037977157.levitte@openssl.org>

In message <20180110.203232.1082744388269773061.levitte at openssl.org> on Wed, 10 Jan 2018 20:32:32 +0100 (CET), Richard Levitte <levitte at openssl.org> said:

levitte> In message <04233dcb-0cdd-037f-4dbd-094571a224b6 at openssl.org> on Wed, 10 Jan 2018 19:10:43 +0000, Matt Caswell <matt at openssl.org> said:
levitte> 
levitte> matt> I've been in Zurich today to collect the Levchin prize on behalf of the
levitte> matt> team. I've put a draft blog post about it in the blog repo.
levitte> matt> 
levitte> matt> Please let me have any comments ASAP!!! I plan to make this public in a
levitte> matt> couple of hours or so - I think it should go out today (the press
levitte> matt> release is already public). I'm also planning to send announcements
levitte> matt> pointing at the blog post to -users, -dev and -announce. If anyone
levitte> matt> objects please let me know.
levitte> matt> 
levitte> matt> I'm particularly pleased with what it says on the trophy:
levitte> matt> 
levitte> matt> "For dramatic improvements to the code quality of OpenSSL"
levitte> 
levitte> +1 on the blog post

Something to be noted, though, is that the blog commit log goes to
openssl-omc only.  Should we change that?  That, or you should
probably attach the blog post to your next message, so everyone has a
chance to look.

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

From matt at openssl.org  Wed Jan 10 19:42:13 2018
From: matt at openssl.org (Matt Caswell)
Date: Wed, 10 Jan 2018 19:42:13 +0000
Subject: [openssl-project] Levchin prize
In-Reply-To: <20180110.203509.257786872037977157.levitte@openssl.org>
References: <04233dcb-0cdd-037f-4dbd-094571a224b6@openssl.org>
 <20180110.203232.1082744388269773061.levitte@openssl.org>
 <20180110.203509.257786872037977157.levitte@openssl.org>
Message-ID: <327bc583-2b5a-4072-9ce9-ee57f8ba6e7b@openssl.org>



On 10/01/18 19:35, Richard Levitte wrote:
> In message <20180110.203232.1082744388269773061.levitte at openssl.org> on Wed, 10 Jan 2018 20:32:32 +0100 (CET), Richard Levitte <levitte at openssl.org> said:
> 
> levitte> In message <04233dcb-0cdd-037f-4dbd-094571a224b6 at openssl.org> on Wed, 10 Jan 2018 19:10:43 +0000, Matt Caswell <matt at openssl.org> said:
> levitte> 
> levitte> matt> I've been in Zurich today to collect the Levchin prize on behalf of the
> levitte> matt> team. I've put a draft blog post about it in the blog repo.
> levitte> matt> 
> levitte> matt> Please let me have any comments ASAP!!! I plan to make this public in a
> levitte> matt> couple of hours or so - I think it should go out today (the press
> levitte> matt> release is already public). I'm also planning to send announcements
> levitte> matt> pointing at the blog post to -users, -dev and -announce. If anyone
> levitte> matt> objects please let me know.
> levitte> matt> 
> levitte> matt> I'm particularly pleased with what it says on the trophy:
> levitte> matt> 
> levitte> matt> "For dramatic improvements to the code quality of OpenSSL"
> levitte> 
> levitte> +1 on the blog post
> 
> Something to be noted, though, is that the blog commit log goes to
> openssl-omc only.  Should we change that?  That, or you should
> probably attach the blog post to your next message, so everyone has a
> chance to look.
> 

Yeah - wasn't sure who had access to it. But since we're talking about
reviewing something before it goes public, I guess I shouldn't attach it
to a list which is public? I'll send it to the openssl-committers list.

Maybe we should change "blog" so committers at least have read access?

Matt

From matt at openssl.org  Wed Jan 10 19:49:42 2018
From: matt at openssl.org (Matt Caswell)
Date: Wed, 10 Jan 2018 19:49:42 +0000
Subject: [openssl-project] Levchin prize
In-Reply-To: <04233dcb-0cdd-037f-4dbd-094571a224b6@openssl.org>
References: <04233dcb-0cdd-037f-4dbd-094571a224b6@openssl.org>
Message-ID: <aa986578-442b-e5b8-a615-fdf0c1d5ed30@openssl.org>

BTW we got a small "cheer" from some members of the audience when it was
announced we had won. I liked that :-)

Matt


On 10/01/18 19:10, Matt Caswell wrote:
> I've been in Zurich today to collect the Levchin prize on behalf of the
> team. I've put a draft blog post about it in the blog repo.
> 
> Please let me have any comments ASAP!!! I plan to make this public in a
> couple of hours or so - I think it should go out today (the press
> release is already public). I'm also planning to send announcements
> pointing at the blog post to -users, -dev and -announce. If anyone
> objects please let me know.
> 
> I'm particularly pleased with what it says on the trophy:
> 
> "For dramatic improvements to the code quality of OpenSSL"
> 
> Matt
> 
> _______________________________________________
> openssl-project mailing list
> openssl-project at openssl.org
> https://mta.openssl.org/mailman/listinfo/openssl-project
> 

From rsalz at akamai.com  Wed Jan 10 20:03:58 2018
From: rsalz at akamai.com (Salz, Rich)
Date: Wed, 10 Jan 2018 20:03:58 +0000
Subject: [openssl-project] Levchin prize
In-Reply-To: <20180110.203509.257786872037977157.levitte@openssl.org>
References: <04233dcb-0cdd-037f-4dbd-094571a224b6@openssl.org>
 <20180110.203232.1082744388269773061.levitte@openssl.org>
 <20180110.203509.257786872037977157.levitte@openssl.org>
Message-ID: <B3E3A215-3EDA-49A5-9FB2-3D5125F3BBDB@akamai.com>

? Something to be noted, though, is that the blog commit log goes to
    openssl-omc only.  Should we change that?

No

?   That, or you should
    probably attach the blog post to your next message, so everyone has a
    chance to look.
    
Maybe.



From rsalz at akamai.com  Wed Jan 10 20:04:38 2018
From: rsalz at akamai.com (Salz, Rich)
Date: Wed, 10 Jan 2018 20:04:38 +0000
Subject: [openssl-project] Levchin prize
In-Reply-To: <327bc583-2b5a-4072-9ce9-ee57f8ba6e7b@openssl.org>
References: <04233dcb-0cdd-037f-4dbd-094571a224b6@openssl.org>
 <20180110.203232.1082744388269773061.levitte@openssl.org>
 <20180110.203509.257786872037977157.levitte@openssl.org>
 <327bc583-2b5a-4072-9ce9-ee57f8ba6e7b@openssl.org>
Message-ID: <491C070B-D240-479F-8AF7-07510BCF7885@akamai.com>

?     Maybe we should change "blog" so committers at least have read access?
    
No.


From levitte at openssl.org  Wed Jan 10 20:06:33 2018
From: levitte at openssl.org (Richard Levitte)
Date: Wed, 10 Jan 2018 21:06:33 +0100 (CET)
Subject: [openssl-project] update on sporadic test failures
In-Reply-To: <20180110193354.GK72574@kduck.kaduk.org>
References: <20180110181329.GH72574@kduck.kaduk.org>
 <20180110193354.GK72574@kduck.kaduk.org>
Message-ID: <20180110.210633.18077756344254585.levitte@openssl.org>

In message <20180110193354.GK72574 at kduck.kaduk.org> on Wed, 10 Jan 2018 13:33:54 -0600, Benjamin Kaduk <kaduk at mit.edu> said:

kaduk> On Wed, Jan 10, 2018 at 12:13:29PM -0600, Benjamin Kaduk wrote:
kaduk> > I've been running 'make test' in a loop to try to reproduce the
kaduk> > sporadic failures that we've been seeing in the build farms.
kaduk> > Subjectively it seemed like it was easier to reproduce issues on
kaduk> > OpenSSL_1_1_0-stable than master, but I have seen "Dubious, test
kaduk> > returned 1 (wstat 256, 0x100)" on both.
kaduk> 
kaduk> And I managed to capture one of these, too.
kaduk> 
kaduk> %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
kaduk> 
kaduk> ok 7 - No matching TLSv1.3 sigalgs
kaduk> Server command: ../../util/shlib_wrap.sh ../../apps/openssl s_server -no_comp -rev -engine ossltest -accept 4443 -cert ../../apps/server.pem -cert2 ../../apps/server.pem -naccept 1 -cipher ECDHE-RSA-AES128-SHA:TLS13-AES-128-GCM-SHA256 -no_tls1_3
kaduk> Proxy started on port 4453
kaduk> Client command: echo test | ../../util/shlib_wrap.sh ../../apps/openssl s_client -engine ossltest -connect localhost:4453
kaduk> engine "ossltest" set.
kaduk> Connection opened
kaduk> engine "ossltest" set.
kaduk> Using default temp DH parameters
kaduk> ACCEPT
kaduk> Received client packet
kaduk> Packet length = 301
kaduk> Processing flight 0
kaduk>  Record 1 (client -> server)
kaduk>   Content type: HANDSHAKE
kaduk>   Version: TLS1.0
kaduk>   Length: 296
kaduk>   Message type: ClientHello
kaduk>   Message Length: 292
kaduk>     Client Version:771
kaduk>     Session ID Len:32
kaduk>     Ciphersuite len:62
kaduk>     Compression Method Len:1
kaduk>     Extensions Len:157
kaduk> 
kaduk> Forwarded packet length = 301
kaduk> 
kaduk> Received server packet
kaduk> Packet length = 1406
kaduk> Processing flight 1
kaduk>  Record 1 (server -> client)
kaduk>   Content type: HANDSHAKE
kaduk>   Version: TLS1.2
kaduk>   Length: 69
kaduk>   Message type: ServerHello
kaduk>   Message Length: 65
kaduk>     Server Version:771
kaduk>     Session ID Len:0
kaduk>     Ciphersuite:49171
kaduk>     Compression Method:0
kaduk>     Extensions Len:25
kaduk>  Record 2 (server -> client)
kaduk>   Content type: HANDSHAKE
kaduk>   Version: TLS1.2
kaduk>   Length: 1013
kaduk>   Message type: Certificate
kaduk>   Message Length: 1009
kaduk>     Certificate List Len:1006
kaduk>     Certificate Len:1003
kaduk>  Record 3 (server -> client)
kaduk>   Content type: HANDSHAKE
kaduk>   Version: TLS1.2
kaduk>   Length: 300
kaduk>   Message type: ServerKeyExchange
kaduk>   Message Length: 296
kaduk>  Record 4 (server -> client)
kaduk>   Content type: HANDSHAKE
kaduk>   Version: TLS1.2
kaduk>   Length: 4
kaduk>   Message type: ServerHelloDone
kaduk>   Message Length: 0
kaduk> 
kaduk> Forwarded packet length = 1406
kaduk> 
kaduk> depth=0 C = UK, O = OpenSSL Group, OU = FOR TESTING PURPOSES ONLY, CN = Test Server Cert
kaduk> verify error:num=20:unable to get local issuer certificate
kaduk> verify return:1
kaduk> depth=0 C = UK, O = OpenSSL Group, OU = FOR TESTING PURPOSES ONLY, CN = Test Server Cert
kaduk> verify error:num=21:unable to verify the first certificate
kaduk> verify return:1
kaduk> Received client packet
kaduk> Packet length = 121
kaduk> Processing flight 2
kaduk>  Record 1 (client -> server)
kaduk>   Content type: HANDSHAKE
kaduk>   Version: TLS1.2
kaduk>   Length: 37
kaduk>   Message type: ClientKeyExchange
kaduk>   Message Length: 33
kaduk>  Record 2 (client -> server)
kaduk>   Content type: CCS
kaduk>   Version: TLS1.2
kaduk>   Length: 1
kaduk>  Record 3 (client -> server)
kaduk>   Content type: HANDSHAKE
kaduk>   Version: TLS1.2
kaduk>   Length: 68
kaduk>   Message type: Finished
kaduk>   Message Length: 12
kaduk> 
kaduk> Forwarded packet length = 121
kaduk> 
kaduk> CONNECTION ESTABLISHED
kaduk> Protocol version: TLSv1.2
kaduk> Client cipher list: ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:DHE-RSA-AES256-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES256-SHA:Received server packet
kaduk> ECDHE-RSA-AES256-SHA:DHE-RSA-AES256-SHA:Packet length = 270
kaduk> ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES128-SHA:DHE-RSA-AES128-SHA:AES256-GCM-SHA384Processing flight 3
kaduk> :AES128-GCM-SHA256:TLS13-AES-256-GCM-SHA384:TLS13-CHACHA20-POLY1305-SHA256:TLS13-AES-128-GCM-SHA256:AES256-SHA256:AES128-SHA256 Record 1:AES256-SHA (server -> client)
kaduk> :AES128-SHA:TLS_EMPTY_RENEGOTIATION_INFO_SCSV
kaduk> Ciphersuite: ECDHE-RSA-AES128-SHA
kaduk> Signature Algorithms: ECDSA+SHA256:ECDSA+SHA384:ECDSA+SHA512:Ed25519:RSA-PSS+SHA256:RSA-PSS+SHA384:RSA-PSS+SHA512:RSA+SHA256:RSA+SHA384:RSA+SHA512:ECDSA  Content type: HANDSHAKE
kaduk> +SHA224:ECDSA  Version: TLS1.2
kaduk> +SHA1:RSA  Length: 186+SHA224:RSA
kaduk> +SHA1:DSA+SHA224:DSA+SHA1:DSA+SHA256:DSA+SHA384:DSA+SHA512
kaduk> No peer certificate
kaduk> Supported Elliptic Curve Point Formats: uncompressed:ansiX962_compressed_prime:ansiX962_compressed_char2
kaduk> Supported Elliptic Groups: X25519:P-256:P-521:P-384
kaduk>   Message type: NewSessionTicket
kaduk>   Message Length: 182
kaduk>  Record 2 (server -> client)
kaduk>   Content type: CCS
kaduk>   Version: TLS1.2
kaduk>   Length: 1
kaduk>  Record 3 (server -> client)
kaduk>   Content type: HANDSHAKE
kaduk>   Version: TLS1.2
kaduk>   Length: 68
kaduk>   Message type: Finished
kaduk>   Message Length: 12
kaduk> 
kaduk> Forwarded packet length = 270
kaduk> 
kaduk> CONNECTED(00000003)
kaduk> ---
kaduk> Certificate chain
kaduk>  0 s:C = UK, O = OpenSSL Group, OU = FOR TESTING PURPOSES ONLY, CN = Test Server Cert
kaduk>    i:C = UK, O = OpenSSL Group, OU = FOR TESTING PURPOSES ONLY, CN = OpenSSL Test Intermediate CA
kaduk> ---
kaduk> Server certificate
kaduk> -----BEGIN CERTIFICATE-----
kaduk> MIID5zCCAs+gAwIBAgIJALnu1NlVpZ6zMA0GCSqGSIb3DQEBBQUAMHAxCzAJBgNV
kaduk> BAYTAlVLMRYwFAYDVQQKDA1PcGVuU1NMIEdyb3VwMSIwIAYDVQQLDBlGT1IgVEVT
kaduk> VElORyBQVVJQT1NFUyBPTkxZMSUwIwYDVQQDDBxPcGVuU1NMIFRlc3QgSW50ZXJt
kaduk> ZWRpYXRlIENBMB4XDTExMTIwODE0MDE0OFoXDTIxMTAxNjE0MDE0OFowZDELMAkG
kaduk> A1UEBhMCVUsxFjAUBgNVBAoMDU9wZW5TU0wgR3JvdXAxIjAgBgNVBAsMGUZPUiBU
kaduk> RVNUSU5HIFBVUlBPU0VTIE9OTFkxGTAXBgNVBAMMEFRlc3QgU2VydmVyIENlcnQw
kaduk> ggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDzhPOSNtyyRspmeuUpxfNJ
kaduk> KCLTuf7g3uQ4zu4iHOmRO5TQci+HhVlLZrHF9XqFXcIP0y4pWDbMSGuiorUmzmfi
kaduk> R7bfSdI/+qIQt8KXRH6HNG1t8ou0VSvWId5TS5Dq/er5ODUr9OaaDva7EquHIcMv
kaduk> vPQGuI+OEAcnleVCy9HVEIySrO4P3CNIicnGkwwiAud05yUAq/gPXBC1hTtmlPD7
kaduk> TVcGVSEiJdvzqqlgv02qedGrkki6GY4S7GjZxrrf7Foc2EP+51LJzwLQx3/JfrCU
kaduk> 41NEWAsu/Sl0tQabXESN+zJ1pDqoZ3uHMgpQjeGiE0olr+YcsSW/tJmiU9OiAr8R
kaduk> AgMBAAGjgY8wgYwwDAYDVR0TAQH/BAIwADAOBgNVHQ8BAf8EBAMCBeAwLAYJYIZI
kaduk> AYb4QgENBB8WHU9wZW5TU0wgR2VuZXJhdGVkIENlcnRpZmljYXRlMB0GA1UdDgQW
kaduk> BBSCvM8AABPR9zklmifnr9LvIBturDAfBgNVHSMEGDAWgBQ2w2yI55X+sL3szj49
kaduk> hqshgYfa2jANBgkqhkiG9w0BAQUFAAOCAQEAqb1NV0B0/pbpK9Z4/bNjzPQLTRLK
kaduk> WnSNm/Jh5v0GEUOE/Beg7GNjNrmeNmqxAlpqWz9qoeoFZax+QBpIZYjROU3TS3fp
kaduk> yLsrnlr0CDQ5R7kCCDGa8dkXxemmpZZLbUCpW2Uoy8sAA4JjN9OtsZY7dvUXFgJ7
kaduk> vVNTRnI01ghknbtD+2SxSQd3CWF6QhcRMAzZJ1z1cbbwGDDzfvGFPzJ+Sq+zEPds
kaduk> xoVLLSetCiBc+40ZcDS5dV98h9XD7JMTQfxzA7mNGv73JoZJA6nFgj+ADSlJsY/t
kaduk> JBv+z1iQRueoh9Qeee+ZbRifPouCB8FDx+AltvHTANdAq0t/K3o+pplMVA==
kaduk> -----END CERTIFICATE-----
kaduk> subject=C = UK, O = OpenSSL Group, OU = FOR TESTING PURPOSES ONLY, CN = Test Server Cert
kaduk> 
kaduk> issuer=C = UK, O = OpenSSL Group, OU = FOR TESTING PURPOSES ONLY, CN = OpenSSL Test Intermediate CA
kaduk> 
kaduk> ---
kaduk> No client certificate CA names sent
kaduk> Peer signing digest: SHA256
kaduk> Peer signature type: RSA-PSS
kaduk> Server Temp Key: X25519, 253 bits
kaduk> ---
kaduk> SSL handshake has read 1676 bytes and written 422 bytes
kaduk> Verification error: unable to verify the first certificate
kaduk> ---
kaduk> New, TLSv1.0, Cipher is ECDHE-RSA-AES128-SHA
kaduk> Server public key is 2048 bit
kaduk> Secure Renegotiation IS supported
kaduk> Compression: NONE
kaduk> Expansion: NONE
kaduk> No ALPN negotiated
kaduk> SSL-Session:
kaduk>     Protocol  : TLSv1.2
kaduk>     Cipher    : ECDHE-RSA-AES128-SHA
kaduk>     Session-ID: 000102030405060708090A0B0C0D0E0F101112131415161718191A1B1C1D1E1F
kaduk>     Session-ID-ctx: 
kaduk>     Master-Key: 000102030405060708090A0B0C0D0E0F101112131415161718191A1B1C1D1E1F000102030405060708090A0B0C0D0E0F
kaduk>     PSK identity: None
kaduk>     PSK identity hint: None
kaduk>     SRP username: None
kaduk>     TLS session ticket lifetime hint: 7200 (seconds)
kaduk>     TLS session ticket:
kaduk>     0000 - 01 02 03 04 05 06 07 08-09 0a 0b 0c 0d 0e 0f 10   ................
kaduk>     0010 - 01 02 03 04 05 06 07 08-09 0a 0b 0c 0d 0e 0f 10   ................
kaduk>     0020 - 82 48 f7 82 0f 7f 21 bf-f4 19 28 80 63 9f da 52   .H....!...(.c..R
kaduk>     0030 - 3a 16 a9 85 de 2f 41 96-90 4d f7 f1 b1 11 b8 63   :..../A..M.....c
kaduk>     0040 - 2d c5 62 f7 e3 da be 90-aa 50 3c 9b e7 ad 41 35   -.b......P<...A5
kaduk>     0050 - c7 76 8d 18 a6 f7 9a 73-6b 25 4a 90 c7 ca 70 ef   .v.....sk%J...p.
kaduk>     0060 - 94 de be 7d e8 88 9f 16-57 c3 c6 c5 6c 94 dd c6   ...}....W...l...
kaduk>     0070 - 18 77 1e ff 26 30 ba 51-f2 dd 37 2e f1 b3 df 0a   .w..&0.Q..7.....
kaduk>     0080 - 02 db 47 a9 ad eb 1a f0-5d 5e d0 a8 85 ee d0 d2   ..G.....]^......
kaduk>     0090 - 00 01 02 03 04 05 06 07-08 09 0a 0b 0c 0d 0e 0f   ................
kaduk>     00a0 - 10 11 12 13 14 15 16 17-18 19 1a 1b 1c 1d 1e 1f   ................
kaduk> 
kaduk>     Start Time: 1515610433
kaduk>     Timeout   : 7200 (sec)
kaduk>     Verify return code: 21 (unable to verify the first certificate)
kaduk>     Extended master secret: yes
kaduk> ---
kaduk> DONE
kaduk> Received client packet
kaduk> Packet length = 57
kaduk> Processing flight 4
kaduk>  Record 1 (client -> server)
kaduk>   Content type: APPLICATION DATA
kaduk>   Version: TLS1.2
kaduk>   Length: 52
kaduk>   [ENCRYPTED APPLICATION DATA]
kaduk>   [test
kaduk> ]
kaduk> 
kaduk> Forwarded packet length = 57
kaduk> 
kaduk> Received server packet
kaduk> Packet length = 57
kaduk> Processing flight 5
kaduk>  Record 1 (server -> client)
kaduk>   Content type: APPLICATION DATA
kaduk>   Version: TLS1.2
kaduk>   Length: 52
kaduk>   [ENCRYPTED APPLICATION DATA]
kaduk>   [tset
kaduk> ]
kaduk> 
kaduk> Forwarded packet length = 57
kaduk> 
kaduk> Connection closed
kaduk> Waiting for server process to close: 26085
kaduk> CONNECTION CLOSED
kaduk>    0 items in the session cache
kaduk>    0 client connects (SSL_connect())
kaduk>    0 client renegotiates (SSL_connect())
kaduk>    0 client connects that finished
kaduk>    1 server accepts (SSL_accept())
kaduk>    0 server renegotiates (SSL_accept())
kaduk>    1 server accepts that finished
kaduk>    0 session cache hits
kaduk>    1 session cache misses
kaduk>    0 session cache timeouts
kaduk>    0 callback cache hits
kaduk>    0 cache full overflows (128 allowed)
kaduk> Waiting for client process to close: 26086
kaduk> not ok 8 - TLSv1.3 client TLSv1.2 server
kaduk> 
kaduk> #   Failed test 'TLSv1.3 client TLSv1.2 server'
kaduk> #   at ../test/recipes/70-test_sslsigalgs.t line 119.
kaduk> 
kaduk> %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
kaduk> 
kaduk> In the pass-ing test, the last forwarded packet is client->server of
kaduk> type ALERT (but is still length 57 including record header).

Does this ever happen in non-verbose mode?

Does this patch make a difference?

diff --git a/util/perl/TLSProxy/Proxy.pm b/util/perl/TLSProxy/Proxy.pm
index 99b0dedd5b..9330ec2844 100644
--- a/util/perl/TLSProxy/Proxy.pm
+++ b/util/perl/TLSProxy/Proxy.pm
@@ -300,6 +302,7 @@ sub clientstart
             && $ctr < 10) {
         if (!(@ready = $sel->can_read(1))) {
             $ctr++;
+            usleep(100000);     # .1 s sleep, totalling 1 s of attempted reads
             next;
         }
         foreach my $hand (@ready) {

From kaduk at mit.edu  Wed Jan 10 20:12:05 2018
From: kaduk at mit.edu (Benjamin Kaduk)
Date: Wed, 10 Jan 2018 14:12:05 -0600
Subject: [openssl-project] update on sporadic test failures
In-Reply-To: <20180110.210633.18077756344254585.levitte@openssl.org>
References: <20180110181329.GH72574@kduck.kaduk.org>
 <20180110193354.GK72574@kduck.kaduk.org>
 <20180110.210633.18077756344254585.levitte@openssl.org>
Message-ID: <20180110201204.GL72574@kduck.kaduk.org>

On Wed, Jan 10, 2018 at 09:06:33PM +0100, Richard Levitte wrote:
> In message <20180110193354.GK72574 at kduck.kaduk.org> on Wed, 10 Jan 2018 13:33:54 -0600, Benjamin Kaduk <kaduk at mit.edu> said:
> 
> kaduk> On Wed, Jan 10, 2018 at 12:13:29PM -0600, Benjamin Kaduk wrote:
> kaduk> > I've been running 'make test' in a loop to try to reproduce the
> kaduk> > sporadic failures that we've been seeing in the build farms.
> kaduk> > Subjectively it seemed like it was easier to reproduce issues on
> kaduk> > OpenSSL_1_1_0-stable than master, but I have seen "Dubious, test
> kaduk> > returned 1 (wstat 256, 0x100)" on both.
> kaduk> 
> kaduk> And I managed to capture one of these, too.
> kaduk> 
> kaduk> %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
> kaduk> 
> kaduk> ok 7 - No matching TLSv1.3 sigalgs
> kaduk> Server command: ../../util/shlib_wrap.sh ../../apps/openssl s_server -no_comp -rev -engine ossltest -accept 4443 -cert ../../apps/server.pem -cert2 ../../apps/server.pem -naccept 1 -cipher ECDHE-RSA-AES128-SHA:TLS13-AES-128-GCM-SHA256 -no_tls1_3
> kaduk> Proxy started on port 4453
> kaduk> Client command: echo test | ../../util/shlib_wrap.sh ../../apps/openssl s_client -engine ossltest -connect localhost:4453
> kaduk> engine "ossltest" set.
> kaduk> Connection opened
> kaduk> engine "ossltest" set.
> kaduk> Using default temp DH parameters
> kaduk> ACCEPT
> kaduk> Received client packet

Looking at the 'git diff --no-index --color-words' output between
the passing and failing case, there is a lot of output inteleaving
going on, so it's hard to tell what is "real" and what is artifact.
But I will note that the "ACCEPT" line comes before "Connection
opened" in the passing case, and after in the failing case.  Could
we somehow be talking to a proxy/server that was left over from the
previous test?  (I assume not, but have to mention the possibility.)

> kaduk> Packet length = 301
> kaduk> Processing flight 0
> kaduk>  Record 1 (client -> server)
> kaduk>   Content type: HANDSHAKE
> kaduk>   Version: TLS1.0
> kaduk>   Length: 296
> kaduk>   Message type: ClientHello
> kaduk>   Message Length: 292
> kaduk>     Client Version:771
> kaduk>     Session ID Len:32
> kaduk>     Ciphersuite len:62
> kaduk>     Compression Method Len:1
> kaduk>     Extensions Len:157
> kaduk> 
> kaduk> Forwarded packet length = 301
> kaduk> 
> kaduk> Received server packet
> kaduk> Packet length = 1406
> kaduk> Processing flight 1
> kaduk>  Record 1 (server -> client)
> kaduk>   Content type: HANDSHAKE
> kaduk>   Version: TLS1.2
> kaduk>   Length: 69
> kaduk>   Message type: ServerHello
> kaduk>   Message Length: 65
> kaduk>     Server Version:771
> kaduk>     Session ID Len:0
> kaduk>     Ciphersuite:49171
> kaduk>     Compression Method:0
> kaduk>     Extensions Len:25
> kaduk>  Record 2 (server -> client)
> kaduk>   Content type: HANDSHAKE
> kaduk>   Version: TLS1.2
> kaduk>   Length: 1013
> kaduk>   Message type: Certificate
> kaduk>   Message Length: 1009
> kaduk>     Certificate List Len:1006
> kaduk>     Certificate Len:1003
> kaduk>  Record 3 (server -> client)
> kaduk>   Content type: HANDSHAKE
> kaduk>   Version: TLS1.2
> kaduk>   Length: 300
> kaduk>   Message type: ServerKeyExchange
> kaduk>   Message Length: 296
> kaduk>  Record 4 (server -> client)
> kaduk>   Content type: HANDSHAKE
> kaduk>   Version: TLS1.2
> kaduk>   Length: 4
> kaduk>   Message type: ServerHelloDone
> kaduk>   Message Length: 0
> kaduk> 
> kaduk> Forwarded packet length = 1406
> kaduk> 
> kaduk> depth=0 C = UK, O = OpenSSL Group, OU = FOR TESTING PURPOSES ONLY, CN = Test Server Cert
> kaduk> verify error:num=20:unable to get local issuer certificate
> kaduk> verify return:1
> kaduk> depth=0 C = UK, O = OpenSSL Group, OU = FOR TESTING PURPOSES ONLY, CN = Test Server Cert
> kaduk> verify error:num=21:unable to verify the first certificate
> kaduk> verify return:1
> kaduk> Received client packet
> kaduk> Packet length = 121
> kaduk> Processing flight 2
> kaduk>  Record 1 (client -> server)
> kaduk>   Content type: HANDSHAKE
> kaduk>   Version: TLS1.2
> kaduk>   Length: 37
> kaduk>   Message type: ClientKeyExchange
> kaduk>   Message Length: 33
> kaduk>  Record 2 (client -> server)
> kaduk>   Content type: CCS
> kaduk>   Version: TLS1.2
> kaduk>   Length: 1
> kaduk>  Record 3 (client -> server)
> kaduk>   Content type: HANDSHAKE
> kaduk>   Version: TLS1.2
> kaduk>   Length: 68
> kaduk>   Message type: Finished
> kaduk>   Message Length: 12
> kaduk> 
> kaduk> Forwarded packet length = 121
> kaduk> 
> kaduk> CONNECTION ESTABLISHED
> kaduk> Protocol version: TLSv1.2
> kaduk> Client cipher list: ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:DHE-RSA-AES256-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES256-SHA:Received server packet
> kaduk> ECDHE-RSA-AES256-SHA:DHE-RSA-AES256-SHA:Packet length = 270
> kaduk> ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES128-SHA:DHE-RSA-AES128-SHA:AES256-GCM-SHA384Processing flight 3
> kaduk> :AES128-GCM-SHA256:TLS13-AES-256-GCM-SHA384:TLS13-CHACHA20-POLY1305-SHA256:TLS13-AES-128-GCM-SHA256:AES256-SHA256:AES128-SHA256 Record 1:AES256-SHA (server -> client)
> kaduk> :AES128-SHA:TLS_EMPTY_RENEGOTIATION_INFO_SCSV
> kaduk> Ciphersuite: ECDHE-RSA-AES128-SHA
> kaduk> Signature Algorithms: ECDSA+SHA256:ECDSA+SHA384:ECDSA+SHA512:Ed25519:RSA-PSS+SHA256:RSA-PSS+SHA384:RSA-PSS+SHA512:RSA+SHA256:RSA+SHA384:RSA+SHA512:ECDSA  Content type: HANDSHAKE
> kaduk> +SHA224:ECDSA  Version: TLS1.2
> kaduk> +SHA1:RSA  Length: 186+SHA224:RSA
> kaduk> +SHA1:DSA+SHA224:DSA+SHA1:DSA+SHA256:DSA+SHA384:DSA+SHA512
> kaduk> No peer certificate
> kaduk> Supported Elliptic Curve Point Formats: uncompressed:ansiX962_compressed_prime:ansiX962_compressed_char2
> kaduk> Supported Elliptic Groups: X25519:P-256:P-521:P-384
> kaduk>   Message type: NewSessionTicket
> kaduk>   Message Length: 182
> kaduk>  Record 2 (server -> client)
> kaduk>   Content type: CCS
> kaduk>   Version: TLS1.2
> kaduk>   Length: 1
> kaduk>  Record 3 (server -> client)
> kaduk>   Content type: HANDSHAKE
> kaduk>   Version: TLS1.2
> kaduk>   Length: 68
> kaduk>   Message type: Finished
> kaduk>   Message Length: 12
> kaduk> 
> kaduk> Forwarded packet length = 270
> kaduk> 
> kaduk> CONNECTED(00000003)
> kaduk> ---
> kaduk> Certificate chain
> kaduk>  0 s:C = UK, O = OpenSSL Group, OU = FOR TESTING PURPOSES ONLY, CN = Test Server Cert
> kaduk>    i:C = UK, O = OpenSSL Group, OU = FOR TESTING PURPOSES ONLY, CN = OpenSSL Test Intermediate CA
> kaduk> ---
> kaduk> Server certificate
> kaduk> -----BEGIN CERTIFICATE-----
> kaduk> MIID5zCCAs+gAwIBAgIJALnu1NlVpZ6zMA0GCSqGSIb3DQEBBQUAMHAxCzAJBgNV
> kaduk> BAYTAlVLMRYwFAYDVQQKDA1PcGVuU1NMIEdyb3VwMSIwIAYDVQQLDBlGT1IgVEVT
> kaduk> VElORyBQVVJQT1NFUyBPTkxZMSUwIwYDVQQDDBxPcGVuU1NMIFRlc3QgSW50ZXJt
> kaduk> ZWRpYXRlIENBMB4XDTExMTIwODE0MDE0OFoXDTIxMTAxNjE0MDE0OFowZDELMAkG
> kaduk> A1UEBhMCVUsxFjAUBgNVBAoMDU9wZW5TU0wgR3JvdXAxIjAgBgNVBAsMGUZPUiBU
> kaduk> RVNUSU5HIFBVUlBPU0VTIE9OTFkxGTAXBgNVBAMMEFRlc3QgU2VydmVyIENlcnQw
> kaduk> ggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDzhPOSNtyyRspmeuUpxfNJ
> kaduk> KCLTuf7g3uQ4zu4iHOmRO5TQci+HhVlLZrHF9XqFXcIP0y4pWDbMSGuiorUmzmfi
> kaduk> R7bfSdI/+qIQt8KXRH6HNG1t8ou0VSvWId5TS5Dq/er5ODUr9OaaDva7EquHIcMv
> kaduk> vPQGuI+OEAcnleVCy9HVEIySrO4P3CNIicnGkwwiAud05yUAq/gPXBC1hTtmlPD7
> kaduk> TVcGVSEiJdvzqqlgv02qedGrkki6GY4S7GjZxrrf7Foc2EP+51LJzwLQx3/JfrCU
> kaduk> 41NEWAsu/Sl0tQabXESN+zJ1pDqoZ3uHMgpQjeGiE0olr+YcsSW/tJmiU9OiAr8R
> kaduk> AgMBAAGjgY8wgYwwDAYDVR0TAQH/BAIwADAOBgNVHQ8BAf8EBAMCBeAwLAYJYIZI
> kaduk> AYb4QgENBB8WHU9wZW5TU0wgR2VuZXJhdGVkIENlcnRpZmljYXRlMB0GA1UdDgQW
> kaduk> BBSCvM8AABPR9zklmifnr9LvIBturDAfBgNVHSMEGDAWgBQ2w2yI55X+sL3szj49
> kaduk> hqshgYfa2jANBgkqhkiG9w0BAQUFAAOCAQEAqb1NV0B0/pbpK9Z4/bNjzPQLTRLK
> kaduk> WnSNm/Jh5v0GEUOE/Beg7GNjNrmeNmqxAlpqWz9qoeoFZax+QBpIZYjROU3TS3fp
> kaduk> yLsrnlr0CDQ5R7kCCDGa8dkXxemmpZZLbUCpW2Uoy8sAA4JjN9OtsZY7dvUXFgJ7
> kaduk> vVNTRnI01ghknbtD+2SxSQd3CWF6QhcRMAzZJ1z1cbbwGDDzfvGFPzJ+Sq+zEPds
> kaduk> xoVLLSetCiBc+40ZcDS5dV98h9XD7JMTQfxzA7mNGv73JoZJA6nFgj+ADSlJsY/t
> kaduk> JBv+z1iQRueoh9Qeee+ZbRifPouCB8FDx+AltvHTANdAq0t/K3o+pplMVA==
> kaduk> -----END CERTIFICATE-----
> kaduk> subject=C = UK, O = OpenSSL Group, OU = FOR TESTING PURPOSES ONLY, CN = Test Server Cert
> kaduk> 
> kaduk> issuer=C = UK, O = OpenSSL Group, OU = FOR TESTING PURPOSES ONLY, CN = OpenSSL Test Intermediate CA
> kaduk> 
> kaduk> ---
> kaduk> No client certificate CA names sent
> kaduk> Peer signing digest: SHA256
> kaduk> Peer signature type: RSA-PSS
> kaduk> Server Temp Key: X25519, 253 bits
> kaduk> ---
> kaduk> SSL handshake has read 1676 bytes and written 422 bytes
> kaduk> Verification error: unable to verify the first certificate
> kaduk> ---
> kaduk> New, TLSv1.0, Cipher is ECDHE-RSA-AES128-SHA
> kaduk> Server public key is 2048 bit
> kaduk> Secure Renegotiation IS supported
> kaduk> Compression: NONE
> kaduk> Expansion: NONE
> kaduk> No ALPN negotiated
> kaduk> SSL-Session:
> kaduk>     Protocol  : TLSv1.2
> kaduk>     Cipher    : ECDHE-RSA-AES128-SHA
> kaduk>     Session-ID: 000102030405060708090A0B0C0D0E0F101112131415161718191A1B1C1D1E1F
> kaduk>     Session-ID-ctx: 
> kaduk>     Master-Key: 000102030405060708090A0B0C0D0E0F101112131415161718191A1B1C1D1E1F000102030405060708090A0B0C0D0E0F
> kaduk>     PSK identity: None
> kaduk>     PSK identity hint: None
> kaduk>     SRP username: None
> kaduk>     TLS session ticket lifetime hint: 7200 (seconds)
> kaduk>     TLS session ticket:
> kaduk>     0000 - 01 02 03 04 05 06 07 08-09 0a 0b 0c 0d 0e 0f 10   ................
> kaduk>     0010 - 01 02 03 04 05 06 07 08-09 0a 0b 0c 0d 0e 0f 10   ................
> kaduk>     0020 - 82 48 f7 82 0f 7f 21 bf-f4 19 28 80 63 9f da 52   .H....!...(.c..R
> kaduk>     0030 - 3a 16 a9 85 de 2f 41 96-90 4d f7 f1 b1 11 b8 63   :..../A..M.....c
> kaduk>     0040 - 2d c5 62 f7 e3 da be 90-aa 50 3c 9b e7 ad 41 35   -.b......P<...A5
> kaduk>     0050 - c7 76 8d 18 a6 f7 9a 73-6b 25 4a 90 c7 ca 70 ef   .v.....sk%J...p.
> kaduk>     0060 - 94 de be 7d e8 88 9f 16-57 c3 c6 c5 6c 94 dd c6   ...}....W...l...
> kaduk>     0070 - 18 77 1e ff 26 30 ba 51-f2 dd 37 2e f1 b3 df 0a   .w..&0.Q..7.....
> kaduk>     0080 - 02 db 47 a9 ad eb 1a f0-5d 5e d0 a8 85 ee d0 d2   ..G.....]^......
> kaduk>     0090 - 00 01 02 03 04 05 06 07-08 09 0a 0b 0c 0d 0e 0f   ................
> kaduk>     00a0 - 10 11 12 13 14 15 16 17-18 19 1a 1b 1c 1d 1e 1f   ................
> kaduk> 
> kaduk>     Start Time: 1515610433
> kaduk>     Timeout   : 7200 (sec)
> kaduk>     Verify return code: 21 (unable to verify the first certificate)
> kaduk>     Extended master secret: yes
> kaduk> ---
> kaduk> DONE
> kaduk> Received client packet
> kaduk> Packet length = 57
> kaduk> Processing flight 4
> kaduk>  Record 1 (client -> server)
> kaduk>   Content type: APPLICATION DATA
> kaduk>   Version: TLS1.2
> kaduk>   Length: 52
> kaduk>   [ENCRYPTED APPLICATION DATA]
> kaduk>   [test
> kaduk> ]
> kaduk> 
> kaduk> Forwarded packet length = 57
> kaduk> 
> kaduk> Received server packet
> kaduk> Packet length = 57
> kaduk> Processing flight 5
> kaduk>  Record 1 (server -> client)
> kaduk>   Content type: APPLICATION DATA
> kaduk>   Version: TLS1.2
> kaduk>   Length: 52
> kaduk>   [ENCRYPTED APPLICATION DATA]
> kaduk>   [tset
> kaduk> ]
> kaduk> 
> kaduk> Forwarded packet length = 57
> kaduk> 
> kaduk> Connection closed
> kaduk> Waiting for server process to close: 26085
> kaduk> CONNECTION CLOSED
> kaduk>    0 items in the session cache
> kaduk>    0 client connects (SSL_connect())
> kaduk>    0 client renegotiates (SSL_connect())
> kaduk>    0 client connects that finished
> kaduk>    1 server accepts (SSL_accept())
> kaduk>    0 server renegotiates (SSL_accept())
> kaduk>    1 server accepts that finished
> kaduk>    0 session cache hits
> kaduk>    1 session cache misses
> kaduk>    0 session cache timeouts
> kaduk>    0 callback cache hits
> kaduk>    0 cache full overflows (128 allowed)
> kaduk> Waiting for client process to close: 26086
> kaduk> not ok 8 - TLSv1.3 client TLSv1.2 server
> kaduk> 
> kaduk> #   Failed test 'TLSv1.3 client TLSv1.2 server'
> kaduk> #   at ../test/recipes/70-test_sslsigalgs.t line 119.
> kaduk> 
> kaduk> %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
> kaduk> 
> kaduk> In the pass-ing test, the last forwarded packet is client->server of
> kaduk> type ALERT (but is still length 57 including record header).
> 
> Does this ever happen in non-verbose mode?

What is "this"?  I have gotten the "Dubious" test failures in both
verbose and non-verbose mode.

> Does this patch make a difference?
> 
> diff --git a/util/perl/TLSProxy/Proxy.pm b/util/perl/TLSProxy/Proxy.pm
> index 99b0dedd5b..9330ec2844 100644
> --- a/util/perl/TLSProxy/Proxy.pm
> +++ b/util/perl/TLSProxy/Proxy.pm
> @@ -300,6 +302,7 @@ sub clientstart
>              && $ctr < 10) {
>          if (!(@ready = $sel->can_read(1))) {
>              $ctr++;
> +            usleep(100000);     # .1 s sleep, totalling 1 s of attempted reads
>              next;
>          }
>          foreach my $hand (@ready) {

I will give it a shot, but seeing how unreliable my reproducer is,
it's hard to say that it will give much confidence of anything.

-Ben

From kaduk at mit.edu  Wed Jan 10 20:26:10 2018
From: kaduk at mit.edu (Benjamin Kaduk)
Date: Wed, 10 Jan 2018 14:26:10 -0600
Subject: [openssl-project] update on sporadic test failures
In-Reply-To: <20180110201204.GL72574@kduck.kaduk.org>
References: <20180110181329.GH72574@kduck.kaduk.org>
 <20180110193354.GK72574@kduck.kaduk.org>
 <20180110.210633.18077756344254585.levitte@openssl.org>
 <20180110201204.GL72574@kduck.kaduk.org>
Message-ID: <20180110202610.GM72574@kduck.kaduk.org>

On Wed, Jan 10, 2018 at 02:12:05PM -0600, Benjamin Kaduk wrote:
> On Wed, Jan 10, 2018 at 09:06:33PM +0100, Richard Levitte wrote:
> 
> > Does this patch make a difference?
> > 
> > diff --git a/util/perl/TLSProxy/Proxy.pm b/util/perl/TLSProxy/Proxy.pm
> > index 99b0dedd5b..9330ec2844 100644
> > --- a/util/perl/TLSProxy/Proxy.pm
> > +++ b/util/perl/TLSProxy/Proxy.pm
> > @@ -300,6 +302,7 @@ sub clientstart
> >              && $ctr < 10) {
> >          if (!(@ready = $sel->can_read(1))) {
> >              $ctr++;
> > +            usleep(100000);     # .1 s sleep, totalling 1 s of attempted reads
> >              next;
> >          }
> >          foreach my $hand (@ready) {
> 
> I will give it a shot, but seeing how unreliable my reproducer is,
> it's hard to say that it will give much confidence of anything.

Well, that was quick:

Waiting for client process to close: 28371
# Subtest: No client extension extended master secret test
    1..4
    #   at ../test/recipes/70-test_tlsextms.t line 233.
    ok 2 - ClientHello extension extended master secret check
    ok 3 - ServerHello extension extended master secret check
    ok 4 - Extended master secret full handshake check
    # Looks like you failed 1 test of 4.
not ok 2 - No client extension extended master secret test

I'll note that I do have some other stuff going on (building openafs
in a loop) to generate some extra load on this system and try to
make races more likely.

-Ben

From tjh at cryptsoft.com  Wed Jan 10 20:27:27 2018
From: tjh at cryptsoft.com (Tim Hudson)
Date: Thu, 11 Jan 2018 06:27:27 +1000
Subject: [openssl-project] Levchin prize
In-Reply-To: <491C070B-D240-479F-8AF7-07510BCF7885@akamai.com>
References: <04233dcb-0cdd-037f-4dbd-094571a224b6@openssl.org>
 <20180110.203232.1082744388269773061.levitte@openssl.org>
 <20180110.203509.257786872037977157.levitte@openssl.org>
 <327bc583-2b5a-4072-9ce9-ee57f8ba6e7b@openssl.org>
 <491C070B-D240-479F-8AF7-07510BCF7885@akamai.com>
Message-ID: <CAHEJ-S6XSdtdfkbnH1no4JYdiAJ-rTmnsy4ZX-3nQW7C7JdgVg@mail.gmail.com>

I agree with Rich - blog should remain OMC only - and that specific blog
draft should go to committers for comment.

And I agree with Matt - this blog post should go out asap.

Matt - the blog posts should have a direct link to levchinprize.com not
just to the press release.

Tim.

On 11 Jan. 2018 6:04 am, "Salz, Rich" <rsalz at akamai.com> wrote:

> ?     Maybe we should change "blog" so committers at least have read
> access?
>
> No.
>
> _______________________________________________
> openssl-project mailing list
> openssl-project at openssl.org
> https://mta.openssl.org/mailman/listinfo/openssl-project
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-project/attachments/20180111/96a1402a/attachment.html>

From bernd.edlinger at hotmail.de  Wed Jan 10 20:31:49 2018
From: bernd.edlinger at hotmail.de (Bernd Edlinger)
Date: Wed, 10 Jan 2018 20:31:49 +0000
Subject: [openssl-project] update on sporadic test failures
In-Reply-To: <20180110201204.GL72574@kduck.kaduk.org>
References: <20180110181329.GH72574@kduck.kaduk.org>
 <20180110193354.GK72574@kduck.kaduk.org>
 <20180110.210633.18077756344254585.levitte@openssl.org>
 <20180110201204.GL72574@kduck.kaduk.org>
Message-ID: <AM5PR0701MB26575B69F2715E05DE948973E4110@AM5PR0701MB2657.eurprd07.prod.outlook.com>

Hi Ben,

I was able to reproduce it on my laptop, so at least you are not alone.

trunk rev. a41a6120cdcb7e883481bc1bed55e7157c9255c4 (unpatched)
./config enable-tls1_3
make
N=0; while make test TESTS=test_sslsigalgs V=1; do N=$((N+1)); done; 
echo count=$N

stopped after 338 repetitions:

   Message type: ClientHello
   Message Length: 292
     Client Version:771
     Session ID Len:32
     Ciphersuite len:62
     Compression Method Len:1
     Extensions Len:157

Forwarded packet length = 265

Received server packet
Packet length = 1406
Processing flight 1
  Record 1 (server -> client)
   Content type: HANDSHAKE
   Version: TLS1.2
   Length: 69
   Message type: ServerHello
   Message Length: 65
     Server Version:771
     Session ID Len:0
     Ciphersuite:49171
     Compression Method:0
     Extensions Len:25
  Record 2 (server -> client)
   Content type: HANDSHAKE
   Version: TLS1.2
   Length: 1013
   Message type: Certificate
   Message Length: 1009
     Certificate List Len:1006
     Certificate Len:1003
  Record 3 (server -> client)
   Content type: HANDSHAKE
   Version: TLS1.2
   Length: 300
   Message type: ServerKeyExchange
   Message Length: 296
  Record 4 (server -> client)
   Content type: HANDSHAKE
   Version: TLS1.2
   Length: 4
   Message type: ServerHelloDone
   Message Length: 0

Forwarded packet length = 1406

depth=0 C = UK, O = OpenSSL Group, OU = FOR TESTING PURPOSES ONLY, CN = 
Test Server Cert
verify error:num=20:unable to get local issuer certificate
verify return:1
depth=0 C = UK, O = OpenSSL Group, OU = FOR TESTING PURPOSES ONLY, CN = 
Test Server Cert
verify error:num=21:unable to verify the first certificate
verify return:1
Received client packet
Packet length = 121
Processing flight 2
  Record 1 (client -> server)
   Content type: HANDSHAKE
   Version: TLS1.2
   Length: 37
   Message type: ClientKeyExchange
   Message Length: 33
  Record 2 (client -> server)
   Content type: CCS
   Version: TLS1.2
   Length: 1
  Record 3 (client -> server)
   Content type: HANDSHAKE
   Version: TLS1.2
   Length: 68
   Message type: Finished
   Message Length: 12

Forwarded packet length = 121

CONNECTION ESTABLISHED
Protocol version: TLSv1.2
Client cipher list: 
ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256Received 
server packet
:DHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384Packet length = 270
:ECDHE-RSA-AES256-SHA384:DHE-RSA-AES256-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256:Processing 
flight 3
DHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES256-SHA:ECDHE-RSA-AES256-SHA:DHE-RSA-AES256-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES128-SHA:DHE-RSA-AES128-SHA 
Record 1:AES256-GCM-SHA384: (server -> client)
AES128-GCM-SHA256:TLS13-AES-256-GCM-SHA384:TLS13-CHACHA20-POLY1305-SHA256:TLS13-AES-128-GCM-SHA256:AES256-SHA256:AES128-SHA256:AES256-SHA:AES128-SHA:TLS_EMPTY_RENEGOTIATION_INFO_SCSV
Ciphersuite: ECDHE-RSA-AES128-SHA
Signature Algorithms: RSA-PSS+SHA256
No peer certificate
Supported Elliptic Curve Point Formats: 
uncompressed:ansiX962_compressed_prime:ansiX962_compressed_char2
Supported Elliptic Groups:   Content type: HANDSHAKE
X25519:  Version: TLS1.2
P-256:P-521  Length: 186:P-384

   Message type: NewSessionTicket
   Message Length: 182
  Record 2 (server -> client)
   Content type: CCS
   Version: TLS1.2
   Length: 1
  Record 3 (server -> client)
   Content type: HANDSHAKE
   Version: TLS1.2
   Length: 68
   Message type: Finished
   Message Length: 12

Forwarded packet length = 270

CONNECTED(00000003)
---
Certificate chain
  0 s:C = UK, O = OpenSSL Group, OU = FOR TESTING PURPOSES ONLY, CN = 
Test Server Cert
    i:C = UK, O = OpenSSL Group, OU = FOR TESTING PURPOSES ONLY, CN = 
OpenSSL Test Intermediate CA
---
Server certificate
-----BEGIN CERTIFICATE-----
MIID5zCCAs+gAwIBAgIJALnu1NlVpZ6zMA0GCSqGSIb3DQEBBQUAMHAxCzAJBgNV
BAYTAlVLMRYwFAYDVQQKDA1PcGVuU1NMIEdyb3VwMSIwIAYDVQQLDBlGT1IgVEVT
VElORyBQVVJQT1NFUyBPTkxZMSUwIwYDVQQDDBxPcGVuU1NMIFRlc3QgSW50ZXJt
ZWRpYXRlIENBMB4XDTExMTIwODE0MDE0OFoXDTIxMTAxNjE0MDE0OFowZDELMAkG
A1UEBhMCVUsxFjAUBgNVBAoMDU9wZW5TU0wgR3JvdXAxIjAgBgNVBAsMGUZPUiBU
RVNUSU5HIFBVUlBPU0VTIE9OTFkxGTAXBgNVBAMMEFRlc3QgU2VydmVyIENlcnQw
ggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDzhPOSNtyyRspmeuUpxfNJ
KCLTuf7g3uQ4zu4iHOmRO5TQci+HhVlLZrHF9XqFXcIP0y4pWDbMSGuiorUmzmfi
R7bfSdI/+qIQt8KXRH6HNG1t8ou0VSvWId5TS5Dq/er5ODUr9OaaDva7EquHIcMv
vPQGuI+OEAcnleVCy9HVEIySrO4P3CNIicnGkwwiAud05yUAq/gPXBC1hTtmlPD7
TVcGVSEiJdvzqqlgv02qedGrkki6GY4S7GjZxrrf7Foc2EP+51LJzwLQx3/JfrCU
41NEWAsu/Sl0tQabXESN+zJ1pDqoZ3uHMgpQjeGiE0olr+YcsSW/tJmiU9OiAr8R
AgMBAAGjgY8wgYwwDAYDVR0TAQH/BAIwADAOBgNVHQ8BAf8EBAMCBeAwLAYJYIZI
AYb4QgENBB8WHU9wZW5TU0wgR2VuZXJhdGVkIENlcnRpZmljYXRlMB0GA1UdDgQW
BBSCvM8AABPR9zklmifnr9LvIBturDAfBgNVHSMEGDAWgBQ2w2yI55X+sL3szj49
hqshgYfa2jANBgkqhkiG9w0BAQUFAAOCAQEAqb1NV0B0/pbpK9Z4/bNjzPQLTRLK
WnSNm/Jh5v0GEUOE/Beg7GNjNrmeNmqxAlpqWz9qoeoFZax+QBpIZYjROU3TS3fp
yLsrnlr0CDQ5R7kCCDGa8dkXxemmpZZLbUCpW2Uoy8sAA4JjN9OtsZY7dvUXFgJ7
vVNTRnI01ghknbtD+2SxSQd3CWF6QhcRMAzZJ1z1cbbwGDDzfvGFPzJ+Sq+zEPds
xoVLLSetCiBc+40ZcDS5dV98h9XD7JMTQfxzA7mNGv73JoZJA6nFgj+ADSlJsY/t
JBv+z1iQRueoh9Qeee+ZbRifPouCB8FDx+AltvHTANdAq0t/K3o+pplMVA==
-----END CERTIFICATE-----
subject=C = UK, O = OpenSSL Group, OU = FOR TESTING PURPOSES ONLY, CN = 
Test Server Cert

issuer=C = UK, O = OpenSSL Group, OU = FOR TESTING PURPOSES ONLY, CN = 
OpenSSL Test Intermediate CA

---
No client certificate CA names sent
Peer signing digest: SHA256
Peer signature type: RSA-PSS
Server Temp Key: X25519, 253 bits
---
SSL handshake has read 1676 bytes and written 422 bytes
Verification error: unable to verify the first certificate
---
New, TLSv1.0, Cipher is ECDHE-RSA-AES128-SHA
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
     Protocol  : TLSv1.2
     Cipher    : ECDHE-RSA-AES128-SHA
     Session-ID: 
000102030405060708090A0B0C0D0E0F101112131415161718191A1B1C1D1E1F
     Session-ID-ctx:
     Master-Key: 
000102030405060708090A0B0C0D0E0F101112131415161718191A1B1C1D1E1F000102030405060708090A0B0C0D0E0F
     PSK identity: None
     PSK identity hint: None
     SRP username: None
     TLS session ticket lifetime hint: 7200 (seconds)
     TLS session ticket:
     0000 - 01 02 03 04 05 06 07 08-09 0a 0b 0c 0d 0e 0f 10 
................
     0010 - 01 02 03 04 05 06 07 08-09 0a 0b 0c 0d 0e 0f 10 
................
     0020 - 82 48 f7 82 0f 7f 21 bf-f4 19 28 80 63 9f da 52 
.H....!...(.c..R
     0030 - 3a 16 a9 85 de 2f 41 96-90 4d f7 f1 b1 11 b8 63 
:..../A..M.....c
     0040 - 2d c5 62 f7 e3 da be 90-aa 50 3c 9b e7 ad 41 35 
-.b......P<...A5
     0050 - c7 76 8d 18 a6 f7 9a 73-6b 25 4a 90 c7 ca 70 ef 
.v.....sk%J...p.
     0060 - a3 46 51 7b 22 47 d9 ef-10 43 11 7b 1f 26 4e c4 
.FQ{"G...C.{.&N.
     0070 - 74 d9 f2 5e 6a 05 65 fa-e4 e7 f3 c5 36 af 1c b0 
t..^j.e.....6...
     0080 - ed b7 ba 5d e6 d3 3e 38-e0 63 53 30 89 37 bd 38 
...]..>8.cS0.7.8
     0090 - 00 01 02 03 04 05 06 07-08 09 0a 0b 0c 0d 0e 0f 
................
     00a0 - 10 11 12 13 14 15 16 17-18 19 1a 1b 1c 1d 1e 1f 
................

     Start Time: 1515615760
     Timeout   : 7200 (sec)
     Verify return code: 21 (unable to verify the first certificate)
     Extended master secret: yes
---
DONE
Received client packet
Packet length = 114
Processing flight 4
  Record 1 (client -> server)
   Content type: APPLICATION DATA
   Version: TLS1.2
   Length: 52
   [ENCRYPTED APPLICATION DATA]
   [test
]
  Record 2 (client -> server)
   Content type: ALERT
   Version: TLS1.2
   Length: 52

Forwarded packet length = 114

Connection closed
Waiting for server process to close: 10002
CONNECTION CLOSED
    0 items in the session cache
    0 client connects (SSL_connect())
    0 client renegotiates (SSL_connect())
    0 client connects that finished
    1 server accepts (SSL_accept())
    0 server renegotiates (SSL_accept())
    1 server accepts that finished
    0 session cache hits
    1 session cache misses
    0 session cache timeouts
    0 callback cache hits
    0 cache full overflows (128 allowed)
Waiting for client process to close: 10003
ok 13 - PSS only sigalgs in TLSv1.2
Proxy started on port 4453
Server command: ../../util/shlib_wrap.sh ../../apps/openssl s_server 
-no_comp -rev -engine ossltest -accept 4443 -cert ../../apps/server.pem 
-cert2 ../../apps/server.pem -naccept 1 -cipher 
ECDHE-RSA-AES128-SHA:TLS13-AES-128-GCM-SHA256
Client command: echo test | ../../util/shlib_wrap.sh ../../apps/openssl 
s_client -engine ossltest -connect localhost:4453 -no_tls1_3 -sigalgs 
RSA+SHA256
engine "ossltest" set.
engine "ossltest" set.
Using default temp DH parameters
ACCEPT
Connection opened
Received client packet
Packet length = 152
Processing flight 0
  Record 1 (client -> server)
   Content type: HANDSHAKE
   Version: TLS1.0
   Length: 147
   Message type: ClientHello
   Message Length: 143
     Client Version:771
     Session ID Len:0
     Ciphersuite len:42
     Compression Method Len:1
     Extensions Len:60

Forwarded packet length = 152

Received server packet
Packet length = 1406
Processing flight 1
  Record 1 (server -> client)
   Content type: HANDSHAKE
   Version: TLS1.2
   Length: 69
   Message type: ServerHello
   Message Length: 65
     Server Version:771
     Session ID Len:0
     Ciphersuite:49171
     Compression Method:0
     Extensions Len:25
  Record 2 (server -> client)
   Content type: HANDSHAKE
   Version: TLS1.2
   Length: 1013
   Message type: Certificate
   Message Length: 1009
     Certificate List Len:1006
     Certificate Len:1003
  Record 3 (server -> client)
   Content type: HANDSHAKE
   Version: TLS1.2
   Length: 300
   Message type: ServerKeyExchange
   Message Length: 296
  Record 4 (server -> client)
   Content type: HANDSHAKE
   Version: TLS1.2
   Length: 4
   Message type: ServerHelloDone
   Message Length: 0

Forwarded packet length = 1406

depth=0 C = UK, O = OpenSSL Group, OU = FOR TESTING PURPOSES ONLY, CN = 
Test Server Cert
verify error:num=20:unable to get local issuer certificate
verify return:1
depth=0 C = UK, O = OpenSSL Group, OU = FOR TESTING PURPOSES ONLY, CN = 
Test Server Cert
verify error:num=21:unable to verify the first certificate
verify return:1
47111746565952:error:1414D172:SSL routines:tls12_check_peer_sigalg:wrong 
signature type:ssl/t1_lib.c:996:
Received client packet
Packet length = 7
Processing flight 2
  Record 1 (client -> server)
   Content type: ALERT
   Version: TLS1.2
   Length: 2

Forwarded packet length = 7

Connection closed
CONNECTED(00000003)
---
Certificate chain
  0 s:C = UK, O = OpenSSL Group, OU = FOR TESTING PURPOSES ONLY, CN = 
Test Server Cert
    i:C = UK, O = OpenSSL Group, OU = FOR TESTING PURPOSES ONLY, CN = 
OpenSSL Test Intermediate CA
---
Server certificate
-----BEGIN CERTIFICATE-----
MIID5zCCAs+gAwIBAgIJALnu1NlVpZ6zMA0GCSqGSIb3DQEBBQUAMHAxCzAJBgNV
BAYTAlVLMRYwFAYDVQQKDA1PcGVuU1NMIEdyb3VwMSIwIAYDVQQLDBlGT1IgVEVT
VElORyBQVVJQT1NFUyBPTkxZMSUwIwYDVQQDDBxPcGVuU1NMIFRlc3QgSW50ZXJt
ZWRpYXRlIENBMB4XDTExMTIwODE0MDE0OFoXDTIxMTAxNjE0MDE0OFowZDELMAkG
A1UEBhMCVUsxFjAUBgNVBAoMDU9wZW5TU0wgR3JvdXAxIjAgBgNVBAsMGUZPUiBU
RVNUSU5HIFBVUlBPU0VTIE9OTFkxGTAXBgNVBAMMEFRlc3QgU2VydmVyIENlcnQw
ggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDzhPOSNtyyRspmeuUpxfNJ
KCLTuf7g3uQ4zu4iHOmRO5TQci+HhVlLZrHF9XqFXcIP0y4pWDbMSGuiorUmzmfi
R7bfSdI/+qIQt8KXRH6HNG1t8ou0VSvWId5TS5Dq/er5ODUr9OaaDva7EquHIcMv
vPQGuI+OEAcnleVCy9HVEIySrO4P3CNIicnGkwwiAud05yUAq/gPXBC1hTtmlPD7
TVcGVSEiJdvzqqlgv02qedGrkki6GY4S7GjZxrrf7Foc2EP+51LJzwLQx3/JfrCU
41NEWAsu/Sl0tQabXESN+zJ1pDqoZ3uHMgpQjeGiE0olr+YcsSW/tJmiU9OiAr8R
AgMBAAGjgY8wgYwwDAYDVR0TAQH/BAIwADAOBgNVHQ8BAf8EBAMCBeAwLAYJYIZI
AYb4QgENBB8WHU9wZW5TU0wgR2VuZXJhdGVkIENlcnRpZmljYXRlMB0GA1UdDgQW
BBSCvM8AABPR9zklmifnr9LvIBturDAfBgNVHSMEGDAWgBQ2w2yI55X+sL3szj49
hqshgYfa2jANBgkqhkiG9w0BAQUFAAOCAQEAqb1NV0B0/pbpK9Z4/bNjzPQLTRLK
WnSNm/Jh5v0GEUOE/Beg7GNjNrmeNmqxAlpqWz9qoeoFZax+QBpIZYjROU3TS3fp
yLsrnlr0CDQ5R7kCCDGa8dkXxemmpZZLbUCpW2Uoy8sAA4JjN9OtsZY7dvUXFgJ7
vVNTRnI01ghknbtD+2SxSQd3CWF6QhcRMAzZJ1z1cbbwGDDzfvGFPzJ+Sq+zEPds
xoVLLSetCiBc+40ZcDS5dV98h9XD7JMTQfxzA7mNGv73JoZJA6nFgj+ADSlJsY/t
JBv+z1iQRueoh9Qeee+ZbRifPouCB8FDx+AltvHTANdAq0t/K3o+pplMVA==
-----END CERTIFICATE-----
subject=C = UK, O = OpenSSL Group, OU = FOR TESTING PURPOSES ONLY, CN = 
Test Server Cert

issuer=C = UK, O = OpenSSL Group, OU = FOR TESTING PURPOSES ONLY, CN = 
OpenSSL Test Intermediate CA

---
No client certificate CA names sent
Server Temp Key: X25519, 253 bits
---
SSL handshake has read 1397 bytes and written 159 bytes
Verification error: unable to verify the first certificate
---
New, (NONE), Cipher is (NONE)
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
     Protocol  : TLSv1.2
     Cipher    : 0000
     Session-ID:
     Session-ID-ctx:
     Master-Key:
     PSK identity: None
     PSK identity hint: None
     SRP username: None
     Start Time: 1515615760
     Timeout   : 7200 (sec)
     Verify return code: 21 (unable to verify the first certificate)
     Extended master secret: yes
---
Waiting for server process to close: 10026
CONNECTION FAILURE
47243456800576:error:14094410:SSL routines:ssl3_read_bytes:sslv3 alert 
handshake failure:ssl/record/rec_layer_s3.c:1587:SSL alert number 40
    0 items in the session cache
    0 client connects (SSL_connect())
    0 client renegotiates (SSL_connect())
    0 client connects that finished
    1 server accepts (SSL_accept())
    0 server renegotiates (SSL_accept())
    0 server accepts that finished
    0 session cache hits
    0 session cache misses
    0 session cache timeouts
    0 callback cache hits
    0 cache full overflows (128 allowed)
Waiting for client process to close: 10027
ok 14 - Sigalg we did not send in TLSv1.2
Server command: ../../util/shlib_wrap.sh ../../apps/openssl s_server 
-no_comp -rev -engine ossltest -accept 4443 -cert ../../apps/server.pem 
-cert2 ../../apps/server.pem -naccept 1 -cipher 
ECDHE-RSA-AES128-SHA:TLS13-AES-128-GCM-SHA256
Proxy started on port 4453
Client command: echo test | ../../util/shlib_wrap.sh ../../apps/openssl 
s_client -engine ossltest -connect localhost:4453 -no_tls1_3 -sigalgs 
ECDSA+SHA256
engine "ossltest" set.
engine "ossltest" set.
Using default temp DH parameters
ACCEPT
Connection opened
Received client packet
Packet length = 126
Processing flight 0
  Record 1 (client -> server)
   Content type: HANDSHAKE
   Version: TLS1.0
   Length: 121
   Message type: ClientHello
   Message Length: 117
     Client Version:771
     Session ID Len:0
     Ciphersuite len:16
     Compression Method Len:1
     Extensions Len:60

Forwarded packet length = 126

CONNECTION FAILURE
Received server packet
Packet length = 7
Processing flight 1
  Record 147986366047872:error:1417A0C1:SSL 
routines:tls_post_process_client_hello:no shared 
cipher:ssl/statem/statem_srvr.c:2131:
  (server -> client)
   Content type: ALERT
   Version: TLS1.2
   Length: 2

Forwarded packet length = 7

Connection closed
Waiting for server process to close: 10050
47262213985920:error:14094410:SSL routines:ssl3_read_bytes:sslv3 alert 
handshake failure:ssl/record/rec_layer_s3.c:1587:SSL alert number 40
    0 items in the session cache
    0 client connects (SSL_connect())
    0 client renegotiates (SSL_connect())
    0 client connects that finished
    1 server accepts (SSL_accept())
    0 server renegotiates (SSL_accept())
    0 server accepts that finished
    0 session cache hits
    0 session cache misses
    0 session cache timeouts
    0 callback cache hits
    0 cache full overflows (128 allowed)
CONNECTED(00000003)
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 7 bytes and written 126 bytes
Verification: OK
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
     Protocol  : TLSv1.2
     Cipher    : 0000
     Session-ID:
     Session-ID-ctx:
     Master-Key:
     PSK identity: None
     PSK identity hint: None
     SRP username: None
     Start Time: 1515615760
     Timeout   : 7200 (sec)
     Verify return code: 0 (ok)
     Extended master secret: no
---
Waiting for client process to close: 10051
ok 15 - No matching TLSv1.2 sigalgs
Proxy started on port 4453
Server command: ../../util/shlib_wrap.sh ../../apps/openssl s_server 
-no_comp -rev -engine ossltest -accept 4443 -cert ../../apps/server.pem 
-cert2 ../../apps/server.pem -naccept 1 -cipher 
ECDHE-ECDSA-AES128-SHA:TLS13-AES-128-GCM-SHA256 -cert 
../../test/certs/server-ecdsa-cert.pem -key 
../../test/certs/server-ecdsa-key.pem
Client command: echo test | ../../util/shlib_wrap.sh ../../apps/openssl 
s_client -engine ossltest -connect localhost:4453 -no_tls1_3
engine "ossltest" set.
Using default temp DH parameters
ACCEPT
engine "ossltest" set.
Connection opened
Received client packet
Packet length = 202
Processing flight 0
  Record 1 (client -> server)
   Content type: HANDSHAKE
   Version: TLS1.0
   Length: 197
   Message type: ClientHello
   Message Length: 193
     Client Version:771
     Session ID Len:0
     Ciphersuite len:56
     Compression Method Len:1
     Extensions Len:96

Forwarded packet length = 158

Received server packet
Packet length = 831
Processing flight 1
  Record 1 (server -> client)
   Content type: HANDSHAKE
   Version: TLS1.2
   Length: 69
   Message type: ServerHello
   Message Length: 65
     Server Version:771
     Session ID Len:0
     Ciphersuite:49161
     Compression Method:0
     Extensions Len:25
  Record 2 (server -> client)
   Content type: HANDSHAKE
   Version: TLS1.2
   Length: 623
   Message type: Certificate
   Message Length: 619
     Certificate List Len:616
     Certificate Len:613
  Record 3 (server -> client)
   Content type: HANDSHAKE
   Version: TLS1.2
   Length: 115
   Message type: ServerKeyExchange
   Message Length: 111
  Record 4 (server -> client)
   Content type: HANDSHAKE
   Version: TLS1.2
   Length: 4
   Message type: ServerHelloDone
   Message Length: 0

Forwarded packet length = 831

depth=0 CN = Server ECDSA cert
verify error:num=20:unable to get local issuer certificate
verify return:1
depth=0 CN = Server ECDSA cert
verify error:num=21:unable to verify the first certificate
verify return:1
Received client packet
Packet length = 121
Processing flight 2
  Record 1 (client -> server)
   Content type: HANDSHAKE
   Version: TLS1.2
   Length: 37
   Message type: ClientKeyExchange
   Message Length: 33
  Record 2 (client -> server)
   Content type: CCS
   Version: TLS1.2
   Length: 1
  Record 3 (client -> server)
   Content type: HANDSHAKE
   Version: TLS1.2
   Length: 68
   Message type: Finished
   Message Length: 12

Forwarded packet length = 121

CONNECTION ESTABLISHED
Protocol version: TLSv1.2
Client cipher list: 
ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:DHE-RSA-AES256-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES256-SHA:ECDHE-RSA-AES256-SHA:DHE-RSA-AES256-SHA:ECDHE-ECDSA-AES128-SHAReceived 
server packet
:ECDHE-RSA-AES128-SHA:Packet length = 270
DHE-RSA-AES128-SHA:AES256-GCM-SHA384:AES128-GCM-SHA256:AES256-SHA256:AES128-SHA256:AES256-SHA:AES128-SHA:TLS_EMPTY_RENEGOTIATION_INFO_SCSV
Ciphersuite: ECDHE-ECDSA-AES128-SHA
No peer certificate
Supported Elliptic Curve Point Formats: 
uncompressed:ansiX962_compressed_prime:ansiX962_compressed_char2
Supported Elliptic Groups: Processing flight 3
X25519:P-256:P-521:P-384 Record 1
  (server -> client)
   Content type: HANDSHAKE
   Version: TLS1.2
   Length: 186
   Message type: NewSessionTicket
   Message Length: 182
  Record 2 (server -> client)
   Content type: CCS
   Version: TLS1.2
   Length: 1
  Record 3 (server -> client)
   Content type: HANDSHAKE
   Version: TLS1.2
   Length: 68
   Message type: Finished
   Message Length: 12

Forwarded packet length = 270

CONNECTED(00000003)
---
Certificate chain
  0 s:CN = Server ECDSA cert
    i:CN = Root CA
---
Server certificate
-----BEGIN CERTIFICATE-----
MIICYTCCAUmgAwIBAgIBAjANBgkqhkiG9w0BAQsFADASMRAwDgYDVQQDDAdSb290
IENBMCAXDTE3MDExMjE0NDUwMVoYDzIxMTcwMTEzMTQ0NTAxWjAcMRowGAYDVQQD
DBFTZXJ2ZXIgRUNEU0EgY2VydDBZMBMGByqGSM49AgEGCCqGSM49AwEHA0IABOI7
NNxE483tJyIKT6KOQM5Zlfrigh12BEcHxnzpudgVHYA4aL5D5JulYGFzL0LQ5Q55
GpCub1V2j+AhyBMKPQqjgYAwfjAdBgNVHQ4EFgQUSDzlr0Ayx22BljPtY6YRLTes
qgwwHwYDVR0jBBgwFoAUcH8uroNoWZgEIyrN6z4XzSTdAUkwCQYDVR0TBAIwADAT
BgNVHSUEDDAKBggrBgEFBQcDATAcBgNVHREEFTATghFTZXJ2ZXIgRUNEU0EgY2Vy
dDANBgkqhkiG9w0BAQsFAAOCAQEAOJDgr1hRNuxW1D93yDWFwP1o2KuaI0BMZVFS
6rzzLThCo3FeS6X7DCrBP699PCYcKeyMDmQwg9mVMABSZzox2GBO3hoqtnUXjsK3
Qxh+4O5EmIXX4v8szdSBP14O2c5krAk4lbVWxLHE78NAc8dL94VORndyTcmaXUTn
FQeBaRJjXto3okPvwYlczPS9sq0AhuBh5hwsLOYwpLf6/loPLjl40iwPQ+iqQ1EV
m0Sac3o+0qI0cKiz4nXgd4NkFvV3G8lwd0Um8KSS/EFuZbgJNKKD6+1+90sibM4a
Y/JiO6weK/VTlqCLn7zV9LcDT4gU18UCn85UV1XlVYKXZlaXYQ==
-----END CERTIFICATE-----
subject=CN = Server ECDSA cert

issuer=CN = Root CA

---
No client certificate CA names sent
Peer signing digest: SHA1
Peer signature type: ECDSA
Server Temp Key: X25519, 253 bits
---
SSL handshake has read 1101 bytes and written 323 bytes
Verification error: unable to verify the first certificate
---
New, TLSv1.0, Cipher is ECDHE-ECDSA-AES128-SHA
Server public key is 256 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
     Protocol  : TLSv1.2
     Cipher    : ECDHE-ECDSA-AES128-SHA
     Session-ID: 
000102030405060708090A0B0C0D0E0F101112131415161718191A1B1C1D1E1F
     Session-ID-ctx:
     Master-Key: 
000102030405060708090A0B0C0D0E0F101112131415161718191A1B1C1D1E1F000102030405060708090A0B0C0D0E0F
     PSK identity: None
     PSK identity hint: None
     SRP username: None
     TLS session ticket lifetime hint: 7200 (seconds)
     TLS session ticket:
     0000 - 01 02 03 04 05 06 07 08-09 0a 0b 0c 0d 0e 0f 10 
................
     0010 - 01 02 03 04 05 06 07 08-09 0a 0b 0c 0d 0e 0f 10 
................
     0020 - 36 30 c1 2b b2 82 bc 0d-a7 91 be 35 cf 46 28 79 
60.+.......5.F(y
     0030 - c0 38 f3 ce 11 73 6b 67-9a 07 5e 15 04 2d fc 2e 
.8...skg..^..-..
     0040 - 95 6f e3 f8 e2 9c 25 33-21 8d 66 e9 3d 15 5b 92 
.o....%3!.f.=.[.
     0050 - 37 89 a0 62 4c 7e 24 17-00 ff 5a 40 75 cf a4 1a 
7..bL~$...Z at u...
     0060 - bc ee eb e0 c2 4a 16 e6-8a 9d bc f1 9f ae f7 42 
.....J.........B
     0070 - 99 52 81 43 6f ae 1d 39-fa 56 ad 3e 17 55 d0 5d 
.R.Co..9.V.>.U.]
     0080 - 3c 64 da f3 31 18 d2 2f-5a b2 85 13 7c 53 ff 38 
<d..1../Z...|S.8
     0090 - 00 01 02 03 04 05 06 07-08 09 0a 0b 0c 0d 0e 0f 
................
     00a0 - 10 11 12 13 14 15 16 17-18 19 1a 1b 1c 1d 1e 1f 
................

     Start Time: 1515615760
     Timeout   : 7200 (sec)
     Verify return code: 21 (unable to verify the first certificate)
     Extended master secret: yes
---
DONE
Received client packet
Packet length = 57
Processing flight 4
  Record 1 (client -> server)
   Content type: APPLICATION DATA
   Version: TLS1.2
   Length: 52
   [ENCRYPTED APPLICATION DATA]
   [test
]

Forwarded packet length = 57

Received client packet
Packet length = 57
Processing flight 5
  Record 1 (client -> server)
   Content type: ALERT
   Version: TLS1.2
   Length: 52

Forwarded packet length = 57

Connection closed
Waiting for server process to close: 10074
CONNECTION CLOSED
    0 items in the session cache
    0 client connects (SSL_connect())
    0 client renegotiates (SSL_connect())
    0 client connects that finished
    1 server accepts (SSL_accept())
    0 server renegotiates (SSL_accept())
    1 server accepts that finished
    0 session cache hits
    0 session cache misses
    0 session cache timeouts
    0 callback cache hits
    0 cache full overflows (128 allowed)
Waiting for client process to close: 10075
ok 16 - No TLSv1.2 sigalgs, ECDSA
Server command: ../../util/shlib_wrap.sh ../../apps/openssl s_server 
-no_comp -rev -engine ossltest -accept 4443 -cert ../../apps/server.pem 
-cert2 ../../apps/server.pem -naccept 1 -cipher 
AES128-SHA:TLS13-AES-128-GCM-SHA256
Proxy started on port 4453
Client command: echo test | ../../util/shlib_wrap.sh ../../apps/openssl 
s_client -engine ossltest -connect localhost:4453 -tls1_3
engine "ossltest" set.
Connection opened
engine "ossltest" set.
Using default temp DH parameters
ACCEPT
Received client packet
Packet length = 223
Processing flight 0
  Record 1 (client -> server)
   Content type: HANDSHAKE
   Version: TLS1.0
   Length: 218
   Message type: ClientHello
   Message Length: 214
     Client Version:771
     Session ID Len:32
     Ciphersuite len:8
     Compression Method Len:1
     Extensions Len:133

Forwarded packet length = 223

Received server packet
Packet length = 1543
Processing flight 1
  Record 1 (server -> client)
   Content type: HANDSHAKE
   Version: TLS1.2
   Length: 122
   Message type: ServerHello
   Message Length: 118
     Server Version:771
     Session ID Len:32
     Ciphersuite:4865
     Compression Method:0
     Extensions Len:46
  Record 2 (server -> client)
   Content type: CCS
   Version: TLS1.2
   Length: 1
  Record 3 (server -> client)
   Content type: APPLICATION DATA
   Version: TLS1.2
   Length: 23
   Inner content type: HANDSHAKE
   Message type: EncryptedExtensions
   Message Length: 2
     Extensions Len:0
  Record 4 (server -> client)
   Content type: APPLICATION DATA
   Version: TLS1.2
   Length: 1033
   Inner content type: HANDSHAKE
   Message type: Certificate
   Message Length: 1012
     Context:
     Certificate List Len:1008
     Certificate Len:1003
     Extensions Len:0
  Record 5 (server -> client)
   Content type: APPLICATION DATA
   Version: TLS1.2
   Length: 281
   Inner content type: HANDSHAKE
   Message type: CertificateVerify
   Message Length: 260
     SigAlg:2052
     Signature Len:256
  Record 6 (server -> client)
   Content type: APPLICATION DATA
   Version: TLS1.2
   Length: 53
   Inner content type: HANDSHAKE
   Message type: Finished
   Message Length: 32

Forwarded packet length = 1547

depth=0 C = UK, O = OpenSSL Group, OU = FOR TESTING PURPOSES ONLY, CN = 
Test Server Cert
verify error:num=20:unable to get local issuer certificate
verify return:1
depth=0 C = UK, O = OpenSSL Group, OU = FOR TESTING PURPOSES ONLY, CN = 
Test Server Cert
verify error:num=21:unable to verify the first certificate
verify return:1
Received client packet
Packet length = 64
Processing flight 2
  Record 1 (client -> server)
   Content type: CCS
   Version: TLS1.2
   Length: 1
  Record 2 (client -> server)
   Content type: APPLICATION DATA
   Version: TLS1.2
   Length: 53
   Inner content type: HANDSHAKE
   Message type: Finished
   Message Length: 32

Forwarded packet length = 65

CONNECTED(00000003)
---
Certificate chain
  0 s:C = UK, O = OpenSSL Group, OU = FOR TESTING PURPOSES ONLY, CN = 
Test Server Cert
    i:C = UK, O = OpenSSL Group, OU = FOR TESTING PURPOSES ONLY, CN = 
OpenSSL Test Intermediate CA
---
Server certificate
-----BEGIN CERTIFICATE-----
MIID5zCCAs+gAwIBAgIJALnu1NlVpZ6zMA0GCSqGSIb3DQEBBQUAMHAxCzAJBgNV
BAYTAlVLMRYwFAYDVQQKDA1PcGVuU1NMIEdyb3VwMSIwIAYDVQQLDBlGT1IgVEVT
VElORyBQVVJQT1NFUyBPTkxZMSUwIwYDVQQDDBxPcGVuU1NMIFRlc3QgSW50ZXJt
ZWRpYXRlIENBMB4XDTExMTIwODE0MDE0OFoXDTIxMTAxNjE0MDE0OFowZDELMAkG
A1UEBhMCVUsxFjAUBgNVBAoMDU9wZW5TU0wgR3JvdXAxIjAgBgNVBAsMGUZPUiBU
RVNUSU5HIFBVUlBPU0VTIE9OTFkxGTAXBgNVBAMMEFRlc3QgU2VydmVyIENlcnQw
ggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDzhPOSNtyyRspmeuUpxfNJ
KCLTuf7g3uQ4zu4iHOmRO5TQci+HhVlLZrHF9XqFXcIP0y4pWDbMSGuiorUmzmfi
R7bfSdI/+qIQt8KXRH6HNG1t8ou0VSvWId5TS5Dq/er5ODUr9OaaDva7EquHIcMv
vPQGuI+OEAcnleVCy9HVEIySrO4P3CNIicnGkwwiAud05yUAq/gPXBC1hTtmlPD7
TVcGVSEiJdvzqqlgv02qedGrkki6GY4S7GjZxrrf7Foc2EP+51LJzwLQx3/JfrCU
41NEWAsu/Sl0tQabXESN+zJ1pDqoZ3uHMgpQjeGiE0olr+YcsSW/tJmiU9OiAr8R
AgMBAAGjgY8wgYwwDAYDVR0TAQH/BAIwADAOBgNVHQ8BAf8EBAMCBeAwLAYJYIZI
AYb4QgENBB8WHU9wZW5TU0wgR2VuZXJhdGVkIENlcnRpZmljYXRlMB0GA1UdDgQW
BBSCvM8AABPR9zklmifnr9LvIBturDAfBgNVHSMEGDAWgBQ2w2yI55X+sL3szj49
hqshgYfa2jANBgkqhkiG9w0BAQUFAAOCAQEAqb1NV0B0/pbpK9Z4/bNjzPQLTRLK
WnSNm/Jh5v0GEUOE/Beg7GNjNrmeNmqxAlpqWz9qoeoFZax+QBpIZYjROU3TS3fp
yLsrnlr0CDQ5R7kCCDGa8dkXxemmpZZLbUCpW2Uoy8sAA4JjN9OtsZY7dvUXFgJ7
vVNTRnI01ghknbtD+2SxSQd3CWF6QhcRMAzZJ1z1cbbwGDDzfvGFPzJ+Sq+zEPds
xoVLLSetCiBc+40ZcDS5dV98h9XD7JMTQfxzA7mNGv73JoZJA6nFgj+ADSlJsY/t
JBv+z1iQRueoh9Qeee+ZbRifPouCB8FDx+AltvHTANdAq0t/K3o+pplMVA==
-----END CERTIFICATE-----
subject=C = UK, O = OpenSSL Group, OU = FOR TESTING PURPOSES ONLY, CN = 
Test Server Cert

issuer=C = UK, O = OpenSSL Group, OU = FOR TESTING PURPOSES ONLY, CN = 
OpenSSL Test Intermediate CA

---
No client certificate CA names sent
Peer signing digest: SHA256
Peer signature type: RSA-PSS
Server Temp Key: X25519, 253 bits
---
SSL handshake has read 1547 bytes and written 287 bytes
Verification error: unable to verify the first certificate
---
New, TLSv1.3, Cipher is TLS13-AES-128-GCM-SHA256
Server public key is 2048 bit
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
Early data was not sent
SSL-Session:
     Protocol  : TLSv1.3
     Cipher    : TLS13-AES-128-GCM-SHA256
     Session-ID:
     Session-ID-ctx:
     Master-Key: 
000102030405060708090A0B0C0D0E0F101112131415161718191A1B1C1D1E1F
     PSK identity: None
     PSK identity hint: None
     SRP username: None
     Start Time: 1515615760
     Timeout   : 7200 (sec)
     Verify return code: 21 (unable to verify the first certificate)
     Extended master secret: no
---
CONNECTION ESTABLISHED
Protocol version: TLSv1.3
Client cipher list: 
TLS13-AES-256-GCM-SHA384:TLS13-CHACHA20-POLY1305-SHA256:TLS13-AES-128-GCM-SHA256:TLS_EMPTY_RENEGOTIATION_INFO_SCSV
Ciphersuite: TLS13-AES-128-GCM-SHA256
Signature Algorithms: 
ECDSA+SHA256:ECDSA+SHA384:ECDSA+SHA512:Ed25519:RSA-PSS+SHA256:RSA-PSS+SHA384:RSA-PSS+SHA512:RSA+SHA256:RSA+SHA384:RSA+SHA512
No peer certificate
Supported Elliptic Groups: X25519:P-256:P-521:P-384
Received client packet
Packet length = 27
Processing flight 3
  Record 1 (client -> server)
   Content type: APPLICATION DATA
   Version: TLS1.2
   Length: 22
   Inner content type: APPLICATION DATA
   [ENCRYPTED APPLICATION DATA]
   [test
]

Forwarded packet length = 28

Received server packet
Packet length = 224
Processing flight 4
  Record 1 (server -> client)
   Content type: APPLICATION DATA
   Version: TLS1.2
   Length: 219
   Inner content type: HANDSHAKE
   Message type: NewSessionTicket
   Message Length: 198
DONE

Forwarded packet length = 225

Received client packet
Packet length = 24
Processing flight 5
  Record 1 (client -> server)
   Content type: APPLICATION DATA
   Version: TLS1.2
   Length: 19
   Inner content type: ALERT

Forwarded packet length = 25

Received server packet
Packet length = 27
Processing flight 6
  Record 1 (server -> client)
   Content type: APPLICATION DATA
   Version: TLS1.2
   Length: 22
   Inner content type: APPLICATION DATA
   [ENCRYPTED APPLICATION DATA]
   [tset
]

Forwarded packet length = 28

CONNECTION CLOSED
    1 items in the session cache
    0 client connects (SSL_connect())
    0 client renegotiates (SSL_connect())
    0 client connects that finished
    1 server accepts (SSL_accept())
    0 server renegotiates (SSL_accept())
    1 server accepts that finished
    0 session cache hits
    0 session cache misses
    0 session cache timeouts
    0 callback cache hits
    0 cache full overflows (128 allowed)
Failed 2/18 subtests

Test Summary Report
-------------------
../test/recipes/70-test_sslsigalgs.t (Wstat: 13 Tests: 16 Failed: 0)
   Non-zero wait status: 13
   Parse errors: Bad plan.  You planned 18 tests but ran 16.
Files=1, Tests=16,  1 wallclock secs ( 0.23 usr  0.03 sys +  0.39 cusr 
0.50 csys =  1.15 CPU)
Result: FAIL
make[1]: *** [_tests] Error 1
make[1]: Leaving directory `/home/ed/OPC/openssl'
make: *** [tests] Fehler 2
count=338


From bernd.edlinger at hotmail.de  Wed Jan 10 20:47:49 2018
From: bernd.edlinger at hotmail.de (Bernd Edlinger)
Date: Wed, 10 Jan 2018 20:47:49 +0000
Subject: [openssl-project] update on sporadic test failures
In-Reply-To: <AM5PR0701MB26575B69F2715E05DE948973E4110@AM5PR0701MB2657.eurprd07.prod.outlook.com>
References: <20180110181329.GH72574@kduck.kaduk.org>
 <20180110193354.GK72574@kduck.kaduk.org>
 <20180110.210633.18077756344254585.levitte@openssl.org>
 <20180110201204.GL72574@kduck.kaduk.org>
 <AM5PR0701MB26575B69F2715E05DE948973E4110@AM5PR0701MB2657.eurprd07.prod.outlook.com>
Message-ID: <AM5PR0701MB2657D7E464C15EBBD87FC356E4110@AM5PR0701MB2657.eurprd07.prod.outlook.com>

Hi,

it happened again with Richard's patch after 314 iterations:

# Looks like you failed 1 test of 18.
Dubious, test returned 1 (wstat 256, 0x100)
Failed 1/18 subtests

Test Summary Report
-------------------
../test/recipes/70-test_sslsigalgs.t (Wstat: 256 Tests: 18 Failed: 1)
   Failed test:  6
   Non-zero exit status: 1
Files=1, Tests=18,  1 wallclock secs ( 0.23 usr  0.04 sys +  0.44 cusr 
0.54 csys =  1.25 CPU)
Result: FAIL
make[1]: *** [_tests] Error 1
make[1]: Leaving directory `/home/ed/OPC/openssl'
make: *** [tests] Fehler 2
count=314

From bernd.edlinger at hotmail.de  Wed Jan 10 21:06:43 2018
From: bernd.edlinger at hotmail.de (Bernd Edlinger)
Date: Wed, 10 Jan 2018 21:06:43 +0000
Subject: [openssl-project] update on sporadic test failures
In-Reply-To: <AM5PR0701MB2657D7E464C15EBBD87FC356E4110@AM5PR0701MB2657.eurprd07.prod.outlook.com>
References: <20180110181329.GH72574@kduck.kaduk.org>
 <20180110193354.GK72574@kduck.kaduk.org>
 <20180110.210633.18077756344254585.levitte@openssl.org>
 <20180110201204.GL72574@kduck.kaduk.org>
 <AM5PR0701MB26575B69F2715E05DE948973E4110@AM5PR0701MB2657.eurprd07.prod.outlook.com>
 <AM5PR0701MB2657D7E464C15EBBD87FC356E4110@AM5PR0701MB2657.eurprd07.prod.outlook.com>
Message-ID: <AM5PR0701MB2657A61AF60A41767572C316E4110@AM5PR0701MB2657.eurprd07.prod.outlook.com>

this time I revert the patch again, and did this command:

N=0; while make test TESTS=test_sslsigalgs V=1 >test$N.log; do 
N=$((N+1)); done; echo count=$N
make[1]: *** [_tests] Error 1
make: *** [tests] Fehler 2
count=352


interesting, it happens always after 310-360 iterations.

attached the last good test and the failed test output.


Bernd.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: test351.log
Type: text/x-log
Size: 100310 bytes
Desc: test351.log
URL: <http://mta.openssl.org/pipermail/openssl-project/attachments/20180110/024cbd76/attachment-0002.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: test352.log
Type: text/x-log
Size: 100503 bytes
Desc: test352.log
URL: <http://mta.openssl.org/pipermail/openssl-project/attachments/20180110/024cbd76/attachment-0003.bin>

From levitte at openssl.org  Wed Jan 10 21:20:56 2018
From: levitte at openssl.org (Richard Levitte)
Date: Wed, 10 Jan 2018 22:20:56 +0100 (CET)
Subject: [openssl-project] update on sporadic test failures
In-Reply-To: <20180110202610.GM72574@kduck.kaduk.org>
References: <20180110.210633.18077756344254585.levitte@openssl.org>
 <20180110201204.GL72574@kduck.kaduk.org>
 <20180110202610.GM72574@kduck.kaduk.org>
Message-ID: <20180110.222056.418092048555995804.levitte@openssl.org>

In message <20180110202610.GM72574 at kduck.kaduk.org> on Wed, 10 Jan 2018 14:26:10 -0600, Benjamin Kaduk <kaduk at mit.edu> said:

kaduk> Well, that was quick:
kaduk> 
kaduk> Waiting for client process to close: 28371
kaduk> # Subtest: No client extension extended master secret test
kaduk>     1..4
kaduk>     #   at ../test/recipes/70-test_tlsextms.t line 233.
kaduk>     ok 2 - ClientHello extension extended master secret check
kaduk>     ok 3 - ServerHello extension extended master secret check
kaduk>     ok 4 - Extended master secret full handshake check
kaduk>     # Looks like you failed 1 test of 4.
kaduk> not ok 2 - No client extension extended master secret test
kaduk> 
kaduk> I'll note that I do have some other stuff going on (building openafs
kaduk> in a loop) to generate some extra load on this system and try to
kaduk> make races more likely.

Ok, so we have a clear race condition here, 'cause what happens is
that an "ok 1 - Handshake" has been eaten up, probably because it was
intermixed with the output from another TLS session in the test that
hadn't quite finished yet...

Thing is, TAP depends on those 'ok' and 'not ok' lines that the
subtests output, so when they get eaten up, TAP gets confused.
Trouble is that the TLSProxy code redirects STDOUT to /dev/null unless
in debug mode (which gets turned on by V=1), so yeah, that tells us
roughly where and how the hickup occurs.  Now, to sanitize it
further...

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

From matt at openssl.org  Wed Jan 10 21:54:08 2018
From: matt at openssl.org (Matt Caswell)
Date: Wed, 10 Jan 2018 21:54:08 +0000
Subject: [openssl-project] Levchin prize
In-Reply-To: <CAHEJ-S6XSdtdfkbnH1no4JYdiAJ-rTmnsy4ZX-3nQW7C7JdgVg@mail.gmail.com>
References: <04233dcb-0cdd-037f-4dbd-094571a224b6@openssl.org>
 <20180110.203232.1082744388269773061.levitte@openssl.org>
 <20180110.203509.257786872037977157.levitte@openssl.org>
 <327bc583-2b5a-4072-9ce9-ee57f8ba6e7b@openssl.org>
 <491C070B-D240-479F-8AF7-07510BCF7885@akamai.com>
 <CAHEJ-S6XSdtdfkbnH1no4JYdiAJ-rTmnsy4ZX-3nQW7C7JdgVg@mail.gmail.com>
Message-ID: <190944df-8c7f-047a-3e09-95c6309b209a@openssl.org>

I've added a link to levchinprize.com. I'm going to publish this within
the next hour unless I hear further feedback.

Matt

On 10/01/18 20:27, Tim Hudson wrote:
> I agree with Rich - blog should remain OMC only - and that specific blog
> draft should go to committers for comment.
> 
> And I agree with Matt - this blog post should go out asap.
> 
> Matt - the blog posts should have a direct link to levchinprize.com
> <http://levchinprize.com> not just to the press release.
> 
> Tim.
> 
> On 11 Jan. 2018 6:04 am, "Salz, Rich" <rsalz at akamai.com
> <mailto:rsalz at akamai.com>> wrote:
> 
>     ?? ? ?Maybe we should change "blog" so committers at least have read
>     access?
> 
>     No.
> 
>     _______________________________________________
>     openssl-project mailing list
>     openssl-project at openssl.org <mailto:openssl-project at openssl.org>
>     https://mta.openssl.org/mailman/listinfo/openssl-project
>     <https://mta.openssl.org/mailman/listinfo/openssl-project>
> 
> 
> 
> _______________________________________________
> openssl-project mailing list
> openssl-project at openssl.org
> https://mta.openssl.org/mailman/listinfo/openssl-project
> 

From levitte at openssl.org  Wed Jan 10 22:07:27 2018
From: levitte at openssl.org (Richard Levitte)
Date: Wed, 10 Jan 2018 23:07:27 +0100 (CET)
Subject: [openssl-project] platforms
In-Reply-To: <CAHEJ-S74_mCgmHzUYsmkuv=rrSW-9=gX0nLreARdES_bSeNcow@mail.gmail.com>
References: <20180109.131256.1811235214787240284.levitte@openssl.org>
 <20180110014852.GA72574@kduck.kaduk.org>
 <CAHEJ-S74_mCgmHzUYsmkuv=rrSW-9=gX0nLreARdES_bSeNcow@mail.gmail.com>
Message-ID: <20180110.230727.1912551937096786632.levitte@openssl.org>

I'd say that for the "big" platforms, we do require full build and
full test to say that "it works".  I would say that should be the base
criteria we work with.

But then, I can see reasons to make exceptions from these criteria.
As you say, on some platforms, only the libraries are built.  I can
also imagine a situation where we cross compile everything, and perl
isn't available on the target architecture, which makes our tests
impossible.  These should be noted for sure if we decide to support
them, but *as exceptions* to the base criteria.

In message <CAHEJ-S74_mCgmHzUYsmkuv=rrSW-9=gX0nLreARdES_bSeNcow at mail.gmail.com> on Wed, 10 Jan 2018 17:21:34 +1000, Tim Hudson <tjh at cryptsoft.com> said:

tjh> Follow on from the discussion in PR#5035, I think we need to add a "status" definition to the
tjh> platform which should cover the different contexts:
tjh> 
tjh> 1) libraries compile
tjh> 2) apps compile
tjh> 3) make test passes
tjh> 
tjh> We have platforms where we don't compile the apps and we have platforms where there are
tjh> issues in the tests - i.e. the library (with or without the apps) compiles and operates correctly but
tjh> there is a defect in the tests.
tjh> Defects in tests or defects in the apps are different to defects in the libraries.
tjh> The apps not being ported also does not mean the platform is unusable.
tjh> 
tjh> That level of differences should be recorded. Perhaps a status for each?
tjh> 
tjh> - libcrypto
tjh> - libssl
tjh> - apps
tjh> - tests
tjh> 
tjh> For many platforms, the apps and the tests simply don't work or are not used; and our test
tjh> automation platform also does not operate for many platforms.
tjh> 
tjh> Tim.
tjh> 
tjh> On Wed, Jan 10, 2018 at 11:48 AM, Benjamin Kaduk <kaduk at mit.edu> wrote:
tjh> 
tjh>  On Tue, Jan 09, 2018 at 01:12:56PM +0100, Richard Levitte wrote:
tjh>  > Speaking of platforms, I think we need to discuss what we actually
tjh>  > include in the secondary category. The platform policy currently
tjh>  > mentions these:
tjh>  >
tjh>  > FreeBSD, Windows (Visual Studio, MinGW), MacOS X and VMS
tjh>  >
tjh>  > For Windows and VMS, I know for sure that it follows our definition of
tjh>  > the secondary category (*), but for FreeBSD and MacOS X, I think we
tjh>  > may have lost the people who actively supported them (for FreeBSD,
tjh>  > that was Ben Laurie as far as I recall).
tjh>  >
tjh>  > So I think we need a raise of hands, here and now:
tjh>  >
tjh>  > 1. Is there anyone currently present on this list that want to take
tjh>  > on FreeBSD or MacOS X?
tjh> 
tjh>  I guess maybe this is overcome by events since I commented on github
tjh>  already, but I can take FreeBSD (amd64). I can spin up i386 FreeBSD
tjh>  in the lead up to new releases but don't normally use it on a
tjh>  regular basis.
tjh> 
tjh>  -Ben
tjh>  _______________________________________________
tjh>  openssl-project mailing list
tjh>  openssl-project at openssl.org
tjh>  https://mta.openssl.org/mailman/listinfo/openssl-project
tjh> 

From levitte at openssl.org  Wed Jan 10 22:17:52 2018
From: levitte at openssl.org (Richard Levitte)
Date: Wed, 10 Jan 2018 23:17:52 +0100 (CET)
Subject: [openssl-project] platforms: what do the different "classes" mean?
Message-ID: <20180110.231752.1990356010519443330.levitte@openssl.org>

Reading the platform policy (https://www.openssl.org/policies/platformpolicy.html),
the classifications seems fairly clear.

    Primary: well defined

    Secondary: at least one team member actively supports

    Community: one or more member of the community supports

    Unknown: we have no idea what the status is

    Deprecated: to be removed later on

And yet, we're bickering over what status Cygwin should have in PR
#5043 (https://github.com/openssl/openssl/pull/5043).  Why is that?
I'm guessing that we don't quite agree what "actively supports"
means.  Is the "active" part about declaration (someone solemnly
declaring "I will support Cygwin"), or is it about action and
behavioral patterns (we do know that a few team members look after
Cygwin, although perhaps not on a daily basis).

(from my very personal point of view, I'd put Cygwin in the
"community" category, 'cause even if Matt and I do test OpenSSL on
Cygwin when we are the ones doing a release, that's also it as far as
I know...  but this isn't just about my opinion, and when opinions are
clearly diverging, it's time to ask why)

Cheers,
Richard

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

From tjh at cryptsoft.com  Wed Jan 10 22:27:37 2018
From: tjh at cryptsoft.com (Tim Hudson)
Date: Thu, 11 Jan 2018 08:27:37 +1000
Subject: [openssl-project] platforms
In-Reply-To: <20180110.230727.1912551937096786632.levitte@openssl.org>
References: <20180109.131256.1811235214787240284.levitte@openssl.org>
 <20180110014852.GA72574@kduck.kaduk.org>
 <CAHEJ-S74_mCgmHzUYsmkuv=rrSW-9=gX0nLreARdES_bSeNcow@mail.gmail.com>
 <20180110.230727.1912551937096786632.levitte@openssl.org>
Message-ID: <CAHEJ-S5hiey8Pf2TeVTHZJdRPvVSafN_6Yx-DhPVfXs9EkodLQ@mail.gmail.com>

Currently having a configuration entry actually means nothing - it does not
state if a platform builds, works, tests, etc. It is just a definition. We
claim no particular status in those terms for a platform.

The only thing we have is the platform policy and it lists a very small set
of primary and secondary platforms - but also does not map those to
configuration platform names.
It isn't about does-it-work or not - it is about does someone "support" it.
That is how the platform policy is explicitly defined.

Absent someone specifically putting their hand up to say they will
"support" a platform, the platform belongs in unknown.
This is not about does-it-work. This is about its support status.

The current objective and focus is to actually put each definition into our
already defined categories according to our platform policy.
Once that is done we can figure out more in terms of what we want to expand
the platform policy to mean in terms of specifics beyond "supported".

Now I do indeed think we should go beyond that - and that means defining
criteria for what we mean by a platform definition going forward - and
right now that isn't defined.
We have a lot of platform definitions where make test simply does not work.

If someone hasn't volunteered explicitly to support a platform then it is
"unknown" or "deprecated" ... those are the available choices.

And Configure should note the status of the platform too in terms of which
category it is in - to encourage people to step forward to "support" a
platform.

Tim.


On Thu, Jan 11, 2018 at 8:07 AM, Richard Levitte <levitte at openssl.org>
wrote:

> I'd say that for the "big" platforms, we do require full build and
> full test to say that "it works".  I would say that should be the base
> criteria we work with.
>
> But then, I can see reasons to make exceptions from these criteria.
> As you say, on some platforms, only the libraries are built.  I can
> also imagine a situation where we cross compile everything, and perl
> isn't available on the target architecture, which makes our tests
> impossible.  These should be noted for sure if we decide to support
> them, but *as exceptions* to the base criteria.
>
> In message <CAHEJ-S74_mCgmHzUYsmkuv=rrSW-9=gX0nLreARdES_bSeNcow at mail.
> gmail.com> on Wed, 10 Jan 2018 17:21:34 +1000, Tim Hudson <
> tjh at cryptsoft.com> said:
>
> tjh> Follow on from the discussion in PR#5035, I think we need to add a
> "status" definition to the
> tjh> platform which should cover the different contexts:
> tjh>
> tjh> 1) libraries compile
> tjh> 2) apps compile
> tjh> 3) make test passes
> tjh>
> tjh> We have platforms where we don't compile the apps and we have
> platforms where there are
> tjh> issues in the tests - i.e. the library (with or without the apps)
> compiles and operates correctly but
> tjh> there is a defect in the tests.
> tjh> Defects in tests or defects in the apps are different to defects in
> the libraries.
> tjh> The apps not being ported also does not mean the platform is unusable.
> tjh>
> tjh> That level of differences should be recorded. Perhaps a status for
> each?
> tjh>
> tjh> - libcrypto
> tjh> - libssl
> tjh> - apps
> tjh> - tests
> tjh>
> tjh> For many platforms, the apps and the tests simply don't work or are
> not used; and our test
> tjh> automation platform also does not operate for many platforms.
> tjh>
> tjh> Tim.
> tjh>
> tjh> On Wed, Jan 10, 2018 at 11:48 AM, Benjamin Kaduk <kaduk at mit.edu>
> wrote:
> tjh>
> tjh>  On Tue, Jan 09, 2018 at 01:12:56PM +0100, Richard Levitte wrote:
> tjh>  > Speaking of platforms, I think we need to discuss what we actually
> tjh>  > include in the secondary category. The platform policy currently
> tjh>  > mentions these:
> tjh>  >
> tjh>  > FreeBSD, Windows (Visual Studio, MinGW), MacOS X and VMS
> tjh>  >
> tjh>  > For Windows and VMS, I know for sure that it follows our
> definition of
> tjh>  > the secondary category (*), but for FreeBSD and MacOS X, I think we
> tjh>  > may have lost the people who actively supported them (for FreeBSD,
> tjh>  > that was Ben Laurie as far as I recall).
> tjh>  >
> tjh>  > So I think we need a raise of hands, here and now:
> tjh>  >
> tjh>  > 1. Is there anyone currently present on this list that want to take
> tjh>  > on FreeBSD or MacOS X?
> tjh>
> tjh>  I guess maybe this is overcome by events since I commented on github
> tjh>  already, but I can take FreeBSD (amd64). I can spin up i386 FreeBSD
> tjh>  in the lead up to new releases but don't normally use it on a
> tjh>  regular basis.
> tjh>
> tjh>  -Ben
> tjh>  _______________________________________________
> tjh>  openssl-project mailing list
> tjh>  openssl-project at openssl.org
> tjh>  https://mta.openssl.org/mailman/listinfo/openssl-project
> tjh>
> _______________________________________________
> openssl-project mailing list
> openssl-project at openssl.org
> https://mta.openssl.org/mailman/listinfo/openssl-project
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-project/attachments/20180111/37a50757/attachment-0001.html>

From tjh at cryptsoft.com  Wed Jan 10 22:32:17 2018
From: tjh at cryptsoft.com (Tim Hudson)
Date: Thu, 11 Jan 2018 08:32:17 +1000
Subject: [openssl-project] platforms: what do the different "classes"
	mean?
In-Reply-To: <20180110.231752.1990356010519443330.levitte@openssl.org>
References: <20180110.231752.1990356010519443330.levitte@openssl.org>
Message-ID: <CAHEJ-S59Kv_gpT2t640GaTJUng3i_bbr+VE5g2sGsrgEPCHCyQ@mail.gmail.com>

If you and or Matt are actively supporting it then it is "Secondary".
If someone who is non-OMC, non-committer steps forward to say they will
support it then it is Community.
Otherwise it is Unknown (unless we plan to deprecate it).

I have no problem with you and/or Matt and/or any OMC or committer stepping
forward to place Cygwin in the Secondary status.
But if you want it in Community then a community member has to step forward.

Although I do see that you could elect to make it Community because you
support it but not "actively" - although that wasn't the intent at all -
either a team member is supporting it or a community member is.
It wasn't intended to be a second-class level of team support.

Tim.


On Thu, Jan 11, 2018 at 8:17 AM, Richard Levitte <levitte at openssl.org>
wrote:

> Reading the platform policy (https://www.openssl.org/
> policies/platformpolicy.html),
> the classifications seems fairly clear.
>
>     Primary: well defined
>
>     Secondary: at least one team member actively supports
>
>     Community: one or more member of the community supports
>
>     Unknown: we have no idea what the status is
>
>     Deprecated: to be removed later on
>
> And yet, we're bickering over what status Cygwin should have in PR
> #5043 (https://github.com/openssl/openssl/pull/5043).  Why is that?
> I'm guessing that we don't quite agree what "actively supports"
> means.  Is the "active" part about declaration (someone solemnly
> declaring "I will support Cygwin"), or is it about action and
> behavioral patterns (we do know that a few team members look after
> Cygwin, although perhaps not on a daily basis).
>
> (from my very personal point of view, I'd put Cygwin in the
> "community" category, 'cause even if Matt and I do test OpenSSL on
> Cygwin when we are the ones doing a release, that's also it as far as
> I know...  but this isn't just about my opinion, and when opinions are
> clearly diverging, it's time to ask why)
>
> Cheers,
> Richard
>
> --
> Richard Levitte         levitte at openssl.org
> OpenSSL Project         http://www.openssl.org/~levitte/
> _______________________________________________
> openssl-project mailing list
> openssl-project at openssl.org
> https://mta.openssl.org/mailman/listinfo/openssl-project
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-project/attachments/20180111/a31f6d7d/attachment.html>

From rsalz at akamai.com  Wed Jan 10 22:34:23 2018
From: rsalz at akamai.com (Salz, Rich)
Date: Wed, 10 Jan 2018 22:34:23 +0000
Subject: [openssl-project] platforms
In-Reply-To: <20180110.230727.1912551937096786632.levitte@openssl.org>
References: <20180109.131256.1811235214787240284.levitte@openssl.org>
 <20180110014852.GA72574@kduck.kaduk.org>
 <CAHEJ-S74_mCgmHzUYsmkuv=rrSW-9=gX0nLreARdES_bSeNcow@mail.gmail.com>
 <20180110.230727.1912551937096786632.levitte@openssl.org>
Message-ID: <326D1DAD-C7AB-4ECB-A198-EFA3E989FCF4@akamai.com>

UEFI is one such exception

On 1/10/18, 5:07 PM, "Richard Levitte" <levitte at openssl.org> wrote:

    I'd say that for the "big" platforms, we do require full build and
    full test to say that "it works".  I would say that should be the base
    criteria we work with.
    
    But then, I can see reasons to make exceptions from these criteria.
    As you say, on some platforms, only the libraries are built.  I can
    also imagine a situation where we cross compile everything, and perl
    isn't available on the target architecture, which makes our tests
    impossible.  These should be noted for sure if we decide to support
    them, but *as exceptions* to the base criteria.
    
    In message <CAHEJ-S74_mCgmHzUYsmkuv=rrSW-9=gX0nLreARdES_bSeNcow at mail.gmail.com> on Wed, 10 Jan 2018 17:21:34 +1000, Tim Hudson <tjh at cryptsoft.com> said:
    
    tjh> Follow on from the discussion in PR#5035, I think we need to add a "status" definition to the
    tjh> platform which should cover the different contexts:
    tjh> 
    tjh> 1) libraries compile
    tjh> 2) apps compile
    tjh> 3) make test passes
    tjh> 
    tjh> We have platforms where we don't compile the apps and we have platforms where there are
    tjh> issues in the tests - i.e. the library (with or without the apps) compiles and operates correctly but
    tjh> there is a defect in the tests.
    tjh> Defects in tests or defects in the apps are different to defects in the libraries.
    tjh> The apps not being ported also does not mean the platform is unusable.
    tjh> 
    tjh> That level of differences should be recorded. Perhaps a status for each?
    tjh> 
    tjh> - libcrypto
    tjh> - libssl
    tjh> - apps
    tjh> - tests
    tjh> 
    tjh> For many platforms, the apps and the tests simply don't work or are not used; and our test
    tjh> automation platform also does not operate for many platforms.
    tjh> 
    tjh> Tim.
    tjh> 
    tjh> On Wed, Jan 10, 2018 at 11:48 AM, Benjamin Kaduk <kaduk at mit.edu> wrote:
    tjh> 
    tjh>  On Tue, Jan 09, 2018 at 01:12:56PM +0100, Richard Levitte wrote:
    tjh>  > Speaking of platforms, I think we need to discuss what we actually
    tjh>  > include in the secondary category. The platform policy currently
    tjh>  > mentions these:
    tjh>  >
    tjh>  > FreeBSD, Windows (Visual Studio, MinGW), MacOS X and VMS
    tjh>  >
    tjh>  > For Windows and VMS, I know for sure that it follows our definition of
    tjh>  > the secondary category (*), but for FreeBSD and MacOS X, I think we
    tjh>  > may have lost the people who actively supported them (for FreeBSD,
    tjh>  > that was Ben Laurie as far as I recall).
    tjh>  >
    tjh>  > So I think we need a raise of hands, here and now:
    tjh>  >
    tjh>  > 1. Is there anyone currently present on this list that want to take
    tjh>  > on FreeBSD or MacOS X?
    tjh> 
    tjh>  I guess maybe this is overcome by events since I commented on github
    tjh>  already, but I can take FreeBSD (amd64). I can spin up i386 FreeBSD
    tjh>  in the lead up to new releases but don't normally use it on a
    tjh>  regular basis.
    tjh> 
    tjh>  -Ben
    tjh>  _______________________________________________
    tjh>  openssl-project mailing list
    tjh>  openssl-project at openssl.org
    tjh>  https://mta.openssl.org/mailman/listinfo/openssl-project
    tjh> 
    _______________________________________________
    openssl-project mailing list
    openssl-project at openssl.org
    https://mta.openssl.org/mailman/listinfo/openssl-project
    


From tjh at cryptsoft.com  Wed Jan 10 22:42:17 2018
From: tjh at cryptsoft.com (Tim Hudson)
Date: Thu, 11 Jan 2018 08:42:17 +1000
Subject: [openssl-project] platforms
In-Reply-To: <326D1DAD-C7AB-4ECB-A198-EFA3E989FCF4@akamai.com>
References: <20180109.131256.1811235214787240284.levitte@openssl.org>
 <20180110014852.GA72574@kduck.kaduk.org>
 <CAHEJ-S74_mCgmHzUYsmkuv=rrSW-9=gX0nLreARdES_bSeNcow@mail.gmail.com>
 <20180110.230727.1912551937096786632.levitte@openssl.org>
 <326D1DAD-C7AB-4ECB-A198-EFA3E989FCF4@akamai.com>
Message-ID: <CAHEJ-S6EFAM7b_rjWOXpUprUrnmHQwok2FNmgPEvfXaYUdwbCg@mail.gmail.com>

android, bs2000, djgpp, wince, ios, uefi, mpe, vos, uclinux, vxworks - i.e.
at least 26+ platform definitions are in the category of "make test" does
not work (in general)
and that isn't talking about the other platforms where it might work or
might now which I doubt anyone has compiled on for a least a decade

The *majority* of the platforms are in unknown status - by definition -
according to our platform policy - and a significant portion of the
platforms defined do not support successful execution of "make test".

Tim.


On Thu, Jan 11, 2018 at 8:34 AM, Salz, Rich <rsalz at akamai.com> wrote:

> UEFI is one such exception
>
> On 1/10/18, 5:07 PM, "Richard Levitte" <levitte at openssl.org> wrote:
>
>     I'd say that for the "big" platforms, we do require full build and
>     full test to say that "it works".  I would say that should be the base
>     criteria we work with.
>
>     But then, I can see reasons to make exceptions from these criteria.
>     As you say, on some platforms, only the libraries are built.  I can
>     also imagine a situation where we cross compile everything, and perl
>     isn't available on the target architecture, which makes our tests
>     impossible.  These should be noted for sure if we decide to support
>     them, but *as exceptions* to the base criteria.
>
>     In message <CAHEJ-S74_mCgmHzUYsmkuv=rrSW-9=gX0nLreARdES_bSeNcow at mail.
> gmail.com> on Wed, 10 Jan 2018 17:21:34 +1000, Tim Hudson <
> tjh at cryptsoft.com> said:
>
>     tjh> Follow on from the discussion in PR#5035, I think we need to add
> a "status" definition to the
>     tjh> platform which should cover the different contexts:
>     tjh>
>     tjh> 1) libraries compile
>     tjh> 2) apps compile
>     tjh> 3) make test passes
>     tjh>
>     tjh> We have platforms where we don't compile the apps and we have
> platforms where there are
>     tjh> issues in the tests - i.e. the library (with or without the apps)
> compiles and operates correctly but
>     tjh> there is a defect in the tests.
>     tjh> Defects in tests or defects in the apps are different to defects
> in the libraries.
>     tjh> The apps not being ported also does not mean the platform is
> unusable.
>     tjh>
>     tjh> That level of differences should be recorded. Perhaps a status
> for each?
>     tjh>
>     tjh> - libcrypto
>     tjh> - libssl
>     tjh> - apps
>     tjh> - tests
>     tjh>
>     tjh> For many platforms, the apps and the tests simply don't work or
> are not used; and our test
>     tjh> automation platform also does not operate for many platforms.
>     tjh>
>     tjh> Tim.
>     tjh>
>     tjh> On Wed, Jan 10, 2018 at 11:48 AM, Benjamin Kaduk <kaduk at mit.edu>
> wrote:
>     tjh>
>     tjh>  On Tue, Jan 09, 2018 at 01:12:56PM +0100, Richard Levitte wrote:
>     tjh>  > Speaking of platforms, I think we need to discuss what we
> actually
>     tjh>  > include in the secondary category. The platform policy
> currently
>     tjh>  > mentions these:
>     tjh>  >
>     tjh>  > FreeBSD, Windows (Visual Studio, MinGW), MacOS X and VMS
>     tjh>  >
>     tjh>  > For Windows and VMS, I know for sure that it follows our
> definition of
>     tjh>  > the secondary category (*), but for FreeBSD and MacOS X, I
> think we
>     tjh>  > may have lost the people who actively supported them (for
> FreeBSD,
>     tjh>  > that was Ben Laurie as far as I recall).
>     tjh>  >
>     tjh>  > So I think we need a raise of hands, here and now:
>     tjh>  >
>     tjh>  > 1. Is there anyone currently present on this list that want to
> take
>     tjh>  > on FreeBSD or MacOS X?
>     tjh>
>     tjh>  I guess maybe this is overcome by events since I commented on
> github
>     tjh>  already, but I can take FreeBSD (amd64). I can spin up i386
> FreeBSD
>     tjh>  in the lead up to new releases but don't normally use it on a
>     tjh>  regular basis.
>     tjh>
>     tjh>  -Ben
>     tjh>  _______________________________________________
>     tjh>  openssl-project mailing list
>     tjh>  openssl-project at openssl.org
>     tjh>  https://mta.openssl.org/mailman/listinfo/openssl-project
>     tjh>
>     _______________________________________________
>     openssl-project mailing list
>     openssl-project at openssl.org
>     https://mta.openssl.org/mailman/listinfo/openssl-project
>
>
> _______________________________________________
> openssl-project mailing list
> openssl-project at openssl.org
> https://mta.openssl.org/mailman/listinfo/openssl-project
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-project/attachments/20180111/b6d2f776/attachment-0001.html>

From levitte at openssl.org  Wed Jan 10 22:53:34 2018
From: levitte at openssl.org (Richard Levitte)
Date: Wed, 10 Jan 2018 23:53:34 +0100 (CET)
Subject: [openssl-project] platforms: what do the different "classes"
 mean?
In-Reply-To: <CAHEJ-S59Kv_gpT2t640GaTJUng3i_bbr+VE5g2sGsrgEPCHCyQ@mail.gmail.com>
References: <20180110.231752.1990356010519443330.levitte@openssl.org>
 <CAHEJ-S59Kv_gpT2t640GaTJUng3i_bbr+VE5g2sGsrgEPCHCyQ@mail.gmail.com>
Message-ID: <20180110.235334.1996973649833265355.levitte@openssl.org>

So your interpretation of "active support" is primarly declarative.
That's perfectly fine, and I hope others will tell us what they think,
and I hope that we will come to an agreement on the meaning.

I kinda sorta agree with you...  most of all for "secondary"
classification, I'd like to see clear declarations of support.
You might note in PR #5043, however, that I haven't put down any name
for the VC and mingw config targets.  The main reason is that through
Travis and Appveyor, we all get to support them (we do worry every
time they aren't green).  It seems like a moot point to declare
anything more...

So for the "community" classification...  you see, I had it stuck in
my head that all new config targets provided by someone outside the
team would automatically end up classified "community", because it was
provided by the community...  but then again, "provided" isn't the
same as "supported", and if "supported" is the primary criteria for
the "community" classification, having such config targets classified
as such, no questions asked, is clearly wrong.  So we end up putting
them in "unknown" until further notice.

Sorry for babbling, I guess I needed to write it aloud to unstick my
own stuck thoughts.

Regarding intent (as you commented re Cygwin), it would seem we aren't
all clear on it (even within the OMC)...  but we may be on our way to
a common view.

Cheers,
Richard

In message <CAHEJ-S59Kv_gpT2t640GaTJUng3i_bbr+VE5g2sGsrgEPCHCyQ at mail.gmail.com> on Thu, 11 Jan 2018 08:32:17 +1000, Tim Hudson <tjh at cryptsoft.com> said:

tjh> If you and or Matt are actively supporting it then it is "Secondary".
tjh> If someone who is non-OMC, non-committer steps forward to say they will support it then it is
tjh> Community.
tjh> Otherwise it is Unknown (unless we plan to deprecate it).
tjh> 
tjh> I have no problem with you and/or Matt and/or any OMC or committer stepping forward to place
tjh> Cygwin in the Secondary status.
tjh> But if you want it in Community then a community member has to step forward.
tjh> 
tjh> Although I do see that you could elect to make it Community because you support it but not
tjh> "actively" - although that wasn't the intent at all - either a team member is supporting it or a
tjh> community member is.
tjh> It wasn't intended to be a second-class level of team support.
tjh> 
tjh> Tim.
tjh> 
tjh> On Thu, Jan 11, 2018 at 8:17 AM, Richard Levitte <levitte at openssl.org> wrote:
tjh> 
tjh>  Reading the platform policy (https://www.openssl.org/policies/platformpolicy.html),
tjh>  the classifications seems fairly clear.
tjh> 
tjh>  Primary: well defined
tjh> 
tjh>  Secondary: at least one team member actively supports
tjh> 
tjh>  Community: one or more member of the community supports
tjh> 
tjh>  Unknown: we have no idea what the status is
tjh> 
tjh>  Deprecated: to be removed later on
tjh> 
tjh>  And yet, we're bickering over what status Cygwin should have in PR
tjh>  #5043 (https://github.com/openssl/openssl/pull/5043). Why is that?
tjh>  I'm guessing that we don't quite agree what "actively supports"
tjh>  means. Is the "active" part about declaration (someone solemnly
tjh>  declaring "I will support Cygwin"), or is it about action and
tjh>  behavioral patterns (we do know that a few team members look after
tjh>  Cygwin, although perhaps not on a daily basis).
tjh> 
tjh>  (from my very personal point of view, I'd put Cygwin in the
tjh>  "community" category, 'cause even if Matt and I do test OpenSSL on
tjh>  Cygwin when we are the ones doing a release, that's also it as far as
tjh>  I know... but this isn't just about my opinion, and when opinions are
tjh>  clearly diverging, it's time to ask why)
tjh> 
tjh>  Cheers,
tjh>  Richard
tjh> 
tjh>  --
tjh>  Richard Levitte levitte at openssl.org
tjh>  OpenSSL Project http://www.openssl.org/~levitte/
tjh>  _______________________________________________
tjh>  openssl-project mailing list
tjh>  openssl-project at openssl.org
tjh>  https://mta.openssl.org/mailman/listinfo/openssl-project
tjh> 

From matt at openssl.org  Wed Jan 10 22:57:41 2018
From: matt at openssl.org (Matt Caswell)
Date: Wed, 10 Jan 2018 22:57:41 +0000
Subject: [openssl-project] platforms: what do the different "classes"
 mean?
In-Reply-To: <CAHEJ-S59Kv_gpT2t640GaTJUng3i_bbr+VE5g2sGsrgEPCHCyQ@mail.gmail.com>
References: <20180110.231752.1990356010519443330.levitte@openssl.org>
 <CAHEJ-S59Kv_gpT2t640GaTJUng3i_bbr+VE5g2sGsrgEPCHCyQ@mail.gmail.com>
Message-ID: <b1b7208c-9710-a943-dbd9-3942b9649aba@openssl.org>



On 10/01/18 22:32, Tim Hudson wrote:
> If you and or Matt are actively supporting it then it is "Secondary".

I usually don't even do it during a release these days. I used to but it
invariably failed and we invariably said that it wasn't a show stopper
and went ahead anyway. So now I don't even bother. I haven't attempted a
Cygwin build in a long time.

Matt



> If someone who is non-OMC, non-committer steps forward to say they will
> support it then it is Community.
> Otherwise it is Unknown (unless we plan to deprecate it).
> 
> I have no problem with you and/or Matt and/or any OMC or committer
> stepping forward to place Cygwin in the Secondary status.?
> But if you want it in Community then a community member has to step forward.
> 
> Although I do see that you could elect to make it Community because you
> support it but not "actively" - although that wasn't the intent at all -
> either a team member is supporting it or a community member is.?
> It wasn't intended to be a second-class level of team support.
> 
> Tim.
> 
> 
> On Thu, Jan 11, 2018 at 8:17 AM, Richard Levitte <levitte at openssl.org
> <mailto:levitte at openssl.org>> wrote:
> 
>     Reading the platform policy
>     (https://www.openssl.org/policies/platformpolicy.html
>     <https://www.openssl.org/policies/platformpolicy.html>),
>     the classifications seems fairly clear.
> 
>     ? ? Primary: well defined
> 
>     ? ? Secondary: at least one team member actively supports
> 
>     ? ? Community: one or more member of the community supports
> 
>     ? ? Unknown: we have no idea what the status is
> 
>     ? ? Deprecated: to be removed later on
> 
>     And yet, we're bickering over what status Cygwin should have in PR
>     #5043 (https://github.com/openssl/openssl/pull/5043
>     <https://github.com/openssl/openssl/pull/5043>).? Why is that?
>     I'm guessing that we don't quite agree what "actively supports"
>     means.? Is the "active" part about declaration (someone solemnly
>     declaring "I will support Cygwin"), or is it about action and
>     behavioral patterns (we do know that a few team members look after
>     Cygwin, although perhaps not on a daily basis).
> 
>     (from my very personal point of view, I'd put Cygwin in the
>     "community" category, 'cause even if Matt and I do test OpenSSL on
>     Cygwin when we are the ones doing a release, that's also it as far as
>     I know...? but this isn't just about my opinion, and when opinions are
>     clearly diverging, it's time to ask why)
> 
>     Cheers,
>     Richard
> 
>     --
>     Richard Levitte? ? ? ? ?levitte at openssl.org <mailto:levitte at openssl.org>
>     OpenSSL Project? ? ? ? ?http://www.openssl.org/~levitte/
>     <http://www.openssl.org/~levitte/>
>     _______________________________________________
>     openssl-project mailing list
>     openssl-project at openssl.org <mailto:openssl-project at openssl.org>
>     https://mta.openssl.org/mailman/listinfo/openssl-project
>     <https://mta.openssl.org/mailman/listinfo/openssl-project>
> 
> 
> 
> 
> _______________________________________________
> openssl-project mailing list
> openssl-project at openssl.org
> https://mta.openssl.org/mailman/listinfo/openssl-project
> 

From levitte at openssl.org  Wed Jan 10 23:04:36 2018
From: levitte at openssl.org (Richard Levitte)
Date: Thu, 11 Jan 2018 00:04:36 +0100 (CET)
Subject: [openssl-project] platforms: what do the different "classes"
 mean?
In-Reply-To: <b1b7208c-9710-a943-dbd9-3942b9649aba@openssl.org>
References: <20180110.231752.1990356010519443330.levitte@openssl.org>
 <CAHEJ-S59Kv_gpT2t640GaTJUng3i_bbr+VE5g2sGsrgEPCHCyQ@mail.gmail.com>
 <b1b7208c-9710-a943-dbd9-3942b9649aba@openssl.org>
Message-ID: <20180111.000436.155962581105471505.levitte@openssl.org>

In message <b1b7208c-9710-a943-dbd9-3942b9649aba at openssl.org> on Wed, 10 Jan 2018 22:57:41 +0000, Matt Caswell <matt at openssl.org> said:

matt> 
matt> 
matt> On 10/01/18 22:32, Tim Hudson wrote:
matt> > If you and or Matt are actively supporting it then it is "Secondary".
matt> 
matt> I usually don't even do it during a release these days. I used to but it
matt> invariably failed and we invariably said that it wasn't a show stopper
matt> and went ahead anyway. So now I don't even bother. I haven't attempted a
matt> Cygwin build in a long time.

Darn.

I need to debug my memory...  or fix Cygwin.  I think that latter is
easier ;-)

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

From levitte at openssl.org  Thu Jan 11 11:53:16 2018
From: levitte at openssl.org (Richard Levitte)
Date: Thu, 11 Jan 2018 12:53:16 +0100 (CET)
Subject: [openssl-project] platforms: what do the different "classes"
 mean?
In-Reply-To: <b1b7208c-9710-a943-dbd9-3942b9649aba@openssl.org>
References: <20180110.231752.1990356010519443330.levitte@openssl.org>
 <CAHEJ-S59Kv_gpT2t640GaTJUng3i_bbr+VE5g2sGsrgEPCHCyQ@mail.gmail.com>
 <b1b7208c-9710-a943-dbd9-3942b9649aba@openssl.org>
Message-ID: <20180111.125316.1605136805896409432.levitte@openssl.org>

In message <b1b7208c-9710-a943-dbd9-3942b9649aba at openssl.org> on Wed, 10 Jan 2018 22:57:41 +0000, Matt Caswell <matt at openssl.org> said:

matt> On 10/01/18 22:32, Tim Hudson wrote:
matt> > If you and or Matt are actively supporting it then it is "Secondary".
matt> 
matt> I usually don't even do it during a release these days. I used to but it
matt> invariably failed and we invariably said that it wasn't a show stopper
matt> and went ahead anyway. So now I don't even bother. I haven't attempted a
matt> Cygwin build in a long time.

I just had another look at Cgwin, and it builds find, but tests in the
70 range seem to fail a bit randomly, in ways that may be the same as
we've started experiencing on Travis and that Ben and Bernd have
reported here yesterday.  My VirtualBox is a slug, so it will take
some time before I can say anything more conclusive, but there ya
go, we may have found something that's not actually limited to Cygwin,
but our installation may be of such nature that they caught the issue
first.

I'll get back on this.

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

From levitte at openssl.org  Fri Jan 12 09:40:35 2018
From: levitte at openssl.org (Richard Levitte)
Date: Fri, 12 Jan 2018 10:40:35 +0100 (CET)
Subject: [openssl-project] update on sporadic test failures
In-Reply-To: <AM5PR0701MB2657A61AF60A41767572C316E4110@AM5PR0701MB2657.eurprd07.prod.outlook.com>
References: <AM5PR0701MB26575B69F2715E05DE948973E4110@AM5PR0701MB2657.eurprd07.prod.outlook.com>
 <AM5PR0701MB2657D7E464C15EBBD87FC356E4110@AM5PR0701MB2657.eurprd07.prod.outlook.com>
 <AM5PR0701MB2657A61AF60A41767572C316E4110@AM5PR0701MB2657.eurprd07.prod.outlook.com>
Message-ID: <20180112.104035.120285537026855126.levitte@openssl.org>

In message <AM5PR0701MB2657A61AF60A41767572C316E4110 at AM5PR0701MB2657.eurprd07.prod.outlook.com> on Wed, 10 Jan 2018 21:06:43 +0000, Bernd Edlinger <bernd.edlinger at hotmail.de> said:

bernd.edlinger> this time I revert the patch again, and did this command:
bernd.edlinger> 
bernd.edlinger> N=0; while make test TESTS=test_sslsigalgs V=1 >test$N.log; do 
bernd.edlinger> N=$((N+1)); done; echo count=$N
bernd.edlinger> make[1]: *** [_tests] Error 1
bernd.edlinger> make: *** [tests] Fehler 2
bernd.edlinger> count=352
bernd.edlinger> 
bernd.edlinger> 
bernd.edlinger> interesting, it happens always after 310-360 iterations.
bernd.edlinger> 
bernd.edlinger> attached the last good test and the failed test output.

So I've looked through the logs and played quite a bit with the proxy
code, and I'm thinking that we've found a point where...  well I'm not
sure if this qualifies as a race condition, but it seems like we're
kind of cutting the proxy short a little now and then, possibly
because of events we don't check for, possibly because s_client
doesn't always flush...

But let's observe.

The first thing to observe is that we have an idea of a successful
communication, codified at the end of TLSProxy::Message::get_message()
(util/perl/TLSProxy/Message.pm, starting at line 258), that says that
if the proxy sees application data and if we have a session file,
which we selfom do, or if it sees a CloseNotify from the client, the
communication is a success.

With that established, we can have a look at the run of
70-test_sslsigalgs.t, more precisely test 6 "OSS only sigalgs in
TLSv1.3".

This is from test351.log, with commenting:

    Server command: ../../util/shlib_wrap.sh ../../apps/openssl s_server -no_comp -rev -engine ossltest -accept 4443 -cert ../../apps/server.pem -cert2 ../../apps/server.pem -naccept 1 -cipher AES128-SHA:TLS13-AES-128-GCM-SHA256
    Proxy started on port 4453
    Client command: echo test | ../../util/shlib_wrap.sh ../../apps/openssl s_client -engine ossltest -connect localhost:4453

>>> Note the above, we're always sending 'test' as payload through the
>>> client side.  It does show up further down

    engine "ossltest" set.
    Using default temp DH parameters
    ACCEPT
    engine "ossltest" set.
    Connection opened
    Received client packet
    Packet length = 301
    Processing flight 0
     Record 1 (client -> server)
      Content type: HANDSHAKE
      Version: TLS1.0
      Length: 296
      Message type: ClientHello
      Message Length: 292
        Client Version:771
        Session ID Len:32
        Ciphersuite len:62
        Compression Method Len:1
        Extensions Len:157
    
    Forwarded packet length = 265
    
    Received server packet
    Packet length = 1543
    Processing flight 1
     Record 1 (server -> client)
      Content type: HANDSHAKE
      Version: TLS1.2
      Length: 122
      Message type: ServerHello
      Message Length: 118
        Server Version:771
        Session ID Len:32
        Ciphersuite:4865
        Compression Method:0
        Extensions Len:46
     Record 2 (server -> client)
      Content type: CCS
      Version: TLS1.2
      Length: 1
     Record 3 (server -> client)
      Content type: APPLICATION DATA
      Version: TLS1.2
      Length: 23
      Inner content type: HANDSHAKE
      Message type: EncryptedExtensions
      Message Length: 2
        Extensions Len:0
     Record 4 (server -> client)
      Content type: APPLICATION DATA
      Version: TLS1.2
      Length: 1033
      Inner content type: HANDSHAKE
      Message type: Certificate
      Message Length: 1012
        Context:
        Certificate List Len:1008
        Certificate Len:1003
        Extensions Len:0
     Record 5 (server -> client)
      Content type: APPLICATION DATA
      Version: TLS1.2
      Length: 281
      Inner content type: HANDSHAKE
      Message type: CertificateVerify
      Message Length: 260
        SigAlg:2052
        Signature Len:256
     Record 6 (server -> client)
      Content type: APPLICATION DATA
      Version: TLS1.2
      Length: 53
      Inner content type: HANDSHAKE
      Message type: Finished
      Message Length: 32
    
    Forwarded packet length = 1547
    
    depth=0 C = UK, O = OpenSSL Group, OU = FOR TESTING PURPOSES ONLY, CN = Test Server Cert
    verify error:num=20:unable to get local issuer certificate
    verify return:1
    depth=0 C = UK, O = OpenSSL Group, OU = FOR TESTING PURPOSES ONLY, CN = Test Server Cert
    verify error:num=21:unable to verify the first certificate
    verify return:1
    Received client packet
    Packet length = 64
    Processing flight 2
     Record 1 (client -> server)
      Content type: CCS
      Version: TLS1.2
      Length: 1
     Record 2 (client -> server)
      Content type: APPLICATION DATA
      Version: TLS1.2
      Length: 53
      Inner content type: HANDSHAKE
      Message type: Finished
      Message Length: 32
    CONNECTED(00000003)
    ---
    Certificate chain
     0 s:C = UK, O = OpenSSL Group, OU = FOR TESTING PURPOSES ONLY, CN = Test Server Cert
       i:C = UK, O = OpenSSL Group, OU = FOR TESTING PURPOSES ONLY, CN = OpenSSL Test Intermediate CA
    ---
    Server certificate
    -----BEGIN CERTIFICATE-----
    MIID5zCCAs+gAwIBAgIJALnu1NlVpZ6zMA0GCSqGSIb3DQEBBQUAMHAxCzAJBgNV
    BAYTAlVLMRYwFAYDVQQKDA1PcGVuU1NMIEdyb3VwMSIwIAYDVQQLDBlGT1IgVEVT
    VElORyBQVVJQT1NFUyBPTkxZMSUwIwYDVQQDDBxPcGVuU1NMIFRlc3QgSW50ZXJt
    ZWRpYXRlIENBMB4XDTExMTIwODE0MDE0OFoXDTIxMTAxNjE0MDE0OFowZDELMAkG
    A1UEBhMCVUsxFjAUBgNVBAoMDU9wZW5TU0wgR3JvdXAxIjAgBgNVBAsMGUZPUiBU
    RVNUSU5HIFBVUlBPU0VTIE9OTFkxGTAXBgNVBAMMEFRlc3QgU2VydmVyIENlcnQw
    ggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDzhPOSNtyyRspmeuUpxfNJ
    KCLTuf7g3uQ4zu4iHOmRO5TQci+HhVlLZrHF9XqFXcIP0y4pWDbMSGuiorUmzmfi
    R7bfSdI/+qIQt8KXRH6HNG1t8ou0VSvWId5TS5Dq/er5ODUr9OaaDva7EquHIcMv
    vPQGuI+OEAcnleVCy9HVEIySrO4P3CNIicnGkwwiAud05yUAq/gPXBC1hTtmlPD7
    TVcGVSEiJdvzqqlgv02qedGrkki6GY4S7GjZxrrf7Foc2EP+51LJzwLQx3/JfrCU
    41NEWAsu/Sl0tQabXESN+zJ1pDqoZ3uHMgpQjeGiE0olr+YcsSW/tJmiU9OiAr8R
    AgMBAAGjgY8wgYwwDAYDVR0TAQH/BAIwADAOBgNVHQ8BAf8EBAMCBeAwLAYJYIZI
    AYb4QgENBB8WHU9wZW5TU0wgR2VuZXJhdGVkIENlcnRpZmljYXRlMB0GA1UdDgQW
    BBSCvM8AABPR9zklmifnr9LvIBturDAfBgNVHSMEGDAWgBQ2w2yI55X+sL3szj49
    hqshgYfa2jANBgkqhkiG9w0BAQUFAAOCAQEAqb1NV0B0/pbpK9Z4/bNjzPQLTRLK
    WnSNm/Jh5v0GEUOE/Beg7GNjNrmeNmqxAlpqWz9qoeoFZax+QBpIZYjROU3TS3fp
    yLsrnlr0CDQ5R7kCCDGa8dkXxemmpZZLbUCpW2Uoy8sAA4JjN9OtsZY7dvUXFgJ7
    vVNTRnI01ghknbtD+2SxSQd3CWF6QhcRMAzZJ1z1cbbwGDDzfvGFPzJ+Sq+zEPds
    xoVLLSetCiBc+40ZcDS5dV98h9XD7JMTQfxzA7mNGv73JoZJA6nFgj+ADSlJsY/t
    JBv+z1iQRueoh9Qeee+ZbRifPouCB8FDx+AltvHTANdAq0t/K3o+pplMVA==
    -----END CERTIFICATE-----
    subject=C = UK, O = OpenSSL Group, OU = FOR TESTING PURPOSES ONLY, CN = Test Server Cert
    
    issuer=C = UK, O = OpenSSL Group, OU = FOR TESTING PURPOSES ONLY, CN = OpenSSL Test Intermediate CA
    
    ---
    No client certificate CA names sent
    Peer signing digest: SHA256
    Peer signature type: RSA-PSS
    Server Temp Key: X25519, 253 bits
    ---
    SSL handshake has read 1547 bytes and written 365 bytes
    Verification error: unable to verify the first certificate
    ---
    New, TLSv1.3, Cipher is TLS13-AES-128-GCM-SHA256
    Server public key is 2048 bit
    Secure Renegotiation IS NOT supported
    Compression: NONE
    Expansion: NONE
    No ALPN negotiated
    Early data was not sent
    SSL-Session:
        Protocol  : TLSv1.3
        Cipher    : TLS13-AES-128-GCM-SHA256
        Session-ID: 
        Session-ID-ctx: 
        Master-Key: 000102030405060708090A0B0C0D0E0F101112131415161718191A1B1C1D1E1F
        PSK identity: None
        PSK identity hint: None
        SRP username: None
        Start Time: 1515617729
        Timeout   : 7200 (sec)
        Verify return code: 21 (unable to verify the first certificate)
        Extended master secret: no
    ---
    
    DONE
    Forwarded packet length = 65
    
    Received client packet
    Packet length = 51
    Processing flight 3
     Record 1 (client -> server)
      Content type: APPLICATION DATA
      Version: TLS1.2
      Length: 22
      Inner content type: APPLICATION DATA
      [ENCRYPTED APPLICATION DATA]
      [test
    ]

>>> ... and that was the payload showing up!

     Record 2 (client -> server)
      Content type: APPLICATION DATA
      Version: TLS1.2
      Length: 19
      Inner content type: ALERT

>>> ... and that was the CloseNotify that triggers our success meter

    Forwarded packet length = 53
    
    Connection closed
    Waiting for server process to close: 10198
    CONNECTION ESTABLISHED
    Protocol version: TLSv1.3
    Client cipher list: ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:DHE-RSA-AES256-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES256-SHA:ECDHE-RSA-AES256-SHA:DHE-RSA-AES256-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES128-SHA:DHE-RSA-AES128-SHA:AES256-GCM-SHA384:AES128-GCM-SHA256:TLS13-AES-256-GCM-SHA384:TLS13-CHACHA20-POLY1305-SHA256:TLS13-AES-128-GCM-SHA256:AES256-SHA256:AES128-SHA256:AES256-SHA:AES128-SHA:TLS_EMPTY_RENEGOTIATION_INFO_SCSV
    Ciphersuite: TLS13-AES-128-GCM-SHA256
    Signature Algorithms: RSA-PSS+SHA256
    No peer certificate
    Supported Elliptic Groups: X25519:P-256:P-521:P-384
       1 items in the session cache
       0 client connects (SSL_connect())
       0 client renegotiates (SSL_connect())
       0 client connects that finished
       1 server accepts (SSL_accept())
       0 server renegotiates (SSL_accept())
       1 server accepts that finished
       0 session cache hits
       0 session cache misses
       0 session cache timeouts
       0 callback cache hits
       0 cache full overflows (128 allowed)
    Waiting for client process to close: 10199
    ok 6 - PSS only sigalgs in TLSv1.3

--------------------

Now, let's have a look at the same test output from test352.log:

    Server command: ../../util/shlib_wrap.sh ../../apps/openssl s_server -no_comp -rev -engine ossltest -accept 4443 -cert ../../apps/server.pem -cert2 ../../apps/server.pem -naccept 1 -cipher AES128-SHA:TLS13-AES-128-GCM-SHA256
    Proxy started on port 4453
    Client command: echo test | ../../util/shlib_wrap.sh ../../apps/openssl s_client -engine ossltest -connect localhost:4453
    engine "ossltest" set.
    Using default temp DH parameters
    ACCEPT
    engine "ossltest" set.
    Connection opened
    Received client packet
    Packet length = 301
    Processing flight 0
     Record 1 (client -> server)
      Content type: HANDSHAKE
      Version: TLS1.0
      Length: 296
      Message type: ClientHello
      Message Length: 292
        Client Version:771
        Session ID Len:32
        Ciphersuite len:62
        Compression Method Len:1
        Extensions Len:157
    
    Forwarded packet length = 265
    
    Received server packet
    Packet length = 1543
    Processing flight 1
     Record 1 (server -> client)
      Content type: HANDSHAKE
      Version: TLS1.2
      Length: 122
      Message type: ServerHello
      Message Length: 118
        Server Version:771
        Session ID Len:32
        Ciphersuite:4865
        Compression Method:0
        Extensions Len:46
     Record 2 (server -> client)
      Content type: CCS
      Version: TLS1.2
      Length: 1
     Record 3 (server -> client)
      Content type: APPLICATION DATA
      Version: TLS1.2
      Length: 23
      Inner content type: HANDSHAKE
      Message type: EncryptedExtensions
      Message Length: 2
        Extensions Len:0
     Record 4 (server -> client)
      Content type: APPLICATION DATA
      Version: TLS1.2
      Length: 1033
      Inner content type: HANDSHAKE
      Message type: Certificate
      Message Length: 1012
        Context:
        Certificate List Len:1008
        Certificate Len:1003
        Extensions Len:0
     Record 5 (server -> client)
      Content type: APPLICATION DATA
      Version: TLS1.2
      Length: 281
      Inner content type: HANDSHAKE
      Message type: CertificateVerify
      Message Length: 260
        SigAlg:2052
        Signature Len:256
     Record 6 (server -> client)
      Content type: APPLICATION DATA
      Version: TLS1.2
      Length: 53
      Inner content type: HANDSHAKE
      Message type: Finished
      Message Length: 32
    
    Forwarded packet length = 1547
    
    depth=0 C = UK, O = OpenSSL Group, OU = FOR TESTING PURPOSES ONLY, CN = Test Server Cert
    verify error:num=20:unable to get local issuer certificate
    verify return:1
    depth=0 C = UK, O = OpenSSL Group, OU = FOR TESTING PURPOSES ONLY, CN = Test Server Cert
    verify error:num=21:unable to verify the first certificate
    verify return:1
    Received client packet
    Packet length = 64
    Processing flight 2
     Record 1 (client -> server)
      Content type: CCS
      Version: TLS1.2
      Length: 1
     Record 2 (client -> server)
      Content type: APPLICATION DATA
      Version: TLS1.2
      Length: 53
      Inner content type: HANDSHAKE
      Message type: Finished
      Message Length: 32
    
    Forwarded packet length = 65
    
    Received server packet
    Packet length = 224
    Processing flight 3
     Record 1 (server -> client)
      Content type: APPLICATION DATA
      Version: TLS1.2
      Length: 219
      Inner content type: HANDSHAKE
      Message type: NewSessionTicket
      Message Length: 198
    
    CONNECTED(00000003)
    ---
    Certificate chain
     0 s:C = UK, O = OpenSSL Group, OU = FOR TESTING PURPOSES ONLY, CN = Test Server Cert
       i:C = UK, O = OpenSSL Group, OU = FOR TESTING PURPOSES ONLY, CN = OpenSSL Test Intermediate CA
    ---
    Server certificate
    -----BEGIN CERTIFICATE-----
    MIID5zCCAs+gAwIBAgIJALnu1NlVpZ6zMA0GCSqGSIb3DQEBBQUAMHAxCzAJBgNV
    BAYTAlVLMRYwFAYDVQQKDA1PcGVuU1NMIEdyb3VwMSIwIAYDVQQLDBlGT1IgVEVT
    VElORyBQVVJQT1NFUyBPTkxZMSUwIwYDVQQDDBxPcGVuU1NMIFRlc3QgSW50ZXJt
    ZWRpYXRlIENBMB4XDTExMTIwODE0MDE0OFoXDTIxMTAxNjE0MDE0OFowZDELMAkG
    A1UEBhMCVUsxFjAUBgNVBAoMDU9wZW5TU0wgR3JvdXAxIjAgBgNVBAsMGUZPUiBU
    RVNUSU5HIFBVUlBPU0VTIE9OTFkxGTAXBgNVBAMMEFRlc3QgU2VydmVyIENlcnQw
    ggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDzhPOSNtyyRspmeuUpxfNJ
    KCLTuf7g3uQ4zu4iHOmRO5TQci+HhVlLZrHF9XqFXcIP0y4pWDbMSGuiorUmzmfi
    R7bfSdI/+qIQt8KXRH6HNG1t8ou0VSvWId5TS5Dq/er5ODUr9OaaDva7EquHIcMv
    vPQGuI+OEAcnleVCy9HVEIySrO4P3CNIicnGkwwiAud05yUAq/gPXBC1hTtmlPD7
    TVcGVSEiJdvzqqlgv02qedGrkki6GY4S7GjZxrrf7Foc2EP+51LJzwLQx3/JfrCU
    41NEWAsu/Sl0tQabXESN+zJ1pDqoZ3uHMgpQjeGiE0olr+YcsSW/tJmiU9OiAr8R
    AgMBAAGjgY8wgYwwDAYDVR0TAQH/BAIwADAOBgNVHQ8BAf8EBAMCBeAwLAYJYIZI
    AYb4QgENBB8WHU9wZW5TU0wgR2VuZXJhdGVkIENlcnRpZmljYXRlMB0GA1UdDgQW
    BBSCvM8AABPR9zklmifnr9LvIBturDAfBgNVHSMEGDAWgBQ2w2yI55X+sL3szj49
    hqshgYfa2jANBgkqhkiG9w0BAQUFAAOCAQEAqb1NV0B0/pbpK9Z4/bNjzPQLTRLK
    WnSNm/Jh5v0GEUOE/Beg7GNjNrmeNmqxAlpqWz9qoeoFZax+QBpIZYjROU3TS3fp
    yLsrnlr0CDQ5R7kCCDGa8dkXxemmpZZLbUCpW2Uoy8sAA4JjN9OtsZY7dvUXFgJ7
    vVNTRnI01ghknbtD+2SxSQd3CWF6QhcRMAzZJ1z1cbbwGDDzfvGFPzJ+Sq+zEPds
    xoVLLSetCiBc+40ZcDS5dV98h9XD7JMTQfxzA7mNGv73JoZJA6nFgj+ADSlJsY/t
    JBv+z1iQRueoh9Qeee+ZbRifPouCB8FDx+AltvHTANdAq0t/K3o+pplMVA==
    -----END CERTIFICATE-----
    subject=C = UK, O = OpenSSL Group, OU = FOR TESTING PURPOSES ONLY, CN = Test Server Cert
    
    issuer=C = UK, O = OpenSSL Group, OU = FOR TESTING PURPOSES ONLY, CN = OpenSSL Test Intermediate CA
    
    ---
    No client certificate CA names sent
    Peer signing digest: SHA256
    Peer signature type: RSA-PSS
    Server Temp Key: X25519, 253 bits
    ---
    SSL handshake has read 1547 bytes and written 365 bytes
    Verification error: unable to verify the first certificate
    ---
    New, TLSv1.3, Cipher is TLS13-AES-128-GCM-SHA256
    Server public key is 2048 bit
    Secure Renegotiation IS NOT supported
    Compression: NONE
    Expansion: NONE
    No ALPN negotiated
    Early data was not sent
    SSL-Session:
        Protocol  : TLSv1.3
        Cipher    : TLS13-AES-128-GCM-SHA256
        Session-ID: 
        Session-ID-ctx: 
        Master-Key: 000102030405060708090A0B0C0D0E0F101112131415161718191A1B1C1D1E1F
        PSK identity: None
        PSK identity hint: None
        SRP username: None
        Start Time: 1515617730
        Timeout   : 7200 (sec)
        Verify return code: 21 (unable to verify the first certificate)
        Extended master secret: no
    ---
    Forwarded packet length = 225
    
    DONE
    Received client packet
    Packet length = 27
    Processing flight 4
     Record 1 (client -> server)
      Content type: APPLICATION DATA
      Version: TLS1.2
      Length: 22
      Inner content type: APPLICATION DATA
      [ENCRYPTED APPLICATION DATA]
      [test
    ]
    
    Forwarded packet length = 28

>>> Same payload comes through...  but no CloseNotify alert!!!

    Connection closed
    Waiting for server process to close: 10698
    CONNECTION ESTABLISHED
    Protocol version: TLSv1.3
    Client cipher list: ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:DHE-RSA-AES256-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES256-SHA:ECDHE-RSA-AES256-SHA:DHE-RSA-AES256-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES128-SHA:DHE-RSA-AES128-SHA:AES256-GCM-SHA384:AES128-GCM-SHA256:TLS13-AES-256-GCM-SHA384:TLS13-CHACHA20-POLY1305-SHA256:TLS13-AES-128-GCM-SHA256:AES256-SHA256:AES128-SHA256:AES256-SHA:AES128-SHA:TLS_EMPTY_RENEGOTIATION_INFO_SCSV
    Ciphersuite: TLS13-AES-128-GCM-SHA256
    Signature Algorithms: RSA-PSS+SHA256
    No peer certificate
    Supported Elliptic Groups: X25519:P-256:P-521:P-384
    CONNECTION CLOSED
       1 items in the session cache
       0 client connects (SSL_connect())
       0 client renegotiates (SSL_connect())
       0 client connects that finished
       1 server accepts (SSL_accept())
       0 server renegotiates (SSL_accept())
       1 server accepts that finished
       0 session cache hits
       0 session cache misses
       0 session cache timeouts
       0 callback cache hits
       0 cache full overflows (128 allowed)
    Waiting for client process to close: 10699
    not ok 6 - PSS only sigalgs in TLSv1.3
    
    #   Failed test 'PSS only sigalgs in TLSv1.3'
    #   at ../test/recipes/70-test_sslsigalgs.t line 93.

And voil?, no CloseNotify alert and application data is irrelevant
because we don't use a session file => no success.

So I'm not yet exactly sure what happens here and why s_client
sometimes seems to not send a CloseNotify.

I'm currently looking at s_client.c's do_ssl_shutdown() and libssl's
ssl3_shutdown() to try and figure out what's going on there, but if
someone else (Matt?) has some ideas that can shed a light on this,
that would be great.

Cheers,
Richard

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

From bernd.edlinger at hotmail.de  Fri Jan 12 12:56:59 2018
From: bernd.edlinger at hotmail.de (Bernd Edlinger)
Date: Fri, 12 Jan 2018 12:56:59 +0000
Subject: [openssl-project] update on sporadic test failures
In-Reply-To: <20180112.104035.120285537026855126.levitte@openssl.org>
References: <AM5PR0701MB26575B69F2715E05DE948973E4110@AM5PR0701MB2657.eurprd07.prod.outlook.com>
 <AM5PR0701MB2657D7E464C15EBBD87FC356E4110@AM5PR0701MB2657.eurprd07.prod.outlook.com>
 <AM5PR0701MB2657A61AF60A41767572C316E4110@AM5PR0701MB2657.eurprd07.prod.outlook.com>
 <20180112.104035.120285537026855126.levitte@openssl.org>
Message-ID: <AM5PR0701MB265769F9AFA0241649A437DDE4170@AM5PR0701MB2657.eurprd07.prod.outlook.com>

Hi Richard,

I am not sure if the missing packet may be split between two sysreads,
if that is possible may depend on the linux version.

I used:

Linux version 3.13.0-139-lowlatency (buildd at lgw01-amd64-031) (gcc 
version 4.8.4 (Ubuntu 4.8.4-2ubuntu1~14.04.3) ) #188-Ubuntu SMP PREEMPT 
Tue Jan 9 15:04:54 UTC 2018


However, if I reduce the buffer space, the test fails every time:

diff --git a/util/perl/TLSProxy/Proxy.pm b/util/perl/TLSProxy/Proxy.pm
index 99b0ded..b436388 100644
--- a/util/perl/TLSProxy/Proxy.pm
+++ b/util/perl/TLSProxy/Proxy.pm
@@ -304,12 +304,12 @@ sub clientstart
          }
          foreach my $hand (@ready) {
              if ($hand == $server_sock) {
-                $server_sock->sysread($indata, 16384) or goto END;
+                $server_sock->sysread($indata, 16) or goto END;
                  $indata = $self->process_packet(1, $indata);
                  $client_sock->syswrite($indata);
                  $ctr = 0;
              } elsif ($hand == $client_sock) {
-                $client_sock->sysread($indata, 16384) or goto END;
+                $client_sock->sysread($indata, 16) or goto END;
                  $indata = $self->process_packet(0, $indata);
                  $server_sock->syswrite($indata);
                  $ctr = 0;

I could imagine that the system returns either a partial message
or both at once under stress.


Bernd.

From levitte at openssl.org  Fri Jan 12 13:26:50 2018
From: levitte at openssl.org (Richard Levitte)
Date: Fri, 12 Jan 2018 14:26:50 +0100 (CET)
Subject: [openssl-project] update on sporadic test failures
In-Reply-To: <AM5PR0701MB265769F9AFA0241649A437DDE4170@AM5PR0701MB2657.eurprd07.prod.outlook.com>
References: <AM5PR0701MB2657A61AF60A41767572C316E4110@AM5PR0701MB2657.eurprd07.prod.outlook.com>
 <20180112.104035.120285537026855126.levitte@openssl.org>
 <AM5PR0701MB265769F9AFA0241649A437DDE4170@AM5PR0701MB2657.eurprd07.prod.outlook.com>
Message-ID: <20180112.142650.742308145580346656.levitte@openssl.org>

In message <AM5PR0701MB265769F9AFA0241649A437DDE4170 at AM5PR0701MB2657.eurprd07.prod.outlook.com> on Fri, 12 Jan 2018 12:56:59 +0000, Bernd Edlinger <bernd.edlinger at hotmail.de> said:

bernd.edlinger> Hi Richard,
bernd.edlinger> 
bernd.edlinger> I am not sure if the missing packet may be split between two sysreads,
bernd.edlinger> if that is possible may depend on the linux version.
bernd.edlinger> 
bernd.edlinger> I used:
bernd.edlinger> 
bernd.edlinger> Linux version 3.13.0-139-lowlatency (buildd at lgw01-amd64-031) (gcc 
bernd.edlinger> version 4.8.4 (Ubuntu 4.8.4-2ubuntu1~14.04.3) ) #188-Ubuntu SMP PREEMPT 
bernd.edlinger> Tue Jan 9 15:04:54 UTC 2018
bernd.edlinger> 
bernd.edlinger> 
bernd.edlinger> However, if I reduce the buffer space, the test fails every time:
bernd.edlinger> 
bernd.edlinger> diff --git a/util/perl/TLSProxy/Proxy.pm b/util/perl/TLSProxy/Proxy.pm
bernd.edlinger> index 99b0ded..b436388 100644
bernd.edlinger> --- a/util/perl/TLSProxy/Proxy.pm
bernd.edlinger> +++ b/util/perl/TLSProxy/Proxy.pm
bernd.edlinger> @@ -304,12 +304,12 @@ sub clientstart
bernd.edlinger>           }
bernd.edlinger>           foreach my $hand (@ready) {
bernd.edlinger>               if ($hand == $server_sock) {
bernd.edlinger> -                $server_sock->sysread($indata, 16384) or goto END;
bernd.edlinger> +                $server_sock->sysread($indata, 16) or goto END;
bernd.edlinger>                   $indata = $self->process_packet(1, $indata);
bernd.edlinger>                   $client_sock->syswrite($indata);
bernd.edlinger>                   $ctr = 0;
bernd.edlinger>               } elsif ($hand == $client_sock) {
bernd.edlinger> -                $client_sock->sysread($indata, 16384) or goto END;
bernd.edlinger> +                $client_sock->sysread($indata, 16) or goto END;
bernd.edlinger>                   $indata = $self->process_packet(0, $indata);
bernd.edlinger>                   $server_sock->syswrite($indata);
bernd.edlinger>                   $ctr = 0;
bernd.edlinger> 
bernd.edlinger> I could imagine that the system returns either a partial message
bernd.edlinger> or both at once under stress.

Unfortunately, that's mostly a red herring, as the proxy message
unpacker doesn't react well with partial messages:

    Received server packet
    Packet length = 256
    Processing flight 3
     Record 1 (server -> client)
    Use of uninitialized value within %record_type in concatenation (.) or string at /home/levitte/gitwrk/openssl.net/official/_build/test/../../master/util/perl/TLSProxy/Record.pm line 89.
      Content type: 
    Use of uninitialized value within %tls_version in concatenation (.) or string at /home/levitte/gitwrk/openssl.net/official/_build/test/../../master/util/perl/TLSProxy/Record.pm line 90.
      Version: 
      Length: 1720 (expected), 251 (actual)
    
    Forwarded packet length = 256

I mean sure, it will forward the data it got in (I think), but the
test filters won't run properly, so tests may fail because of that

Something I worry about is that ' or goto END;', 'cause I see the
possibility that if one end closes but not the other, the proxy may
miss in some messages.  That may be the main reason why we don't see
that CloseNotify alert...  'cause say that the server stopped
communication for whatever reason, then $server_sock->sysread will
return undef, and we will jump out of that read/write loop and
possibly disregard one last message from the client...

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

From levitte at openssl.org  Fri Jan 12 13:48:23 2018
From: levitte at openssl.org (Richard Levitte)
Date: Fri, 12 Jan 2018 14:48:23 +0100 (CET)
Subject: [openssl-project] update on sporadic test failures
In-Reply-To: <AM5PR0701MB265769F9AFA0241649A437DDE4170@AM5PR0701MB2657.eurprd07.prod.outlook.com>
References: <AM5PR0701MB2657A61AF60A41767572C316E4110@AM5PR0701MB2657.eurprd07.prod.outlook.com>
 <20180112.104035.120285537026855126.levitte@openssl.org>
 <AM5PR0701MB265769F9AFA0241649A437DDE4170@AM5PR0701MB2657.eurprd07.prod.outlook.com>
Message-ID: <20180112.144823.754975592782949338.levitte@openssl.org>

So with regards to the read/write loop in TLSProxy::Proxy, may I ask
that you try the attached patch, independently of my previous patch?

For some reason, I cannot seem to get things to fail on my machine for
the moment, with or without patch...

Cheers,
Richard

-- 
Richard Levitte         levitte at openssl.org
OpenSSL Project         http://www.openssl.org/~levitte/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: TLSProxy.diff
Type: text/x-patch
Size: 2517 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-project/attachments/20180112/809ccea4/attachment.bin>

From bernd.edlinger at hotmail.de  Fri Jan 12 13:58:10 2018
From: bernd.edlinger at hotmail.de (Bernd Edlinger)
Date: Fri, 12 Jan 2018 13:58:10 +0000
Subject: [openssl-project] update on sporadic test failures
In-Reply-To: <20180112.144823.754975592782949338.levitte@openssl.org>
References: <AM5PR0701MB2657A61AF60A41767572C316E4110@AM5PR0701MB2657.eurprd07.prod.outlook.com>
 <20180112.104035.120285537026855126.levitte@openssl.org>
 <AM5PR0701MB265769F9AFA0241649A437DDE4170@AM5PR0701MB2657.eurprd07.prod.outlook.com>
 <20180112.144823.754975592782949338.levitte@openssl.org>
Message-ID: <AM5PR0701MB265775C33EEE5A6E4BB14773E4170@AM5PR0701MB2657.eurprd07.prod.outlook.com>

On 01/12/18 14:48, Richard Levitte wrote:
> So with regards to the read/write loop in TLSProxy::Proxy, may I ask
> that you try the attached patch, independently of my previous patch?
> 
> For some reason, I cannot seem to get things to fail on my machine for
> the moment, with or without patch...
> 
Sure, test with your patch is running now in a loop,
I will keep you informed when something interesting happens here...

It is also very intermittent here, must have been luck when I
managed to reproduce 3 times in a row with <400 iterations,
today it took 2482 iterations.


Bernd.

From bernd.edlinger at hotmail.de  Fri Jan 12 15:47:00 2018
From: bernd.edlinger at hotmail.de (Bernd Edlinger)
Date: Fri, 12 Jan 2018 15:47:00 +0000
Subject: [openssl-project] update on sporadic test failures
In-Reply-To: <53c36778-f4d0-66d2-c292-1d7d403c99ce@hotmail.de>
References: <AM5PR0701MB2657A61AF60A41767572C316E4110@AM5PR0701MB2657.eurprd07.prod.outlook.com>
 <20180112.104035.120285537026855126.levitte@openssl.org>
 <AM5PR0701MB265769F9AFA0241649A437DDE4170@AM5PR0701MB2657.eurprd07.prod.outlook.com>
 <20180112.144823.754975592782949338.levitte@openssl.org>
 <53c36778-f4d0-66d2-c292-1d7d403c99ce@hotmail.de>
Message-ID: <AM5PR0701MB265733EDD9CE8A9A7DA4EBB2E4170@AM5PR0701MB2657.eurprd07.prod.outlook.com>

Hi,


N=0; while make test TESTS=test_sslsigalgs V=1 >test$N.log; do 
N=$((N+1)); done; echo count=$N
make[1]: *** [_tests] Error 1
make: *** [tests] Fehler 2
count=4657


I wonder where the "[tset" comes from?

I have also seen it in Ben's test results,
when the test fails.

You said the plain text is always test.

grep tset test*.log shows that 81 out of 4657 test runs have this.


I have attached the last working and first failing test runs with
your patch.


Bernd.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: test4656.log
Type: text/x-log
Size: 99591 bytes
Desc: test4656.log
URL: <http://mta.openssl.org/pipermail/openssl-project/attachments/20180112/a82c4d94/attachment-0002.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: test4657.log
Type: text/x-log
Size: 92318 bytes
Desc: test4657.log
URL: <http://mta.openssl.org/pipermail/openssl-project/attachments/20180112/a82c4d94/attachment-0003.bin>

From kurt at roeckx.be  Fri Jan 12 17:54:19 2018
From: kurt at roeckx.be (Kurt Roeckx)
Date: Fri, 12 Jan 2018 18:54:19 +0100
Subject: [openssl-project] update on sporadic test failures
In-Reply-To: <20180110181329.GH72574@kduck.kaduk.org>
References: <20180110181329.GH72574@kduck.kaduk.org>
Message-ID: <20180112175418.GA21241@roeckx.be>

On Wed, Jan 10, 2018 at 12:13:29PM -0600, Benjamin Kaduk wrote:
> I've been running 'make test' in a loop to try to reproduce the
> sporadic failures that we've been seeing in the build farms.

I want to remind you of github issue #4650, which might be
related. For some reason debian-hurd seems to be very good at
reproducing such issues.

I'm also not sure why this is discussed here. Why is this for
instance not in a github issue?


Kurt


From bernd.edlinger at hotmail.de  Fri Jan 12 18:15:15 2018
From: bernd.edlinger at hotmail.de (Bernd Edlinger)
Date: Fri, 12 Jan 2018 18:15:15 +0000
Subject: [openssl-project] update on sporadic test failures
In-Reply-To: <20180112175418.GA21241@roeckx.be>
References: <20180110181329.GH72574@kduck.kaduk.org>
 <20180112175418.GA21241@roeckx.be>
Message-ID: <AM5PR0701MB2657D722F53DE418BB284E7AE4170@AM5PR0701MB2657.eurprd07.prod.outlook.com>

On 01/12/18 18:54, Kurt Roeckx wrote:
> On Wed, Jan 10, 2018 at 12:13:29PM -0600, Benjamin Kaduk wrote:
>> I've been running 'make test' in a loop to try to reproduce the
>> sporadic failures that we've been seeing in the build farms.
> 
> I want to remind you of github issue #4650, which might be
> related. For some reason debian-hurd seems to be very good at
> reproducing such issues.
> 
> I'm also not sure why this is discussed here. Why is this for
> instance not in a github issue?
> 
> 



Yes, you are right, just one last message, in this thread...

I think this will give us some insight in the nature of the
problem.  Next will step will likely be a pull-request.


I continued testing with Richard's patch, but this time
I did this:

N=0; while strace -f -o test$N.trace make test TESTS=test_sslsigalgs V=1 
 >test$N.log; do N=$((N+1)); done; echo count=$N
make[1]: *** [_tests] Error 1
make: *** [tests] Fehler 2
count=1140


This time something slightly different happened, a SIGPIPE here:
                  $indata = $self->process_packet(1, $indata);
                  $client_sock->syswrite($indata);
                  $ctr = 0;

which happens because the client exited already.

So I have the trace output showing what is going on when the
test fails.


Bernd.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: test1140.trace.bz2
Type: application/x-bzip
Size: 274856 bytes
Desc: test1140.trace.bz2
URL: <http://mta.openssl.org/pipermail/openssl-project/attachments/20180112/16b940bc/attachment-0002.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: test1140.log
Type: text/x-log
Size: 100199 bytes
Desc: test1140.log
URL: <http://mta.openssl.org/pipermail/openssl-project/attachments/20180112/16b940bc/attachment-0003.bin>

From kaduk at mit.edu  Fri Jan 12 18:24:23 2018
From: kaduk at mit.edu (Benjamin Kaduk)
Date: Fri, 12 Jan 2018 12:24:23 -0600
Subject: [openssl-project] update on sporadic test failures
In-Reply-To: <20180112175418.GA21241@roeckx.be>
References: <20180110181329.GH72574@kduck.kaduk.org>
 <20180112175418.GA21241@roeckx.be>
Message-ID: <20180112182422.GX72574@mit.edu>

On Fri, Jan 12, 2018 at 06:54:19PM +0100, Kurt Roeckx wrote:
> 
> I'm also not sure why this is discussed here. Why is this for
> instance not in a github issue?

In my head it was a continuation of the thread on -committers that
started as a forward of a build failure log from -commits.  But
considered de novo, yes, a github issue is better.

-Ben

From kaduk at mit.edu  Fri Jan 12 20:54:06 2018
From: kaduk at mit.edu (Benjamin Kaduk)
Date: Fri, 12 Jan 2018 14:54:06 -0600
Subject: [openssl-project] update on sporadic test failures
In-Reply-To: <AM5PR0701MB265733EDD9CE8A9A7DA4EBB2E4170@AM5PR0701MB2657.eurprd07.prod.outlook.com>
References: <AM5PR0701MB2657A61AF60A41767572C316E4110@AM5PR0701MB2657.eurprd07.prod.outlook.com>
 <20180112.104035.120285537026855126.levitte@openssl.org>
 <AM5PR0701MB265769F9AFA0241649A437DDE4170@AM5PR0701MB2657.eurprd07.prod.outlook.com>
 <20180112.144823.754975592782949338.levitte@openssl.org>
 <53c36778-f4d0-66d2-c292-1d7d403c99ce@hotmail.de>
 <AM5PR0701MB265733EDD9CE8A9A7DA4EBB2E4170@AM5PR0701MB2657.eurprd07.prod.outlook.com>
Message-ID: <20180112205406.GB72574@mit.edu>

On Fri, Jan 12, 2018 at 03:47:00PM +0000, Bernd Edlinger wrote:
> Hi,
> 
> 
> I wonder where the "[tset" comes from?
> 
> I have also seen it in Ben's test results,
> when the test fails.

This is the s_server -rev option; "tset" is the reversed version of
"test".

-Ben

From matt at openssl.org  Mon Jan 15 10:08:07 2018
From: matt at openssl.org (Matt Caswell)
Date: Mon, 15 Jan 2018 10:08:07 +0000
Subject: [openssl-project] update on sporadic test failures
In-Reply-To: <AM5PR0701MB265733EDD9CE8A9A7DA4EBB2E4170@AM5PR0701MB2657.eurprd07.prod.outlook.com>
References: <AM5PR0701MB2657A61AF60A41767572C316E4110@AM5PR0701MB2657.eurprd07.prod.outlook.com>
 <20180112.104035.120285537026855126.levitte@openssl.org>
 <AM5PR0701MB265769F9AFA0241649A437DDE4170@AM5PR0701MB2657.eurprd07.prod.outlook.com>
 <20180112.144823.754975592782949338.levitte@openssl.org>
 <53c36778-f4d0-66d2-c292-1d7d403c99ce@hotmail.de>
 <AM5PR0701MB265733EDD9CE8A9A7DA4EBB2E4170@AM5PR0701MB2657.eurprd07.prod.outlook.com>
Message-ID: <daf53ab8-9be9-92bb-328f-41d44adf0183@openssl.org>



On 12/01/18 15:47, Bernd Edlinger wrote:
> Hi,
> 
> 
> N=0; while make test TESTS=test_sslsigalgs V=1 >test$N.log; do 
> N=$((N+1)); done; echo count=$N
> make[1]: *** [_tests] Error 1
> make: *** [tests] Fehler 2
> count=4657
> 
> 
> I wonder where the "[tset" comes from?
> 

Because s_server is started with the "-rev" option. This causes s_server
to echo back anything it receives, but reverses it.

Matt


> I have also seen it in Ben's test results,
> when the test fails.
> 
> You said the plain text is always test.
> 
> grep tset test*.log shows that 81 out of 4657 test runs have this.
> 
> 
> I have attached the last working and first failing test runs with
> your patch.
> 
> 
> Bernd.
> 
> 
> 
> _______________________________________________
> openssl-project mailing list
> openssl-project at openssl.org
> https://mta.openssl.org/mailman/listinfo/openssl-project
> 

From matt at openssl.org  Mon Jan 15 14:43:32 2018
From: matt at openssl.org (Matt Caswell)
Date: Mon, 15 Jan 2018 14:43:32 +0000
Subject: [openssl-project] Unable to start up proxy
Message-ID: <d1183b43-014e-ded9-a4b0-2e1e4b4b29c3@openssl.org>

We seem to be getting a lot of these errors from TLSProxy in the
run-checker builds:

../../openssl/test/recipes/70-test_sslmessages.t ...... skipped: Unable
to start up Proxy for tests

Could the various changes we've been making in this area have caused this?

Matt

From mark at awe.com  Mon Jan 15 15:07:00 2018
From: mark at awe.com (Mark J Cox)
Date: Mon, 15 Jan 2018 15:07:00 +0000
Subject: [openssl-project] Simplifying the security policy
Message-ID: <CABU6YOZRGE3i9VmLmiAmynN+1LvHmvLZFCKTerPT9YmENVPYiA@mail.gmail.com>

At our face to face we took a look at the security policy and noticed
that it contained a lot of background details of why we decided on the
policy that we did (in light mostly of the issues back in 2014) as
well as a bit of repeated and redundant information.  I've taken some
time to simplify it, clean it up, and remove the redundant sections
with the intention of not changing any of the actual policy.   See
attached draft, which I'll run a vote on if there are no silly
mistakes or problems.

https://www.openssl.org/policies/secpolicy.html

Detailed changes:
- removed introductory wordy paragraphs
- how to report issues is already covered on another page so just
replace with link
- consolidate who we tell about issues into new 'triage' section (it
was in 3 different places) explain why we work with those folks
- take out most of the background section.  Where the background forms
part of our reasons for doing something include them in a new section
'principles' at the end with the same wording.
-- removed "the more people you tell" leak statement
-- consolidated how we benefit from prenotifying people into earlier section
-- removed competitive phrases
-- removed why we don't run our own prenotification list and who we've
tired to use in the past
- no changes to severity wording
- simplify prenotification section wording without changing what we do
or who we tell

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

From rsalz at akamai.com  Mon Jan 15 15:25:21 2018
From: rsalz at akamai.com (Salz, Rich)
Date: Mon, 15 Jan 2018 15:25:21 +0000
Subject: [openssl-project] Simplifying the security policy
In-Reply-To: <CABU6YOZRGE3i9VmLmiAmynN+1LvHmvLZFCKTerPT9YmENVPYiA@mail.gmail.com>
References: <CABU6YOZRGE3i9VmLmiAmynN+1LvHmvLZFCKTerPT9YmENVPYiA@mail.gmail.com>
Message-ID: <A0D4E63A-A92B-421B-B559-49F30E954C2F@akamai.com>

I like your changes, except that I was  confused by the multiple references to ?timing channel? attacks and had a hard time telling which is which, and why.



From mark at awe.com  Mon Jan 15 16:07:13 2018
From: mark at awe.com (Mark J Cox)
Date: Mon, 15 Jan 2018 16:07:13 +0000
Subject: [openssl-project] Simplifying the security policy
In-Reply-To: <A0D4E63A-A92B-421B-B559-49F30E954C2F@akamai.com>
References: <CABU6YOZRGE3i9VmLmiAmynN+1LvHmvLZFCKTerPT9YmENVPYiA@mail.gmail.com>
 <A0D4E63A-A92B-421B-B559-49F30E954C2F@akamai.com>
Message-ID: <CABU6YOZ6wheYrosxXXauiu7bNsa=R9RDXF4PM-rz6jyoWLgchA@mail.gmail.com>

Thanks for reviewing, I didn't change the wording for any of the
definitions of severities from the original policy because those could
change how we rate issue which is a more substantive change to the
policy for later.

Mark

On Mon, Jan 15, 2018 at 3:25 PM, Salz, Rich <rsalz at akamai.com> wrote:
> I like your changes, except that I was  confused by the multiple references to ?timing channel? attacks and had a hard time telling which is which, and why.
>
>
> _______________________________________________
> openssl-project mailing list
> openssl-project at openssl.org
> https://mta.openssl.org/mailman/listinfo/openssl-project

From paul.dale at oracle.com  Mon Jan 15 20:47:57 2018
From: paul.dale at oracle.com (Paul Dale)
Date: Mon, 15 Jan 2018 12:47:57 -0800 (PST)
Subject: [openssl-project] Simplifying the security policy
In-Reply-To: <CABU6YOZRGE3i9VmLmiAmynN+1LvHmvLZFCKTerPT9YmENVPYiA@mail.gmail.com>
References: <CABU6YOZRGE3i9VmLmiAmynN+1LvHmvLZFCKTerPT9YmENVPYiA@mail.gmail.com>
Message-ID: <8037b410-dc4e-47e8-ab04-f80034e18220@default>

Looks good here.

Might "hard to exploit timing (side channel) attacks" be better as "hard to exploit side channel attacks"?  I.e. remove the "timing".
Also "those that produce a a general purpose" could do with one less "a".


Pauli
-- 
Oracle
Dr Paul Dale | Cryptographer | Network Security & Encryption 
Phone +61 7 3031 7217
Oracle Australia

-----Original Message-----
From: Mark J Cox [mailto:mark at awe.com] 
Sent: Tuesday, 16 January 2018 1:07 AM
To: openssl-project at openssl.org
Subject: [openssl-project] Simplifying the security policy

At our face to face we took a look at the security policy and noticed that it contained a lot of background details of why we decided on the policy that we did (in light mostly of the issues back in 2014) as well as a bit of repeated and redundant information.  I've taken some time to simplify it, clean it up, and remove the redundant sections
with the intention of not changing any of the actual policy.   See
attached draft, which I'll run a vote on if there are no silly mistakes or problems.

https://www.openssl.org/policies/secpolicy.html

Detailed changes:
- removed introductory wordy paragraphs
- how to report issues is already covered on another page so just replace with link
- consolidate who we tell about issues into new 'triage' section (it was in 3 different places) explain why we work with those folks
- take out most of the background section.  Where the background forms part of our reasons for doing something include them in a new section 'principles' at the end with the same wording.
-- removed "the more people you tell" leak statement
-- consolidated how we benefit from prenotifying people into earlier section
-- removed competitive phrases
-- removed why we don't run our own prenotification list and who we've tired to use in the past
- no changes to severity wording
- simplify prenotification section wording without changing what we do or who we tell

Mark

From rsalz at akamai.com  Thu Jan 18 02:31:01 2018
From: rsalz at akamai.com (Salz, Rich)
Date: Thu, 18 Jan 2018 02:31:01 +0000
Subject: [openssl-project] using the copyright script
Message-ID: <8CEAB400-C0A9-4B9E-B4B0-5718407D56D3@akamai.com>

Before each release we should do something like this:
                ; git log '--since=2018-01-01' --name-only --oneline | xargs ./util/openssl-update-copyright
make sense?

But I get funky output (try the log command piped through sort), any ideas?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-project/attachments/20180118/0e8802e4/attachment.html>

From levitte at openssl.org  Thu Jan 18 09:19:44 2018
From: levitte at openssl.org (Richard Levitte)
Date: Thu, 18 Jan 2018 10:19:44 +0100 (CET)
Subject: [openssl-project] using the copyright script
In-Reply-To: <8CEAB400-C0A9-4B9E-B4B0-5718407D56D3@akamai.com>
References: <8CEAB400-C0A9-4B9E-B4B0-5718407D56D3@akamai.com>
Message-ID: <20180118.101944.2285781391700483966.levitte@openssl.org>

In message <8CEAB400-C0A9-4B9E-B4B0-5718407D56D3 at akamai.com> on Thu, 18 Jan 2018 02:31:01 +0000, "Salz, Rich" <rsalz at akamai.com> said:

rsalz> Before each release we should do something like this:
rsalz> 
rsalz> ; git log '--since=2018-01-01' --name-only --oneline | xargs ./util/openssl-update-copyright
rsalz> 
rsalz> make sense?

Nope.

rsalz> But I get funky output (try the log command piped through sort), any ideas?

That's because you do get one line commit logs mingled with the file
names.

Remember that 'git diff' is a porcelain command, i.e. it's geared for
humans, not for scripts.  For this kind of thing (like all scripting),
it's better (safer!) to go for the plumbing commands:

git diff-tree -r --name-only `git rev-list -1 --before=2018-01-01 HEAD`..HEAD \
    | xargs ./util/openssl-update-copyright

Cheers,
Richard

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

From matt at openssl.org  Thu Jan 18 11:44:22 2018
From: matt at openssl.org (Matt Caswell)
Date: Thu, 18 Jan 2018 11:44:22 +0000
Subject: [openssl-project] Fwd: [openssl-commits] FAILED build of OpenSSL
 branch OpenSSL_1_1_0-stable with options -d --strict-warnings no-dgram
In-Reply-To: <1516275755.353922.25293.nullmailer@run.openssl.org>
References: <1516275755.353922.25293.nullmailer@run.openssl.org>
Message-ID: <7953c900-c709-b662-6f29-3d7f96670e6c@openssl.org>

We're still getting lots of spurious failures from TLSProxy in run-checker:

../../openssl/test/recipes/70-test_sslcbcpadding.t .... skipped: Unable
to start up Proxy for tests
../../openssl/test/recipes/70-test_sslcertstatus.t .... skipped: Unable
to start up Proxy for tests
../../openssl/test/recipes/70-test_sslextension.t ..... ok
../../openssl/test/recipes/70-test_sslmessages.t ...... skipped: Unable
to start up Proxy for tests
../../openssl/test/recipes/70-test_sslrecords.t ....... Dubious, test
returned 1 (wstat 256, 0x100)
Failed 1/11 subtests ../../openssl/test/recipes/70-test_sslsessiontick.t
... skipped: Unable to start up Proxy for tests
../../openssl/test/recipes/70-test_sslskewith0p.t ..... skipped: Unable
to start up Proxy for tests
../../openssl/test/recipes/70-test_sslvertol.t ........ ok
../../openssl/test/recipes/70-test_tlsextms.t ......... Dubious, test
returned 3 (wstat 768, 0x300)


Grrrr. WTF?

Matt


From levitte at openssl.org  Thu Jan 18 13:09:26 2018
From: levitte at openssl.org (Richard Levitte)
Date: Thu, 18 Jan 2018 14:09:26 +0100 (CET)
Subject: [openssl-project] Fwd: [openssl-commits] FAILED build of
 OpenSSL branch OpenSSL_1_1_0-stable with options -d --strict-warnings
 no-dgram
In-Reply-To: <7953c900-c709-b662-6f29-3d7f96670e6c@openssl.org>
References: <1516275755.353922.25293.nullmailer@run.openssl.org>
 <7953c900-c709-b662-6f29-3d7f96670e6c@openssl.org>
Message-ID: <20180118.140926.1655380191337487200.levitte@openssl.org>

Darnit...  I'll have a look

In message <7953c900-c709-b662-6f29-3d7f96670e6c at openssl.org> on Thu, 18 Jan 2018 11:44:22 +0000, Matt Caswell <matt at openssl.org> said:

matt> We're still getting lots of spurious failures from TLSProxy in run-checker:
matt> 
matt> ../../openssl/test/recipes/70-test_sslcbcpadding.t .... skipped: Unable
matt> to start up Proxy for tests
matt> ../../openssl/test/recipes/70-test_sslcertstatus.t .... skipped: Unable
matt> to start up Proxy for tests
matt> ../../openssl/test/recipes/70-test_sslextension.t ..... ok
matt> ../../openssl/test/recipes/70-test_sslmessages.t ...... skipped: Unable
matt> to start up Proxy for tests
matt> ../../openssl/test/recipes/70-test_sslrecords.t ....... Dubious, test
matt> returned 1 (wstat 256, 0x100)
matt> Failed 1/11 subtests ../../openssl/test/recipes/70-test_sslsessiontick.t
matt> ... skipped: Unable to start up Proxy for tests
matt> ../../openssl/test/recipes/70-test_sslskewith0p.t ..... skipped: Unable
matt> to start up Proxy for tests
matt> ../../openssl/test/recipes/70-test_sslvertol.t ........ ok
matt> ../../openssl/test/recipes/70-test_tlsextms.t ......... Dubious, test
matt> returned 3 (wstat 768, 0x300)
matt> 
matt> 
matt> Grrrr. WTF?
matt> 
matt> Matt
matt> 
matt> _______________________________________________
matt> openssl-project mailing list
matt> openssl-project at openssl.org
matt> https://mta.openssl.org/mailman/listinfo/openssl-project
matt> 

From rsalz at akamai.com  Thu Jan 18 13:18:54 2018
From: rsalz at akamai.com (Salz, Rich)
Date: Thu, 18 Jan 2018 13:18:54 +0000
Subject: [openssl-project] using the copyright script
In-Reply-To: <20180118.101944.2285781391700483966.levitte@openssl.org>
References: <8CEAB400-C0A9-4B9E-B4B0-5718407D56D3@akamai.com>
 <20180118.101944.2285781391700483966.levitte@openssl.org>
Message-ID: <6BC008D3-4BEF-4B6E-9689-D730FB3A1727@akamai.com>

? That's because you do get one line commit logs mingled with the file
    names.
    
Seems like a bug in the ?name-only flag to *git log* ?

? git diff-tree -r --name-only `git rev-list -1 --before=2018-01-01 HEAD`..HEAD \
        | xargs ./util/openssl-update-copyright

Whatever works is fine with me.  Want to update the release how-to or should I?



From levitte at openssl.org  Thu Jan 18 13:40:31 2018
From: levitte at openssl.org (Richard Levitte)
Date: Thu, 18 Jan 2018 14:40:31 +0100 (CET)
Subject: [openssl-project] Fwd: [openssl-commits] FAILED build of
 OpenSSL branch OpenSSL_1_1_0-stable with options -d --strict-warnings
 no-dgram
In-Reply-To: <7953c900-c709-b662-6f29-3d7f96670e6c@openssl.org>
References: <1516275755.353922.25293.nullmailer@run.openssl.org>
 <7953c900-c709-b662-6f29-3d7f96670e6c@openssl.org>
Message-ID: <20180118.144031.891045670865089619.levitte@openssl.org>

Oh, I see what's happening...

Here's how things are layed out (crontab):

  2 22  *   *  0-4   (set -x; cd $HOME/run-checker && bash ./run-checker.sh) >> $HOME/run-checker.cron.log 2>&1
  2 10  *   *  1-5   (set -x; cd $HOME/run-checker-1.1.0 && bash ./run-checker.sh) >> $HOME/run-checker-1.1.0.cron.log 2>&1

The trouble is this (current listing):

    openssl at run:~$ ls -ltr ~/run-checker
    ...
    -rw-rw-r--  1 openssl openssl  14644664 Jan 17 22:09 default.tar.xz
    -rw-rw-r--  1 openssl openssl  14632920 Jan 17 22:17 no-afalgeng.tar.xz
    ...
    -rw-rw-r--  1 openssl openssl  14637020 Jan 18 13:30 no-tls.tar.xz
    drwxrwxr-x 12 openssl openssl      4096 Jan 18 13:31 no-ssl3
    openssl at run:~$ ls -ltr ~/run-checker-1.1.0
    ...
    -rw-rw-r--  1 openssl openssl   7599764 Jan 18 10:05 default.tar.xz
    -rw-rw-r--  1 openssl openssl   7583800 Jan 18 10:10 no-afalgeng.tar.xz
    ...
    -rw-rw-r--  1 openssl openssl   7600464 Jan 18 13:33 no-md2.tar.xz
    drwxrwxr-x 12 openssl openssl      4096 Jan 18 13:34 no-msan

The last line in each listing (directory) indicates what job is
currently running (those directories are gzipped at the end of each
job).

Unfortunately, there's no barrier between these runs, so when it comes
to things like network ports, they trample all over each other.  Now,
TLSProxy uses hard coded ports, you can see how that gets problematic.

So I think the option is to jail the two run-checkers, and from recent
reading, I understand that docker can be used for that kind of thing.
Trouble is, I've never ever played with docker.  I'm willing to
experiment, but it will probably be done much quicker if someone can
give me some quick'n'easy instructions.

We run this on a Ubuntu 16.04 machine, FYI.

In the mean time, I'm turning off run-checker, as these reports are
disruptive and not useful at all.

In message <7953c900-c709-b662-6f29-3d7f96670e6c at openssl.org> on Thu, 18 Jan 2018 11:44:22 +0000, Matt Caswell <matt at openssl.org> said:

matt> We're still getting lots of spurious failures from TLSProxy in run-checker:
matt> 
matt> ../../openssl/test/recipes/70-test_sslcbcpadding.t .... skipped: Unable
matt> to start up Proxy for tests
matt> ../../openssl/test/recipes/70-test_sslcertstatus.t .... skipped: Unable
matt> to start up Proxy for tests
matt> ../../openssl/test/recipes/70-test_sslextension.t ..... ok
matt> ../../openssl/test/recipes/70-test_sslmessages.t ...... skipped: Unable
matt> to start up Proxy for tests
matt> ../../openssl/test/recipes/70-test_sslrecords.t ....... Dubious, test
matt> returned 1 (wstat 256, 0x100)
matt> Failed 1/11 subtests ../../openssl/test/recipes/70-test_sslsessiontick.t
matt> ... skipped: Unable to start up Proxy for tests
matt> ../../openssl/test/recipes/70-test_sslskewith0p.t ..... skipped: Unable
matt> to start up Proxy for tests
matt> ../../openssl/test/recipes/70-test_sslvertol.t ........ ok
matt> ../../openssl/test/recipes/70-test_tlsextms.t ......... Dubious, test
matt> returned 3 (wstat 768, 0x300)
matt> 
matt> 
matt> Grrrr. WTF?
matt> 
matt> Matt
matt> 
matt> _______________________________________________
matt> openssl-project mailing list
matt> openssl-project at openssl.org
matt> https://mta.openssl.org/mailman/listinfo/openssl-project
matt> 

From matt at openssl.org  Thu Jan 18 13:48:58 2018
From: matt at openssl.org (Matt Caswell)
Date: Thu, 18 Jan 2018 13:48:58 +0000
Subject: [openssl-project] Fwd: [openssl-commits] FAILED build of
 OpenSSL branch OpenSSL_1_1_0-stable with options -d --strict-warnings
 no-dgram
In-Reply-To: <20180118.144031.891045670865089619.levitte@openssl.org>
References: <1516275755.353922.25293.nullmailer@run.openssl.org>
 <7953c900-c709-b662-6f29-3d7f96670e6c@openssl.org>
 <20180118.144031.891045670865089619.levitte@openssl.org>
Message-ID: <684f6ef0-f626-72fe-46de-a304ca1f858f@openssl.org>



On 18/01/18 13:40, Richard Levitte wrote:
> Oh, I see what's happening...
> 
> Here's how things are layed out (crontab):
> 
>   2 22  *   *  0-4   (set -x; cd $HOME/run-checker && bash ./run-checker.sh) >> $HOME/run-checker.cron.log 2>&1
>   2 10  *   *  1-5   (set -x; cd $HOME/run-checker-1.1.0 && bash ./run-checker.sh) >> $HOME/run-checker-1.1.0.cron.log 2>&1
> 
> The trouble is this (current listing):
> 
>     openssl at run:~$ ls -ltr ~/run-checker
>     ...
>     -rw-rw-r--  1 openssl openssl  14644664 Jan 17 22:09 default.tar.xz
>     -rw-rw-r--  1 openssl openssl  14632920 Jan 17 22:17 no-afalgeng.tar.xz
>     ...
>     -rw-rw-r--  1 openssl openssl  14637020 Jan 18 13:30 no-tls.tar.xz
>     drwxrwxr-x 12 openssl openssl      4096 Jan 18 13:31 no-ssl3
>     openssl at run:~$ ls -ltr ~/run-checker-1.1.0
>     ...
>     -rw-rw-r--  1 openssl openssl   7599764 Jan 18 10:05 default.tar.xz
>     -rw-rw-r--  1 openssl openssl   7583800 Jan 18 10:10 no-afalgeng.tar.xz
>     ...
>     -rw-rw-r--  1 openssl openssl   7600464 Jan 18 13:33 no-md2.tar.xz
>     drwxrwxr-x 12 openssl openssl      4096 Jan 18 13:34 no-msan
> 
> The last line in each listing (directory) indicates what job is
> currently running (those directories are gzipped at the end of each
> job).
> 
> Unfortunately, there's no barrier between these runs, so when it comes
> to things like network ports, they trample all over each other.  Now,
> TLSProxy uses hard coded ports, you can see how that gets problematic.
> 
> So I think the option is to jail the two run-checkers, and from recent
> reading, I understand that docker can be used for that kind of thing.
> Trouble is, I've never ever played with docker.  I'm willing to
> experiment, but it will probably be done much quicker if someone can
> give me some quick'n'easy instructions.
> 
> We run this on a Ubuntu 16.04 machine, FYI.
> 
> In the mean time, I'm turning off run-checker, as these reports are
> disruptive and not useful at all.

Why not just switch off the 1.1.0 run-checker for now?

Matt

> 
> In message <7953c900-c709-b662-6f29-3d7f96670e6c at openssl.org> on Thu, 18 Jan 2018 11:44:22 +0000, Matt Caswell <matt at openssl.org> said:
> 
> matt> We're still getting lots of spurious failures from TLSProxy in run-checker:
> matt> 
> matt> ../../openssl/test/recipes/70-test_sslcbcpadding.t .... skipped: Unable
> matt> to start up Proxy for tests
> matt> ../../openssl/test/recipes/70-test_sslcertstatus.t .... skipped: Unable
> matt> to start up Proxy for tests
> matt> ../../openssl/test/recipes/70-test_sslextension.t ..... ok
> matt> ../../openssl/test/recipes/70-test_sslmessages.t ...... skipped: Unable
> matt> to start up Proxy for tests
> matt> ../../openssl/test/recipes/70-test_sslrecords.t ....... Dubious, test
> matt> returned 1 (wstat 256, 0x100)
> matt> Failed 1/11 subtests ../../openssl/test/recipes/70-test_sslsessiontick.t
> matt> ... skipped: Unable to start up Proxy for tests
> matt> ../../openssl/test/recipes/70-test_sslskewith0p.t ..... skipped: Unable
> matt> to start up Proxy for tests
> matt> ../../openssl/test/recipes/70-test_sslvertol.t ........ ok
> matt> ../../openssl/test/recipes/70-test_tlsextms.t ......... Dubious, test
> matt> returned 3 (wstat 768, 0x300)
> matt> 
> matt> 
> matt> Grrrr. WTF?
> matt> 
> matt> Matt
> matt> 
> matt> _______________________________________________
> matt> openssl-project mailing list
> matt> openssl-project at openssl.org
> matt> https://mta.openssl.org/mailman/listinfo/openssl-project
> matt> 
> _______________________________________________
> openssl-project mailing list
> openssl-project at openssl.org
> https://mta.openssl.org/mailman/listinfo/openssl-project
> 

From levitte at openssl.org  Thu Jan 18 13:56:01 2018
From: levitte at openssl.org (Richard Levitte)
Date: Thu, 18 Jan 2018 14:56:01 +0100 (CET)
Subject: [openssl-project] Fwd: [openssl-commits] FAILED build of
 OpenSSL branch OpenSSL_1_1_0-stable with options -d --strict-warnings
 no-dgram
In-Reply-To: <684f6ef0-f626-72fe-46de-a304ca1f858f@openssl.org>
References: <7953c900-c709-b662-6f29-3d7f96670e6c@openssl.org>
 <20180118.144031.891045670865089619.levitte@openssl.org>
 <684f6ef0-f626-72fe-46de-a304ca1f858f@openssl.org>
Message-ID: <20180118.145601.2037918927696463674.levitte@openssl.org>

In message <684f6ef0-f626-72fe-46de-a304ca1f858f at openssl.org> on Thu, 18 Jan 2018 13:48:58 +0000, Matt Caswell <matt at openssl.org> said:

matt> On 18/01/18 13:40, Richard Levitte wrote:
matt> > In the mean time, I'm turning off run-checker, as these reports are
matt> > disruptive and not useful at all.
matt> 
matt> Why not just switch off the 1.1.0 run-checker for now?

Good point.  Done and disabled in crontab

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

From matt at openssl.org  Thu Jan 18 13:57:12 2018
From: matt at openssl.org (Matt Caswell)
Date: Thu, 18 Jan 2018 13:57:12 +0000
Subject: [openssl-project] Fwd: [openssl-commits] FAILED build of
 OpenSSL branch OpenSSL_1_1_0-stable with options -d --strict-warnings
 no-dgram
In-Reply-To: <20180118.145601.2037918927696463674.levitte@openssl.org>
References: <7953c900-c709-b662-6f29-3d7f96670e6c@openssl.org>
 <20180118.144031.891045670865089619.levitte@openssl.org>
 <684f6ef0-f626-72fe-46de-a304ca1f858f@openssl.org>
 <20180118.145601.2037918927696463674.levitte@openssl.org>
Message-ID: <a9e93af5-83c5-7d3a-92fd-117ec83ac317@openssl.org>



On 18/01/18 13:56, Richard Levitte wrote:
> In message <684f6ef0-f626-72fe-46de-a304ca1f858f at openssl.org> on Thu, 18 Jan 2018 13:48:58 +0000, Matt Caswell <matt at openssl.org> said:
> 
> matt> On 18/01/18 13:40, Richard Levitte wrote:
> matt> > In the mean time, I'm turning off run-checker, as these reports are
> matt> > disruptive and not useful at all.
> matt> 
> matt> Why not just switch off the 1.1.0 run-checker for now?
> 
> Good point.  Done and disabled in crontab
> 

How about we change the port numbers in 1.1.0!?

Matt

From rsalz at akamai.com  Thu Jan 18 14:23:38 2018
From: rsalz at akamai.com (Salz, Rich)
Date: Thu, 18 Jan 2018 14:23:38 +0000
Subject: [openssl-project] Fwd: [openssl-commits] FAILED build of
 OpenSSL branch OpenSSL_1_1_0-stable with options -d --strict-warnings
 no-dgram
In-Reply-To: <20180118.144031.891045670865089619.levitte@openssl.org>
References: <1516275755.353922.25293.nullmailer@run.openssl.org>
 <7953c900-c709-b662-6f29-3d7f96670e6c@openssl.org>
 <20180118.144031.891045670865089619.levitte@openssl.org>
Message-ID: <A2BF6E1F-004A-479C-A12C-2150990F8DA3@akamai.com>

Turn off the 1.1.0 run-checker; the master one is useful!

On 1/18/18, 8:40 AM, "Richard Levitte" <levitte at openssl.org> wrote:

    Oh, I see what's happening...
    
    Here's how things are layed out (crontab):
    
      2 22  *   *  0-4   (set -x; cd $HOME/run-checker && bash ./run-checker.sh) >> $HOME/run-checker.cron.log 2>&1
      2 10  *   *  1-5   (set -x; cd $HOME/run-checker-1.1.0 && bash ./run-checker.sh) >> $HOME/run-checker-1.1.0.cron.log 2>&1
    
    The trouble is this (current listing):
    
        openssl at run:~$ ls -ltr ~/run-checker
        ...
        -rw-rw-r--  1 openssl openssl  14644664 Jan 17 22:09 default.tar.xz
        -rw-rw-r--  1 openssl openssl  14632920 Jan 17 22:17 no-afalgeng.tar.xz
        ...
        -rw-rw-r--  1 openssl openssl  14637020 Jan 18 13:30 no-tls.tar.xz
        drwxrwxr-x 12 openssl openssl      4096 Jan 18 13:31 no-ssl3
        openssl at run:~$ ls -ltr ~/run-checker-1.1.0
        ...
        -rw-rw-r--  1 openssl openssl   7599764 Jan 18 10:05 default.tar.xz
        -rw-rw-r--  1 openssl openssl   7583800 Jan 18 10:10 no-afalgeng.tar.xz
        ...
        -rw-rw-r--  1 openssl openssl   7600464 Jan 18 13:33 no-md2.tar.xz
        drwxrwxr-x 12 openssl openssl      4096 Jan 18 13:34 no-msan
    
    The last line in each listing (directory) indicates what job is
    currently running (those directories are gzipped at the end of each
    job).
    
    Unfortunately, there's no barrier between these runs, so when it comes
    to things like network ports, they trample all over each other.  Now,
    TLSProxy uses hard coded ports, you can see how that gets problematic.
    
    So I think the option is to jail the two run-checkers, and from recent
    reading, I understand that docker can be used for that kind of thing.
    Trouble is, I've never ever played with docker.  I'm willing to
    experiment, but it will probably be done much quicker if someone can
    give me some quick'n'easy instructions.
    
    We run this on a Ubuntu 16.04 machine, FYI.
    
    In the mean time, I'm turning off run-checker, as these reports are
    disruptive and not useful at all.
    
    In message <7953c900-c709-b662-6f29-3d7f96670e6c at openssl.org> on Thu, 18 Jan 2018 11:44:22 +0000, Matt Caswell <matt at openssl.org> said:
    
    matt> We're still getting lots of spurious failures from TLSProxy in run-checker:
    matt> 
    matt> ../../openssl/test/recipes/70-test_sslcbcpadding.t .... skipped: Unable
    matt> to start up Proxy for tests
    matt> ../../openssl/test/recipes/70-test_sslcertstatus.t .... skipped: Unable
    matt> to start up Proxy for tests
    matt> ../../openssl/test/recipes/70-test_sslextension.t ..... ok
    matt> ../../openssl/test/recipes/70-test_sslmessages.t ...... skipped: Unable
    matt> to start up Proxy for tests
    matt> ../../openssl/test/recipes/70-test_sslrecords.t ....... Dubious, test
    matt> returned 1 (wstat 256, 0x100)
    matt> Failed 1/11 subtests ../../openssl/test/recipes/70-test_sslsessiontick.t
    matt> ... skipped: Unable to start up Proxy for tests
    matt> ../../openssl/test/recipes/70-test_sslskewith0p.t ..... skipped: Unable
    matt> to start up Proxy for tests
    matt> ../../openssl/test/recipes/70-test_sslvertol.t ........ ok
    matt> ../../openssl/test/recipes/70-test_tlsextms.t ......... Dubious, test
    matt> returned 3 (wstat 768, 0x300)
    matt> 
    matt> 
    matt> Grrrr. WTF?
    matt> 
    matt> Matt
    matt> 
    matt> _______________________________________________
    matt> openssl-project mailing list
    matt> openssl-project at openssl.org
    matt> https://mta.openssl.org/mailman/listinfo/openssl-project
    matt> 
    _______________________________________________
    openssl-project mailing list
    openssl-project at openssl.org
    https://mta.openssl.org/mailman/listinfo/openssl-project
    


From levitte at openssl.org  Thu Jan 18 14:30:26 2018
From: levitte at openssl.org (Richard Levitte)
Date: Thu, 18 Jan 2018 15:30:26 +0100 (CET)
Subject: [openssl-project] Fwd: [openssl-commits] FAILED build of
 OpenSSL branch OpenSSL_1_1_0-stable with options -d --strict-warnings
 no-dgram
In-Reply-To: <A2BF6E1F-004A-479C-A12C-2150990F8DA3@akamai.com>
References: <7953c900-c709-b662-6f29-3d7f96670e6c@openssl.org>
 <20180118.144031.891045670865089619.levitte@openssl.org>
 <A2BF6E1F-004A-479C-A12C-2150990F8DA3@akamai.com>
Message-ID: <20180118.153026.1125740122327857917.levitte@openssl.org>

I'd say the 1.1.0 one is useful too, considering that's the check we
have after we've made a cherry-pick from master stuff.  But it's
turned off for the moment.

In message <A2BF6E1F-004A-479C-A12C-2150990F8DA3 at akamai.com> on Thu, 18 Jan 2018 14:23:38 +0000, "Salz, Rich" <rsalz at akamai.com> said:

rsalz> Turn off the 1.1.0 run-checker; the master one is useful!
rsalz> 
rsalz> On 1/18/18, 8:40 AM, "Richard Levitte" <levitte at openssl.org> wrote:
rsalz> 
rsalz>     Oh, I see what's happening...
rsalz>     
rsalz>     Here's how things are layed out (crontab):
rsalz>     
rsalz>       2 22  *   *  0-4   (set -x; cd $HOME/run-checker && bash ./run-checker.sh) >> $HOME/run-checker.cron.log 2>&1
rsalz>       2 10  *   *  1-5   (set -x; cd $HOME/run-checker-1.1.0 && bash ./run-checker.sh) >> $HOME/run-checker-1.1.0.cron.log 2>&1
rsalz>     
rsalz>     The trouble is this (current listing):
rsalz>     
rsalz>         openssl at run:~$ ls -ltr ~/run-checker
rsalz>         ...
rsalz>         -rw-rw-r--  1 openssl openssl  14644664 Jan 17 22:09 default.tar.xz
rsalz>         -rw-rw-r--  1 openssl openssl  14632920 Jan 17 22:17 no-afalgeng.tar.xz
rsalz>         ...
rsalz>         -rw-rw-r--  1 openssl openssl  14637020 Jan 18 13:30 no-tls.tar.xz
rsalz>         drwxrwxr-x 12 openssl openssl      4096 Jan 18 13:31 no-ssl3
rsalz>         openssl at run:~$ ls -ltr ~/run-checker-1.1.0
rsalz>         ...
rsalz>         -rw-rw-r--  1 openssl openssl   7599764 Jan 18 10:05 default.tar.xz
rsalz>         -rw-rw-r--  1 openssl openssl   7583800 Jan 18 10:10 no-afalgeng.tar.xz
rsalz>         ...
rsalz>         -rw-rw-r--  1 openssl openssl   7600464 Jan 18 13:33 no-md2.tar.xz
rsalz>         drwxrwxr-x 12 openssl openssl      4096 Jan 18 13:34 no-msan
rsalz>     
rsalz>     The last line in each listing (directory) indicates what job is
rsalz>     currently running (those directories are gzipped at the end of each
rsalz>     job).
rsalz>     
rsalz>     Unfortunately, there's no barrier between these runs, so when it comes
rsalz>     to things like network ports, they trample all over each other.  Now,
rsalz>     TLSProxy uses hard coded ports, you can see how that gets problematic.
rsalz>     
rsalz>     So I think the option is to jail the two run-checkers, and from recent
rsalz>     reading, I understand that docker can be used for that kind of thing.
rsalz>     Trouble is, I've never ever played with docker.  I'm willing to
rsalz>     experiment, but it will probably be done much quicker if someone can
rsalz>     give me some quick'n'easy instructions.
rsalz>     
rsalz>     We run this on a Ubuntu 16.04 machine, FYI.
rsalz>     
rsalz>     In the mean time, I'm turning off run-checker, as these reports are
rsalz>     disruptive and not useful at all.
rsalz>     
rsalz>     In message <7953c900-c709-b662-6f29-3d7f96670e6c at openssl.org> on Thu, 18 Jan 2018 11:44:22 +0000, Matt Caswell <matt at openssl.org> said:
rsalz>     
rsalz>     matt> We're still getting lots of spurious failures from TLSProxy in run-checker:
rsalz>     matt> 
rsalz>     matt> ../../openssl/test/recipes/70-test_sslcbcpadding.t .... skipped: Unable
rsalz>     matt> to start up Proxy for tests
rsalz>     matt> ../../openssl/test/recipes/70-test_sslcertstatus.t .... skipped: Unable
rsalz>     matt> to start up Proxy for tests
rsalz>     matt> ../../openssl/test/recipes/70-test_sslextension.t ..... ok
rsalz>     matt> ../../openssl/test/recipes/70-test_sslmessages.t ...... skipped: Unable
rsalz>     matt> to start up Proxy for tests
rsalz>     matt> ../../openssl/test/recipes/70-test_sslrecords.t ....... Dubious, test
rsalz>     matt> returned 1 (wstat 256, 0x100)
rsalz>     matt> Failed 1/11 subtests ../../openssl/test/recipes/70-test_sslsessiontick.t
rsalz>     matt> ... skipped: Unable to start up Proxy for tests
rsalz>     matt> ../../openssl/test/recipes/70-test_sslskewith0p.t ..... skipped: Unable
rsalz>     matt> to start up Proxy for tests
rsalz>     matt> ../../openssl/test/recipes/70-test_sslvertol.t ........ ok
rsalz>     matt> ../../openssl/test/recipes/70-test_tlsextms.t ......... Dubious, test
rsalz>     matt> returned 3 (wstat 768, 0x300)
rsalz>     matt> 
rsalz>     matt> 
rsalz>     matt> Grrrr. WTF?
rsalz>     matt> 
rsalz>     matt> Matt
rsalz>     matt> 
rsalz>     matt> _______________________________________________
rsalz>     matt> openssl-project mailing list
rsalz>     matt> openssl-project at openssl.org
rsalz>     matt> https://mta.openssl.org/mailman/listinfo/openssl-project
rsalz>     matt> 
rsalz>     _______________________________________________
rsalz>     openssl-project mailing list
rsalz>     openssl-project at openssl.org
rsalz>     https://mta.openssl.org/mailman/listinfo/openssl-project
rsalz>     
rsalz> 
rsalz> _______________________________________________
rsalz> openssl-project mailing list
rsalz> openssl-project at openssl.org
rsalz> https://mta.openssl.org/mailman/listinfo/openssl-project
rsalz> 

From levitte at openssl.org  Thu Jan 18 14:31:57 2018
From: levitte at openssl.org (Richard Levitte)
Date: Thu, 18 Jan 2018 15:31:57 +0100 (CET)
Subject: [openssl-project] Fwd: [openssl-commits] FAILED build of
 OpenSSL branch OpenSSL_1_1_0-stable with options -d --strict-warnings
 no-dgram
In-Reply-To: <a9e93af5-83c5-7d3a-92fd-117ec83ac317@openssl.org>
References: <684f6ef0-f626-72fe-46de-a304ca1f858f@openssl.org>
 <20180118.145601.2037918927696463674.levitte@openssl.org>
 <a9e93af5-83c5-7d3a-92fd-117ec83ac317@openssl.org>
Message-ID: <20180118.153157.106610087436414078.levitte@openssl.org>

In message <a9e93af5-83c5-7d3a-92fd-117ec83ac317 at openssl.org> on Thu, 18 Jan 2018 13:57:12 +0000, Matt Caswell <matt at openssl.org> said:

matt> 
matt> 
matt> On 18/01/18 13:56, Richard Levitte wrote:
matt> > In message <684f6ef0-f626-72fe-46de-a304ca1f858f at openssl.org> on Thu, 18 Jan 2018 13:48:58 +0000, Matt Caswell <matt at openssl.org> said:
matt> > 
matt> > matt> On 18/01/18 13:40, Richard Levitte wrote:
matt> > matt> > In the mean time, I'm turning off run-checker, as these reports are
matt> > matt> > disruptive and not useful at all.
matt> > matt> 
matt> > matt> Why not just switch off the 1.1.0 run-checker for now?
matt> > 
matt> > Good point.  Done and disabled in crontab
matt> > 
matt> 
matt> How about we change the port numbers in 1.1.0!?

I'd say it's better to change them in master, then...

So does this mean we change the TLSProxy ports every minor release
then? ;-)

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

From matt at openssl.org  Thu Jan 18 14:34:00 2018
From: matt at openssl.org (Matt Caswell)
Date: Thu, 18 Jan 2018 14:34:00 +0000
Subject: [openssl-project] Fwd: [openssl-commits] FAILED build of
 OpenSSL branch OpenSSL_1_1_0-stable with options -d --strict-warnings
 no-dgram
In-Reply-To: <20180118.153157.106610087436414078.levitte@openssl.org>
References: <684f6ef0-f626-72fe-46de-a304ca1f858f@openssl.org>
 <20180118.145601.2037918927696463674.levitte@openssl.org>
 <a9e93af5-83c5-7d3a-92fd-117ec83ac317@openssl.org>
 <20180118.153157.106610087436414078.levitte@openssl.org>
Message-ID: <4a502429-f83b-61e7-afb8-620ae683e80e@openssl.org>



On 18/01/18 14:31, Richard Levitte wrote:
> In message <a9e93af5-83c5-7d3a-92fd-117ec83ac317 at openssl.org> on Thu, 18 Jan 2018 13:57:12 +0000, Matt Caswell <matt at openssl.org> said:
> 
> matt> 
> matt> 
> matt> On 18/01/18 13:56, Richard Levitte wrote:
> matt> > In message <684f6ef0-f626-72fe-46de-a304ca1f858f at openssl.org> on Thu, 18 Jan 2018 13:48:58 +0000, Matt Caswell <matt at openssl.org> said:
> matt> > 
> matt> > matt> On 18/01/18 13:40, Richard Levitte wrote:
> matt> > matt> > In the mean time, I'm turning off run-checker, as these reports are
> matt> > matt> > disruptive and not useful at all.
> matt> > matt> 
> matt> > matt> Why not just switch off the 1.1.0 run-checker for now?
> matt> > 
> matt> > Good point.  Done and disabled in crontab
> matt> > 
> matt> 
> matt> How about we change the port numbers in 1.1.0!?
> 
> I'd say it's better to change them in master, then...
> 
> So does this mean we change the TLSProxy ports every minor release
> then? ;-)
> 

Yes...master would be better. Even nicer would be a way to configure it
from the command line. :-)

make PROXYPORTS=12345 test

Matt

From rsalz at akamai.com  Thu Jan 18 14:35:11 2018
From: rsalz at akamai.com (Salz, Rich)
Date: Thu, 18 Jan 2018 14:35:11 +0000
Subject: [openssl-project] Fwd: [openssl-commits] FAILED build of
 OpenSSL branch OpenSSL_1_1_0-stable with options -d --strict-warnings
 no-dgram
In-Reply-To: <20180118.153157.106610087436414078.levitte@openssl.org>
References: <684f6ef0-f626-72fe-46de-a304ca1f858f@openssl.org>
 <20180118.145601.2037918927696463674.levitte@openssl.org>
 <a9e93af5-83c5-7d3a-92fd-117ec83ac317@openssl.org>
 <20180118.153157.106610087436414078.levitte@openssl.org>
Message-ID: <C91B2EE4-7934-4CD3-BE6B-6BF6CCAA5790@akamai.com>


>    So does this mean we change the TLSProxy ports every minor release
    then? ;-)
  
How about an environment variable that species the port.  Run-checker sets the env var (or inherits from the crontab command line)



From levitte at openssl.org  Thu Jan 18 14:38:43 2018
From: levitte at openssl.org (Richard Levitte)
Date: Thu, 18 Jan 2018 15:38:43 +0100 (CET)
Subject: [openssl-project] Fwd: [openssl-commits] FAILED build of
 OpenSSL branch OpenSSL_1_1_0-stable with options -d --strict-warnings
 no-dgram
In-Reply-To: <4a502429-f83b-61e7-afb8-620ae683e80e@openssl.org>
References: <a9e93af5-83c5-7d3a-92fd-117ec83ac317@openssl.org>
 <20180118.153157.106610087436414078.levitte@openssl.org>
 <4a502429-f83b-61e7-afb8-620ae683e80e@openssl.org>
Message-ID: <20180118.153843.1048492878430326534.levitte@openssl.org>

In message <4a502429-f83b-61e7-afb8-620ae683e80e at openssl.org> on Thu, 18 Jan 2018 14:34:00 +0000, Matt Caswell <matt at openssl.org> said:

matt> 
matt> 
matt> On 18/01/18 14:31, Richard Levitte wrote:
matt> > In message <a9e93af5-83c5-7d3a-92fd-117ec83ac317 at openssl.org> on Thu, 18 Jan 2018 13:57:12 +0000, Matt Caswell <matt at openssl.org> said:
matt> > 
matt> > matt> 
matt> > matt> 
matt> > matt> On 18/01/18 13:56, Richard Levitte wrote:
matt> > matt> > In message <684f6ef0-f626-72fe-46de-a304ca1f858f at openssl.org> on Thu, 18 Jan 2018 13:48:58 +0000, Matt Caswell <matt at openssl.org> said:
matt> > matt> > 
matt> > matt> > matt> On 18/01/18 13:40, Richard Levitte wrote:
matt> > matt> > matt> > In the mean time, I'm turning off run-checker, as these reports are
matt> > matt> > matt> > disruptive and not useful at all.
matt> > matt> > matt> 
matt> > matt> > matt> Why not just switch off the 1.1.0 run-checker for now?
matt> > matt> > 
matt> > matt> > Good point.  Done and disabled in crontab
matt> > matt> > 
matt> > matt> 
matt> > matt> How about we change the port numbers in 1.1.0!?
matt> > 
matt> > I'd say it's better to change them in master, then...
matt> > 
matt> > So does this mean we change the TLSProxy ports every minor release
matt> > then? ;-)
matt> > 
matt> 
matt> Yes...master would be better. Even nicer would be a way to configure it
matt> from the command line. :-)
matt> 
matt> make PROXYPORTS=12345 test

There are two ports to define, the s_server accept port as well.

But good idea, and all that's needed is a change in Proxy.pm, as far as I know.

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

From matt at openssl.org  Thu Jan 18 14:43:58 2018
From: matt at openssl.org (Matt Caswell)
Date: Thu, 18 Jan 2018 14:43:58 +0000
Subject: [openssl-project] Fwd: [openssl-commits] Broken:
 openssl/openssl#15676 (master - e44c7d0)
In-Reply-To: <5a60acdbd8d1d_43fb99c78e890102778@448662c1-6ee3-42b8-ba9e-5bdcfaab6bc7.mail>
References: <5a60acdbd8d1d_43fb99c78e890102778@448662c1-6ee3-42b8-ba9e-5bdcfaab6bc7.mail>
Message-ID: <71b90238-cb35-ee19-2b7b-59e1d5983769@openssl.org>

This failure is interesting.

Test Summary Report
-------------------
../test/recipes/90-test_store.t                  (Wstat: 0 Tests: 200
Failed: 1)
  Failed test:  199
  Parse errors: Tests out of sequence.  Found (1) but expected (2)
                Tests out of sequence.  Found (2) but expected (3)
                Tests out of sequence.  Found (3) but expected (4)
                Tests out of sequence.  Found (4) but expected (5)
                Tests out of sequence.  Found (5) but expected (6)
Displayed the first 5 of 200 TAP syntax errors.


Looking in the full log I see this:


../../../util/shlib_wrap.sh ../../../apps/openssl req -new -config
../../../test/recipes/90-test_store_data/user.cnf -key ec-key-pkcs8.pem
-out ec-cert.csr => 0
Signature ok
subject=CN = A user, UID = test
Getting CA Private Key
../../../util/shlib_wrap.sh ../../../apps/openssl x509 -days 3650 -CA
cacert.pem -CAkey cakey.pem -set_serial 1516283742 -req -in ec-cert.csr
-out ec-cert.pem => 0
../../../util/shlib_wrap.sh ../../../apps/openssl pkcs12 -inkey
rsa-key-pkcs8.pem -in rsa-cert.pem -passout 'pass:password' -export
-macalg SHA1 -certpbe pbeWithSHA1And3-KeyTripleDES-CBC -keypbe
pbeWithSHA1And3-KeyTripleDES-CBC -out rsa-key-sha1-3des-sha1.p12 => 0
../../../util/shlib_wrap.sh ../../../apps/openssl pkcs12 -inkey
rsa-key-pkcs8.pem -in rsa-cert.pem -passout 'pass:password' -export
-macalg SHA256 -certpbe pbeWithSHA1And3-KeyTripleDES-CBC -keypbe
pbeWithSHA1And3-KeyTripleDES-CBC -out rsa-key-sha1-3des-sha256.p12 => 0
../../../util/shlib_wrap.sh ../../../apps/openssl pkcs12 -inkey
rsa-key-pkcs8.pem -in rsa-cert.pem -passout 'pass:password' -export
-macalg SHA256 -certpbe AES-256-CBC -keypbe AES-256-CBC -out
rsa-key-aes256-cbc-sha256.p12 => 0
../../../util/shlib_wrap.sh ../../../apps/openssl pkcs12 -inkey
rsa-key-pkcs8.pem -in rsa-cert.pem -passout 'pass:password' -export
-macalg SHA1 -certpbe pbeWithMD5AndDES-CBC -keypbe pbeWithMD5AndDES-CBC
-out rsa-key-md5-des-sha1.p12 => 0
../../../util/shlib_wrap.sh ../../../apps/openssl pkcs12 -inkey
rsa-key-pkcs8.pem -in rsa-cert.pem -passout 'pass:password' -export
-macalg SHA256 -certpbe AES-256-CBC -keypbe pbeWithMD5AndDES-CBC -out
rsa-key-aes256-cbc-md5-des-sha256.p12 => 0
../../../util/shlib_wrap.sh ../../../apps/openssl pkcs12 -inkey
dsa-key-pkcs8.pem -in dsa-cert.pem -passout 'pass:password' -export
-macalg SHA256 -certpbe AES-256-CBC -keypbe AES-256-CBC -out
dsa-key-aes256-cbc-sha256.p12 => 0
../../../util/shlib_wrap.sh ../../../apps/openssl pkcs12 -inkey
ec-key-pkcs8.pem -in ec-cert.pem -passout 'pass:password' -export
-macalg SHA256 -certpbe AES-256-CBC -keypbe AES-256-CBC -out
ec-key-aes256-cbc-sha256.p12 => 0
writing RSA key
-----BEGIN RSA PRIVATE KEY-----
MIIFewIBAAKCATEA50TA+B07pML0X33QS2WtDKwfaw+shSb114U7qa71aiavTWEb
KSnPntvFTlxEHaCuQ/dB2K+phsjOKVlP3sHAx3YRYiamVr/ip1nhw4QhWiXg6dlJ
DO9k/egJYa1bzrZu1N2CAFGqfUmrAHEs/jgbe2vmYouWfXhHZcjCj+bVL2zbhn8I
Ye4d2J/bKf5lwKmoHMAIQK9K7ni3sXqS2WJdPT6tyx+WAOdsPBi1MAn22TON2m3a
xYNNaaI6Xve6l0415EqdiGgj19hNz2UOtvMLqxxF5EBD+nDULnZkyiz6JgnVvEbS
yiFlJ92sK3GFG11sTxhJbECyMUca3uKGht1TzxtTPyH66Ct3GedunwghiEAHrhz5
MI6o2uHZTYWex+9pm32OILULozEeLk7VWzdxgQIDAQABAoIBMG9epK7XJQnK+HOj
2tL0O8mGefrMqX/Vqz4GYxzrrDNaPcE9qh7Ai8Msgm+h7wt1fXYtdAAtV64YtW8k
G1piY7uqF+T0R9Yuwa9lkVreHlGTPCRhBtS71B6RxzLKkROStvy7TwdoTHnZKAgm
eExUKKfe5is+nVH+wiM58rfpqXAVNAIo2piOWsEe+iPW5plJGjP+JftAbw03GqMc
BSnP6p01FATP3nk2om9TkUm67fkUxlsjCLGkVVgHYZHh1yuG8vqWUu37RgCYi0rJ
QGCK+nFcsJXDvOw/As6eHeDnjMTsDkIgGsO4fwQzVL4X3TgDGEGcqyPBG2ygqaEJ
C6dZ9zSfp/V9H0sbrOl3kk1anZjQXfEdIx8DeNsGgtmXtIwlUGCjDaazWlL5pVtN
8bY9uAECgZkA9Vl8em7FE39ykqaijdLkNStgKbD2bEbs9vRH1YW8fbjJQfw69C+5
B/heMsQb4UCV4p8jnC/A0URTG41ytwX2aDCN6N9DnQwpRDiuIQ0xq6AR+A5nxgfG
3s9PVS7EkHLd5TIo/BdPnta7NuzzWOowGw3nU97fO+JLLIEneCCEhweRiMQr1/4K
YiONVPX9/82ZnaDno1t7WdECgZkA8U7J63a1QyVNjmA4/4pQFTVFfGX+Y4nh4Zc6
bjT2tcNu7F7Q8q64TFf1ZG/z2DN3iK/93m3tB1xo+rAwfVDq8+U92IbeWdH4Sw5I
1k5mAEoxpESmXpUs5+u5y63YBqMfgZW7MJ8jjgvaM2GFOaS7HbVl0zMLSEG25OW/
SOWtJH+K/pOl2Gh565TaPRxuOpIBumVnFvhG2LECgZhs/lX4JeFS6hlB4Njx3DAZ
Fq3fl4fBTjjS9G49Au5bg42UzLJ76/9s9P8T2l7wUDrFtCCjr+sejBXHdazydamj
W36PZy+oQtDKR8vDTxMzxSZ2Zh/fr3C/ZqU9mEsmSIEe4oumgcyTKZ19pwHsDA1W
13Reo/HTrpHqsW2RRhDZ05jpgwxfJbIDKvwMNEOkMff+OI7u2SMRIQKBmG9syERY
Hj8RHIzf1bH59hy06o8UsbDY3FrE8BAvmLQ5uCChb66AC04FV6S3JUvyCAIv8fQh
ok/B1h/b96gGE1fnxPUU4dtr31EZGX0L2oHLwLxvjrsh+whkiviIH7aA4G1/7F35

^^
Is the ok here confusing TAP?



Pfu7cVhEcbY6YMTJHGm3qkAFSCTOCdPpalfuJQqEtxIEvDeSFmwdkrCs9utRI5cx
sdUhAoGZAMyR+y9qAN7tybPJwbgTrVFgJAwYcsSuwT6wCDhUVpsp3CX228vo8zaK
nspOk4JPHsIsof5Er27+B4b5i383+WSnfNsgdlu42jq48WY35QmeuDJrCY1RBEWD
ieKJeK77+526dVY87J35/VyjlTMmrTg5sqkAB8GHkOBy6gdWfPsAl22JCfwTBCg8
wWgv7ld7VAROIHGej5hN
-----END RSA PRIVATE KEY-----
../../../util/shlib_wrap.sh ../../../apps/openssl rsa -in
rsa-key-pkcs8-pbes2-sha256.pem -passin 'pass:password' => 0
ok 1
Couldn't open file or uri ../../../test/blahdiblah.pem
47458563135488:error:02016002:system library:stat:No such file or
directory:crypto/store/loader_file.c:812:../../../test/blahdiblah.pem
../../../util/shlib_wrap.sh ../../../apps/openssl storeutl
../../../test/blahdiblah.pem => 1
ok 2
Couldn't open file or uri
/home/travis/build/openssl/openssl/test/test-runs/store_28852/../../../test/blahdiblah.pem
47753908746240:error:02016002:system library:stat:No such file or
directory:crypto/store/loader_file.c:812:/home/travis/build/openssl/openssl/test/test-runs/store_28852/../../../test/blahdiblah.pem
../../../util/shlib_wrap.sh ../../../apps/openssl storeutl
/home/travis/build/openssl/openssl/test/test-runs/store_28852/../../../test/blahdiblah.pem
=> 1
ok 3
Couldn't open file or uri
file:/home/travis/build/openssl/openssl/test/blahdiblah.pem
47862721009664:error:02016002:system library:stat:No such file or
directory:crypto/store/loader_file.c:812:file:/home/travis/build/openssl/openssl/test/blahdiblah.pem
47862721009664:error:02016002:system library:stat:No such file or
directory:crypto/store/loader_file.c:812:/home/travis/build/openssl/openssl/test/blahdiblah.pem
../../../util/shlib_wrap.sh ../../../apps/openssl storeutl
'file:/home/travis/build/openssl/openssl/test/blahdiblah.pem' => 1
ok 4





-------- Forwarded Message --------
Subject: 	[openssl-commits] Broken: openssl/openssl#15676 (master - e44c7d0)
Date: 	Thu, 18 Jan 2018 14:19:08 +0000
From: 	Travis CI <builds at travis-ci.org>
To: 	openssl-commits at openssl.org



*openssl / openssl
<https://travis-ci.org/openssl/openssl?utm_source=email&utm_medium=notification>*
(master <https://github.com/openssl/openssl/tree/master>)

	Build #15676 was broken.
<https://travis-ci.org/openssl/openssl/builds/330363362?utm_source=email&utm_medium=notification>
	
29 minutes and 56 seconds
	*Richard Levitte* 	e44c7d0
<https://github.com/openssl/openssl/commit/e44c7d02ddac975ec6abff7901e77a0c37f9949d>
Changeset ?
<https://github.com/openssl/openssl/compare/e02d58866360...e44c7d02ddac>
? 	Only implement secure malloc if _POSIX_VERSION allows

Reviewed-by: Andy Polyakov <appro at openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5060)

*Want to know about upcoming build environment updates?*

Would you like to stay up-to-date with the upcoming Travis CI build
environment updates? We set up a mailing list for you! Sign up here
<http://eepurl.com/9OCsP>.

	Documentation <https://docs.travis-ci.com> about Travis CI
Need help? Mail support <mailto:support at travis-ci.com>!
Choose who receives these build notification emails in your
configuration file <https://docs.travis-ci.com/user/notifications>.

*Would you like to test your private code?*

Travis CI for Private Projects
<https://travis-ci.com?utm_source=build_email_footer&utm_campaign=travis-ci.org&utm_medium=email>
could be your new best friend!

-------------- next part --------------
_____
openssl-commits mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-commits


From matt at openssl.org  Thu Jan 18 14:45:40 2018
From: matt at openssl.org (Matt Caswell)
Date: Thu, 18 Jan 2018 14:45:40 +0000
Subject: [openssl-project] Fwd: [openssl-commits] FAILED build of
 OpenSSL branch OpenSSL_1_1_0-stable with options -d --strict-warnings
 no-dgram
In-Reply-To: <20180118.153843.1048492878430326534.levitte@openssl.org>
References: <a9e93af5-83c5-7d3a-92fd-117ec83ac317@openssl.org>
 <20180118.153157.106610087436414078.levitte@openssl.org>
 <4a502429-f83b-61e7-afb8-620ae683e80e@openssl.org>
 <20180118.153843.1048492878430326534.levitte@openssl.org>
Message-ID: <6edde3f9-49c2-a9a6-dfbc-900949a9473f@openssl.org>



On 18/01/18 14:38, Richard Levitte wrote:
> In message <4a502429-f83b-61e7-afb8-620ae683e80e at openssl.org> on Thu, 18 Jan 2018 14:34:00 +0000, Matt Caswell <matt at openssl.org> said:
> 
> matt> 
> matt> 
> matt> On 18/01/18 14:31, Richard Levitte wrote:
> matt> > In message <a9e93af5-83c5-7d3a-92fd-117ec83ac317 at openssl.org> on Thu, 18 Jan 2018 13:57:12 +0000, Matt Caswell <matt at openssl.org> said:
> matt> > 
> matt> > matt> 
> matt> > matt> 
> matt> > matt> On 18/01/18 13:56, Richard Levitte wrote:
> matt> > matt> > In message <684f6ef0-f626-72fe-46de-a304ca1f858f at openssl.org> on Thu, 18 Jan 2018 13:48:58 +0000, Matt Caswell <matt at openssl.org> said:
> matt> > matt> > 
> matt> > matt> > matt> On 18/01/18 13:40, Richard Levitte wrote:
> matt> > matt> > matt> > In the mean time, I'm turning off run-checker, as these reports are
> matt> > matt> > matt> > disruptive and not useful at all.
> matt> > matt> > matt> 
> matt> > matt> > matt> Why not just switch off the 1.1.0 run-checker for now?
> matt> > matt> > 
> matt> > matt> > Good point.  Done and disabled in crontab
> matt> > matt> > 
> matt> > matt> 
> matt> > matt> How about we change the port numbers in 1.1.0!?
> matt> > 
> matt> > I'd say it's better to change them in master, then...
> matt> > 
> matt> > So does this mean we change the TLSProxy ports every minor release
> matt> > then? ;-)
> matt> > 
> matt> 
> matt> Yes...master would be better. Even nicer would be a way to configure it
> matt> from the command line. :-)
> matt> 
> matt> make PROXYPORTS=12345 test
> 
> There are two ports to define, the s_server accept port as well.
> 
> But good idea, and all that's needed is a change in Proxy.pm, as far as I know.
> 

Well, we could make it that the env variable defines a base port. Then
we just use base port, and base port + 1.

Matt

From matt at openssl.org  Thu Jan 18 14:59:32 2018
From: matt at openssl.org (Matt Caswell)
Date: Thu, 18 Jan 2018 14:59:32 +0000
Subject: [openssl-project] Fwd: [openssl-commits] Broken:
 openssl/openssl#15676 (master - e44c7d0)
In-Reply-To: <71b90238-cb35-ee19-2b7b-59e1d5983769@openssl.org>
References: <5a60acdbd8d1d_43fb99c78e890102778@448662c1-6ee3-42b8-ba9e-5bdcfaab6bc7.mail>
 <71b90238-cb35-ee19-2b7b-59e1d5983769@openssl.org>
Message-ID: <8a1f0baf-b0f8-7f5c-23a4-30ab8587b622@openssl.org>



On 18/01/18 14:43, Matt Caswell wrote:
> ok/B1h/b96gGE1fnxPUU4dtr31EZGX0L2oHLwLxvjrsh+whkiviIH7aA4G1/7F35
> 
> ^^
> Is the ok here confusing TAP?


A quick test proves to me that it does confuse it. The chances of 2
characters of base64 at the beginning of a lines are "ok" (assuming
evenly distributed data) is about 1 in 4000. But the store test outputs
100s of lines of base64 so this will increase the odds significantly.

Richard - any ideas?

Matt


From rsalz at akamai.com  Thu Jan 18 16:51:41 2018
From: rsalz at akamai.com (Salz, Rich)
Date: Thu, 18 Jan 2018 16:51:41 +0000
Subject: [openssl-project] An "inactive" bot for issues
Message-ID: <D6AC0912-57A9-4756-B5B3-51916EC7A13E@akamai.com>

Some projects have a bot that closes issues that have had no activity for some period of time.  Should we do the same?

I am thing of something like this.  Every month we scan all open issues.  For any that have had no activity for a year, we post the list to openssl-project. For those that have had no activity for 13 months we close them.

What do people think?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-project/attachments/20180118/6586fa8f/attachment.html>

From matt at openssl.org  Thu Jan 18 16:53:28 2018
From: matt at openssl.org (Matt Caswell)
Date: Thu, 18 Jan 2018 16:53:28 +0000
Subject: [openssl-project] An "inactive" bot for issues
In-Reply-To: <D6AC0912-57A9-4756-B5B3-51916EC7A13E@akamai.com>
References: <D6AC0912-57A9-4756-B5B3-51916EC7A13E@akamai.com>
Message-ID: <ba756495-5e40-3a08-cf4a-3a932aef7936@openssl.org>

Might be a good idea. With perhaps a refinement to say that if we add
some specified label it should never be closed by the bot. In case there
is some long standing issue that we don't want to forget about, but
aren't expecting any activity for a while (such as for an issue to be
resolved in 1.2.0).

Matt


On 18/01/18 16:51, Salz, Rich wrote:
> Some projects have a bot that closes issues that have had no activity
> for some period of time.? Should we do the same?
> 
> ?
> 
> I am thing of something like this.? Every month we scan all open
> issues.? For any that have had no activity for a year, we post the list
> to openssl-project. For those that have had no activity for 13 months we
> close them.
> 
> ?
> 
> What do people think?
> 
> 
> 
> _______________________________________________
> openssl-project mailing list
> openssl-project at openssl.org
> https://mta.openssl.org/mailman/listinfo/openssl-project
> 

From rsalz at akamai.com  Thu Jan 18 16:54:55 2018
From: rsalz at akamai.com (Salz, Rich)
Date: Thu, 18 Jan 2018 16:54:55 +0000
Subject: [openssl-project] An "inactive" bot for issues
In-Reply-To: <ba756495-5e40-3a08-cf4a-3a932aef7936@openssl.org>
References: <D6AC0912-57A9-4756-B5B3-51916EC7A13E@akamai.com>
 <ba756495-5e40-3a08-cf4a-3a932aef7936@openssl.org>
Message-ID: <F788F0F7-760A-4CB8-A458-DA2BE4AC2A5A@akamai.com>

Could do that, but I think anything left idle for a year deserves a quick manual review.

On 1/18/18, 11:53 AM, "Matt Caswell" <matt at openssl.org> wrote:

    Might be a good idea. With perhaps a refinement to say that if we add
    some specified label it should never be closed by the bot. In case there
    is some long standing issue that we don't want to forget about, but
    aren't expecting any activity for a while (such as for an issue to be
    resolved in 1.2.0).
    
    Matt
    
    
    On 18/01/18 16:51, Salz, Rich wrote:
    > Some projects have a bot that closes issues that have had no activity
    > for some period of time.  Should we do the same?
    > 
    >  
    > 
    > I am thing of something like this.  Every month we scan all open
    > issues.  For any that have had no activity for a year, we post the list
    > to openssl-project. For those that have had no activity for 13 months we
    > close them.
    > 
    >  
    > 
    > What do people think?
    > 
    > 
    > 
    > _______________________________________________
    > openssl-project mailing list
    > openssl-project at openssl.org
    > https://mta.openssl.org/mailman/listinfo/openssl-project
    > 
    _______________________________________________
    openssl-project mailing list
    openssl-project at openssl.org
    https://mta.openssl.org/mailman/listinfo/openssl-project


From rsalz at akamai.com  Fri Jan 19 15:21:07 2018
From: rsalz at akamai.com (Salz, Rich)
Date: Fri, 19 Jan 2018 15:21:07 +0000
Subject: [openssl-project] should doc-nits flag long lines?
Message-ID: <9065A29A-3E28-47CD-B8DD-EC83F761B6B9@akamai.com>

Maybe not within code displays?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-project/attachments/20180119/e3b51507/attachment.html>

From rsalz at akamai.com  Fri Jan 19 17:45:37 2018
From: rsalz at akamai.com (Salz, Rich)
Date: Fri, 19 Jan 2018 17:45:37 +0000
Subject: [openssl-project] Congrats Matt!
Message-ID: <931BCDE2-0C5E-4C2A-AA5E-8C066D6990FB@akamai.com>

I see that Matt is on a tear reviewing just about all open issues and PR?s.  As someone who has done that before, back in the RT days, I just want to call it out and thank him!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-project/attachments/20180119/8ef794db/attachment-0001.html>

From matt at openssl.org  Fri Jan 19 18:32:00 2018
From: matt at openssl.org (Matt Caswell)
Date: Fri, 19 Jan 2018 18:32:00 +0000
Subject: [openssl-project] Congrats Matt!
In-Reply-To: <931BCDE2-0C5E-4C2A-AA5E-8C066D6990FB@akamai.com>
References: <931BCDE2-0C5E-4C2A-AA5E-8C066D6990FB@akamai.com>
Message-ID: <0edd0d60-d3c9-7665-5271-32ddfec9db39@openssl.org>

Thanks :-)

Now down to less than 300 issues!!

Matt


On 19/01/18 17:45, Salz, Rich wrote:
> I see that Matt is on a tear reviewing just about all open issues and
> PR?s.? As someone who has done that before, back in the RT days, I just
> want to call it out and thank him!
> 
> 
> 
> _______________________________________________
> openssl-project mailing list
> openssl-project at openssl.org
> https://mta.openssl.org/mailman/listinfo/openssl-project
> 

From levitte at openssl.org  Sun Jan 21 07:40:56 2018
From: levitte at openssl.org (Richard Levitte)
Date: Sun, 21 Jan 2018 08:40:56 +0100 (CET)
Subject: [openssl-project] What's a new feature, vs what's a fix?
Message-ID: <20180121.084056.568872854570887767.levitte@openssl.org>

This may need being rehashed, as it seems we don't have a concensus.

Our versioning policy stipulates that released versions of OpenSSL
should only be updated with fixes, that new features should go into
new releases (right now, 1.1.1 will be the next new release, while
1.1.0 has already been released and is only updated).

The question that keeps coming up, through comments like the attached,
is "what do we mean by 'new feature'".  I have been surprised at times
by what others have considered a 'new feature', and obviously, I can
surprise as well.

I think that it's clear to every one that added APIs is a new feature.

I think that it's clear to every one that added new functions is a new
feature...  most of the times (the exception is when a fairly obvious
function is missing in a newly released API).

But then we have other items where it's not quite as clear, and
opinions seems to differ, such as:

- is a new config target a new feature?  I think that most of us have
  agreed that it is, but am not entirely sure everyone sees it that
  way.

- is a new config option a new feature?  I have argued that it is, but
  am not at all sure we have a consensus.

- is a new C macro to indicate if a certain feature is desirable or
  not a new feature?  I actually have no clue, which is also the
  reason I raised the question in the PR.
  A side question is why this was coded as a direct C macro
  configuration and not as our other config options, and in that case,
  why we should consider it differently from the usual config options.

Cheers,
Richard

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

-------------- next part --------------
An embedded message was scrubbed...
From: Rich Salz <notifications at github.com>
Subject: Re: [openssl/openssl] Add a configure option for sec mem [1.1.0] (#5122)
Date: Sat, 20 Jan 2018 17:48:50 -0800
Size: 5128
URL: <http://mta.openssl.org/pipermail/openssl-project/attachments/20180121/2c4ba473/attachment.mht>

From bernd.edlinger at hotmail.de  Sun Jan 21 09:33:14 2018
From: bernd.edlinger at hotmail.de (Bernd Edlinger)
Date: Sun, 21 Jan 2018 09:33:14 +0000
Subject: [openssl-project] What's a new feature, vs what's a fix?
In-Reply-To: <20180121.084056.568872854570887767.levitte@openssl.org>
References: <20180121.084056.568872854570887767.levitte@openssl.org>
Message-ID: <AM5PR0701MB2657E7033C94368AD3647FABE4ED0@AM5PR0701MB2657.eurprd07.prod.outlook.com>

On 01/21/18 08:40, Richard Levitte wrote:
> This may need being rehashed, as it seems we don't have a concensus.
> 
> Our versioning policy stipulates that released versions of OpenSSL
> should only be updated with fixes, that new features should go into
> new releases (right now, 1.1.1 will be the next new release, while
> 1.1.0 has already been released and is only updated).
> 
> The question that keeps coming up, through comments like the attached,
> is "what do we mean by 'new feature'".  I have been surprised at times
> by what others have considered a 'new feature', and obviously, I can
> surprise as well.
> 
> I think that it's clear to every one that added APIs is a new feature.
> 
> I think that it's clear to every one that added new functions is a new
> feature...  most of the times (the exception is when a fairly obvious
> function is missing in a newly released API).

IMHO a light-weight configuration option like this falls under the same
exception.

> 
> But then we have other items where it's not quite as clear, and
> opinions seems to differ, such as:
> 
> - is a new config target a new feature?  I think that most of us have
>    agreed that it is, but am not entirely sure everyone sees it that
>    way.
> 
> - is a new config option a new feature?  I have argued that it is, but
>    am not at all sure we have a consensus.
> 
> - is a new C macro to indicate if a certain feature is desirable or
>    not a new feature?  I actually have no clue, which is also the
>    reason I raised the question in the PR.
>    A side question is why this was coded as a direct C macro
>    configuration and not as our other config options, and in that case,
>    why we should consider it differently from the usual config options.
> 

a) It should not influence the exported functions or the header files in
any way.

b) It should not add any complexity (and future maintenance cost) to
the configuration process.

c) A "normal" config option would cross the border to a new feature.


Thanks
Bernd.

From paul.dale at oracle.com  Sun Jan 21 23:25:02 2018
From: paul.dale at oracle.com (Paul Dale)
Date: Sun, 21 Jan 2018 15:25:02 -0800 (PST)
Subject: [openssl-project] What's a new feature, vs what's a fix?
In-Reply-To: <20180121.084056.568872854570887767.levitte@openssl.org>
References: <20180121.084056.568872854570887767.levitte@openssl.org>
Message-ID: <599acf1f-8c2a-489c-bea1-bbac617d7dc7@default>

I'll start by saying I'm generally in agreement.


> - is a new config target a new feature?  I think that most of us have
>   agreed that it is, but am not entirely sure everyone sees it that
>   way.

I would say that it is a new feature too.


> - is a new config option a new feature?  I have argued that it is, but
>   am not at all sure we have a consensus.

I'd tend to think of it as a new feature.  However, I'd allow an obvious API that was omitted.


> - is a new C macro to indicate if a certain feature is desirable or
>   not a new feature?  I actually have no clue, which is also the
>   reason I raised the question in the PR.
>   A side question is why this was coded as a direct C macro
>   configuration and not as our other config options, and in that case,
>   why we should consider it differently from the usual config options.

If it were a new function instead of a macro would it be included?
Does it pass the test of being a fairly obvious function that is missing?
Without additional context, a feature test would seem to qualify as a fix.


Pauli
-- 
Oracle
Dr Paul Dale | Cryptographer | Network Security & Encryption 
Phone +61 7 3031 7217
Oracle Australia

From matt at openssl.org  Mon Jan 22 09:31:52 2018
From: matt at openssl.org (Matt Caswell)
Date: Mon, 22 Jan 2018 09:31:52 +0000
Subject: [openssl-project] What's a new feature, vs what's a fix?
In-Reply-To: <20180121.084056.568872854570887767.levitte@openssl.org>
References: <20180121.084056.568872854570887767.levitte@openssl.org>
Message-ID: <1be05bb5-c2df-6592-01ca-f4d57a444373@openssl.org>



On 21/01/18 07:40, Richard Levitte wrote:
> This may need being rehashed, as it seems we don't have a concensus.
> 
> Our versioning policy stipulates that released versions of OpenSSL
> should only be updated with fixes, that new features should go into
> new releases (right now, 1.1.1 will be the next new release, while
> 1.1.0 has already been released and is only updated).
> 
> The question that keeps coming up, through comments like the attached,
> is "what do we mean by 'new feature'".  I have been surprised at times
> by what others have considered a 'new feature', and obviously, I can
> surprise as well.
> 
> I think that it's clear to every one that added APIs is a new feature.
> 
> I think that it's clear to every one that added new functions is a new
> feature...  most of the times (the exception is when a fairly obvious
> function is missing in a newly released API).
> 

In my mind even simple new functions (getters/setters) are a new
feature. Its just that, as a matter of pragmatism, we have decided to
allow them (effectively they are a "fix" for a broken design).

> But then we have other items where it's not quite as clear, and
> opinions seems to differ, such as:
> 
> - is a new config target a new feature?  I think that most of us have
>   agreed that it is, but am not entirely sure everyone sees it that
>   way.

IMO, yes. A new target is a new feature.

> 
> - is a new config option a new feature?  I have argued that it is, but
>   am not at all sure we have a consensus.

Yes, I'd say it was.

> 
> - is a new C macro to indicate if a certain feature is desirable or
>   not a new feature?  I actually have no clue, which is also the
>   reason I raised the question in the PR.
>   A side question is why this was coded as a direct C macro
>   configuration and not as our other config options, and in that case,
>   why we should consider it differently from the usual config options.

I don't have the context for this to really know - but as a general rule
I'd say anything new like this in a public header is probably a feature.
OTOH what is the motivation for adding it? For missing getters/setters
the motivation is we are adding back in the capability to do something
which was intended to be there in the first place but was inadvertently
broken due to opacity. Pull #4901 is a slightly different version of this:

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

Here we are proposing to add a new SSL_OP_ flag into 1.1.0 because
something that you used to be able to do in 1.0.2 is no longer possible
due to opacity.

If we are adding a feature in order to "fix" something that should work
but doesn't (especially if you used to be able to do something but now
can't), then this is a fairly strong argument for using the exception.
As with all of these things though there is always going to be a grey
area where we will have to exercise our judgement.

Matt


From appro at openssl.org  Mon Jan 22 12:48:45 2018
From: appro at openssl.org (Andy Polyakov)
Date: Mon, 22 Jan 2018 13:48:45 +0100
Subject: [openssl-project] [openssl-dev] Blog post;
	changing in email, crypto policy, etc
In-Reply-To: <BC9EA3C9-8748-4075-81E3-3256D9696880@akamai.com>
References: <BC9EA3C9-8748-4075-81E3-3256D9696880@akamai.com>
Message-ID: <9ea920be-2e65-6453-93ea-b2be930258be@openssl.org>

> There?s a new blog post at 
>     https://www.openssl.org/blog/blog/2018/01/18/f2f-london/

Quoting the blog post:

"Insecure configuration options will not be enabled by default but must
be enabled by a compile-time switch. We had already started to do this
by disabling SSLv2 and small keys. A recent change is that ?multi-prime
RSA? will enforce a maximum number of prime factors by default. In the
future, it?s possible we?ll increase the minimum key sizes for a variety
of algorithms."

This is confusing. For starters it's mixing up two completely different
things. It's one thing to make availability of *legacy* crypto (or
protocol) an option, it's another thing to *introduce* insecure options.
Secondly, it gives an impression that maximum amount of primes in RSA is
a compile-time *option*, when it's not. Nor should it be. For above
reason, no new insecure option should be *introduced*. And there is
additional reason when it comes to assymetric crypto. As already said,
it's principally different from symmetric, as there are things that peer
can't verify in communication protocol and has to *trust* another party
with. And Open-source software is part of that trust chain. Now, does
wording mean that omc is actually open to suggestions to *introduce*
insecure options?

From rsalz at akamai.com  Mon Jan 22 13:40:52 2018
From: rsalz at akamai.com (Salz, Rich)
Date: Mon, 22 Jan 2018 13:40:52 +0000
Subject: [openssl-project] What's a new feature, vs what's a fix?
In-Reply-To: <1be05bb5-c2df-6592-01ca-f4d57a444373@openssl.org>
References: <20180121.084056.568872854570887767.levitte@openssl.org>
 <1be05bb5-c2df-6592-01ca-f4d57a444373@openssl.org>
Message-ID: <44697668-83FC-46A5-A15F-8FAE093B85D1@akamai.com>

? In my mind even simple new functions (getters/setters) are a new
    feature. Its just that, as a matter of pragmatism, we have decided to
    allow them (effectively they are a "fix" for a broken design).
    
I slightly disagree.  We explicitly decided to treat them as a bugfix, not because of a broken design, but because we knew we wouldn?t get enough feedback to make sure we had everything.  I think that?s important.


From appro at openssl.org  Mon Jan 22 13:44:58 2018
From: appro at openssl.org (Andy Polyakov)
Date: Mon, 22 Jan 2018 14:44:58 +0100
Subject: [openssl-project] What's a new feature, vs what's a fix?
In-Reply-To: <20180121.084056.568872854570887767.levitte@openssl.org>
References: <20180121.084056.568872854570887767.levitte@openssl.org>
Message-ID: <09607e7e-a0da-6fb0-d611-cfcfddb3f2ef@openssl.org>

> - is a new config target a new feature?  I think that most of us have
>   agreed that it is, but am not entirely sure everyone sees it that
>   way.

At the same time one can argue that rules don't have to be as rigid for
LTS. It's appropriate to "entice" people to use latest version, but at
the same time we actually recognize that it's not actually reasonable to
unconditionally *demand* that they do. How do we do that? By maintaining
LTS concept itself. Now, one of OpenSSL's strong sides is that it's
multi-platform, i.e. facilitates common applications across multiple
platforms. And on certain level denial of new platform support actually
contradicts LTS concept. Because it prevents stable application code
reuse. Do note "don't have to be as rigid for LTS" in the beginning. It
doesn't mean that we should be open to *any* suggestion, only that we
don't have be closed to *every* one of them. To give a practical
example, consider Android clang problem... [I refer to the fact that
they plan to remove gcc from ndk.]


From rsalz at akamai.com  Mon Jan 22 14:18:09 2018
From: rsalz at akamai.com (Salz, Rich)
Date: Mon, 22 Jan 2018 14:18:09 +0000
Subject: [openssl-project] [openssl-dev] Blog post;
 changing in email, crypto policy, etc
In-Reply-To: <9ea920be-2e65-6453-93ea-b2be930258be@openssl.org>
References: <BC9EA3C9-8748-4075-81E3-3256D9696880@akamai.com>
 <9ea920be-2e65-6453-93ea-b2be930258be@openssl.org>
Message-ID: <A440A07B-C333-4B33-ACB4-9CAD734FC756@akamai.com>

Oh heck, we?re gonna get wrapped around the axle of wording again?

>    This is confusing. For starters it's mixing up two completely different
    things. It's one thing to make availability of *legacy* crypto (or
    protocol) an option, it's another thing to *introduce* insecure options.

Disagree.  That?s just an implementation detail.  From the end-user?s perspective, weakness is weakness no matter where or how it comes from.
  
> Now, does
    wording mean that omc is actually open to suggestions to *introduce*
    insecure options?
  
That wasn?t the intent.  It could happen.


From appro at openssl.org  Mon Jan 22 15:34:23 2018
From: appro at openssl.org (Andy Polyakov)
Date: Mon, 22 Jan 2018 16:34:23 +0100
Subject: [openssl-project] [openssl-dev] Blog post;
 changing in email, crypto policy, etc
In-Reply-To: <A440A07B-C333-4B33-ACB4-9CAD734FC756@akamai.com>
References: <BC9EA3C9-8748-4075-81E3-3256D9696880@akamai.com>
 <9ea920be-2e65-6453-93ea-b2be930258be@openssl.org>
 <A440A07B-C333-4B33-ACB4-9CAD734FC756@akamai.com>
Message-ID: <5e198b51-5062-8a9c-0e23-4a9debadb285@openssl.org>

> Oh heck, we?re gonna get wrapped around the axle of wording again?

??? Humans communicate with words. If we are to agree on something,
words is *all* we have to use. And wordings have meanings too...

>>    This is confusing. For starters it's mixing up two completely different
>     things. It's one thing to make availability of *legacy* crypto (or
>     protocol) an option, it's another thing to *introduce* insecure options.
> 
> Disagree.  That?s just an implementation detail.  From the end-user?s perspective, weakness is weakness no matter where or how it comes from.

Let me rephrase. "It's another thing to *purposefully* introduce options
known to be insecure by the time of introduction." [I actually written
"known to be insecure by time" in original draft, but later thought that
it's implied by word "introduce".] Well, arguably there is ambiguity in
use of word "option". Is it a config-time switch, or code it controls? I
obviously refer to code.

>> Now, does
>     wording mean that omc is actually open to suggestions to *introduce*
>     insecure options?
>   
> That wasn?t the intent.  It could happen.

I'm sorry [for taking the risk to irritate you even more with
"irrelevant wording" stuff], but what does *this* mean? "That wasn't the
intent. [But] it [,insecure options,] could happen [anyway]."? This
would mean affirmative answer to the question. Is this it? Or was it
"That wasn't the intent. It [wording] just happened."?

From rsalz at akamai.com  Mon Jan 22 16:25:25 2018
From: rsalz at akamai.com (Salz, Rich)
Date: Mon, 22 Jan 2018 16:25:25 +0000
Subject: [openssl-project] [openssl-dev] Blog post;
 changing in email, crypto policy, etc
In-Reply-To: <5e198b51-5062-8a9c-0e23-4a9debadb285@openssl.org>
References: <BC9EA3C9-8748-4075-81E3-3256D9696880@akamai.com>
 <9ea920be-2e65-6453-93ea-b2be930258be@openssl.org>
 <A440A07B-C333-4B33-ACB4-9CAD734FC756@akamai.com>
 <5e198b51-5062-8a9c-0e23-4a9debadb285@openssl.org>
Message-ID: <36BC99B6-3C46-4060-AEEB-224617DA32E3@akamai.com>

? ??? Humans communicate with words. If we are to agree on something,
    words is *all* we have to use. And wordings have meanings too...
    
Fair point.

?     Let me rephrase. "It's another thing to *purposefully* introduce options
    known to be insecure by the time of introduction."

Yes run-time and compile-time is something to keep in mind.

We do not plan to introduce any insecure options that are enabled by default.  Option refers to compile-time and build-time both.  But I?ve been in this field for a long time, and I don?t think we can guarantee that it will not happen.  For example, the extra-entropy extension, the DualEC DRBG, etc.

Ok?




From openssl-users at dukhovni.org  Mon Jan 22 16:50:50 2018
From: openssl-users at dukhovni.org (Viktor Dukhovni)
Date: Mon, 22 Jan 2018 11:50:50 -0500
Subject: [openssl-project] [openssl-dev] Blog post;
 changing in email, crypto policy, etc
In-Reply-To: <9ea920be-2e65-6453-93ea-b2be930258be@openssl.org>
References: <BC9EA3C9-8748-4075-81E3-3256D9696880@akamai.com>
 <9ea920be-2e65-6453-93ea-b2be930258be@openssl.org>
Message-ID: <B38A89FE-8244-48F1-9413-1F5FCF579CF8@dukhovni.org>



> On Jan 22, 2018, at 7:48 AM, Andy Polyakov <appro at openssl.org> wrote:
> 
> For above
> reason, no new insecure option should be *introduced*.

I think I'm with Andy on this one.  We should aim to not introduce
new weakened crypto.  I hope we are not moved by "market forces"
to add support for dubious algorithms that interoperate with some
sort of standard for constrained devices.  Can't rule out that
possibility, but it would have to be one that the "industry" as
a whole accepts (not just OpenSSL, but all major TLS implementations
decide to support some such algorithm).  Presumably it would not
simply an opaque weak mode of a strong algorithm, but a distinct
algorithm known to be weaker by all sides.

-- 
	Viktor.


From rsalz at akamai.com  Mon Jan 22 21:35:20 2018
From: rsalz at akamai.com (Salz, Rich)
Date: Mon, 22 Jan 2018 21:35:20 +0000
Subject: [openssl-project] FYI: GitHub on our servers
Message-ID: <0674696A-86DE-41FD-8A07-8540798A8B53@akamai.com>

Background: at the F2F we discussed using GitHub for our internal security releases, and to provide a ticketing system for our support customers and us to use.  We currently use GitLab to prepare our security releases.

Here?s the pricing summary.

A first try to get a free enterprise GitHub install failed.  I got a sales call in response to my filling out a webform. Sorry, there was no time to bring in another OMC member.

If we did a private repo hosted on GitHub, it would cost $7/mo/person, or around 756/year (I assumed we?ll have another OMC member at some point.)  Once we get 501c3 status, we could get the GH-hosted option with a private repository for free. If we want to self-host that?s GitHub enterprise it costs $21/user (minimum ten) and is billed annually, for $2500 a year. See the URL?s below.

https://github.com/pricing/business-enterprise
https://github.com/nonprofit
https://github.com/pricing


From: Alison Marcozzi <alimarcozzi at github.com>
Date: Tuesday, January 9, 2018 at 6:53 PM
To: Rich Salz <rsalz at akamai.com>
Subject: Re: Hi Rich - Just left you a voicemail

Hi again Rich,

It was great speaking with you today! As mentioned, here are the links to our pricing page<https://urldefense.proofpoint.com/v2/url?u=http-3A__t.yesware.com_tt_ba8e658a231581305b21024b160605b0c17843d6_aa36a7dd17a31e82c74b44eb09022971_1c0be20cc7f3f282330fe989a389ecf2_github.com_pricing&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=4LM0GbR0h9Fvx86FtsKI-w&m=fguf9p5WvL1vQlr8jahWmHsI2O4aY1P6Q8WVO_NyDwc&s=bMOIn5O6Uv9CysEsmXNscg0nYw5H3w9ZOCGqCljv1Qw&e=> and nonprofit page<https://urldefense.proofpoint.com/v2/url?u=https-3A__t.yesware.com_tt_ba8e658a231581305b21024b160605b0c17843d6_aa36a7dd17a31e82c74b44eb09022971_2833943519414d5d8f878972a91f1f48_github.com_nonprofit&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=4LM0GbR0h9Fvx86FtsKI-w&m=fguf9p5WvL1vQlr8jahWmHsI2O4aY1P6Q8WVO_NyDwc&s=bV2Sb4rOJqPKhDHpk4kYVm4kyp73ZmT5mRF79oBD7ow&e=>. Once you have a chance to review the pricing page, please let me know which plan you would like to move forward with and I would be happy to help!

Cheers,
Alison


--

Alison Marcozzi
Sales Development Representative- AMER
w: +1 (415) 906- 5332
[https://docs.google.com/uc?export=download&id=0BzaBOMULbUvrOEVJWDlKcVNzdGc&revid=0BzaBOMULbUvrZ3BFZ09xREw2UHloOStVOUxQRFd3eXF3OFdZPQ]

On Tue, Jan 9, 2018 at 10:41 AM, Salz, Rich <rsalz at akamai.com<mailto:rsalz at akamai.com>> wrote:
Great thanks

From: Alison Marcozzi <alimarcozzi at github.com<mailto:alimarcozzi at github.com>>
Date: Tuesday, January 9, 2018 at 1:26 PM
To: Rich Salz <rsalz at akamai.com<mailto:rsalz at akamai.com>>
Subject: Re: Hi Rich - Just left you a voicemail

Hi Rich,

Thank you for getting back to me! I will call you today at 4:30 pm EST today (1/9). I look forward to speaking with you!

Best,
Alison


--

Alison Marcozzi
Sales Development Representative- AMER
w: +1 (415) 906- 5332<tel:(415)%20906-5332>
[https://docs.google.com/uc?export=download&id=0BzaBOMULbUvrOEVJWDlKcVNzdGc&revid=0BzaBOMULbUvrZ3BFZ09xREw2UHloOStVOUxQRFd3eXF3OFdZPQ]

On Mon, Jan 8, 2018 at 6:26 PM, Salz, Rich <rsalz at akamai.com<mailto:rsalz at akamai.com>> wrote:
I am wide open tomorrow except 1-4.  I?m in Cambridge, MA.  Thanks.

From: Alison Marcozzi <alimarcozzi at github.com<mailto:alimarcozzi at github.com>>
Date: Monday, January 8, 2018 at 5:27 PM
To: "rsalz at openssl.org<mailto:rsalz at openssl.org>" <rsalz at openssl.org<mailto:rsalz at openssl.org>>
Subject: Hi Rich - Just left you a voicemail

Hi Rich,

Just left you a voicemail.  I am following up on your Contact Request for OpenSSL and I'd love to connect before Wednesday (1/10).  Let me know if you have time to chat on the phone, or if you would rather communicate via email thats perfectly fine as well.

I look forward to speaking and have a great day!

Cheers,

Alison


--

Alison Marcozzi
Sales Development Representative- AMER
w: +1 (415) 906- 5332<tel:(415)%20906-5332>
[https://docs.google.com/uc?export=download&id=0BzaBOMULbUvrOEVJWDlKcVNzdGc&revid=0BzaBOMULbUvrZ3BFZ09xREw2UHloOStVOUxQRFd3eXF3OFdZPQ]


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

From appro at openssl.org  Mon Jan 22 23:36:45 2018
From: appro at openssl.org (Andy Polyakov)
Date: Tue, 23 Jan 2018 00:36:45 +0100
Subject: [openssl-project] [openssl-dev] Blog post;
 changing in email, crypto policy, etc
In-Reply-To: <36BC99B6-3C46-4060-AEEB-224617DA32E3@akamai.com>
References: <BC9EA3C9-8748-4075-81E3-3256D9696880@akamai.com>
 <9ea920be-2e65-6453-93ea-b2be930258be@openssl.org>
 <A440A07B-C333-4B33-ACB4-9CAD734FC756@akamai.com>
 <5e198b51-5062-8a9c-0e23-4a9debadb285@openssl.org>
 <36BC99B6-3C46-4060-AEEB-224617DA32E3@akamai.com>
Message-ID: <647648eb-7a44-de82-1339-bc1c1aea2381@openssl.org>

> ?     Let me rephrase. "It's another thing to *purposefully* introduce options
>     known to be insecure by the time of introduction."
> 
> Yes run-time and compile-time is something to keep in mind.
> 
> We do not plan to introduce any insecure options that are enabled by default.  Option refers to compile-time and build-time both.  But I?ve been in this field for a long time, and I don?t think we can guarantee that it will not happen.  For example, the extra-entropy extension, the DualEC DRBG, etc.
> 
> Ok?

Sorry, but no, not OK. "Do not *plan*"? Doesn't it imply "plans can
change"? So it *is* open question. Really? It should be "we shall
*refuse* to *implement* an insecure option(*)". Period. As for things
that can happen. Yes, there is no guarantee that something like DualEC
can't happen in future, *but* then it may not be *intentional* on our
side. I mean we may fail to recognize new option as insecure, but it's
not OK to implement one that is already recognized as insecure. Allow me
to add this. If the said plans, specifically in respect to implementing
options already recognized as insecure, change and get realized, I'll
have to refuse to participate in the endeavour.

(*) As already mentioned, in the context "option" is rather "code" than
just "config-time flag". And once again, *legacy* cases are different,
because the *choice* is between *removal* of existing code, and making
compilation conditional. Different from *adding* code that is.

From rsalz at akamai.com  Tue Jan 23 02:05:43 2018
From: rsalz at akamai.com (Salz, Rich)
Date: Tue, 23 Jan 2018 02:05:43 +0000
Subject: [openssl-project] [openssl-dev] Blog post;
 changing in email, crypto policy, etc
In-Reply-To: <647648eb-7a44-de82-1339-bc1c1aea2381@openssl.org>
References: <BC9EA3C9-8748-4075-81E3-3256D9696880@akamai.com>
 <9ea920be-2e65-6453-93ea-b2be930258be@openssl.org>
 <A440A07B-C333-4B33-ACB4-9CAD734FC756@akamai.com>
 <5e198b51-5062-8a9c-0e23-4a9debadb285@openssl.org>
 <36BC99B6-3C46-4060-AEEB-224617DA32E3@akamai.com>
 <647648eb-7a44-de82-1339-bc1c1aea2381@openssl.org>
Message-ID: <0EAE3237-848A-4BC1-A56A-E32ABEBF4F25@akamai.com>


    Sorry, but no, not OK. "Do not *plan*"? Doesn't it imply "plans can
    change"? So it *is* open question. Really? It should be "we shall
    *refuse* to *implement* an insecure option(*)". Period.

Great, no define ?insecure?

I don?t think I have anything else to add on this thread.  Maybe someone else will chime in.

WE ARE NOT GOING TO KNOWINGLY IMPLEMENT OR PROVIDE ANYTHING THAT IS KNOWN TO BE INSECURE ACCORDING TO iNDUSTRY STANDARD.



From mark at awe.com  Tue Jan 23 10:13:14 2018
From: mark at awe.com (Mark J Cox)
Date: Tue, 23 Jan 2018 10:13:14 +0000
Subject: [openssl-project] FYI: GitHub on our servers
In-Reply-To: <0674696A-86DE-41FD-8A07-8540798A8B53@akamai.com>
References: <0674696A-86DE-41FD-8A07-8540798A8B53@akamai.com>
Message-ID: <CABU6YOZ4P-FN+tgvSiHLxi7ejK3nhTRoGvKEcdC4WNEsSmz1cA@mail.gmail.com>

The plan for security use of this would be to give accounts to all the
prenotification folks, so this would quickly become more expensive on a
per-seat basis, hence I'd wait until we qualify for a free account.

Mark

On Mon, Jan 22, 2018 at 9:35 PM, Salz, Rich <rsalz at akamai.com> wrote:

> Background: at the F2F we discussed using GitHub for our internal security
> releases, and to provide a ticketing system for our support customers and
> us to use.  We currently use GitLab to prepare our security releases.
>
>
>
> Here?s the pricing summary.
>
>
>
> A first try to get a free enterprise GitHub install failed.  I got a sales
> call in response to my filling out a webform. Sorry, there was no time to
> bring in another OMC member.
>
>
>
> If we did a private repo hosted on GitHub, it would cost $7/mo/person, or
> around 756/year (I assumed we?ll have another OMC member at some point.)
> Once we get 501c3 status, we could get the GH-hosted option with a private
> repository for free. If we want to self-host that?s GitHub enterprise it
> costs $21/user (minimum ten) and is billed annually, for $2500 a year. See
> the URL?s below.
>
>
>
> https://github.com/pricing/business-enterprise
>
> https://github.com/nonprofit
>
> https://github.com/pricing
>
>
>
>
>
> *From: *Alison Marcozzi <alimarcozzi at github.com>
> *Date: *Tuesday, January 9, 2018 at 6:53 PM
> *To: *Rich Salz <rsalz at akamai.com>
> *Subject: *Re: Hi Rich - Just left you a voicemail
>
>
>
> Hi again Rich,
>
>
>
> It was great speaking with you today! As mentioned, here are the links to
> our pricing page
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__t.yesware.com_tt_ba8e658a231581305b21024b160605b0c17843d6_aa36a7dd17a31e82c74b44eb09022971_1c0be20cc7f3f282330fe989a389ecf2_github.com_pricing&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=4LM0GbR0h9Fvx86FtsKI-w&m=fguf9p5WvL1vQlr8jahWmHsI2O4aY1P6Q8WVO_NyDwc&s=bMOIn5O6Uv9CysEsmXNscg0nYw5H3w9ZOCGqCljv1Qw&e=>
>  and nonprofit page
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__t.yesware.com_tt_ba8e658a231581305b21024b160605b0c17843d6_aa36a7dd17a31e82c74b44eb09022971_2833943519414d5d8f878972a91f1f48_github.com_nonprofit&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=4LM0GbR0h9Fvx86FtsKI-w&m=fguf9p5WvL1vQlr8jahWmHsI2O4aY1P6Q8WVO_NyDwc&s=bV2Sb4rOJqPKhDHpk4kYVm4kyp73ZmT5mRF79oBD7ow&e=>.
> Once you have a chance to review the pricing page, please let me know which
> plan you would like to move forward with and I would be happy to help!
>
>
>
> Cheers,
>
> Alison
>
>
> --
>
>
>
> Alison Marcozzi
>
> Sales Development Representative- AMER
>
> w: +1 (415) 906- 5332 <(415)%20906-5332>
>
>
>
> On Tue, Jan 9, 2018 at 10:41 AM, Salz, Rich <rsalz at akamai.com> wrote:
>
> Great thanks
>
>
>
> *From: *Alison Marcozzi <alimarcozzi at github.com>
> *Date: *Tuesday, January 9, 2018 at 1:26 PM
> *To: *Rich Salz <rsalz at akamai.com>
> *Subject: *Re: Hi Rich - Just left you a voicemail
>
>
>
> Hi Rich,
>
>
>
> Thank you for getting back to me! I will call you today at 4:30 pm EST
> today (1/9). I look forward to speaking with you!
>
>
>
> Best,
>
> Alison
>
>
> --
>
>
>
> Alison Marcozzi
>
> Sales Development Representative- AMER
>
> w: +1 (415) 906- 5332 <(415)%20906-5332>
>
>
>
> On Mon, Jan 8, 2018 at 6:26 PM, Salz, Rich <rsalz at akamai.com> wrote:
>
> I am wide open tomorrow except 1-4.  I?m in Cambridge, MA.  Thanks.
>
>
>
> *From: *Alison Marcozzi <alimarcozzi at github.com>
> *Date: *Monday, January 8, 2018 at 5:27 PM
> *To: *"rsalz at openssl.org" <rsalz at openssl.org>
> *Subject: *Hi Rich - Just left you a voicemail
>
>
>
> Hi Rich,
>
>
>
> Just left you a voicemail.  I am following up on your Contact Request
> for OpenSSL and I'd love to connect before Wednesday (1/10).  Let me know
> if you have time to chat on the phone, or if you would rather communicate
> via email thats perfectly fine as well.
>
>
>
> I look forward to speaking and have a great day!
>
>
>
> Cheers,
>
>
>
> Alison
>
>
> --
>
>
>
> Alison Marcozzi
>
> Sales Development Representative- AMER
>
> w: +1 (415) 906- 5332 <(415)%20906-5332>
>
>
>
>
>
> _______________________________________________
> openssl-project mailing list
> openssl-project at openssl.org
> https://mta.openssl.org/mailman/listinfo/openssl-project
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-project/attachments/20180123/6c5a0cf9/attachment-0001.html>

From mark at awe.com  Tue Jan 23 10:18:33 2018
From: mark at awe.com (Mark J Cox)
Date: Tue, 23 Jan 2018 10:18:33 +0000
Subject: [openssl-project] CNA git experiment (just FYI no process changes
	at the moment)
Message-ID: <CABU6YObohJnY8JkXVRxptAZBpSW9y67AnMOv_FXM_8qFZC-z8w@mail.gmail.com>

Mitre are testing a new way to submit CVE entries to them from CNAs
rather than us using the web form.  Instead you clone their github
repo, edit the json file for the CVE, and submit a PR back to them.
I've got a tool that converts our XML vulndb info into JSON already
and have been cleaning up the XML vulndb entries as well.   I'm going
to be experimenting with this, and have talked to Richard about the
right way to set this up, i.e. unlike our other repos this would be a
github-only repo.

So no changes right now to our current policy on dealing with CVEs and
the release-manager steps are unchanged for now, just don't be
suprised by the new repo in our github org.

Mark

From rsalz at akamai.com  Tue Jan 23 14:13:54 2018
From: rsalz at akamai.com (Salz, Rich)
Date: Tue, 23 Jan 2018 14:13:54 +0000
Subject: [openssl-project] FYI: GitHub on our servers
In-Reply-To: <CABU6YOZ4P-FN+tgvSiHLxi7ejK3nhTRoGvKEcdC4WNEsSmz1cA@mail.gmail.com>
References: <0674696A-86DE-41FD-8A07-8540798A8B53@akamai.com>
 <CABU6YOZ4P-FN+tgvSiHLxi7ejK3nhTRoGvKEcdC4WNEsSmz1cA@mail.gmail.com>
Message-ID: <AC62C83A-1C04-4E39-975A-6AC990C0B726@akamai.com>

That?s an excellent point.  So perhaps we should now decide if we?re okay with private repo?s hosted on GitHub?s servers, since that is the only way to get free.  On-prem is not free.

From: Mark Cox <mark at awe.com>
Reply-To: "openssl-project at openssl.org" <openssl-project at openssl.org>
Date: Tuesday, January 23, 2018 at 5:13 AM
To: "openssl-project at openssl.org" <openssl-project at openssl.org>
Subject: Re: [openssl-project] FYI: GitHub on our servers

The plan for security use of this would be to give accounts to all the prenotification folks, so this would quickly become more expensive on a per-seat basis, hence I'd wait until we qualify for a free account.

Mark

On Mon, Jan 22, 2018 at 9:35 PM, Salz, Rich <rsalz at akamai.com<mailto:rsalz at akamai.com>> wrote:
Background: at the F2F we discussed using GitHub for our internal security releases, and to provide a ticketing system for our support customers and us to use.  We currently use GitLab to prepare our security releases.

Here?s the pricing summary.

A first try to get a free enterprise GitHub install failed.  I got a sales call in response to my filling out a webform. Sorry, there was no time to bring in another OMC member.

If we did a private repo hosted on GitHub, it would cost $7/mo/person, or around 756/year (I assumed we?ll have another OMC member at some point.)  Once we get 501c3 status, we could get the GH-hosted option with a private repository for free. If we want to self-host that?s GitHub enterprise it costs $21/user (minimum ten) and is billed annually, for $2500 a year. See the URL?s below.

https://github.com/pricing/business-enterprise<https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_pricing_business-2Denterprise&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=4LM0GbR0h9Fvx86FtsKI-w&m=ZDlJOAYxLl5hgKZX-ZnuqW4_CMJagceXwwIY1PLyWDA&s=t22zpwbEcUu5y6S1mSLanULn3ZumHNmxjKI8cTncgSs&e=>
https://github.com/nonprofit<https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_nonprofit&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=4LM0GbR0h9Fvx86FtsKI-w&m=ZDlJOAYxLl5hgKZX-ZnuqW4_CMJagceXwwIY1PLyWDA&s=YS0s4gJ8yXCXlYPyRWQAV76e3w0lO3CUJiHCujca6x4&e=>
https://github.com/pricing<https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_pricing&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=4LM0GbR0h9Fvx86FtsKI-w&m=ZDlJOAYxLl5hgKZX-ZnuqW4_CMJagceXwwIY1PLyWDA&s=gPq123ufWRR2kQsmREbUHARlUfGsgx_Sd11ALtFush4&e=>


From: Alison Marcozzi <alimarcozzi at github.com<mailto:alimarcozzi at github.com>>
Date: Tuesday, January 9, 2018 at 6:53 PM
To: Rich Salz <rsalz at akamai.com<mailto:rsalz at akamai.com>>
Subject: Re: Hi Rich - Just left you a voicemail

Hi again Rich,

It was great speaking with you today! As mentioned, here are the links to our pricing page<https://urldefense.proofpoint.com/v2/url?u=http-3A__t.yesware.com_tt_ba8e658a231581305b21024b160605b0c17843d6_aa36a7dd17a31e82c74b44eb09022971_1c0be20cc7f3f282330fe989a389ecf2_github.com_pricing&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=4LM0GbR0h9Fvx86FtsKI-w&m=fguf9p5WvL1vQlr8jahWmHsI2O4aY1P6Q8WVO_NyDwc&s=bMOIn5O6Uv9CysEsmXNscg0nYw5H3w9ZOCGqCljv1Qw&e=> and nonprofit page<https://urldefense.proofpoint.com/v2/url?u=https-3A__t.yesware.com_tt_ba8e658a231581305b21024b160605b0c17843d6_aa36a7dd17a31e82c74b44eb09022971_2833943519414d5d8f878972a91f1f48_github.com_nonprofit&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=4LM0GbR0h9Fvx86FtsKI-w&m=fguf9p5WvL1vQlr8jahWmHsI2O4aY1P6Q8WVO_NyDwc&s=bV2Sb4rOJqPKhDHpk4kYVm4kyp73ZmT5mRF79oBD7ow&e=>. Once you have a chance to review the pricing page, please let me know which plan you would like to move forward with and I would be happy to help!

Cheers,
Alison


--

Alison Marcozzi
Sales Development Representative- AMER
w: +1 (415) 906- 5332<tel:(415)%20906-5332>
[https://docs.google.com/uc?export=download&id=0BzaBOMULbUvrOEVJWDlKcVNzdGc&revid=0BzaBOMULbUvrZ3BFZ09xREw2UHloOStVOUxQRFd3eXF3OFdZPQ]

On Tue, Jan 9, 2018 at 10:41 AM, Salz, Rich <rsalz at akamai.com<mailto:rsalz at akamai.com>> wrote:
Great thanks

From: Alison Marcozzi <alimarcozzi at github.com<mailto:alimarcozzi at github.com>>
Date: Tuesday, January 9, 2018 at 1:26 PM
To: Rich Salz <rsalz at akamai.com<mailto:rsalz at akamai.com>>
Subject: Re: Hi Rich - Just left you a voicemail

Hi Rich,

Thank you for getting back to me! I will call you today at 4:30 pm EST today (1/9). I look forward to speaking with you!

Best,
Alison


--

Alison Marcozzi
Sales Development Representative- AMER
w: +1 (415) 906- 5332<tel:(415)%20906-5332>
[https://docs.google.com/uc?export=download&id=0BzaBOMULbUvrOEVJWDlKcVNzdGc&revid=0BzaBOMULbUvrZ3BFZ09xREw2UHloOStVOUxQRFd3eXF3OFdZPQ]

On Mon, Jan 8, 2018 at 6:26 PM, Salz, Rich <rsalz at akamai.com<mailto:rsalz at akamai.com>> wrote:
I am wide open tomorrow except 1-4.  I?m in Cambridge, MA.  Thanks.

From: Alison Marcozzi <alimarcozzi at github.com<mailto:alimarcozzi at github.com>>
Date: Monday, January 8, 2018 at 5:27 PM
To: "rsalz at openssl.org<mailto:rsalz at openssl.org>" <rsalz at openssl.org<mailto:rsalz at openssl.org>>
Subject: Hi Rich - Just left you a voicemail

Hi Rich,

Just left you a voicemail.  I am following up on your Contact Request for OpenSSL and I'd love to connect before Wednesday (1/10).  Let me know if you have time to chat on the phone, or if you would rather communicate via email thats perfectly fine as well.

I look forward to speaking and have a great day!

Cheers,

Alison


--

Alison Marcozzi
Sales Development Representative- AMER
w: +1 (415) 906- 5332<tel:(415)%20906-5332>
[https://docs.google.com/uc?export=download&id=0BzaBOMULbUvrOEVJWDlKcVNzdGc&revid=0BzaBOMULbUvrZ3BFZ09xREw2UHloOStVOUxQRFd3eXF3OFdZPQ]



_______________________________________________
openssl-project mailing list
openssl-project at openssl.org<mailto:openssl-project at openssl.org>
https://mta.openssl.org/mailman/listinfo/openssl-project<https://urldefense.proofpoint.com/v2/url?u=https-3A__mta.openssl.org_mailman_listinfo_openssl-2Dproject&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=4LM0GbR0h9Fvx86FtsKI-w&m=ZDlJOAYxLl5hgKZX-ZnuqW4_CMJagceXwwIY1PLyWDA&s=NdKHU_AQOskdfZGanC-qXTXbHSeeurXriodTmyUFZQs&e=>

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

From mark at awe.com  Tue Jan 23 14:46:05 2018
From: mark at awe.com (Mark J Cox)
Date: Tue, 23 Jan 2018 14:46:05 +0000
Subject: [openssl-project] Simplifying the security policy
In-Reply-To: <CABU6YOZRGE3i9VmLmiAmynN+1LvHmvLZFCKTerPT9YmENVPYiA@mail.gmail.com>
References: <CABU6YOZRGE3i9VmLmiAmynN+1LvHmvLZFCKTerPT9YmENVPYiA@mail.gmail.com>
Message-ID: <CABU6YOaSmjGPpkHL3g+2ieJn1q8xNiWMQJQ0ybtz8BWcXx1tsg@mail.gmail.com>

Hi, this passed an OMC vote and has been updated.  Thanks!


On Mon, Jan 15, 2018 at 3:07 PM, Mark J Cox <mark at awe.com> wrote:
> At our face to face we took a look at the security policy and noticed
> that it contained a lot of background details of why we decided on the
> policy that we did (in light mostly of the issues back in 2014) as
> well as a bit of repeated and redundant information.  I've taken some
> time to simplify it, clean it up, and remove the redundant sections
> with the intention of not changing any of the actual policy.   See
> attached draft, which I'll run a vote on if there are no silly
> mistakes or problems.
>
> https://www.openssl.org/policies/secpolicy.html
>
> Detailed changes:
> - removed introductory wordy paragraphs
> - how to report issues is already covered on another page so just
> replace with link
> - consolidate who we tell about issues into new 'triage' section (it
> was in 3 different places) explain why we work with those folks
> - take out most of the background section.  Where the background forms
> part of our reasons for doing something include them in a new section
> 'principles' at the end with the same wording.
> -- removed "the more people you tell" leak statement
> -- consolidated how we benefit from prenotifying people into earlier section
> -- removed competitive phrases
> -- removed why we don't run our own prenotification list and who we've
> tired to use in the past
> - no changes to severity wording
> - simplify prenotification section wording without changing what we do
> or who we tell
>
> Mark

From rsalz at akamai.com  Tue Jan 23 16:35:02 2018
From: rsalz at akamai.com (Salz, Rich)
Date: Tue, 23 Jan 2018 16:35:02 +0000
Subject: [openssl-project] Welcome Dr. Matthias St. Pierre
Message-ID: <E128F56B-8BA2-464F-97C7-BB429035DF9C@akamai.com>

Please welcome Matthias as our newest committer.

I have added him to the committers email list, and enabled posting privileges to the project mailing list.  In a little while, Richard should have his SSH keys integrated into our systems, and will email him some more detailed instructions.

Thanks.

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

From matt at openssl.org  Tue Jan 23 16:49:20 2018
From: matt at openssl.org (Matt Caswell)
Date: Tue, 23 Jan 2018 16:49:20 +0000
Subject: [openssl-project] Welcome Dr. Matthias St. Pierre
In-Reply-To: <E128F56B-8BA2-464F-97C7-BB429035DF9C@akamai.com>
References: <E128F56B-8BA2-464F-97C7-BB429035DF9C@akamai.com>
Message-ID: <aaf59f86-69d2-5971-14fa-2dc8ef624d94@openssl.org>

I invited him to the committers team on github.

Welcome Matthias!

Matt


On 23/01/18 16:35, Salz, Rich wrote:
> Please welcome Matthias as our newest committer.
> 
> ?
> 
> I have added him to the committers email list, and enabled posting
> privileges to the project mailing list.? In a little while, Richard
> should have his SSH keys integrated into our systems, and will email him
> some more detailed instructions.
> 
> ?
> 
> Thanks.
> 
> ?
> 
> 
> 
> _______________________________________________
> openssl-project mailing list
> openssl-project at openssl.org
> https://mta.openssl.org/mailman/listinfo/openssl-project
> 

From Matthias.St.Pierre at ncp-e.com  Tue Jan 23 16:56:02 2018
From: Matthias.St.Pierre at ncp-e.com (Dr. Matthias St. Pierre)
Date: Tue, 23 Jan 2018 17:56:02 +0100
Subject: [openssl-project] Welcome Dr. Matthias St. Pierre
In-Reply-To: <aaf59f86-69d2-5971-14fa-2dc8ef624d94@openssl.org>
References: <E128F56B-8BA2-464F-97C7-BB429035DF9C@akamai.com>
 <aaf59f86-69d2-5971-14fa-2dc8ef624d94@openssl.org>
Message-ID: <1b572723-5d3b-fd62-8add-01b2aff0cae1@ncp-e.com>

Thank you everybody! Feels great to be here!

Matthias


On 23.01.2018 17:49, Matt Caswell wrote:
> I invited him to the committers team on github.
>
> Welcome Matthias!
>
> Matt
>
>
> On 23/01/18 16:35, Salz, Rich wrote:
>> Please welcome Matthias as our newest committer.
>>
>> ?
>>
>> I have added him to the committers email list, and enabled posting
>> privileges to the project mailing list.? In a little while, Richard
>> should have his SSH keys integrated into our systems, and will email him
>> some more detailed instructions.
>>
>> ?
>>
>> Thanks.
>>
>> ?
>>
>>
>>
>> _______________________________________________
>> openssl-project mailing list
>> openssl-project at openssl.org
>> https://mta.openssl.org/mailman/listinfo/openssl-project
>>
> _______________________________________________
> openssl-project mailing list
> openssl-project at openssl.org
> https://mta.openssl.org/mailman/listinfo/openssl-project


From matt at openssl.org  Tue Jan 23 17:49:53 2018
From: matt at openssl.org (Matt Caswell)
Date: Tue, 23 Jan 2018 17:49:53 +0000
Subject: [openssl-project] Issues review
Message-ID: <48db012c-58a3-3bae-14e7-65ebb310be78@openssl.org>

I completed my first pass review of all issues. I still need to look at
PRs. I have put all PRs against a milestone using the following criteria:

If it only applies to 1.0.2 or below: 1.0.2 milestone
If it only applies to 1.1.0 or below: 1.1.0 milesone
If it's API/ABI breaking to fix: 1.2.0 milestone
If it's a feature request that we aren't already planning to do for
1.1.1: Post 1.1.1 milestone
If it's something which is independent of a release (e.g. web issues,
policy/procedure etc): Other milestone
If it applies to master and doesn't fit into one of the categories
above: 1.1.1 milestone


Some stats:

We now have 249 issues open.
Since I started this exercise we have closed 134 issues.
Issues against 1.0.2: 17
Issues against 1.1.0: 3
Issues against 1.1.1: 141
Issues against 1.2.0: 15
Issues against Post 1.1.1: 58
Issues against Other: 15


Matt

From matt at openssl.org  Tue Jan 23 17:51:41 2018
From: matt at openssl.org (Matt Caswell)
Date: Tue, 23 Jan 2018 17:51:41 +0000
Subject: [openssl-project] Issues review
In-Reply-To: <48db012c-58a3-3bae-14e7-65ebb310be78@openssl.org>
References: <48db012c-58a3-3bae-14e7-65ebb310be78@openssl.org>
Message-ID: <9284c814-e666-f30c-fafc-baf0a787f1a1@openssl.org>



On 23/01/18 17:49, Matt Caswell wrote:
> I completed my first pass review of all issues. I still need to look at
> PRs. I have put all PRs against a milestone using the following criteria:

I have put all *issues* against a milestone not PR!!

> 
> If it only applies to 1.0.2 or below: 1.0.2 milestone
> If it only applies to 1.1.0 or below: 1.1.0 milesone
> If it's API/ABI breaking to fix: 1.2.0 milestone
> If it's a feature request that we aren't already planning to do for
> 1.1.1: Post 1.1.1 milestone
> If it's something which is independent of a release (e.g. web issues,
> policy/procedure etc): Other milestone
> If it applies to master and doesn't fit into one of the categories
> above: 1.1.1 milestone
> 
> 
> Some stats:
> 
> We now have 249 issues open.
> Since I started this exercise we have closed 134 issues.
> Issues against 1.0.2: 17
> Issues against 1.1.0: 3
> Issues against 1.1.1: 141
> Issues against 1.2.0: 15
> Issues against Post 1.1.1: 58
> Issues against Other: 15
> 
> 
> Matt
> _______________________________________________
> openssl-project mailing list
> openssl-project at openssl.org
> https://mta.openssl.org/mailman/listinfo/openssl-project
> 

From rsalz at akamai.com  Tue Jan 23 18:04:08 2018
From: rsalz at akamai.com (Salz, Rich)
Date: Tue, 23 Jan 2018 18:04:08 +0000
Subject: [openssl-project] Issues review
In-Reply-To: <9284c814-e666-f30c-fafc-baf0a787f1a1@openssl.org>
References: <48db012c-58a3-3bae-14e7-65ebb310be78@openssl.org>
 <9284c814-e666-f30c-fafc-baf0a787f1a1@openssl.org>
Message-ID: <7D94B372-5AB2-4246-B011-49DFE1F06ACD@akamai.com>

I reviewed all PR?s and issues that have FIPS in the text and closed most of them as not relevant.

On 1/23/18, 12:51 PM, "Matt Caswell" <matt at openssl.org> wrote:

    
    
    On 23/01/18 17:49, Matt Caswell wrote:
    > I completed my first pass review of all issues. I still need to look at
    > PRs. I have put all PRs against a milestone using the following criteria:
    
    I have put all *issues* against a milestone not PR!!
    
    > 
    > If it only applies to 1.0.2 or below: 1.0.2 milestone
    > If it only applies to 1.1.0 or below: 1.1.0 milesone
    > If it's API/ABI breaking to fix: 1.2.0 milestone
    > If it's a feature request that we aren't already planning to do for
    > 1.1.1: Post 1.1.1 milestone
    > If it's something which is independent of a release (e.g. web issues,
    > policy/procedure etc): Other milestone
    > If it applies to master and doesn't fit into one of the categories
    > above: 1.1.1 milestone
    > 
    > 
    > Some stats:
    > 
    > We now have 249 issues open.
    > Since I started this exercise we have closed 134 issues.
    > Issues against 1.0.2: 17
    > Issues against 1.1.0: 3
    > Issues against 1.1.1: 141
    > Issues against 1.2.0: 15
    > Issues against Post 1.1.1: 58
    > Issues against Other: 15
    > 
    > 
    > Matt
    > _______________________________________________
    > openssl-project mailing list
    > openssl-project at openssl.org
    > https://mta.openssl.org/mailman/listinfo/openssl-project
    > 
    _______________________________________________
    openssl-project mailing list
    openssl-project at openssl.org
    https://mta.openssl.org/mailman/listinfo/openssl-project
    


From kaduk at mit.edu  Tue Jan 23 18:05:01 2018
From: kaduk at mit.edu (Benjamin Kaduk)
Date: Tue, 23 Jan 2018 12:05:01 -0600
Subject: [openssl-project] Issues review
In-Reply-To: <9284c814-e666-f30c-fafc-baf0a787f1a1@openssl.org>
References: <48db012c-58a3-3bae-14e7-65ebb310be78@openssl.org>
 <9284c814-e666-f30c-fafc-baf0a787f1a1@openssl.org>
Message-ID: <20180123180500.GZ93961@mit.edu>

On Tue, Jan 23, 2018 at 05:51:41PM +0000, Matt Caswell wrote:
> 
> 
> On 23/01/18 17:49, Matt Caswell wrote:
> > I completed my first pass review of all issues. I still need to look at
> > PRs. I have put all PRs against a milestone using the following criteria:
> 
> I have put all *issues* against a milestone not PR!!

Do we still need to review the issues assigned to milestones that
have already happened (e.g., 1.1.0, post-1.1.0)?

-Ben

From matt at openssl.org  Tue Jan 23 18:11:50 2018
From: matt at openssl.org (Matt Caswell)
Date: Tue, 23 Jan 2018 18:11:50 +0000
Subject: [openssl-project] Issues review
In-Reply-To: <20180123180500.GZ93961@mit.edu>
References: <48db012c-58a3-3bae-14e7-65ebb310be78@openssl.org>
 <9284c814-e666-f30c-fafc-baf0a787f1a1@openssl.org>
 <20180123180500.GZ93961@mit.edu>
Message-ID: <feb33236-feaa-89dd-8ee8-8767668bc7c7@openssl.org>



On 23/01/18 18:05, Benjamin Kaduk wrote:
> On Tue, Jan 23, 2018 at 05:51:41PM +0000, Matt Caswell wrote:
>>
>>
>> On 23/01/18 17:49, Matt Caswell wrote:
>>> I completed my first pass review of all issues. I still need to look at
>>> PRs. I have put all PRs against a milestone using the following criteria:
>>
>> I have put all *issues* against a milestone not PR!!
> 
> Do we still need to review the issues assigned to milestones that
> have already happened (e.g., 1.1.0, post-1.1.0)?

There no issues against post-1.1.0 (there are PRs - but that will be
fixed when I do the PR review).

1.1.0 and 1.0.2 are still supported so issues against those milestones
are still relevant. They are *not* relevant to the 1.1.1 release
timetable though (which is why I started this exercise). Consider an
issues against the 1.1.0 milestone to mean, relevant to the next 1.1.0
letter release.

Matt


From kaduk at mit.edu  Tue Jan 23 20:55:09 2018
From: kaduk at mit.edu (Benjamin Kaduk)
Date: Tue, 23 Jan 2018 14:55:09 -0600
Subject: [openssl-project] Issues review
In-Reply-To: <feb33236-feaa-89dd-8ee8-8767668bc7c7@openssl.org>
References: <48db012c-58a3-3bae-14e7-65ebb310be78@openssl.org>
 <9284c814-e666-f30c-fafc-baf0a787f1a1@openssl.org>
 <20180123180500.GZ93961@mit.edu>
 <feb33236-feaa-89dd-8ee8-8767668bc7c7@openssl.org>
Message-ID: <20180123205509.GA33102@kduck.kaduk.org>

On Tue, Jan 23, 2018 at 06:11:50PM +0000, Matt Caswell wrote:
> 
> 
> On 23/01/18 18:05, Benjamin Kaduk wrote:
> > On Tue, Jan 23, 2018 at 05:51:41PM +0000, Matt Caswell wrote:
> >>
> >>
> >> On 23/01/18 17:49, Matt Caswell wrote:
> >>> I completed my first pass review of all issues. I still need to look at
> >>> PRs. I have put all PRs against a milestone using the following criteria:
> >>
> >> I have put all *issues* against a milestone not PR!!
> > 
> > Do we still need to review the issues assigned to milestones that
> > have already happened (e.g., 1.1.0, post-1.1.0)?
> 
> There no issues against post-1.1.0 (there are PRs - but that will be
> fixed when I do the PR review).
> 
> 1.1.0 and 1.0.2 are still supported so issues against those milestones
> are still relevant. They are *not* relevant to the 1.1.1 release
> timetable though (which is why I started this exercise). Consider an
> issues against the 1.1.0 milestone to mean, relevant to the next 1.1.0
> letter release.

That's great if that's the intent, but I don't think that the
current application of those tags is consistent with the above
description.  For example, #1418 is a somewhat abstract question of
what it means for acertificate to be self-signed, yet has the 1.0.2
milestone, when (to me) 1.2.0 would seem more appropriate.

-Ben

From paul.dale at oracle.com  Tue Jan 23 21:36:07 2018
From: paul.dale at oracle.com (Paul Dale)
Date: Tue, 23 Jan 2018 13:36:07 -0800 (PST)
Subject: [openssl-project] Welcome Dr. Matthias St. Pierre
In-Reply-To: <1b572723-5d3b-fd62-8add-01b2aff0cae1@ncp-e.com>
References: <E128F56B-8BA2-464F-97C7-BB429035DF9C@akamai.com>
 <aaf59f86-69d2-5971-14fa-2dc8ef624d94@openssl.org>
 <1b572723-5d3b-fd62-8add-01b2aff0cae1@ncp-e.com>
Message-ID: <6310f115-8f70-4956-aa59-2a7d35cf9d3c@default>

Very much deserved.  Congratulations Matthias.


Pauli
-- 
Oracle
Dr Paul Dale | Cryptographer | Network Security & Encryption 
Phone +61 7 3031 7217
Oracle Australia

-----Original Message-----
From: Dr. Matthias St. Pierre [mailto:Matthias.St.Pierre at ncp-e.com] 
Sent: Wednesday, 24 January 2018 2:56 AM
To: openssl-project at openssl.org
Subject: Re: [openssl-project] Welcome Dr. Matthias St. Pierre

Thank you everybody! Feels great to be here!

Matthias


On 23.01.2018 17:49, Matt Caswell wrote:
> I invited him to the committers team on github.
>
> Welcome Matthias!
>
> Matt
>
>
> On 23/01/18 16:35, Salz, Rich wrote:
>> Please welcome Matthias as our newest committer.
>>
>> ?
>>
>> I have added him to the committers email list, and enabled posting 
>> privileges to the project mailing list.? In a little while, Richard 
>> should have his SSH keys integrated into our systems, and will email 
>> him some more detailed instructions.
>>
>> ?
>>
>> Thanks.
>>
>> ?
>>
>>
>>
>> _______________________________________________
>> openssl-project mailing list
>> openssl-project at openssl.org
>> https://mta.openssl.org/mailman/listinfo/openssl-project
>>
> _______________________________________________
> openssl-project mailing list
> openssl-project at openssl.org
> https://mta.openssl.org/mailman/listinfo/openssl-project

_______________________________________________
openssl-project mailing list
openssl-project at openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project

From levitte at openssl.org  Tue Jan 23 22:55:39 2018
From: levitte at openssl.org (Richard Levitte)
Date: Tue, 23 Jan 2018 23:55:39 +0100 (CET)
Subject: [openssl-project] Welcome Dr. Matthias St. Pierre
In-Reply-To: <E128F56B-8BA2-464F-97C7-BB429035DF9C@akamai.com>
References: <E128F56B-8BA2-464F-97C7-BB429035DF9C@akamai.com>
Message-ID: <20180123.235539.145165079432396539.levitte@openssl.org>

In message <E128F56B-8BA2-464F-97C7-BB429035DF9C at akamai.com> on Tue, 23 Jan 2018 16:35:02 +0000, "Salz, Rich" <rsalz at akamai.com> said:

rsalz> In a little while, Richard should have his SSH keys integrated
rsalz> into our systems, and will email him some more detailed
rsalz> instructions.

Done and done!  Welcome, Matthias

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

From matt at openssl.org  Tue Jan 23 23:20:20 2018
From: matt at openssl.org (Matt Caswell)
Date: Tue, 23 Jan 2018 23:20:20 +0000
Subject: [openssl-project] Issues review
In-Reply-To: <20180123205509.GA33102@kduck.kaduk.org>
References: <48db012c-58a3-3bae-14e7-65ebb310be78@openssl.org>
 <9284c814-e666-f30c-fafc-baf0a787f1a1@openssl.org>
 <20180123180500.GZ93961@mit.edu>
 <feb33236-feaa-89dd-8ee8-8767668bc7c7@openssl.org>
 <20180123205509.GA33102@kduck.kaduk.org>
Message-ID: <0e506951-e83f-b7d0-6930-89bb2dde87a9@openssl.org>



On 23/01/18 20:55, Benjamin Kaduk wrote:
> On Tue, Jan 23, 2018 at 06:11:50PM +0000, Matt Caswell wrote:
>>
>>
>> On 23/01/18 18:05, Benjamin Kaduk wrote:
>>> On Tue, Jan 23, 2018 at 05:51:41PM +0000, Matt Caswell wrote:
>>>>
>>>>
>>>> On 23/01/18 17:49, Matt Caswell wrote:
>>>>> I completed my first pass review of all issues. I still need to look at
>>>>> PRs. I have put all PRs against a milestone using the following criteria:
>>>>
>>>> I have put all *issues* against a milestone not PR!!
>>>
>>> Do we still need to review the issues assigned to milestones that
>>> have already happened (e.g., 1.1.0, post-1.1.0)?
>>
>> There no issues against post-1.1.0 (there are PRs - but that will be
>> fixed when I do the PR review).
>>
>> 1.1.0 and 1.0.2 are still supported so issues against those milestones
>> are still relevant. They are *not* relevant to the 1.1.1 release
>> timetable though (which is why I started this exercise). Consider an
>> issues against the 1.1.0 milestone to mean, relevant to the next 1.1.0
>> letter release.
> 
> That's great if that's the intent, but I don't think that the
> current application of those tags is consistent with the above
> description.  For example, #1418 is a somewhat abstract question of
> what it means for acertificate to be self-signed, yet has the 1.0.2
> milestone, when (to me) 1.2.0 would seem more appropriate.

That *is* the intent. What I've done here is *triage* - spending a few
minutes on each one to assess the correct milestone. It would not
surprise me to learn that, having done that for over 380 issues, we
might have come to a different assessment on a few of them. :-)

To be absolutely sure though I just re-reviewed all of those issues
against the 1.0.2 and 1.1.0 milestones (there weren't that many of
them), to make sure I got them right. I made 2 or 3 changes including to
the issue you highlighted (moving it to the "Post 1.1.1" milestone).
Feel free to make any other adjustments you think might be necessary as
you come across them.

The primary objective here is to inform the debate on the release
criteria for 1.1.1 and the associated timeframes. You will recall that
one of the proposed criteria was:

"- All open github issues/PRs older than 2 weeks at the time of release
to be assessed for relevance to 1.1.1. Any flagged with the 1.1.1
milestone to be closed (see below)

...

Valid reasons for closing an issue/PR with a 1.1.1 milestone might be:
- We have just now or sometime in the past fixed the issue
- Unable to reproduce (following discussion with original reporter if
possible)
- Working as intended
- Deliberate decision not to fix until a later release
- Not enough information and unable to contact reporter
- etc"

We then got into discussions about timeframes - which was difficult
without knowing the scope of the work.

Although there may be some disagreements on a few of the issues. I am
confident that the milestones as they are currently set are broadly
correct - and a good basis for planning.

Matt


From kaduk at mit.edu  Wed Jan 24 03:01:07 2018
From: kaduk at mit.edu (Benjamin Kaduk)
Date: Tue, 23 Jan 2018 21:01:07 -0600
Subject: [openssl-project] Issues review
In-Reply-To: <0e506951-e83f-b7d0-6930-89bb2dde87a9@openssl.org>
References: <48db012c-58a3-3bae-14e7-65ebb310be78@openssl.org>
 <9284c814-e666-f30c-fafc-baf0a787f1a1@openssl.org>
 <20180123180500.GZ93961@mit.edu>
 <feb33236-feaa-89dd-8ee8-8767668bc7c7@openssl.org>
 <20180123205509.GA33102@kduck.kaduk.org>
 <0e506951-e83f-b7d0-6930-89bb2dde87a9@openssl.org>
Message-ID: <20180124030107.GC3284@kduck.kaduk.org>

On Tue, Jan 23, 2018 at 11:20:20PM +0000, Matt Caswell wrote:
> 
> 
> On 23/01/18 20:55, Benjamin Kaduk wrote:
> > On Tue, Jan 23, 2018 at 06:11:50PM +0000, Matt Caswell wrote:
> >>
> >>
> >> 1.1.0 and 1.0.2 are still supported so issues against those milestones
> >> are still relevant. They are *not* relevant to the 1.1.1 release
> >> timetable though (which is why I started this exercise). Consider an
> >> issues against the 1.1.0 milestone to mean, relevant to the next 1.1.0
> >> letter release.
> > 
> > That's great if that's the intent, but I don't think that the
> > current application of those tags is consistent with the above
> > description.  For example, #1418 is a somewhat abstract question of
> > what it means for acertificate to be self-signed, yet has the 1.0.2
> > milestone, when (to me) 1.2.0 would seem more appropriate.
> 
> That *is* the intent. What I've done here is *triage* - spending a few
> minutes on each one to assess the correct milestone. It would not
> surprise me to learn that, having done that for over 380 issues, we
> might have come to a different assessment on a few of them. :-)

Understood.  Hopefully the bits I did last week helped with the
triage.

I mostly was just not sure if this has always been the policy, or if
there was a period of time when things were much more haphazard as
we first started using github.  Going forward I expect that we'll be
in better shape.

> To be absolutely sure though I just re-reviewed all of those issues
> against the 1.0.2 and 1.1.0 milestones (there weren't that many of
> them), to make sure I got them right. I made 2 or 3 changes including to
> the issue you highlighted (moving it to the "Post 1.1.1" milestone).

Thank you; I do appreciate it!

> Feel free to make any other adjustments you think might be necessary as
> you come across them.

Okay.  I may try to look at the 1.0.2 and 1.1.0 issues, but really
ought to finish up the draft-23 support PR first :)

> Although there may be some disagreements on a few of the issues. I am
> confident that the milestones as they are currently set are broadly
> correct - and a good basis for planning.

We should probably revive the release timeline/planning thread now,
yes.

-Ben

From emilia at openssl.org  Wed Jan 24 10:07:39 2018
From: emilia at openssl.org (=?UTF-8?Q?Emilia_K=C3=A4sper?=)
Date: Wed, 24 Jan 2018 10:07:39 +0000
Subject: [openssl-project] Welcome Dr. Matthias St. Pierre
In-Reply-To: <20180123.235539.145165079432396539.levitte@openssl.org>
References: <E128F56B-8BA2-464F-97C7-BB429035DF9C@akamai.com>
 <20180123.235539.145165079432396539.levitte@openssl.org>
Message-ID: <CAGZjfUbwFqfbA2FAMAvk9zCCYmBufDQSUmRGTjyr_fwm-Kc17g@mail.gmail.com>

Welcome!

On Tue, Jan 23, 2018 at 11:55 PM Richard Levitte <levitte at openssl.org>
wrote:

> In message <E128F56B-8BA2-464F-97C7-BB429035DF9C at akamai.com> on Tue, 23
> Jan 2018 16:35:02 +0000, "Salz, Rich" <rsalz at akamai.com> said:
>
> rsalz> In a little while, Richard should have his SSH keys integrated
> rsalz> into our systems, and will email him some more detailed
> rsalz> instructions.
>
> Done and done!  Welcome, Matthias
>
> --
> Richard Levitte         levitte at openssl.org
> OpenSSL Project         http://www.openssl.org/~levitte/
> _______________________________________________
> openssl-project mailing list
> openssl-project at openssl.org
> https://mta.openssl.org/mailman/listinfo/openssl-project
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-project/attachments/20180124/632c9607/attachment.html>

From levitte at openssl.org  Wed Jan 24 13:10:58 2018
From: levitte at openssl.org (Richard Levitte)
Date: Wed, 24 Jan 2018 14:10:58 +0100 (CET)
Subject: [openssl-project] Speaking of releases,
	did we finalize a release plan for 1.1.1?
Message-ID: <20180124.141058.1626360301389343190.levitte@openssl.org>

I can't seem to remember a final agreement...  last thing I remember
is a disagreement of what "the last alpha" means in practice, and that
I finally got Matt's point with having it being a feature freeze in
practice.  But a final release plan, I can't remember one.

Time to reiterate this, perhaps?

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

From matt at openssl.org  Wed Jan 24 13:41:16 2018
From: matt at openssl.org (Matt Caswell)
Date: Wed, 24 Jan 2018 13:41:16 +0000
Subject: [openssl-project] Speaking of releases,
 did we finalize a release plan for 1.1.1?
In-Reply-To: <20180124.141058.1626360301389343190.levitte@openssl.org>
References: <20180124.141058.1626360301389343190.levitte@openssl.org>
Message-ID: <fb80cd57-15ed-d4b6-9280-58d4582084d7@openssl.org>



On 24/01/18 13:10, Richard Levitte wrote:
> I can't seem to remember a final agreement...  last thing I remember
> is a disagreement of what "the last alpha" means in practice, and that
> I finally got Matt's point with having it being a feature freeze in
> practice.  But a final release plan, I can't remember one.
> 
> Time to reiterate this, perhaps?
> 

There was some debate around how many/how long the release cycles should
be. Part of the problem was that it is difficult to quantify the amount
of work required to close off old issues (assuming we go with my
proposed release criteria). That is the motivation for the work I have
been doing reviewing the issues (and now the PRs). I have been going
through them all and assigning a milestone to them. When I have
completed that work I will revive the discussion on release plan.

Matt

From matt at openssl.org  Wed Jan 24 17:06:23 2018
From: matt at openssl.org (Matt Caswell)
Date: Wed, 24 Jan 2018 17:06:23 +0000
Subject: [openssl-project] Issues review
In-Reply-To: <48db012c-58a3-3bae-14e7-65ebb310be78@openssl.org>
References: <48db012c-58a3-3bae-14e7-65ebb310be78@openssl.org>
Message-ID: <07724fdb-1a93-4065-6153-c00a2425437a@openssl.org>

I have now also reviewed the PRs.

We currently have 144 PRs open:
PRs against 1.0.2: 6
PRs against 1.1.0: 7
PRs against 1.1.1: 55
PRs against 1.2.0: 9
PRs against Post 1.1.1: 63
PRs against Other: 2

I was quite strict about allocating PRs to a milestone. This might mean
that some of those decisions are controversial. Basically if a PR was
about adding a feature, and it wasn't directly TLSv1.3 related (which is
the stated primary objective for the release) then I put it against the
Post 1.1.1 milestone.

This does *not* mean that I think that a PR flagged as "Post 1.1.1"
shouldn't go into 1.1.1. It just means that it is not relevant as far as
the release criteria go - if it makes it into the release then great; if
it doesn't - well we're not going to hold up the release schedule for it.

If there are individual cases where you think a PR absolutely *MUST* go
into 1.1.1 for whatever reason (to the point that we should hold up the
release schedule for it) then we can argue that out on a case-by-case
basis and amend the milestones accordingly. Alternatively just make sure
you get it reviewed and committed before feature freeze.

Matt


On 23/01/18 17:49, Matt Caswell wrote:
> I completed my first pass review of all issues. I still need to look at
> PRs. I have put all PRs against a milestone using the following criteria:
> 
> If it only applies to 1.0.2 or below: 1.0.2 milestone
> If it only applies to 1.1.0 or below: 1.1.0 milesone
> If it's API/ABI breaking to fix: 1.2.0 milestone
> If it's a feature request that we aren't already planning to do for
> 1.1.1: Post 1.1.1 milestone
> If it's something which is independent of a release (e.g. web issues,
> policy/procedure etc): Other milestone
> If it applies to master and doesn't fit into one of the categories
> above: 1.1.1 milestone
> 
> 
> Some stats:
> 
> We now have 249 issues open.
> Since I started this exercise we have closed 134 issues.
> Issues against 1.0.2: 17
> Issues against 1.1.0: 3
> Issues against 1.1.1: 141
> Issues against 1.2.0: 15
> Issues against Post 1.1.1: 58
> Issues against Other: 15
> 
> 
> Matt
> _______________________________________________
> openssl-project mailing list
> openssl-project at openssl.org
> https://mta.openssl.org/mailman/listinfo/openssl-project
> 

From matt at openssl.org  Wed Jan 24 17:32:00 2018
From: matt at openssl.org (Matt Caswell)
Date: Wed, 24 Jan 2018 17:32:00 +0000
Subject: [openssl-project] 1.1.1 Release timetable (again)
Message-ID: <c6011243-36f6-5dec-11df-b32cff90c147@openssl.org>

Reviving the 1.1.1 release timetable discussion now that we have a
clearer idea of the scope of outstanding issues/PRs.

Here is my updated straw man proposal for the 1.1.1 release timetable.
The only changes to this from my original proposal is to shift the dates
(because in my original proposal we would already have done the first
alpha) and I have relabelled the second release as a "beta". My original
plan called this an alpha with feature freeze at the same time, which
people (vehemently) objected to. :-)

14th February 2018, alpha release 1 (pre1)
14th March 2018, beta release 1 (pre2)
	OpenSSL_1_1_1-stable created (feature freeze)
	master becomes basis for 1.1.2 or 1.2.0 (TBD)
11th March 2018, beta release 2 (pre3)
9th May 2018, 1.1.1 public release (assuming TLSv1.3 RFC is published)

An alpha release means:
- Not (necessarily) feature complete
- Not necessarily all new APIs in place yet

A beta release means:
- Feature complete/Feature freeze
- Bug fixes only

My proposed release criteria are:
- All open github issues/PRs older than 2 weeks at the time of release
to be assessed for relevance to 1.1.1. Any flagged with the 1.1.1
milestone to be closed (see below)
- Clean builds in Travis and Appveyor for two days
- run-checker.sh to be showing as clean 2 days before release
- No open Coverity issues (not flagged as "False Positive" or "Ignore")
- TLSv1.3 RFC published

Valid reasons for closing an issue/PR with a 1.1.1 milestone might be:
- We have just now or sometime in the past fixed the issue
- Unable to reproduce (following discussion with original reporter if
possible)
- Working as intended
- Deliberate decision not to fix until a later release (this wouldn't
actually close the issue/PR but change the milestone instead)
- Not enough information and unable to contact reporter
- etc

This plan gives us 2 months from feature freeze to get all issues and
PRs with the 1.1.1 milestone closed (or assigned to a different
milestone). Currently this stands at 141 issues and 55 PRs. In practice
I think the only way we get through that lot is to make explicit
decisions not to fix/implement some of them and change the milestone.
But I think making explicit decisions about these rather than just
letting them drift indefinitely is a good thing.

If the TLSv1.3 RFC is not published by the time we are ready to release,
or we haven't made the progress we want on the other release criteria
then we can add additional betas as we see fit until such time as we are
ready.

Matt

From matt at openssl.org  Wed Jan 24 17:34:28 2018
From: matt at openssl.org (Matt Caswell)
Date: Wed, 24 Jan 2018 17:34:28 +0000
Subject: [openssl-project] 1.1.1 Release timetable (again)
In-Reply-To: <c6011243-36f6-5dec-11df-b32cff90c147@openssl.org>
References: <c6011243-36f6-5dec-11df-b32cff90c147@openssl.org>
Message-ID: <024d1439-a88b-c4ce-0f6d-282089b41144@openssl.org>



On 24/01/18 17:32, Matt Caswell wrote:
> 14th March 2018, beta release 1 (pre2)
> 	OpenSSL_1_1_1-stable created (feature freeze)
> 	master becomes basis for 1.1.2 or 1.2.0 (TBD)
> 11th March 2018, beta release 2 (pre3)

That should of course say 11th April.

Matt

From rsalz at akamai.com  Wed Jan 24 19:12:27 2018
From: rsalz at akamai.com (Salz, Rich)
Date: Wed, 24 Jan 2018 19:12:27 +0000
Subject: [openssl-project] 1.1.1 Release timetable (again)
In-Reply-To: <c6011243-36f6-5dec-11df-b32cff90c147@openssl.org>
References: <c6011243-36f6-5dec-11df-b32cff90c147@openssl.org>
Message-ID: <960F4FFA-8EEC-41A2-BD47-CFB119BC99EA@akamai.com>

A monthly release cadence for beta seems too long.  I would prefer two weeks.  And we keep doing that until TLS 1.3 is published.


On 1/24/18, 12:32 PM, "Matt Caswell" <matt at openssl.org> wrote:

    Reviving the 1.1.1 release timetable discussion now that we have a
    clearer idea of the scope of outstanding issues/PRs.
    
    Here is my updated straw man proposal for the 1.1.1 release timetable.
    The only changes to this from my original proposal is to shift the dates
    (because in my original proposal we would already have done the first
    alpha) and I have relabelled the second release as a "beta". My original
    plan called this an alpha with feature freeze at the same time, which
    people (vehemently) objected to. :-)
    
    14th February 2018, alpha release 1 (pre1)
    14th March 2018, beta release 1 (pre2)
    	OpenSSL_1_1_1-stable created (feature freeze)
    	master becomes basis for 1.1.2 or 1.2.0 (TBD)
    11th March 2018, beta release 2 (pre3)
    9th May 2018, 1.1.1 public release (assuming TLSv1.3 RFC is published)
    
    An alpha release means:
    - Not (necessarily) feature complete
    - Not necessarily all new APIs in place yet
    
    A beta release means:
    - Feature complete/Feature freeze
    - Bug fixes only
    
    My proposed release criteria are:
    - All open github issues/PRs older than 2 weeks at the time of release
    to be assessed for relevance to 1.1.1. Any flagged with the 1.1.1
    milestone to be closed (see below)
    - Clean builds in Travis and Appveyor for two days
    - run-checker.sh to be showing as clean 2 days before release
    - No open Coverity issues (not flagged as "False Positive" or "Ignore")
    - TLSv1.3 RFC published
    
    Valid reasons for closing an issue/PR with a 1.1.1 milestone might be:
    - We have just now or sometime in the past fixed the issue
    - Unable to reproduce (following discussion with original reporter if
    possible)
    - Working as intended
    - Deliberate decision not to fix until a later release (this wouldn't
    actually close the issue/PR but change the milestone instead)
    - Not enough information and unable to contact reporter
    - etc
    
    This plan gives us 2 months from feature freeze to get all issues and
    PRs with the 1.1.1 milestone closed (or assigned to a different
    milestone). Currently this stands at 141 issues and 55 PRs. In practice
    I think the only way we get through that lot is to make explicit
    decisions not to fix/implement some of them and change the milestone.
    But I think making explicit decisions about these rather than just
    letting them drift indefinitely is a good thing.
    
    If the TLSv1.3 RFC is not published by the time we are ready to release,
    or we haven't made the progress we want on the other release criteria
    then we can add additional betas as we see fit until such time as we are
    ready.
    
    Matt
    _______________________________________________
    openssl-project mailing list
    openssl-project at openssl.org
    https://mta.openssl.org/mailman/listinfo/openssl-project
    


From matt at openssl.org  Wed Jan 24 20:48:54 2018
From: matt at openssl.org (Matt Caswell)
Date: Wed, 24 Jan 2018 20:48:54 +0000
Subject: [openssl-project] 1.1.1 Release timetable (again)
In-Reply-To: <960F4FFA-8EEC-41A2-BD47-CFB119BC99EA@akamai.com>
References: <c6011243-36f6-5dec-11df-b32cff90c147@openssl.org>
 <960F4FFA-8EEC-41A2-BD47-CFB119BC99EA@akamai.com>
Message-ID: <a854cb79-3cab-dea2-e29e-76666d97273f@openssl.org>



On 24/01/18 19:12, Salz, Rich wrote:
> A monthly release cadence for beta seems too long.  I would prefer two weeks.  And we keep doing that until TLS 1.3 is published.

That might be ok. As a technical issue though we can only have a maximum
of 14 alpha/beta releases (due to the format of OPENSSL_VERSION_NUMBER
in opensslv.h). If we were to do a release every 2 weeks starting on
14th Feb, that would mean the last beta we could possibly do would be on
15th August.  If there is a risk that the TLSv1.3 publication could go
beyond that date then we would be stuck.

Matt

> 
> 
> On 1/24/18, 12:32 PM, "Matt Caswell" <matt at openssl.org> wrote:
> 
>     Reviving the 1.1.1 release timetable discussion now that we have a
>     clearer idea of the scope of outstanding issues/PRs.
>     
>     Here is my updated straw man proposal for the 1.1.1 release timetable.
>     The only changes to this from my original proposal is to shift the dates
>     (because in my original proposal we would already have done the first
>     alpha) and I have relabelled the second release as a "beta". My original
>     plan called this an alpha with feature freeze at the same time, which
>     people (vehemently) objected to. :-)
>     
>     14th February 2018, alpha release 1 (pre1)
>     14th March 2018, beta release 1 (pre2)
>     	OpenSSL_1_1_1-stable created (feature freeze)
>     	master becomes basis for 1.1.2 or 1.2.0 (TBD)
>     11th March 2018, beta release 2 (pre3)
>     9th May 2018, 1.1.1 public release (assuming TLSv1.3 RFC is published)
>     
>     An alpha release means:
>     - Not (necessarily) feature complete
>     - Not necessarily all new APIs in place yet
>     
>     A beta release means:
>     - Feature complete/Feature freeze
>     - Bug fixes only
>     
>     My proposed release criteria are:
>     - All open github issues/PRs older than 2 weeks at the time of release
>     to be assessed for relevance to 1.1.1. Any flagged with the 1.1.1
>     milestone to be closed (see below)
>     - Clean builds in Travis and Appveyor for two days
>     - run-checker.sh to be showing as clean 2 days before release
>     - No open Coverity issues (not flagged as "False Positive" or "Ignore")
>     - TLSv1.3 RFC published
>     
>     Valid reasons for closing an issue/PR with a 1.1.1 milestone might be:
>     - We have just now or sometime in the past fixed the issue
>     - Unable to reproduce (following discussion with original reporter if
>     possible)
>     - Working as intended
>     - Deliberate decision not to fix until a later release (this wouldn't
>     actually close the issue/PR but change the milestone instead)
>     - Not enough information and unable to contact reporter
>     - etc
>     
>     This plan gives us 2 months from feature freeze to get all issues and
>     PRs with the 1.1.1 milestone closed (or assigned to a different
>     milestone). Currently this stands at 141 issues and 55 PRs. In practice
>     I think the only way we get through that lot is to make explicit
>     decisions not to fix/implement some of them and change the milestone.
>     But I think making explicit decisions about these rather than just
>     letting them drift indefinitely is a good thing.
>     
>     If the TLSv1.3 RFC is not published by the time we are ready to release,
>     or we haven't made the progress we want on the other release criteria
>     then we can add additional betas as we see fit until such time as we are
>     ready.
>     
>     Matt
>     _______________________________________________
>     openssl-project mailing list
>     openssl-project at openssl.org
>     https://mta.openssl.org/mailman/listinfo/openssl-project
>     
> 
> _______________________________________________
> openssl-project mailing list
> openssl-project at openssl.org
> https://mta.openssl.org/mailman/listinfo/openssl-project
> 

From rsalz at akamai.com  Wed Jan 24 20:57:00 2018
From: rsalz at akamai.com (Salz, Rich)
Date: Wed, 24 Jan 2018 20:57:00 +0000
Subject: [openssl-project] 1.1.1 Release timetable (again)
In-Reply-To: <a854cb79-3cab-dea2-e29e-76666d97273f@openssl.org>
References: <c6011243-36f6-5dec-11df-b32cff90c147@openssl.org>
 <960F4FFA-8EEC-41A2-BD47-CFB119BC99EA@akamai.com>
 <a854cb79-3cab-dea2-e29e-76666d97273f@openssl.org>
Message-ID: <14437FD0-9B9B-4136-B9B9-BC04D0D719D6@akamai.com>

So a few months into it, we look at changing the schedule if we need to stretch thing out.

On 1/24/18, 3:49 PM, "Matt Caswell" <matt at openssl.org> wrote:

    
    
    On 24/01/18 19:12, Salz, Rich wrote:
    > A monthly release cadence for beta seems too long.  I would prefer two weeks.  And we keep doing that until TLS 1.3 is published.
    
    That might be ok. As a technical issue though we can only have a maximum
    of 14 alpha/beta releases (due to the format of OPENSSL_VERSION_NUMBER
    in opensslv.h). If we were to do a release every 2 weeks starting on
    14th Feb, that would mean the last beta we could possibly do would be on
    15th August.  If there is a risk that the TLSv1.3 publication could go
    beyond that date then we would be stuck.
    
    Matt
    
    > 
    > 
    > On 1/24/18, 12:32 PM, "Matt Caswell" <matt at openssl.org> wrote:
    > 
    >     Reviving the 1.1.1 release timetable discussion now that we have a
    >     clearer idea of the scope of outstanding issues/PRs.
    >     
    >     Here is my updated straw man proposal for the 1.1.1 release timetable.
    >     The only changes to this from my original proposal is to shift the dates
    >     (because in my original proposal we would already have done the first
    >     alpha) and I have relabelled the second release as a "beta". My original
    >     plan called this an alpha with feature freeze at the same time, which
    >     people (vehemently) objected to. :-)
    >     
    >     14th February 2018, alpha release 1 (pre1)
    >     14th March 2018, beta release 1 (pre2)
    >     	OpenSSL_1_1_1-stable created (feature freeze)
    >     	master becomes basis for 1.1.2 or 1.2.0 (TBD)
    >     11th March 2018, beta release 2 (pre3)
    >     9th May 2018, 1.1.1 public release (assuming TLSv1.3 RFC is published)
    >     
    >     An alpha release means:
    >     - Not (necessarily) feature complete
    >     - Not necessarily all new APIs in place yet
    >     
    >     A beta release means:
    >     - Feature complete/Feature freeze
    >     - Bug fixes only
    >     
    >     My proposed release criteria are:
    >     - All open github issues/PRs older than 2 weeks at the time of release
    >     to be assessed for relevance to 1.1.1. Any flagged with the 1.1.1
    >     milestone to be closed (see below)
    >     - Clean builds in Travis and Appveyor for two days
    >     - run-checker.sh to be showing as clean 2 days before release
    >     - No open Coverity issues (not flagged as "False Positive" or "Ignore")
    >     - TLSv1.3 RFC published
    >     
    >     Valid reasons for closing an issue/PR with a 1.1.1 milestone might be:
    >     - We have just now or sometime in the past fixed the issue
    >     - Unable to reproduce (following discussion with original reporter if
    >     possible)
    >     - Working as intended
    >     - Deliberate decision not to fix until a later release (this wouldn't
    >     actually close the issue/PR but change the milestone instead)
    >     - Not enough information and unable to contact reporter
    >     - etc
    >     
    >     This plan gives us 2 months from feature freeze to get all issues and
    >     PRs with the 1.1.1 milestone closed (or assigned to a different
    >     milestone). Currently this stands at 141 issues and 55 PRs. In practice
    >     I think the only way we get through that lot is to make explicit
    >     decisions not to fix/implement some of them and change the milestone.
    >     But I think making explicit decisions about these rather than just
    >     letting them drift indefinitely is a good thing.
    >     
    >     If the TLSv1.3 RFC is not published by the time we are ready to release,
    >     or we haven't made the progress we want on the other release criteria
    >     then we can add additional betas as we see fit until such time as we are
    >     ready.
    >     
    >     Matt
    >     _______________________________________________
    >     openssl-project mailing list
    >     openssl-project at openssl.org
    >     https://mta.openssl.org/mailman/listinfo/openssl-project
    >     
    > 
    > _______________________________________________
    > openssl-project mailing list
    > openssl-project at openssl.org
    > https://mta.openssl.org/mailman/listinfo/openssl-project
    > 
    _______________________________________________
    openssl-project mailing list
    openssl-project at openssl.org
    https://mta.openssl.org/mailman/listinfo/openssl-project
    


From levitte at openssl.org  Thu Jan 25 07:39:54 2018
From: levitte at openssl.org (Richard Levitte)
Date: Thu, 25 Jan 2018 08:39:54 +0100 (CET)
Subject: [openssl-project] 1.1.1 Release timetable (again)
In-Reply-To: <a854cb79-3cab-dea2-e29e-76666d97273f@openssl.org>
References: <c6011243-36f6-5dec-11df-b32cff90c147@openssl.org>
 <960F4FFA-8EEC-41A2-BD47-CFB119BC99EA@akamai.com>
 <a854cb79-3cab-dea2-e29e-76666d97273f@openssl.org>
Message-ID: <20180125.083954.321572440752486616.levitte@openssl.org>

In message <a854cb79-3cab-dea2-e29e-76666d97273f at openssl.org> on Wed, 24 Jan 2018 20:48:54 +0000, Matt Caswell <matt at openssl.org> said:

matt> On 24/01/18 19:12, Salz, Rich wrote:
matt> > A monthly release cadence for beta seems too long.  I would prefer two weeks.  And we keep doing that until TLS 1.3 is published.
matt> 
matt> That might be ok. As a technical issue though we can only have a maximum
matt> of 14 alpha/beta releases (due to the format of OPENSSL_VERSION_NUMBER
matt> in opensslv.h). If we were to do a release every 2 weeks starting on
matt> 14th Feb, that would mean the last beta we could possibly do would be on
matt> 15th August.  If there is a risk that the TLSv1.3 publication could go
matt> beyond that date then we would be stuck.

This is the first time, as far as I recall, that we've decided to wait
on someone else for our releases, so I'm thinking that we have the
freedom to decide how to act if there's a delay, for example to delay
our own beta cycle.  It shouldn't be too hard to write a kind of
"caveat emptor" where we say that "should the TLSv1.3 publication be
delayed, we till re-evaluate our plans".

(another way to do it is to refuse making a release plan before we
receive a clear signal that publication *will* happen and when it
will...  after all, we *are* putting ourselves in a kind of hostage
situation)

Cheers,
Richard

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

From matt at openssl.org  Thu Jan 25 11:00:10 2018
From: matt at openssl.org (Matt Caswell)
Date: Thu, 25 Jan 2018 11:00:10 +0000
Subject: [openssl-project] 1.1.1 Release timetable (again)
In-Reply-To: <20180125.083954.321572440752486616.levitte@openssl.org>
References: <c6011243-36f6-5dec-11df-b32cff90c147@openssl.org>
 <960F4FFA-8EEC-41A2-BD47-CFB119BC99EA@akamai.com>
 <a854cb79-3cab-dea2-e29e-76666d97273f@openssl.org>
 <20180125.083954.321572440752486616.levitte@openssl.org>
Message-ID: <b43fe301-70ab-c7ec-4b13-a37ac7b4d81b@openssl.org>



On 25/01/18 07:39, Richard Levitte wrote:
> In message <a854cb79-3cab-dea2-e29e-76666d97273f at openssl.org> on Wed, 24 Jan 2018 20:48:54 +0000, Matt Caswell <matt at openssl.org> said:
> 
> matt> On 24/01/18 19:12, Salz, Rich wrote:
> matt> > A monthly release cadence for beta seems too long.  I would prefer two weeks.  And we keep doing that until TLS 1.3 is published.
> matt> 
> matt> That might be ok. As a technical issue though we can only have a maximum
> matt> of 14 alpha/beta releases (due to the format of OPENSSL_VERSION_NUMBER
> matt> in opensslv.h). If we were to do a release every 2 weeks starting on
> matt> 14th Feb, that would mean the last beta we could possibly do would be on
> matt> 15th August.  If there is a risk that the TLSv1.3 publication could go
> matt> beyond that date then we would be stuck.
> 
> This is the first time, as far as I recall, that we've decided to wait
> on someone else for our releases, so I'm thinking that we have the
> freedom to decide how to act if there's a delay, for example to delay
> our own beta cycle.  It shouldn't be too hard to write a kind of
> "caveat emptor" where we say that "should the TLSv1.3 publication be
> delayed, we till re-evaluate our plans".
> 
> (another way to do it is to refuse making a release plan before we
> receive a clear signal that publication *will* happen and when it
> will...  after all, we *are* putting ourselves in a kind of hostage
> situation)

Absolutely. As I said in the email that started this thread part of the
release criteria include:

- TLSv1.3 RFC published

And then I later said:

"If the TLSv1.3 RFC is not published by the time we are ready to
release,or we haven't made the progress we want on the other release
criteria then we can add additional betas as we see fit until such time
as we are ready."

A two week release cadence might look like this:

13th February 2018, alpha release 1 (pre1)
27th February 2018, alpha release 2 (pre2)
13th March 2018, beta release 1 (pre3)
	OpenSSL_1_1_1-stable created (feature freeze)
	master becomes basis for 1.1.2 or 1.2.0 (TBD)
27th March 2018, beta release 2 (pre4)
10th April 2018, beta release 3 (pre5)
24th April 2018, beta release 4 (pre6)
1st May 2018, release readiness check (new release cycles added if
required, first possible final release date: 8th May 2018)

Instead of putting the final release date into the plan (which would
have been 8th May), I have put the the final step as a "release
readiness check", 1 week after beta4. This puts an explicit opportunity
for us to see how we are doing against the criteria. If we are ready
then we could push ahead for an 8th May release, otherwise we extend it
out as needed.

This plan uses up 6 of our maximum possible 14 pre-releases. If we go
with this approach and we get to the release readiness check without an
RFC then we should probably slow down our release cadence at that point.


Matt

From rsalz at akamai.com  Thu Jan 25 11:59:36 2018
From: rsalz at akamai.com (Salz, Rich)
Date: Thu, 25 Jan 2018 11:59:36 +0000
Subject: [openssl-project] 1.1.1 Release timetable (again)
In-Reply-To: <b43fe301-70ab-c7ec-4b13-a37ac7b4d81b@openssl.org>
References: <c6011243-36f6-5dec-11df-b32cff90c147@openssl.org>
 <960F4FFA-8EEC-41A2-BD47-CFB119BC99EA@akamai.com>
 <a854cb79-3cab-dea2-e29e-76666d97273f@openssl.org>
 <20180125.083954.321572440752486616.levitte@openssl.org>
 <b43fe301-70ab-c7ec-4b13-a37ac7b4d81b@openssl.org>
Message-ID: <D872FCA7-3F03-4253-B842-20E66FDF06FF@akamai.com>

As long as we have the freedom to release earlier, this looks okay to me.

On 1/25/18, 6:00 AM, "Matt Caswell" <matt at openssl.org> wrote:

    
    
    On 25/01/18 07:39, Richard Levitte wrote:
    > In message <a854cb79-3cab-dea2-e29e-76666d97273f at openssl.org> on Wed, 24 Jan 2018 20:48:54 +0000, Matt Caswell <matt at openssl.org> said:
    > 
    > matt> On 24/01/18 19:12, Salz, Rich wrote:
    > matt> > A monthly release cadence for beta seems too long.  I would prefer two weeks.  And we keep doing that until TLS 1.3 is published.
    > matt> 
    > matt> That might be ok. As a technical issue though we can only have a maximum
    > matt> of 14 alpha/beta releases (due to the format of OPENSSL_VERSION_NUMBER
    > matt> in opensslv.h). If we were to do a release every 2 weeks starting on
    > matt> 14th Feb, that would mean the last beta we could possibly do would be on
    > matt> 15th August.  If there is a risk that the TLSv1.3 publication could go
    > matt> beyond that date then we would be stuck.
    > 
    > This is the first time, as far as I recall, that we've decided to wait
    > on someone else for our releases, so I'm thinking that we have the
    > freedom to decide how to act if there's a delay, for example to delay
    > our own beta cycle.  It shouldn't be too hard to write a kind of
    > "caveat emptor" where we say that "should the TLSv1.3 publication be
    > delayed, we till re-evaluate our plans".
    > 
    > (another way to do it is to refuse making a release plan before we
    > receive a clear signal that publication *will* happen and when it
    > will...  after all, we *are* putting ourselves in a kind of hostage
    > situation)
    
    Absolutely. As I said in the email that started this thread part of the
    release criteria include:
    
    - TLSv1.3 RFC published
    
    And then I later said:
    
    "If the TLSv1.3 RFC is not published by the time we are ready to
    release,or we haven't made the progress we want on the other release
    criteria then we can add additional betas as we see fit until such time
    as we are ready."
    
    A two week release cadence might look like this:
    
    13th February 2018, alpha release 1 (pre1)
    27th February 2018, alpha release 2 (pre2)
    13th March 2018, beta release 1 (pre3)
    	OpenSSL_1_1_1-stable created (feature freeze)
    	master becomes basis for 1.1.2 or 1.2.0 (TBD)
    27th March 2018, beta release 2 (pre4)
    10th April 2018, beta release 3 (pre5)
    24th April 2018, beta release 4 (pre6)
    1st May 2018, release readiness check (new release cycles added if
    required, first possible final release date: 8th May 2018)
    
    Instead of putting the final release date into the plan (which would
    have been 8th May), I have put the the final step as a "release
    readiness check", 1 week after beta4. This puts an explicit opportunity
    for us to see how we are doing against the criteria. If we are ready
    then we could push ahead for an 8th May release, otherwise we extend it
    out as needed.
    
    This plan uses up 6 of our maximum possible 14 pre-releases. If we go
    with this approach and we get to the release readiness check without an
    RFC then we should probably slow down our release cadence at that point.
    
    
    Matt
    _______________________________________________
    openssl-project mailing list
    openssl-project at openssl.org
    https://mta.openssl.org/mailman/listinfo/openssl-project
    


From matt at openssl.org  Thu Jan 25 19:08:29 2018
From: matt at openssl.org (Matt Caswell)
Date: Thu, 25 Jan 2018 19:08:29 +0000
Subject: [openssl-project] 1.1.1 Release timetable (again)
In-Reply-To: <D872FCA7-3F03-4253-B842-20E66FDF06FF@akamai.com>
References: <c6011243-36f6-5dec-11df-b32cff90c147@openssl.org>
 <960F4FFA-8EEC-41A2-BD47-CFB119BC99EA@akamai.com>
 <a854cb79-3cab-dea2-e29e-76666d97273f@openssl.org>
 <20180125.083954.321572440752486616.levitte@openssl.org>
 <b43fe301-70ab-c7ec-4b13-a37ac7b4d81b@openssl.org>
 <D872FCA7-3F03-4253-B842-20E66FDF06FF@akamai.com>
Message-ID: <5b07b199-edce-0184-99f9-f76f07e84199@openssl.org>



On 25/01/18 11:59, Salz, Rich wrote:
> As long as we have the freedom to release earlier, this looks okay to me.

I added this sentence to make that freedom crystal clear:

"This may be amended at any time as the need arises"

I have taken this proposal and made it into a PR for updating the
release strategy. The PR is here:

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

Please provide any review comments there. Once any reviews seem to have
settled down to a consensus I will propose an OMC vote.

Matt



> 
> On 1/25/18, 6:00 AM, "Matt Caswell" <matt at openssl.org> wrote:
> 
>     
>     
>     On 25/01/18 07:39, Richard Levitte wrote:
>     > In message <a854cb79-3cab-dea2-e29e-76666d97273f at openssl.org> on Wed, 24 Jan 2018 20:48:54 +0000, Matt Caswell <matt at openssl.org> said:
>     > 
>     > matt> On 24/01/18 19:12, Salz, Rich wrote:
>     > matt> > A monthly release cadence for beta seems too long.  I would prefer two weeks.  And we keep doing that until TLS 1.3 is published.
>     > matt> 
>     > matt> That might be ok. As a technical issue though we can only have a maximum
>     > matt> of 14 alpha/beta releases (due to the format of OPENSSL_VERSION_NUMBER
>     > matt> in opensslv.h). If we were to do a release every 2 weeks starting on
>     > matt> 14th Feb, that would mean the last beta we could possibly do would be on
>     > matt> 15th August.  If there is a risk that the TLSv1.3 publication could go
>     > matt> beyond that date then we would be stuck.
>     > 
>     > This is the first time, as far as I recall, that we've decided to wait
>     > on someone else for our releases, so I'm thinking that we have the
>     > freedom to decide how to act if there's a delay, for example to delay
>     > our own beta cycle.  It shouldn't be too hard to write a kind of
>     > "caveat emptor" where we say that "should the TLSv1.3 publication be
>     > delayed, we till re-evaluate our plans".
>     > 
>     > (another way to do it is to refuse making a release plan before we
>     > receive a clear signal that publication *will* happen and when it
>     > will...  after all, we *are* putting ourselves in a kind of hostage
>     > situation)
>     
>     Absolutely. As I said in the email that started this thread part of the
>     release criteria include:
>     
>     - TLSv1.3 RFC published
>     
>     And then I later said:
>     
>     "If the TLSv1.3 RFC is not published by the time we are ready to
>     release,or we haven't made the progress we want on the other release
>     criteria then we can add additional betas as we see fit until such time
>     as we are ready."
>     
>     A two week release cadence might look like this:
>     
>     13th February 2018, alpha release 1 (pre1)
>     27th February 2018, alpha release 2 (pre2)
>     13th March 2018, beta release 1 (pre3)
>     	OpenSSL_1_1_1-stable created (feature freeze)
>     	master becomes basis for 1.1.2 or 1.2.0 (TBD)
>     27th March 2018, beta release 2 (pre4)
>     10th April 2018, beta release 3 (pre5)
>     24th April 2018, beta release 4 (pre6)
>     1st May 2018, release readiness check (new release cycles added if
>     required, first possible final release date: 8th May 2018)
>     
>     Instead of putting the final release date into the plan (which would
>     have been 8th May), I have put the the final step as a "release
>     readiness check", 1 week after beta4. This puts an explicit opportunity
>     for us to see how we are doing against the criteria. If we are ready
>     then we could push ahead for an 8th May release, otherwise we extend it
>     out as needed.
>     
>     This plan uses up 6 of our maximum possible 14 pre-releases. If we go
>     with this approach and we get to the release readiness check without an
>     RFC then we should probably slow down our release cadence at that point.
>     
>     
>     Matt
>     _______________________________________________
>     openssl-project mailing list
>     openssl-project at openssl.org
>     https://mta.openssl.org/mailman/listinfo/openssl-project
>     
> 
> _______________________________________________
> openssl-project mailing list
> openssl-project at openssl.org
> https://mta.openssl.org/mailman/listinfo/openssl-project
> 

From rsalz at akamai.com  Fri Jan 26 13:26:58 2018
From: rsalz at akamai.com (Salz, Rich)
Date: Fri, 26 Jan 2018 13:26:58 +0000
Subject: [openssl-project] Style guide updates
Message-ID: <2A47205B-D7F1-406B-B99B-D0139C075979@akamai.com>

Some things I think we should add to the style guide.  Let?s discuss here.

No space after sizeof, use parens.  (But see ssl/record/rec_layer_{d1,s3}.c )

Multiline conditionals, such as in an if, should be broken before the logical connector and indented an extra tabstop.  For example:

    while (this_is_true
              && that_is_not_false) {
        frobit();
        more_stuff();
    }

When dealing with long lines, try to avoid breaking across a function call. Don?t do this:
    If (some_long_text && foo(a,
         b, c) && bar()) {
Instead do this:
    If (some_long_text
        && foo(a, b, c,)
        && bar())

What else needs to be updated?

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

From bernd.edlinger at hotmail.de  Fri Jan 26 13:52:42 2018
From: bernd.edlinger at hotmail.de (Bernd Edlinger)
Date: Fri, 26 Jan 2018 13:52:42 +0000
Subject: [openssl-project] Style guide updates
In-Reply-To: <2A47205B-D7F1-406B-B99B-D0139C075979@akamai.com>
References: <2A47205B-D7F1-406B-B99B-D0139C075979@akamai.com>
Message-ID: <AM5PR0701MB2657EB884B7F4171F36A5DE4E4E00@AM5PR0701MB2657.eurprd07.prod.outlook.com>

On 01/26/18 14:26, Salz, Rich wrote:
> Some things I think we should add to the style guide.? Let?s discuss here.
> 
> No space after sizeof, use parens.? (But see 
> ssl/record/rec_layer_{d1,s3}.c )
> 
> Multiline conditionals, such as in an if, should be broken before the 
> logical connector and indented an extra tabstop.? For example:
> 
>  ??? while (this_is_true
> 
>  ??? ??????????&& that_is_not_false) {
> 
>  ??????? frobit();
> 
>  ??????? more_stuff();
> 
>  ??? }
> 
> When dealing with long lines, try to avoid breaking across a function 
> call. Don?t do this:
> 
>  ??? If (some_long_text && foo(a,
> 
>  ???????? b, c) && bar()) {
> 
> Instead do this:
> 
>  ??? If (some_long_text
> 
>  ??????? && foo(a, b, c,)
> 
>  ??????? && bar())
> 
> What else needs to be updated?
> 

There was some discussion about fully parenthesed macro arguments, a
while ago.

At least at that time the style guide did not cover that topic.


Bernd.

From rsalz at akamai.com  Fri Jan 26 13:53:57 2018
From: rsalz at akamai.com (Salz, Rich)
Date: Fri, 26 Jan 2018 13:53:57 +0000
Subject: [openssl-project] FW: [curves] new 25519 measurements of formally
 verified implementations
In-Reply-To: <20180126120600.14775.qmail@cr.yp.to>
References: <CAHmME9p-_J24DC4_RsCgnZDf2QpL8zsm2=v8e5GYMK9C5_eEWw@mail.gmail.com>
 <20180126120600.14775.qmail@cr.yp.to>
Message-ID: <AC57A800-58A7-4AD0-8AA5-02A9C76CBDF3@akamai.com>

FYI

On 1/26/18, 7:06 AM, "D. J. Bernstein" <djb at cr.yp.to> wrote:

    Tung Chou's sandy2x code was (as the name suggests) optimized for Sandy
    Bridge. For Haswell and Skylake, the slides from Julio Lopez in
    
       https://hyperelliptic.org/tanja/lc17/ascrypto.html
    
    report two followup implementations producing roughly 25% speedups for
    Curve25519; see slide 67/83.
    
    I do think that the hacl64 Curve25519 speeds are fast enough for pretty
    much everybody, and verification is certainly a huge plus, but people
    who want more speed should be aware of what's possible---and people
    working on Curve25519 verification shouldn't think they're done yet!
    
    ---Dan
    _______________________________________________
    Curves mailing list
    Curves at moderncrypto.org
    https://moderncrypto.org/mailman/listinfo/curves
    


From matt at openssl.org  Fri Jan 26 14:06:27 2018
From: matt at openssl.org (Matt Caswell)
Date: Fri, 26 Jan 2018 14:06:27 +0000
Subject: [openssl-project] Style guide updates
In-Reply-To: <2A47205B-D7F1-406B-B99B-D0139C075979@akamai.com>
References: <2A47205B-D7F1-406B-B99B-D0139C075979@akamai.com>
Message-ID: <c20f5fd4-1c85-c96b-42e7-e2a84e411bd7@openssl.org>

Possible things to include:

- Don't use else after return?


- Don't check if a value is non NULL before calling xxx_free()


- Use size_t for sizes of things


- Treat single line if body with a separate line for a comment as multi
line:

e.g.

if (x) {
    /* my comment */
    single_line();
}


- Use ossl_assert() for asserting things


- Initialise in the declaration if appropriate, e.g.

int x = set_a_val();

Not

int x;

x = set_a_val();


- Blank line after variable declarations




On 26/01/18 13:26, Salz, Rich wrote:
> Some things I think we should add to the style guide.? Let?s discuss here.
> 
> ?
> 
> No space after sizeof, use parens.? (But see
> ssl/record/rec_layer_{d1,s3}.c )
> 
> ?
> 
> Multiline conditionals, such as in an if, should be broken before the
> logical connector and indented an extra tabstop.? For example:
> 
> ?
> 
> ??? while (this_is_true
> 
> ??? ??????????&& that_is_not_false) {
> 
> ??????? frobit();
> 
> ??????? more_stuff();
> 
> ??? }
> 
> ?
> 
> When dealing with long lines, try to avoid breaking across a function
> call. Don?t do this:
> 
> ??? If (some_long_text && foo(a,
> 
> ???????? b, c) && bar()) {
> 
> Instead do this:
> 
> ??? If (some_long_text
> 
> ??????? && foo(a, b, c,)
> 
> ??????? && bar())
> 
> ?
> 
> What else needs to be updated?
> 
> ?
> 
> 
> 
> _______________________________________________
> openssl-project mailing list
> openssl-project at openssl.org
> https://mta.openssl.org/mailman/listinfo/openssl-project
> 

From matt at openssl.org  Fri Jan 26 16:32:10 2018
From: matt at openssl.org (Matt Caswell)
Date: Fri, 26 Jan 2018 16:32:10 +0000
Subject: [openssl-project] Fwd: [openssl-commits] Broken:
 openssl/openssl#15866 (master - cf8e923)
In-Reply-To: <5a6b52fb8745e_43fcf3da29d6413442f9@6df8fc81-36b2-4379-a7f0-28de3184b29f.mail>
References: <5a6b52fb8745e_43fcf3da29d6413442f9@6df8fc81-36b2-4379-a7f0-28de3184b29f.mail>
Message-ID: <f60c8f89-44b5-48c2-7bcb-caba725520e3@openssl.org>

This looks like another instance of this:

https://mta.openssl.org/pipermail/openssl-project/2018-January/000140.html

i.e. the word "ok" appearing at the beginning of a line in test_store
while it is printing base-64 encoded output - which then confuses TAP

Richard - any ideas?

Matt


-------- Forwarded Message --------
Subject: 	[openssl-commits] Broken: openssl/openssl#15866 (master - cf8e923)
Date: 	Fri, 26 Jan 2018 16:10:35 +0000
From: 	Travis CI <builds at travis-ci.org>
To: 	openssl-commits at openssl.org



*openssl / openssl
<https://travis-ci.org/openssl/openssl?utm_source=email&utm_medium=notification>*
(master <https://github.com/openssl/openssl/tree/master>)

	Build #15866 was broken.
<https://travis-ci.org/openssl/openssl/builds/333780174?utm_source=email&utm_medium=notification>
	
28 minutes and 51 seconds
	*Benjamin Kaduk* 	cf8e923
<https://github.com/openssl/openssl/commit/cf8e9233f0139f8ebacbfd4fa34ccf410ec8430c>
Changeset ?
<https://github.com/openssl/openssl/compare/c1acef9263b8...cf8e9233f013>
? 	Catch some more old sigalg names in comments

Make the sigalg name in comments reflect one that actually exists
in the draft standard.

Reviewed-by: Matt Caswell <matt at openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5174)

*Want to know about upcoming build environment updates?*

Would you like to stay up-to-date with the upcoming Travis CI build
environment updates? We set up a mailing list for you! Sign up here
<http://eepurl.com/9OCsP>.

	Documentation <https://docs.travis-ci.com> about Travis CI
Need help? Mail support <mailto:support at travis-ci.com>!
Choose who receives these build notification emails in your
configuration file <https://docs.travis-ci.com/user/notifications>.

*Would you like to test your private code?*

Travis CI for Private Projects
<https://travis-ci.com?utm_source=build_email_footer&utm_campaign=travis-ci.org&utm_medium=email>
could be your new best friend!

-------------- next part --------------
_____
openssl-commits mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-commits


From levitte at openssl.org  Fri Jan 26 16:44:51 2018
From: levitte at openssl.org (Richard Levitte)
Date: Fri, 26 Jan 2018 17:44:51 +0100 (CET)
Subject: [openssl-project] Style guide updates
In-Reply-To: <2A47205B-D7F1-406B-B99B-D0139C075979@akamai.com>
References: <2A47205B-D7F1-406B-B99B-D0139C075979@akamai.com>
Message-ID: <20180126.174451.1997010352655007854.levitte@openssl.org>

In message <2A47205B-D7F1-406B-B99B-D0139C075979 at akamai.com> on Fri, 26 Jan 2018 13:26:58 +0000, "Salz, Rich" <rsalz at akamai.com> said:

rsalz> Some things I think we should add to the style guide.  Let?s discuss here.
rsalz> 
rsalz> No space after sizeof, use parens.  (But see ssl/record/rec_layer_{d1,s3}.c )

Yes

rsalz> Multiline conditionals, such as in an if, should be broken
rsalz> before the logical connector and indented an extra tabstop.
rsalz> For example:
rsalz> 
rsalz>     while (this_is_true
rsalz>               && that_is_not_false) {
rsalz>         frobit();
rsalz>         more_stuff();
rsalz>     }

Please don't call it a tabstop.  extra indentation if you will, and in
that case, it should be 4 spaces inside the parenthesis.

Now, to have indent do that for us is a whole other story...
(side note: I saw an indent program a few days ago that's quite
promising.  I'll dig it up again)

Frankly, I'm not sure I like this, and strictly speaking, it only has
visual value for 'if' conditionals, since the inside of the
conditional parenthesis is exactly 4 spaces in, and because we break
before operators, I don't see the visual problem, but that's a very
personal viewpoint, YMMV...

rsalz> When dealing with long lines, try to avoid breaking across a function call. Don?t do this:
rsalz>     If (some_long_text && foo(a,
rsalz>          b, c) && bar()) {
rsalz> Instead do this:
rsalz>     If (some_long_text
rsalz>         && foo(a, b, c,)
rsalz>         && bar())

YES!

rsalz> What else needs to be updated?

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

From levitte at openssl.org  Fri Jan 26 17:03:18 2018
From: levitte at openssl.org (Richard Levitte)
Date: Fri, 26 Jan 2018 18:03:18 +0100 (CET)
Subject: [openssl-project] Style guide updates
In-Reply-To: <c20f5fd4-1c85-c96b-42e7-e2a84e411bd7@openssl.org>
References: <2A47205B-D7F1-406B-B99B-D0139C075979@akamai.com>
 <c20f5fd4-1c85-c96b-42e7-e2a84e411bd7@openssl.org>
Message-ID: <20180126.180318.734774329335039544.levitte@openssl.org>

In message <c20f5fd4-1c85-c96b-42e7-e2a84e411bd7 at openssl.org> on Fri, 26 Jan 2018 14:06:27 +0000, Matt Caswell <matt at openssl.org> said:

matt> - Use size_t for sizes of things

... and, it seems, as array index.

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

From matt at openssl.org  Fri Jan 26 17:05:06 2018
From: matt at openssl.org (Matt Caswell)
Date: Fri, 26 Jan 2018 17:05:06 +0000
Subject: [openssl-project] Style guide updates
In-Reply-To: <20180126.180318.734774329335039544.levitte@openssl.org>
References: <2A47205B-D7F1-406B-B99B-D0139C075979@akamai.com>
 <c20f5fd4-1c85-c96b-42e7-e2a84e411bd7@openssl.org>
 <20180126.180318.734774329335039544.levitte@openssl.org>
Message-ID: <3d4abb9f-7412-47e9-ddeb-c7f3c7decfd5@openssl.org>



On 26/01/18 17:03, Richard Levitte wrote:
> In message <c20f5fd4-1c85-c96b-42e7-e2a84e411bd7 at openssl.org> on Fri, 26 Jan 2018 14:06:27 +0000, Matt Caswell <matt at openssl.org> said:
> 
> matt> - Use size_t for sizes of things
> 
> ... and, it seems, as array index.
> 

Yes - because an array index is bounded by the size of the array, which
would be defined by a size_t.

Matt

From levitte at openssl.org  Fri Jan 26 17:21:53 2018
From: levitte at openssl.org (Richard Levitte)
Date: Fri, 26 Jan 2018 18:21:53 +0100 (CET)
Subject: [openssl-project] Fwd: [openssl-commits] Broken:
 openssl/openssl#15866 (master - cf8e923)
In-Reply-To: <f60c8f89-44b5-48c2-7bcb-caba725520e3@openssl.org>
References: <5a6b52fb8745e_43fcf3da29d6413442f9@6df8fc81-36b2-4379-a7f0-28de3184b29f.mail>
 <f60c8f89-44b5-48c2-7bcb-caba725520e3@openssl.org>
Message-ID: <20180126.182153.393499696687728967.levitte@openssl.org>

I think I said it earlier, that prefixing the output with '#' is a TAP
compatible way to fix this.  One way is to pipe the execution of the
program through a "sed -e 's|^|# |'", except that it's not exactly
portable...  Another way *might* be to open("program |") and handle
the output in OpenSSL::Test.  However, both these solutions will mess
with all the test programs that we've made TAP friendly.

Hmmmm...

Come to think of it, a third option is to have the openssl program
notice the environment variable 'OPENSSL_HARNESS_PREFIX' that contains
a string to prefix all the output with, and in that case, use a custom
BIO filter that gets pushed on bio_out.

Actually, I think that last idea is the one to go for.

Cheers,
Richard

In message <f60c8f89-44b5-48c2-7bcb-caba725520e3 at openssl.org> on Fri, 26 Jan 2018 16:32:10 +0000, Matt Caswell <matt at openssl.org> said:

matt> This looks like another instance of this:
matt> 
matt> https://mta.openssl.org/pipermail/openssl-project/2018-January/000140.html
matt> 
matt> i.e. the word "ok" appearing at the beginning of a line in test_store
matt> while it is printing base-64 encoded output - which then confuses TAP
matt> 
matt> Richard - any ideas?
matt> 
matt> Matt
matt> 
matt> 
matt> -------- Forwarded Message --------
matt> Subject: 	[openssl-commits] Broken: openssl/openssl#15866 (master - cf8e923)
matt> Date: 	Fri, 26 Jan 2018 16:10:35 +0000
matt> From: 	Travis CI <builds at travis-ci.org>
matt> To: 	openssl-commits at openssl.org
matt> 
matt> 
matt> 
matt> *openssl / openssl
matt> <https://travis-ci.org/openssl/openssl?utm_source=email&utm_medium=notification>*
matt> (master <https://github.com/openssl/openssl/tree/master>)
matt> 
matt> 	Build #15866 was broken.
matt> <https://travis-ci.org/openssl/openssl/builds/333780174?utm_source=email&utm_medium=notification>
matt> 	
matt> 28 minutes and 51 seconds
matt> 	*Benjamin Kaduk* 	cf8e923
matt> <https://github.com/openssl/openssl/commit/cf8e9233f0139f8ebacbfd4fa34ccf410ec8430c>
matt> Changeset ?
matt> <https://github.com/openssl/openssl/compare/c1acef9263b8...cf8e9233f013>
matt> ? 	Catch some more old sigalg names in comments
matt> 
matt> Make the sigalg name in comments reflect one that actually exists
matt> in the draft standard.
matt> 
matt> Reviewed-by: Matt Caswell <matt at openssl.org>
matt> (Merged from https://github.com/openssl/openssl/pull/5174)
matt> 
matt> *Want to know about upcoming build environment updates?*
matt> 
matt> Would you like to stay up-to-date with the upcoming Travis CI build
matt> environment updates? We set up a mailing list for you! Sign up here
matt> <http://eepurl.com/9OCsP>.
matt> 
matt> 	Documentation <https://docs.travis-ci.com> about Travis CI
matt> Need help? Mail support <mailto:support at travis-ci.com>!
matt> Choose who receives these build notification emails in your
matt> configuration file <https://docs.travis-ci.com/user/notifications>.
matt> 
matt> *Would you like to test your private code?*
matt> 
matt> Travis CI for Private Projects
matt> <https://travis-ci.com?utm_source=build_email_footer&utm_campaign=travis-ci.org&utm_medium=email>
matt> could be your new best friend!
matt> 

From appro at openssl.org  Fri Jan 26 17:54:24 2018
From: appro at openssl.org (Andy Polyakov)
Date: Fri, 26 Jan 2018 18:54:24 +0100
Subject: [openssl-project] Style guide updates
In-Reply-To: <2A47205B-D7F1-406B-B99B-D0139C075979@akamai.com>
References: <2A47205B-D7F1-406B-B99B-D0139C075979@akamai.com>
Message-ID: <4347c5b3-c78d-60c9-ee75-ace264b6fdb3@openssl.org>

> Multiline conditionals, such as in an if, should be broken before the
> logical connector and indented an extra tabstop.? For example:
> 
> ?
> 
> ??? while (this_is_true
> ??? ??????????&& that_is_not_false) {
> ??????? frobit();
> ??????? more_stuff();
> ??? }

One has to recognize that this is if-specific problem. I mean while is
*perfectly* readable without extra indentation. And given that it's not
unthinkable that you exceed line width, enforcing this on cases other
than if can feel excessive. In other words I'd suggest to limit extra
indentation specifically to if cases.

From appro at openssl.org  Fri Jan 26 18:08:06 2018
From: appro at openssl.org (Andy Polyakov)
Date: Fri, 26 Jan 2018 19:08:06 +0100
Subject: [openssl-project] Style guide updates
In-Reply-To: <c20f5fd4-1c85-c96b-42e7-e2a84e411bd7@openssl.org>
References: <2A47205B-D7F1-406B-B99B-D0139C075979@akamai.com>
 <c20f5fd4-1c85-c96b-42e7-e2a84e411bd7@openssl.org>
Message-ID: <37c741f6-f200-98d0-1aec-d94b7be837e8@openssl.org>

> - Don't use else after return?

I'd argue against making it an absolute requirement. To give an example.
You don't a problem with returns in switch, so why should it be a
problem with returns from switch-like if-elseif chain?

From appro at openssl.org  Fri Jan 26 18:11:53 2018
From: appro at openssl.org (Andy Polyakov)
Date: Fri, 26 Jan 2018 19:11:53 +0100
Subject: [openssl-project] Style guide updates
In-Reply-To: <2A47205B-D7F1-406B-B99B-D0139C075979@akamai.com>
References: <2A47205B-D7F1-406B-B99B-D0139C075979@akamai.com>
Message-ID: <d8a55698-fb8d-c199-2b10-cd77e0108ca7@openssl.org>

> What else needs to be updated?

Relax requirement that argument names in function definition has to
match function declaration to permit adding 'unused_' prefix prior
unused arguments.

From kurt at roeckx.be  Fri Jan 26 20:27:55 2018
From: kurt at roeckx.be (Kurt Roeckx)
Date: Fri, 26 Jan 2018 21:27:55 +0100
Subject: [openssl-project] Style guide updates
In-Reply-To: <c20f5fd4-1c85-c96b-42e7-e2a84e411bd7@openssl.org>
References: <2A47205B-D7F1-406B-B99B-D0139C075979@akamai.com>
 <c20f5fd4-1c85-c96b-42e7-e2a84e411bd7@openssl.org>
Message-ID: <20180126202754.GA17220@roeckx.be>

On Fri, Jan 26, 2018 at 02:06:27PM +0000, Matt Caswell wrote:
> - Use size_t for sizes of things

How do you feel about ssize_t?


Kurt


From matt at openssl.org  Sat Jan 27 00:26:38 2018
From: matt at openssl.org (Matt Caswell)
Date: Sat, 27 Jan 2018 00:26:38 +0000
Subject: [openssl-project] Style guide updates
In-Reply-To: <20180126202754.GA17220@roeckx.be>
References: <2A47205B-D7F1-406B-B99B-D0139C075979@akamai.com>
 <c20f5fd4-1c85-c96b-42e7-e2a84e411bd7@openssl.org>
 <20180126202754.GA17220@roeckx.be>
Message-ID: <a8e4ecf2-d79b-1e5c-9c44-3ec117aeb59e@openssl.org>



On 26/01/18 20:27, Kurt Roeckx wrote:
> On Fri, Jan 26, 2018 at 02:06:27PM +0000, Matt Caswell wrote:
>> - Use size_t for sizes of things
> 
> How do you feel about ssize_t?

When I did the size_t work in libssl one of things I was trying hard to
eradicate was the constant casting of types from one thing to another.
It was common to see things like one function use an int for a size, and
then pass that to a function that uses a long for a size, but which then
needs to call something that uses a size_t. I saw numerous instances of
the same values being cast 4 or 5 times in a single chain of events
(often going back and forwards between the same type).

Such casts are dangerous and should be avoided as much as possible.
Negative numbers can suddenly become large positives. Large positives
can suddenly get truncated or go negative. Stuff that works safely on
one platform is dangerous on another. You have to be really careful
about bounds checking, and experience showed that we just weren't that
good at it.

By deciding on a single type for sizes we can avoid lots of casts. The
same argument might apply for other types of things too - but sizes are
an extremely common instance of this. size_t is here to stay (we are
already committed to in our API, and many C library calls expect it). I
think that, in general, introducing ssize_t into the mix is not helpful.
It will inevitably lead to casts between size_t and ssize_t and back
again - and all the problems that that entails.

Obviously the argument for using ssize_t is its ability to hold negative
numbers. Actually though it is quite rare for something to validly have
a negative size. Often the reason for wanting a negative value is to be
able to have some kind of error state (e.g. <0 means error, >=0 means
its a real size). This is then trying to force two different types of
meaning into a single thing and introduces even more problems. Suddenly
an error code when cast to a size_t becomes a valid size and vice versa.
I think we should generally be trying to avoid APIs (internal and
external) that work like that. Instead we should try and separate the
concepts, e.g. the return code of a function is a simple success/failure
indicator; a returned size is passed back via a pointer argument.

I wouldn't say that we should never use ssize_t. There are real uses for
this, e.g. an offset into something. An offset could quite legitimately
have a positive value or a negative value. An offset though is not a
size so casts between a size thing and an offset are less likely to
happen. More likely is an addition of a size_t and an ssize_t which will
require some casting to get the expected result - but that is probably
unavoidable.

Matt

From kurt at roeckx.be  Sat Jan 27 12:03:04 2018
From: kurt at roeckx.be (Kurt Roeckx)
Date: Sat, 27 Jan 2018 13:03:04 +0100
Subject: [openssl-project] Style guide updates
In-Reply-To: <a8e4ecf2-d79b-1e5c-9c44-3ec117aeb59e@openssl.org>
References: <2A47205B-D7F1-406B-B99B-D0139C075979@akamai.com>
 <c20f5fd4-1c85-c96b-42e7-e2a84e411bd7@openssl.org>
 <20180126202754.GA17220@roeckx.be>
 <a8e4ecf2-d79b-1e5c-9c44-3ec117aeb59e@openssl.org>
Message-ID: <20180127120304.GA7624@roeckx.be>

On Sat, Jan 27, 2018 at 12:26:38AM +0000, Matt Caswell wrote:
> 
> 
> On 26/01/18 20:27, Kurt Roeckx wrote:
> > On Fri, Jan 26, 2018 at 02:06:27PM +0000, Matt Caswell wrote:
> >> - Use size_t for sizes of things
> > 
> > How do you feel about ssize_t?
> 
> When I did the size_t work in libssl one of things I was trying hard to
> eradicate was the constant casting of types from one thing to another.
> It was common to see things like one function use an int for a size, and
> then pass that to a function that uses a long for a size, but which then
> needs to call something that uses a size_t. I saw numerous instances of
> the same values being cast 4 or 5 times in a single chain of events
> (often going back and forwards between the same type).
> 
> Such casts are dangerous and should be avoided as much as possible.
> Negative numbers can suddenly become large positives. Large positives
> can suddenly get truncated or go negative. Stuff that works safely on
> one platform is dangerous on another. You have to be really careful
> about bounds checking, and experience showed that we just weren't that
> good at it.
> 
> By deciding on a single type for sizes we can avoid lots of casts. The
> same argument might apply for other types of things too - but sizes are
> an extremely common instance of this. size_t is here to stay (we are
> already committed to in our API, and many C library calls expect it). I
> think that, in general, introducing ssize_t into the mix is not helpful.
> It will inevitably lead to casts between size_t and ssize_t and back
> again - and all the problems that that entails.
> 
> Obviously the argument for using ssize_t is its ability to hold negative
> numbers. Actually though it is quite rare for something to validly have
> a negative size. Often the reason for wanting a negative value is to be
> able to have some kind of error state (e.g. <0 means error, >=0 means
> its a real size). This is then trying to force two different types of
> meaning into a single thing and introduces even more problems. Suddenly
> an error code when cast to a size_t becomes a valid size and vice versa.
> I think we should generally be trying to avoid APIs (internal and
> external) that work like that. Instead we should try and separate the
> concepts, e.g. the return code of a function is a simple success/failure
> indicator; a returned size is passed back via a pointer argument.

It's just that there seem to be 2 camps, one saying that all types
should be signed except when it's to access the bits. The other
that a size can't be negative so you go for an unsigned type. If
it's a signed type you could check that they gave you a negative
value by accident and return an error.

One problem with the unsigned type is that in theory you could
store the double amount of data but in practice you probably can't
because you'll run into undefined behavior caused by the ptrdiff_t
which is signed.

Anyway, I'm fine with either.


Kurt


From kurt at roeckx.be  Sat Jan 27 12:08:29 2018
From: kurt at roeckx.be (Kurt Roeckx)
Date: Sat, 27 Jan 2018 13:08:29 +0100
Subject: [openssl-project] Style guide updates
In-Reply-To: <20180127120304.GA7624@roeckx.be>
References: <2A47205B-D7F1-406B-B99B-D0139C075979@akamai.com>
 <c20f5fd4-1c85-c96b-42e7-e2a84e411bd7@openssl.org>
 <20180126202754.GA17220@roeckx.be>
 <a8e4ecf2-d79b-1e5c-9c44-3ec117aeb59e@openssl.org>
 <20180127120304.GA7624@roeckx.be>
Message-ID: <20180127120829.GA8047@roeckx.be>

On Sat, Jan 27, 2018 at 01:03:04PM +0100, Kurt Roeckx wrote:
> 
> It's just that there seem to be 2 camps, one saying that all types
> should be signed except when it's to access the bits. The other
> that a size can't be negative so you go for an unsigned type. If
> it's a signed type you could check that they gave you a negative
> value by accident and return an error.

The other argument to go with a signed type it's that it's easier
to write a reverse for loop and not end up with an infite loop.


Kurt


From rsalz at akamai.com  Sat Jan 27 14:48:07 2018
From: rsalz at akamai.com (Salz, Rich)
Date: Sat, 27 Jan 2018 14:48:07 +0000
Subject: [openssl-project] Style guide updates
In-Reply-To: <d8a55698-fb8d-c199-2b10-cd77e0108ca7@openssl.org>
References: <2A47205B-D7F1-406B-B99B-D0139C075979@akamai.com>
 <d8a55698-fb8d-c199-2b10-cd77e0108ca7@openssl.org>
Message-ID: <B0AB52C9-CA8F-4BB0-B3CB-4CA63AA019EB@akamai.com>

And also
	https://github.com/openssl/web/pull/42


On 1/26/18, 1:11 PM, "Andy Polyakov" <appro at openssl.org> wrote:

    > What else needs to be updated?
    
    Relax requirement that argument names in function definition has to
    match function declaration to permit adding 'unused_' prefix prior
    unused arguments.
    _______________________________________________
    openssl-project mailing list
    openssl-project at openssl.org
    https://mta.openssl.org/mailman/listinfo/openssl-project
    


From appro at openssl.org  Sat Jan 27 22:04:21 2018
From: appro at openssl.org (Andy Polyakov)
Date: Sat, 27 Jan 2018 23:04:21 +0100
Subject: [openssl-project] Style guide updates
In-Reply-To: <20180126202754.GA17220@roeckx.be>
References: <2A47205B-D7F1-406B-B99B-D0139C075979@akamai.com>
 <c20f5fd4-1c85-c96b-42e7-e2a84e411bd7@openssl.org>
 <20180126202754.GA17220@roeckx.be>
Message-ID: <38221a03-0df5-bf94-e0dc-7bfa8d181ed7@openssl.org>

>> - Use size_t for sizes of things
> 
> How do you feel about ssize_t?

One has to keep in mind that ssize_t is not part of C language
specification, but POSIX thing. C specification defines ptrdiff_t with
[presumably] desired properties. However, there is natural ambiguity
originating from fact that size_t customarily "covers" twice as much
space. So if you are to rely on positivity of signed value, object has
to be small enough. In other words you would have to perform sanity
checks before you do so. So it's not exactly walk on roses. I mean if
one assumes the premise that signed is "easier" to handle. Well, one can
make all kind of practical arguments about practicality of such
situation, i.e. what it takes to run into ptrdiff_t vs. size_t
ambiguity, and argue that it never happens. Well, while it would be case
on most systems, there are two cases, arguably not that impractical.
64-bit VMS, where we have sizeof(size_t)<sizeof(void *), and 32-bit
application running on 64-bit system. In both cases you would be
perfectly capable of allocating 2GB+1 bytes, and you would have trouble
using ptrdiff_t with such object.


[On related note one can wonder how is ambiguity resolved in say
read(2). I mean let's say you have 2GB+1 bytes file and attempt to read
it in one go in either of above cases. Well, I can't speak for VMS, but
Linux would return 2GB-4KB bytes counting on caller to make second call
to read the remaining data.]

From kaduk at mit.edu  Sun Jan 28 00:34:49 2018
From: kaduk at mit.edu (Benjamin Kaduk)
Date: Sat, 27 Jan 2018 18:34:49 -0600
Subject: [openssl-project] Style guide updates
In-Reply-To: <2A47205B-D7F1-406B-B99B-D0139C075979@akamai.com>
References: <2A47205B-D7F1-406B-B99B-D0139C075979@akamai.com>
Message-ID: <20180128003448.GB67221@kduck.kaduk.org>

On Fri, Jan 26, 2018 at 01:26:58PM +0000, Salz, Rich wrote:
> Some things I think we should add to the style guide.  Let?s discuss here.
> 
> No space after sizeof, use parens.  (But see ssl/record/rec_layer_{d1,s3}.c )
> 
> Multiline conditionals, such as in an if, should be broken before the logical connector and indented an extra tabstop.  For example:
> 
>     while (this_is_true
>               && that_is_not_false) {
>         frobit();
>         more_stuff();
>     }

To state it explictly, in the absence of the "extra" indentation
this would be formatted

    while (this_is_true
	   && that_is_not_false) {
	frobit();
	more_stuff();
    }

which is, as was noted, quite readable for the while() case, and
only if() has trouble.

> When dealing with long lines, try to avoid breaking across a function call. Don?t do this:
>     If (some_long_text && foo(a,
>          b, c) && bar()) {

And for this specific case, I am used to the rule being that if you
break mid-function-call, you indent to the paren for the function
call, as in

    if (some_long_text && foo(a,
                              b, c) && bar()) {

which rather inherently incentivizes not breaking across the
function call.

I read the rest of the thread and don't really have more to add to
it.

-Ben

> Instead do this:
>     If (some_long_text
>         && foo(a, b, c,)
>         && bar())
> 
> What else needs to be updated?
> 

> _______________________________________________
> openssl-project mailing list
> openssl-project at openssl.org
> https://mta.openssl.org/mailman/listinfo/openssl-project


From appro at openssl.org  Sun Jan 28 13:22:40 2018
From: appro at openssl.org (Andy Polyakov)
Date: Sun, 28 Jan 2018 14:22:40 +0100
Subject: [openssl-project] Style guide updates
In-Reply-To: <2A47205B-D7F1-406B-B99B-D0139C075979@akamai.com>
References: <2A47205B-D7F1-406B-B99B-D0139C075979@akamai.com>
Message-ID: <6aa5ae66-b764-2edc-a202-6be949b607cd@openssl.org>

> Multiline conditionals, such as in an if, should be broken before the
> logical connector and indented an extra tabstop.? For example:

One can wonder if it would be appropriate to explicitly say that
preferred way to organize multi-line conditionals with same chain
condition per line even if pair of them fit into line. I mean

    if (this-is-long
          && that
          && even-that)

vs.

    if (this-is-long
          && that && even-that)

with first example being preferred. And this is even if 'this-is-long'
is short.

[Or should one tolerate following provided that 'this' is short enough?

    if (this && that
          && even-that)
]

Either way, suggestion is that *if* you find yourself breaking condition
to multiple lines, you should take it step further, if not all the way.
But it shouldn't preclude things like

    if (this-is-long
          && (that || (even-that && not-the-one))
          && don't-forget-this)

This actually means that one should be able to write second example as

    if (this-is-long
          && (that && even-that))

but it would imply that logical relation between 'that' and 'even-that'
is strong enough to justify the parentheses.


[Also note that in above examples additional indentation is just two
spaces. It's not a coincidence, it's also kind of suggestion, for
if-specific indentation.]

From matt at openssl.org  Mon Jan 29 11:04:25 2018
From: matt at openssl.org (Matt Caswell)
Date: Mon, 29 Jan 2018 11:04:25 +0000
Subject: [openssl-project] 1.1.1 Release timetable (again)
In-Reply-To: <5b07b199-edce-0184-99f9-f76f07e84199@openssl.org>
References: <c6011243-36f6-5dec-11df-b32cff90c147@openssl.org>
 <960F4FFA-8EEC-41A2-BD47-CFB119BC99EA@akamai.com>
 <a854cb79-3cab-dea2-e29e-76666d97273f@openssl.org>
 <20180125.083954.321572440752486616.levitte@openssl.org>
 <b43fe301-70ab-c7ec-4b13-a37ac7b4d81b@openssl.org>
 <D872FCA7-3F03-4253-B842-20E66FDF06FF@akamai.com>
 <5b07b199-edce-0184-99f9-f76f07e84199@openssl.org>
Message-ID: <37773e09-ec15-339e-6319-a6f443c4fd7c@openssl.org>



On 25/01/18 19:08, Matt Caswell wrote:
> 
> 
> On 25/01/18 11:59, Salz, Rich wrote:
>> As long as we have the freedom to release earlier, this looks okay to me.
> 
> I added this sentence to make that freedom crystal clear:
> 
> "This may be amended at any time as the need arises"
> 
> I have taken this proposal and made it into a PR for updating the
> release strategy. The PR is here:
> 
> https://github.com/openssl/web/pull/41
> 
> Please provide any review comments there. Once any reviews seem to have
> settled down to a consensus I will propose an OMC vote.

I've had several approvals and no objections on this PR so I think we
should go ahead with a vote. My proposed vote text is:

"We should update the release strategy as shown in
https://github.com/openssl/web/pull/41, commit id 52d9ea8fb"

Any objections to the wording before I raise this?

Matt

> 
> Matt
> 
> 
> 
>>
>> On 1/25/18, 6:00 AM, "Matt Caswell" <matt at openssl.org> wrote:
>>
>>     
>>     
>>     On 25/01/18 07:39, Richard Levitte wrote:
>>     > In message <a854cb79-3cab-dea2-e29e-76666d97273f at openssl.org> on Wed, 24 Jan 2018 20:48:54 +0000, Matt Caswell <matt at openssl.org> said:
>>     > 
>>     > matt> On 24/01/18 19:12, Salz, Rich wrote:
>>     > matt> > A monthly release cadence for beta seems too long.  I would prefer two weeks.  And we keep doing that until TLS 1.3 is published.
>>     > matt> 
>>     > matt> That might be ok. As a technical issue though we can only have a maximum
>>     > matt> of 14 alpha/beta releases (due to the format of OPENSSL_VERSION_NUMBER
>>     > matt> in opensslv.h). If we were to do a release every 2 weeks starting on
>>     > matt> 14th Feb, that would mean the last beta we could possibly do would be on
>>     > matt> 15th August.  If there is a risk that the TLSv1.3 publication could go
>>     > matt> beyond that date then we would be stuck.
>>     > 
>>     > This is the first time, as far as I recall, that we've decided to wait
>>     > on someone else for our releases, so I'm thinking that we have the
>>     > freedom to decide how to act if there's a delay, for example to delay
>>     > our own beta cycle.  It shouldn't be too hard to write a kind of
>>     > "caveat emptor" where we say that "should the TLSv1.3 publication be
>>     > delayed, we till re-evaluate our plans".
>>     > 
>>     > (another way to do it is to refuse making a release plan before we
>>     > receive a clear signal that publication *will* happen and when it
>>     > will...  after all, we *are* putting ourselves in a kind of hostage
>>     > situation)
>>     
>>     Absolutely. As I said in the email that started this thread part of the
>>     release criteria include:
>>     
>>     - TLSv1.3 RFC published
>>     
>>     And then I later said:
>>     
>>     "If the TLSv1.3 RFC is not published by the time we are ready to
>>     release,or we haven't made the progress we want on the other release
>>     criteria then we can add additional betas as we see fit until such time
>>     as we are ready."
>>     
>>     A two week release cadence might look like this:
>>     
>>     13th February 2018, alpha release 1 (pre1)
>>     27th February 2018, alpha release 2 (pre2)
>>     13th March 2018, beta release 1 (pre3)
>>     	OpenSSL_1_1_1-stable created (feature freeze)
>>     	master becomes basis for 1.1.2 or 1.2.0 (TBD)
>>     27th March 2018, beta release 2 (pre4)
>>     10th April 2018, beta release 3 (pre5)
>>     24th April 2018, beta release 4 (pre6)
>>     1st May 2018, release readiness check (new release cycles added if
>>     required, first possible final release date: 8th May 2018)
>>     
>>     Instead of putting the final release date into the plan (which would
>>     have been 8th May), I have put the the final step as a "release
>>     readiness check", 1 week after beta4. This puts an explicit opportunity
>>     for us to see how we are doing against the criteria. If we are ready
>>     then we could push ahead for an 8th May release, otherwise we extend it
>>     out as needed.
>>     
>>     This plan uses up 6 of our maximum possible 14 pre-releases. If we go
>>     with this approach and we get to the release readiness check without an
>>     RFC then we should probably slow down our release cadence at that point.
>>     
>>     
>>     Matt
>>     _______________________________________________
>>     openssl-project mailing list
>>     openssl-project at openssl.org
>>     https://mta.openssl.org/mailman/listinfo/openssl-project
>>     
>>
>> _______________________________________________
>> openssl-project mailing list
>> openssl-project at openssl.org
>> https://mta.openssl.org/mailman/listinfo/openssl-project
>>

From rsalz at akamai.com  Mon Jan 29 16:17:50 2018
From: rsalz at akamai.com (Salz, Rich)
Date: Mon, 29 Jan 2018 16:17:50 +0000
Subject: [openssl-project] Draft Travel Reimbursement policy
Message-ID: <CF41E0A4-6D64-40FC-9EBA-C96D92DBEE5D@akamai.com>

At the London F2F I had the action item to draft a travel reimbursement policy.  Here?s a starting point.  After discussion dies down I?ll post it to the bureau and vote.


The OpenSSL project may pay travel expenses for OMC members when pre-approved by the OMC or when it is an official OMC meeting (as determined by vote). Project members may seek to be reimbursed if their employer is not covering the expense. The requirements for reimbursement are:


  *   An email sent to openssl-omc, including scanned attachments of all receipts over 30 Euro?s.
  *   Barring exceptional circumstances, for an all-day meeting the project will pay for arrival the day before and departure the following morning.
  *   When presenting at a conference, the project will pay the expenses for the entire conference provided the attendee agrees to act as representative of the project during that time.
  *   Reasonable lodging and meal expenses during the travel time will be covered.
  *   Barring exceptional circumstances, room service, minibar, in-room movies, and other similar amenities are not covered.


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

From matt at openssl.org  Tue Jan 30 10:45:47 2018
From: matt at openssl.org (Matt Caswell)
Date: Tue, 30 Jan 2018 10:45:47 +0000
Subject: [openssl-project] 1.1.1 Release timetable (again)
In-Reply-To: <37773e09-ec15-339e-6319-a6f443c4fd7c@openssl.org>
References: <c6011243-36f6-5dec-11df-b32cff90c147@openssl.org>
 <960F4FFA-8EEC-41A2-BD47-CFB119BC99EA@akamai.com>
 <a854cb79-3cab-dea2-e29e-76666d97273f@openssl.org>
 <20180125.083954.321572440752486616.levitte@openssl.org>
 <b43fe301-70ab-c7ec-4b13-a37ac7b4d81b@openssl.org>
 <D872FCA7-3F03-4253-B842-20E66FDF06FF@akamai.com>
 <5b07b199-edce-0184-99f9-f76f07e84199@openssl.org>
 <37773e09-ec15-339e-6319-a6f443c4fd7c@openssl.org>
Message-ID: <d3e4fc6d-6b0b-8380-1456-ff6d881f2b75@openssl.org>



On 29/01/18 11:04, Matt Caswell wrote:
> 
> 
> On 25/01/18 19:08, Matt Caswell wrote:
>>
>>
>> On 25/01/18 11:59, Salz, Rich wrote:
>>> As long as we have the freedom to release earlier, this looks okay to me.
>>
>> I added this sentence to make that freedom crystal clear:
>>
>> "This may be amended at any time as the need arises"
>>
>> I have taken this proposal and made it into a PR for updating the
>> release strategy. The PR is here:
>>
>> https://github.com/openssl/web/pull/41
>>
>> Please provide any review comments there. Once any reviews seem to have
>> settled down to a consensus I will propose an OMC vote.
> 
> I've had several approvals and no objections on this PR so I think we
> should go ahead with a vote. My proposed vote text is:
> 
> "We should update the release strategy as shown in
> https://github.com/openssl/web/pull/41, commit id 52d9ea8fb"
> 
> Any objections to the wording before I raise this?

No feedback so I started the vote:

topic: We should update the release strategy as shown in
https://github.com/openssl/web/pull/41, commit id 52d9ea8fb
Proposed by Matt Caswell
Public: yes
opened:	2018-01-30
closed: yyyy-mm-dd
ONE WEEK VOTE

I will report back here with the result once the vote is complete.

> 
> Matt
> 
>>
>> Matt
>>
>>
>>
>>>
>>> On 1/25/18, 6:00 AM, "Matt Caswell" <matt at openssl.org> wrote:
>>>
>>>     
>>>     
>>>     On 25/01/18 07:39, Richard Levitte wrote:
>>>     > In message <a854cb79-3cab-dea2-e29e-76666d97273f at openssl.org> on Wed, 24 Jan 2018 20:48:54 +0000, Matt Caswell <matt at openssl.org> said:
>>>     > 
>>>     > matt> On 24/01/18 19:12, Salz, Rich wrote:
>>>     > matt> > A monthly release cadence for beta seems too long.  I would prefer two weeks.  And we keep doing that until TLS 1.3 is published.
>>>     > matt> 
>>>     > matt> That might be ok. As a technical issue though we can only have a maximum
>>>     > matt> of 14 alpha/beta releases (due to the format of OPENSSL_VERSION_NUMBER
>>>     > matt> in opensslv.h). If we were to do a release every 2 weeks starting on
>>>     > matt> 14th Feb, that would mean the last beta we could possibly do would be on
>>>     > matt> 15th August.  If there is a risk that the TLSv1.3 publication could go
>>>     > matt> beyond that date then we would be stuck.
>>>     > 
>>>     > This is the first time, as far as I recall, that we've decided to wait
>>>     > on someone else for our releases, so I'm thinking that we have the
>>>     > freedom to decide how to act if there's a delay, for example to delay
>>>     > our own beta cycle.  It shouldn't be too hard to write a kind of
>>>     > "caveat emptor" where we say that "should the TLSv1.3 publication be
>>>     > delayed, we till re-evaluate our plans".
>>>     > 
>>>     > (another way to do it is to refuse making a release plan before we
>>>     > receive a clear signal that publication *will* happen and when it
>>>     > will...  after all, we *are* putting ourselves in a kind of hostage
>>>     > situation)
>>>     
>>>     Absolutely. As I said in the email that started this thread part of the
>>>     release criteria include:
>>>     
>>>     - TLSv1.3 RFC published
>>>     
>>>     And then I later said:
>>>     
>>>     "If the TLSv1.3 RFC is not published by the time we are ready to
>>>     release,or we haven't made the progress we want on the other release
>>>     criteria then we can add additional betas as we see fit until such time
>>>     as we are ready."
>>>     
>>>     A two week release cadence might look like this:
>>>     
>>>     13th February 2018, alpha release 1 (pre1)
>>>     27th February 2018, alpha release 2 (pre2)
>>>     13th March 2018, beta release 1 (pre3)
>>>     	OpenSSL_1_1_1-stable created (feature freeze)
>>>     	master becomes basis for 1.1.2 or 1.2.0 (TBD)
>>>     27th March 2018, beta release 2 (pre4)
>>>     10th April 2018, beta release 3 (pre5)
>>>     24th April 2018, beta release 4 (pre6)
>>>     1st May 2018, release readiness check (new release cycles added if
>>>     required, first possible final release date: 8th May 2018)
>>>     
>>>     Instead of putting the final release date into the plan (which would
>>>     have been 8th May), I have put the the final step as a "release
>>>     readiness check", 1 week after beta4. This puts an explicit opportunity
>>>     for us to see how we are doing against the criteria. If we are ready
>>>     then we could push ahead for an 8th May release, otherwise we extend it
>>>     out as needed.
>>>     
>>>     This plan uses up 6 of our maximum possible 14 pre-releases. If we go
>>>     with this approach and we get to the release readiness check without an
>>>     RFC then we should probably slow down our release cadence at that point.
>>>     
>>>     
>>>     Matt
>>>     _______________________________________________
>>>     openssl-project mailing list
>>>     openssl-project at openssl.org
>>>     https://mta.openssl.org/mailman/listinfo/openssl-project
>>>     
>>>
>>> _______________________________________________
>>> openssl-project mailing list
>>> openssl-project at openssl.org
>>> https://mta.openssl.org/mailman/listinfo/openssl-project
>>>

From kaduk at mit.edu  Tue Jan 30 14:27:16 2018
From: kaduk at mit.edu (Benjamin Kaduk)
Date: Tue, 30 Jan 2018 08:27:16 -0600
Subject: [openssl-project] travis builds failing with aligment errors?
Message-ID: <20180130142716.GJ67221@kduck.kaduk.org>

It seems that we've started getting issues with a single build
configuration, e.g.,
https://travis-ci.org/openssl/openssl/jobs/335110257

Lots of complaints about alignment, like:

crypto/modes/gcm128.c:1090:36: runtime error: load of misaligned
address 0x000002350ce5 for type 'const size_t' (aka 'const unsigned
long'), which requires 8 byte alignment
0x000002350ce5: note: pointer points here
 68 1f ea 3b 14 00 00  0c 00 02 00 00 00 00 00  0c a3 35 89 7d a7 5e 9e  87 fa d7 fd 8b c7 34 8a  8d
             ^ 
I didn't see anything particularly special about that configuration
on a quick once-over; any ideas?

-Ben

From matt at openssl.org  Tue Jan 30 14:30:50 2018
From: matt at openssl.org (Matt Caswell)
Date: Tue, 30 Jan 2018 14:30:50 +0000
Subject: [openssl-project] travis builds failing with aligment errors?
In-Reply-To: <20180130142716.GJ67221@kduck.kaduk.org>
References: <20180130142716.GJ67221@kduck.kaduk.org>
Message-ID: <76dd62cc-9efc-b29c-524e-5bab4cad075f@openssl.org>



On 30/01/18 14:27, Benjamin Kaduk wrote:
> It seems that we've started getting issues with a single build
> configuration, e.g.,
> https://travis-ci.org/openssl/openssl/jobs/335110257
> 
> Lots of complaints about alignment, like:
> 
> crypto/modes/gcm128.c:1090:36: runtime error: load of misaligned
> address 0x000002350ce5 for type 'const size_t' (aka 'const unsigned
> long'), which requires 8 byte alignment
> 0x000002350ce5: note: pointer points here
>  68 1f ea 3b 14 00 00  0c 00 02 00 00 00 00 00  0c a3 35 89 7d a7 5e 9e  87 fa d7 fd 8b c7 34 8a  8d
>              ^ 
> I didn't see anything particularly special about that configuration
> on a quick once-over; any ideas?

I raised an issue on this with some of my thoughts and investigation:

https://github.com/openssl/openssl/issues/5203


The error message about unsigned int requiring 8 byte alignment seems
suspicious to me. Shouldn't it be 4?

Matt

From matt at openssl.org  Tue Jan 30 14:32:33 2018
From: matt at openssl.org (Matt Caswell)
Date: Tue, 30 Jan 2018 14:32:33 +0000
Subject: [openssl-project] travis builds failing with aligment errors?
In-Reply-To: <76dd62cc-9efc-b29c-524e-5bab4cad075f@openssl.org>
References: <20180130142716.GJ67221@kduck.kaduk.org>
 <76dd62cc-9efc-b29c-524e-5bab4cad075f@openssl.org>
Message-ID: <d0917fdf-4af5-c5b0-83d0-5271f146cbf1@openssl.org>



On 30/01/18 14:30, Matt Caswell wrote:
> 
> 
> On 30/01/18 14:27, Benjamin Kaduk wrote:
>> It seems that we've started getting issues with a single build
>> configuration, e.g.,
>> https://travis-ci.org/openssl/openssl/jobs/335110257
>>
>> Lots of complaints about alignment, like:
>>
>> crypto/modes/gcm128.c:1090:36: runtime error: load of misaligned
>> address 0x000002350ce5 for type 'const size_t' (aka 'const unsigned
>> long'), which requires 8 byte alignment
>> 0x000002350ce5: note: pointer points here
>>  68 1f ea 3b 14 00 00  0c 00 02 00 00 00 00 00  0c a3 35 89 7d a7 5e 9e  87 fa d7 fd 8b c7 34 8a  8d
>>              ^ 
>> I didn't see anything particularly special about that configuration
>> on a quick once-over; any ideas?
> 
> I raised an issue on this with some of my thoughts and investigation:
> 
> https://github.com/openssl/openssl/issues/5203
> 
> 
> The error message about unsigned int requiring 8 byte alignment seems
> suspicious to me. Shouldn't it be 4?

Oh...sorry just realised this is a slightly different but very similar
error. In my issue it is complaining about an unsigned int requiring 8
byte alignment. This issue is for an unsigned long.

Matt


From levitte at openssl.org  Tue Jan 30 15:57:29 2018
From: levitte at openssl.org (Richard Levitte)
Date: Tue, 30 Jan 2018 16:57:29 +0100 (CET)
Subject: [openssl-project] travis builds failing with aligment errors?
In-Reply-To: <d0917fdf-4af5-c5b0-83d0-5271f146cbf1@openssl.org>
References: <20180130142716.GJ67221@kduck.kaduk.org>
 <76dd62cc-9efc-b29c-524e-5bab4cad075f@openssl.org>
 <d0917fdf-4af5-c5b0-83d0-5271f146cbf1@openssl.org>
Message-ID: <20180130.165729.1250926312366104071.levitte@openssl.org>

In message <d0917fdf-4af5-c5b0-83d0-5271f146cbf1 at openssl.org> on Tue, 30 Jan 2018 14:32:33 +0000, Matt Caswell <matt at openssl.org> said:

matt> 
matt> 
matt> On 30/01/18 14:30, Matt Caswell wrote:
matt> > 
matt> > 
matt> > On 30/01/18 14:27, Benjamin Kaduk wrote:
matt> >> It seems that we've started getting issues with a single build
matt> >> configuration, e.g.,
matt> >> https://travis-ci.org/openssl/openssl/jobs/335110257
matt> >>
matt> >> Lots of complaints about alignment, like:
matt> >>
matt> >> crypto/modes/gcm128.c:1090:36: runtime error: load of misaligned
matt> >> address 0x000002350ce5 for type 'const size_t' (aka 'const unsigned
matt> >> long'), which requires 8 byte alignment
matt> >> 0x000002350ce5: note: pointer points here
matt> >>  68 1f ea 3b 14 00 00  0c 00 02 00 00 00 00 00  0c a3 35 89 7d a7 5e 9e  87 fa d7 fd 8b c7 34 8a  8d
matt> >>              ^ 
matt> >> I didn't see anything particularly special about that configuration
matt> >> on a quick once-over; any ideas?
matt> > 
matt> > I raised an issue on this with some of my thoughts and investigation:
matt> > 
matt> > https://github.com/openssl/openssl/issues/5203
matt> > 
matt> > 
matt> > The error message about unsigned int requiring 8 byte alignment seems
matt> > suspicious to me. Shouldn't it be 4?
matt> 
matt> Oh...sorry just realised this is a slightly different but very similar
matt> error. In my issue it is complaining about an unsigned int requiring 8
matt> byte alignment. This issue is for an unsigned long.

So, err, ubsan isn't my forte, so I have to ask, shouldn't the
-fno-sanitize=alignment that's added in both cases have us avoid
this kind of message?  I.e. we know that we break alignment in some
cases, but that happens to be fine on those machines?

(for crypto/modes/gcm128.c, alignment should depend very much on |in|
and |out|, and if you look, you'll see that there are some checks if
STRICT_ALIGNMENT is defined, and you'll find in crypto/modes/modes_lcl.h
that it's undefined, so we obviously think we know what we're doing)

...

Hmmm, I think I know!  The configuration line is (if shortened to an
absolute minimum):

    ./config enable-ubsan -fno-sanitize-alignment

In 1.1.0 (and in master about a week ago), we got these flags among
the CFLAGS, in this order (actually, the last one is absolutely last):

    -fsanitize=undefined -fno-sanitize-recover=all
    -fno-omit-frame-pointer -fno-sanitize=alignment

In master now, we get this:

    -fno-sanitize=alignment -fsanitize=undefined
    -fno-sanitize-recover=all -fno-omit-frame-pointer

I just tried a fresh master and hacked reordered CFLAGS in Makefile to
-fno-sanitize=alignment last, and suddenly, the tests work.

So, err, I screwed up with the recent changes in Configure, in adding
the user added flags much too early to $config{cflags} and so on.

I'm on it, you should see a PR show up soon.

Cheers,
Richard

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

From rsalz at akamai.com  Tue Jan 30 16:13:55 2018
From: rsalz at akamai.com (Salz, Rich)
Date: Tue, 30 Jan 2018 16:13:55 +0000
Subject: [openssl-project] Local kid does good
Message-ID: <5DBAB91F-2569-455B-81C3-86E79848095C@akamai.com>

One of our own, Ben Kaduk, was just picked to be the Security Area co-Director in the IETF!

Conratulations.

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

From matt at openssl.org  Tue Jan 30 16:14:52 2018
From: matt at openssl.org (Matt Caswell)
Date: Tue, 30 Jan 2018 16:14:52 +0000
Subject: [openssl-project] Local kid does good
In-Reply-To: <5DBAB91F-2569-455B-81C3-86E79848095C@akamai.com>
References: <5DBAB91F-2569-455B-81C3-86E79848095C@akamai.com>
Message-ID: <8a61a860-fd8f-f575-75ee-d16873621d2b@openssl.org>



On 30/01/18 16:13, Salz, Rich wrote:
> One of our own, Ben Kaduk, was just picked to be the Security Area
> co-Director in the IETF!

Awesome! Well done Ben!

Matt


From kaduk at mit.edu  Tue Jan 30 17:42:55 2018
From: kaduk at mit.edu (Benjamin Kaduk)
Date: Tue, 30 Jan 2018 11:42:55 -0600
Subject: [openssl-project] Local kid does good
In-Reply-To: <8a61a860-fd8f-f575-75ee-d16873621d2b@openssl.org>
References: <5DBAB91F-2569-455B-81C3-86E79848095C@akamai.com>
 <8a61a860-fd8f-f575-75ee-d16873621d2b@openssl.org>
Message-ID: <20180130174255.GM67221@kduck.kaduk.org>

On Tue, Jan 30, 2018 at 04:14:52PM +0000, Matt Caswell wrote:
> 
> 
> On 30/01/18 16:13, Salz, Rich wrote:
> > One of our own, Ben Kaduk, was just picked to be the Security Area
> > co-Director in the IETF!
> 
> Awesome! Well done Ben!

Thanks!

It does seem likely to imply that I will be spending less time on
code (reviews), though.

-Ben

From Matthias.St.Pierre at ncp-e.com  Tue Jan 30 20:25:20 2018
From: Matthias.St.Pierre at ncp-e.com (Dr. Matthias St. Pierre)
Date: Tue, 30 Jan 2018 21:25:20 +0100
Subject: [openssl-project] Local kid does good
In-Reply-To: <5DBAB91F-2569-455B-81C3-86E79848095C@akamai.com>
References: <5DBAB91F-2569-455B-81C3-86E79848095C@akamai.com>
Message-ID: <5A70D4B0.1070800@ncp-e.com>

Wow! Congratulations, Ben!

Am 30.01.2018 um 17:13 schrieb Salz, Rich:
>
> One of our own, Ben Kaduk, was just picked to be the Security Area
> co-Director in the IETF!
>
>  
>

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

From paul.dale at oracle.com  Tue Jan 30 20:57:25 2018
From: paul.dale at oracle.com (Paul Dale)
Date: Tue, 30 Jan 2018 12:57:25 -0800 (PST)
Subject: [openssl-project] Local kid does good
In-Reply-To: <5DBAB91F-2569-455B-81C3-86E79848095C@akamai.com>
References: <5DBAB91F-2569-455B-81C3-86E79848095C@akamai.com>
Message-ID: <0bfbe411-c6f9-43ea-96d9-6951fa56cf6a@default>

Great going Ben!

?

Pauli

-- 

Oracle

Dr Paul Dale | Cryptographer | Network Security & Encryption 

Phone +61 7 3031 7217

Oracle Australia

?

From: Salz, Rich [mailto:rsalz at akamai.com] 
Sent: Wednesday, 31 January 2018 2:14 AM
To: openssl-project at openssl.org
Subject: [openssl-project] Local kid does good

?

One of our own, Ben Kaduk, was just picked to be the Security Area co-Director in the IETF!

?

Conratulations.

?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-project/attachments/20180130/8237252a/attachment-0001.html>