punycode licensing

2019-06-20 Thread Matt Caswell
PR 9199 incorporates the C punycode implementation from RFC3492: https://github.com/openssl/openssl/pull/9199 The RFC itself has this section in it: B. Disclaimer and license Regarding this entire document or any portion of it (including the pseudocode and C code), the author makes no

Re: Removing function names from errors (PR 9058)

2019-06-13 Thread Matt Caswell
On 13/06/2019 10:50, Richard Levitte wrote: > > Good point, but note that there is no conflict with what I wrote. Yes, I realise that. > The > additional information you're talking about is something we currently > provide the ERR_add_error_data() function for, and that together with > the

Re: Removing function names from errors (PR 9058)

2019-06-13 Thread Matt Caswell
I agree with everything Richard just said. I just have some additional thoughts inserted below. On 13/06/2019 10:00, Richard Levitte wrote: > If we look at it from the perspective of the application author, > what's most often needed are reliable error/reason codes (to check and > to react

Re: Removing function names from errors (PR 9058)

2019-06-12 Thread Matt Caswell
On 12/06/2019 04:51, Richard Levitte wrote: > Many of us, both past and present, have looked at the error reporting > code and wante to change it somehow. There's currently a PR, 9058, > which covers one aspect, the function name indicator. > > A -1 was raised early on for the purpose of

Re: OpenSSL 3.0.0 FIPS Validation

2019-06-04 Thread Matt Caswell
On 04/06/2019 00:08, Matthew Lindner wrote: > I notice that the OpenSSL 3.0.0 design page > https://www.openssl.org/docs/OpenSSL300Design.html still references > "CAVS testing" even though CAVS testing is shortly ending with the > release of ACVP testing. See: >

Monthly Status Report (May)

2019-06-03 Thread Matt Caswell
As well as normal reviews, responding to user queries, wiki user requests, OMC business, handling security reports, etc., key activities this month: - Moved various global data items to use OPENSSL_CTX instead in preparation for making EVP available from within the FIPS module - Preparation for 2

Re: Forthcoming OpenSSL Releases

2019-05-29 Thread Matt Caswell
On 21/05/2019 16:43, Matt Caswell wrote: > The OpenSSL project team would like to announce the forthcoming release > of OpenSSL versions 1.1.1c, 1.1.0k and 1.0.2s. > > These releases will be made available on 28th May 2019 between approximately > 1200-1600 UTC. > > Open

Re: Repo frozen

2019-05-28 Thread Matt Caswell
Repo is now unfrozen! Matt On 27/05/2019 19:34, Matt Caswell wrote: > In preparation for tomorrow's release the repo has been frozen. > > We'll let you know when you can do pushes again. > > Matt >

Repo frozen

2019-05-27 Thread Matt Caswell
In preparation for tomorrow's release the repo has been frozen. We'll let you know when you can do pushes again. Matt

Re: AW: [openssl] OpenSSL_1_1_1-stable update

2019-05-24 Thread Matt Caswell
On 24/05/2019 15:30, Richard Levitte wrote: > On Fri, 24 May 2019 16:20:59 +0200, > Matt Caswell wrote: >> On 24/05/2019 15:10, Richard Levitte wrote: >>> If we go with the idea that an approval also involves approving what >>> branches it goes to, then what hap

Re: AW: [openssl] OpenSSL_1_1_1-stable update

2019-05-24 Thread Matt Caswell
On 24/05/2019 15:10, Richard Levitte wrote: > Not sure I see it as picking nits, it's rather about some fundamental > difference in what we thinking we're approving, and how we actually > act around that. > > My idea has always been that I approve a code change, i.e. essentially > a patch or a

Re: proposed change to committers policy

2019-05-24 Thread Matt Caswell
On 24/05/2019 10:28, SHANE LONTIS wrote: > It doesn’t stop us both reviewing a PR. That doesn’t mean we both need to > approve. Right...but in Matthias's version if you raise a PR, and then Pauli approves it, then you only then need to get a second committer approval. Otherwise you would need to

Re: Committers Day Blog

2019-05-23 Thread Matt Caswell
On 23/05/2019 18:25, Matt Caswell wrote: > Please see the following blog post by Matthias about the recent committers > day: > > https://www.openssl.org/blog/blog/2019/05/23/f2f-committers-day/ I should point out BTW that eating vegemite is not a requirement for becoming

Committers Day Blog

2019-05-23 Thread Matt Caswell
Please see the following blog post by Matthias about the recent committers day: https://www.openssl.org/blog/blog/2019/05/23/f2f-committers-day/ Matt

Re: No two reviewers from same company

2019-05-23 Thread Matt Caswell
On 23/05/2019 18:14, Tomas Mraz wrote: > On Thu, 2019-05-23 at 17:17 +0200, Richard Levitte wrote: >> On Thu, 23 May 2019 16:25:07 +0200, >> Salz, Rich wrote: >>> I understand that OpenSSL is changing things so that, by mechanism >>> (and maybe by policy although >>> it’s not published yet),

Re: No two reviewers from same company

2019-05-23 Thread Matt Caswell
On 23/05/2019 16:54, Salz, Rich wrote: >> In that example the potential conflict of interest comes from the >> individual's > employment with the third party organisation, not because they are fellows. > > Do you disagree with my contention that the OMC represents the project, and > not the

Re: No two reviewers from same company

2019-05-23 Thread Matt Caswell
On 23/05/2019 16:31, Salz, Rich wrote: > > In private email, and > https://github.com/openssl/openssl/pull/8886#issuecomment-494624313 the > implication is that this was a policy. > > AFAIK this is not the case. > > Is the comment wrong, either factually or because it is

Re: No two reviewers from same company

2019-05-23 Thread Matt Caswell
On 23/05/2019 16:01, Salz, Rich wrote: > > I understand that OpenSSL is changing things so that, by mechanism (and > maybe by > > policy although it’s not published yet), two members of the same > company cannot > > approve the same PR. That’s great. (I never approved Akamai

Re: No two reviewers from same company

2019-05-23 Thread Matt Caswell
On 23/05/2019 15:25, Salz, Rich wrote: > I understand that OpenSSL is changing things so that, by mechanism (and maybe > by > policy although it’s not published yet), two members of the same company > cannot > approve the same PR.  That’s great.  (I never approved Akamai requests unless > it

Forthcoming OpenSSL Releases

2019-05-21 Thread Matt Caswell
The OpenSSL project team would like to announce the forthcoming release of OpenSSL versions 1.1.1c, 1.1.0k and 1.0.2s. These releases will be made available on 28th May 2019 between approximately 1200-1600 UTC. OpenSSL 1.1.0k and 1.0.2s contain security hardening bug fixes only but do not

Re: Update

2019-05-20 Thread Matt Caswell
On 20/05/2019 20:01, Kurt Roeckx wrote: > On Mon, May 20, 2019 at 10:21:45AM -0700, Paul Yang wrote: >> >> The Chinese modified TLS protocol is not intended to interoperate with any >> other TLS protocols. The cipher suites defined in this protocol should not >> be used with the standard IETF

Re: Update

2019-05-20 Thread Matt Caswell
On 20/05/2019 15:23, Salz, Rich wrote: >>I don't see it that way. As I understand it this is a completely different > protocol to standard TLS. > > That's an interesting point, but ... they use the SSL "name." Which isn't even an IETF name...the IETF call it TLS ;-) >> It is not

Re: Update

2019-05-20 Thread Matt Caswell
On 20/05/2019 15:05, Salz, Rich wrote: > > The problem is that they squatted on codepoints that the IETF controls. So > while it is a national standard, it is also in conflict with the IETF > specifications. > I don't see it that way. As I understand it this is a completely different

Welcoming our new committers

2019-05-20 Thread Matt Caswell
Please welcome our four new committers as announced here: https://www.openssl.org/blog/blog/2019/05/20/committers/ The new committers are: Dmitry Belyavsky, Shane Lontis, Tomáš Mráz and Patrick Steuer. Welcome all! Matt

Re: Vote proposal: votes should get discussed first

2019-05-12 Thread Matt Caswell
On 12/05/2019 10:06, Kurt Roeckx wrote: > I would like to propose the following vote: > All public votes should be discussed on the openssl-project list > before a vote is called. The minimum time between a proposal > and calling for a vote is 1 week. If the proposal is changed, the > 1 week

Monthly Status Report (April)

2019-05-07 Thread Matt Caswell
As well as normal reviews, responding to user queries, wiki user requests, OMC business, handling security reports, etc., key activities this month: - Worked on and pushed the PR to add SHA256 support to the FIPS provider - Fixed no-sm2/no-sm3/no-ec - Corrected some documentation for

Monthly Status Report (March)

2019-04-04 Thread Matt Caswell
As well as normal reviews, responding to user queries, wiki user requests, OMC business, handling security reports, etc., key activities this month: - Fixed an issue where the ticket index was written to the session during the handshake, even though the session is supposed to be immutable -

Re: Issues and pull requests are largely getting ignored

2019-03-26 Thread Matt Caswell
On 25/03/2019 20:10, Matthew Lindner wrote: > Hello OpenSSL Team, > > The issues and pull requests on github are largely getting ignored, I > know the team is busy on the new release but please spend some time on > these as well. I don't think this is a fair characterisation. I see all posts

Re: Thoughts on OSSL_ALGORITHM

2019-03-22 Thread Matt Caswell
On 22/03/2019 15:45, Matt Caswell wrote: > An alternative is for the provider to pass the algorithm name instead, but > this > potentially requires lots of strcmps to identify which algorithm we're dealing > with which doesn't sound particularly attractive. I meant &qu

Thoughts on OSSL_ALGORITHM

2019-03-22 Thread Matt Caswell
Currently we have the OSSL_ALGORITHM type defined as follows: struct ossl_algorithm_st { const char *algorithm_name; /* key */ const char *property_definition; /* key */ const OSSL_DISPATCH *implementation; }; I'm wondering whether we should add an additional member to this

Monthly Status Report (February)

2019-03-06 Thread Matt Caswell
As well as normal reviews, responding to user queries, wiki user requests, OMC business, handling security reports, etc., key activities this month: - Worked with Richard to publish the Design and Strategy documents and wrote a blog post about them - Created a PR to rewrite SSL_dup - Made

Re: Repo frozen

2019-02-26 Thread Matt Caswell
On 25/02/2019 18:41, Matt Caswell wrote: > All > > The repo has been frozen in preparation for tomorrow's release. I'll let you > all > know when it is available for pushes again. The release is done and I have unfrozen the repo. Thanks to Richard for his support during the release. Matt

Repo frozen

2019-02-25 Thread Matt Caswell
All The repo has been frozen in preparation for tomorrow's release. I'll let you all know when it is available for pushes again. Matt

Re: [openssl-project] Updates to the release strategy

2019-02-25 Thread Matt Caswell
On 14/02/2019 14:20, Matt Caswell wrote: > > > On 12/02/2019 10:54, Matt Caswell wrote: >> Is there any more feedback on the release strategy updates? See: >> >> https://github.com/openssl/web/pull/82 >> >> Since this is a policy change it will need

Forthcoming OpenSSL Releases

2019-02-19 Thread Matt Caswell
The OpenSSL project team would like to announce the forthcoming release of OpenSSL versions 1.1.1b and 1.0.2r. There will be no new 1.1.0 release at this time. These releases will be made available on 26th February 2019 between approximately 1300-1700 UTC. OpenSSL 1.0.2r is a security-fix

Re: Thoughts about library contexts

2019-02-18 Thread Matt Caswell
On 18/02/2019 10:28, Tim Hudson wrote: > It should remain completely opaque. > As a general rule, I've never seen a context where someone regretted making a > structure opaque over time, but the converse is not true. > This is opaque and should remain opaque. > We need the flexibility to adjust

Re: Thoughts about library contexts

2019-02-18 Thread Matt Caswell
On 18/02/2019 01:38, Michael Richardson wrote: > > Paul Dale wrote: > > Library contexts are going to allow us to separate different portions > of the > > TLS/cryptographic activity within one application. No problems, here. > This > > seems like a useful and worthwhile idea. It

Re: [openssl-project] OpenSSL 3.0 and FIPS Update

2019-02-14 Thread Matt Caswell
> Senior Software Engineer, Micro Focus > > > *From:* openssl-project on behalf of > Matt > Caswell > *Sent:* Wednesday, February 13, 2019 4:26 AM > *To:* openssl-annou...@openssl.org; opens

Re: [openssl-project] Updates to the release strategy

2019-02-14 Thread Matt Caswell
On 12/02/2019 10:54, Matt Caswell wrote: > Is there any more feedback on the release strategy updates? See: > > https://github.com/openssl/web/pull/82 > > Since this is a policy change it will need an OMC vote. Proposed vote wording: > > "The release strategy shoul

[openssl-project] OpenSSL 3.0 and FIPS Update

2019-02-13 Thread Matt Caswell
Please see my blog post for an OpenSSL 3.0 and FIPS Update: https://www.openssl.org/blog/blog/2019/02/13/FIPS-update/ Matt ___ openssl-project mailing list openssl-project@openssl.org https://mta.openssl.org/mailman/listinfo/openssl-project

Re: [openssl-project] Proposed vote text for the SSL_CB_HANDSHAKE_START change

2019-02-13 Thread Matt Caswell
On 12/02/2019 10:08, Matt Caswell wrote: > > > On 07/02/2019 15:03, Matt Caswell wrote: >> That would make the proposed vote text for this OMC vote: >> >> "master and 1.1.1 will be updated so that they do not signal the start and >> end >> of

[openssl-project] Updates to the release strategy

2019-02-12 Thread Matt Caswell
Is there any more feedback on the release strategy updates? See: https://github.com/openssl/web/pull/82 Since this is a policy change it will need an OMC vote. Proposed vote wording: "The release strategy should be updated as per commit 8166924606 in https://github.com/openssl/web/pull/82;

Re: [openssl-project] Proposed vote text for the SSL_CB_HANDSHAKE_START change

2019-02-12 Thread Matt Caswell
On 07/02/2019 15:03, Matt Caswell wrote: > That would make the proposed vote text for this OMC vote: > > "master and 1.1.1 will be updated so that they do not signal the start and end > of post-handshake message exchanges in the info callback using > SS

Re: [openssl-project] Proposed vote text for the SSL_CB_HANDSHAKE_START change

2019-02-07 Thread Matt Caswell
On 06/02/2019 23:11, Kurt Roeckx wrote: > On Thu, Jan 31, 2019 at 02:19:28PM -0600, David Benjamin wrote: >> On Thu, Jan 31, 2019 at 2:01 PM Matt Caswell wrote: >> >>> >>> On 31/01/2019 18:50, David Benjamin wrote: >>>> We will see if this dama

[openssl-project] Monthly Status Report (January)

2019-02-05 Thread Matt Caswell
As well as normal reviews, responding to user queries, wiki user requests, OMC business, handling security reports, etc., key activities this month: - Significant work on the FIPS design/architecture - Fixed no-cmac - Fixed no-sock - Finished and pushed the no-pinshared PR, and backported it to

Re: [openssl-project] Proposed vote text for the SSL_CB_HANDSHAKE_START change

2019-01-31 Thread Matt Caswell
On 31/01/2019 18:50, David Benjamin wrote: > We will see if this damage turns out fatal for KeyUpdate, but OpenSSL can at > least help slow its spread by issuing a fix That's precisely what PR 8096 does. > As a heuristic for API design: if the caller needs to know the implementation > details

Re: [openssl-project] Proposed vote text for the SSL_CB_HANDSHAKE_START change

2019-01-30 Thread Matt Caswell
On 30/01/2019 17:20, Kurt Roeckx wrote: > On Wed, Jan 30, 2019 at 10:44:12AM +0000, Matt Caswell wrote: >> >> >> On 29/01/2019 19:27, David Benjamin wrote: >>> On Tue, Jan 29, 2019 at 11:31 AM Kurt Roeckx >> <mailto:k...@roeckx.be>> wrote: >>

Re: [openssl-project] Proposed vote text for the SSL_CB_HANDSHAKE_START change

2019-01-30 Thread Matt Caswell
On 29/01/2019 19:27, David Benjamin wrote: > On Tue, Jan 29, 2019 at 11:31 AM Kurt Roeckx <mailto:k...@roeckx.be>> wrote: > > On Tue, Jan 29, 2019 at 02:07:09PM +, Matt Caswell wrote: > > So I plan to start the vote soon for merging PR#8096 and backportin

Re: [openssl-project] Proposed vote text for the SSL_CB_HANDSHAKE_START change

2019-01-30 Thread Matt Caswell
On 29/01/2019 17:31, Kurt Roeckx wrote: > On Tue, Jan 29, 2019 at 02:07:09PM +0000, Matt Caswell wrote: >> So I plan to start the vote soon for merging PR#8096 and backporting it to >> 1.1.1. This is a breaking change as previously discussed. >> >> My proposed vote

[openssl-project] Proposed vote text for the SSL_CB_HANDSHAKE_START change

2019-01-29 Thread Matt Caswell
So I plan to start the vote soon for merging PR#8096 and backporting it to 1.1.1. This is a breaking change as previously discussed. My proposed vote text is as follows. Please let me know asap of any feedback. Otherwise I will start the vote soon. "master and 1.1.1 will be updated to use

Re: [openssl-project] Release strategy updates

2019-01-29 Thread Matt Caswell
On 14/01/2019 15:21, Matt Caswell wrote: > > > On 21/09/2018 14:19, Matt Caswell wrote: >> I am very concerned about stability of our API moving forwards. There >> are various discussions about changing the version number to 1.2.0 (or >> possibly 2.0.0) - which

Re: [openssl-project] [TLS] Yet more TLS 1.3 deployment updates

2019-01-28 Thread Matt Caswell
On 28/01/2019 21:18, Kurt Roeckx wrote: > On Mon, Jan 28, 2019 at 03:38:50PM +0000, Matt Caswell wrote: >> >> >> On 24/01/2019 18:12, Sam Roberts wrote: >>> The other changes that TLS1.3 requires, multiple session tickets, a >>> few new APIs to replace som

Re: [openssl-project] [TLS] Yet more TLS 1.3 deployment updates

2019-01-28 Thread Matt Caswell
On 24/01/2019 18:12, Sam Roberts wrote: > The other changes that TLS1.3 requires, multiple session tickets, a > few new APIs to replace some of the SSL_renegotiate use-cases, etc., > all are pretty routine. We could get TLS1.3 support in Node.js fairly > quickly if the info callback issue was

[openssl-project] Point compression config

2019-01-24 Thread Matt Caswell
Issue 8067 points out that we have code for enabling the configuration of the ec point formats: https://github.com/openssl/openssl/issues/8067 However, while the code exists, it is not exposed in any public API - so it is effectively dead code. I suppose in 1.0.2 it could have been used by

Re: [openssl-project] [TLS] Yet more TLS 1.3 deployment updates

2019-01-24 Thread Matt Caswell
On 23/01/2019 18:29, Viktor Dukhovni wrote: > I should also note that there are two > issues in this thread, of which this is the second. The first one is about > the limit on the number of key update messages per connection, and I hope > that we can do something sensible there with less

Re: [openssl-project] [TLS] Yet more TLS 1.3 deployment updates

2019-01-24 Thread Matt Caswell
On 23/01/2019 17:42, David Benjamin wrote: > On Wed, Jan 23, 2019 at 4:24 AM Matt Caswell <mailto:m...@openssl.org>> wrote: > > On 22/01/2019 20:41, David Benjamin wrote: > > On Tue, Jan 22, 2019 at 1:48 PM Viktor Dukhovni > mailto

Re: [openssl-project] [TLS] Yet more TLS 1.3 deployment updates

2019-01-23 Thread Matt Caswell
On 22/01/2019 20:41, David Benjamin wrote: > On Tue, Jan 22, 2019 at 1:48 PM Viktor Dukhovni > wrote: > > > > > On Jan 22, 2019, at 2:06 PM, Adam Langley > wrote: > > > > (This is another installment of our

Re: [openssl-project] Release strategy updates

2019-01-14 Thread Matt Caswell
On 21/09/2018 14:19, Matt Caswell wrote: > I am very concerned about stability of our API moving forwards. There > are various discussions about changing the version number to 1.2.0 (or > possibly 2.0.0) - which according to our versioning scheme would allow > breaking cha

[openssl-project] Monthly Status Report (December)

2019-01-06 Thread Matt Caswell
As well as normal reviews, responding to user queries, wiki user requests, OMC business, handling security reports, etc., key activities this month: - Continued input on the FIPS design - Fixed an Ed448 signature maleability issue - Fixed a regression in SSL_export_keying_material which was

[openssl-project] Monthly Status Report (November)

2018-12-06 Thread Matt Caswell
As well as normal reviews, responding to user queries, wiki user requests, OMC business, handling security reports, etc., key activities this month: - Significant review work on the Kernel TLS Socket API PR (5253) - Significant work on the FIPS Strategy and Design documents - Significnat review

[openssl-project] To deprecate OpenSSL_version() or not

2018-12-05 Thread Matt Caswell
Richard and I are discussing whether OpenSSL_version() should be deprecated or not in favour of a new function OPENSSL_info() which does more or less the same thing. See: https://github.com/openssl/openssl/pull/7724#discussion_r239067887 Richard's motivation for doing so is that he finds the old

[openssl-project] OpenSSL Versioning and License

2018-11-28 Thread Matt Caswell
Please see the following blog post about OpenSSL Versioning and License: https://www.openssl.org/blog/blog/2018/11/28/version/ Matt ___ openssl-project mailing list openssl-project@openssl.org https://mta.openssl.org/mailman/listinfo/openssl-project

Re: [openssl-project] Repo frozen

2018-11-20 Thread Matt Caswell
The release is now complete and the repo is unfrozen. Thanks to Richard for all his help during the release. Matt On 19/11/2018 16:54, Matt Caswell wrote: > In preparation for the releases tomorrow the repo has now been frozen. I'll > let > you know when its available again. >

[openssl-project] Repo frozen

2018-11-19 Thread Matt Caswell
In preparation for the releases tomorrow the repo has now been frozen. I'll let you know when its available again. Matt ___ openssl-project mailing list openssl-project@openssl.org https://mta.openssl.org/mailman/listinfo/openssl-project

[openssl-project] Forthcoming OpenSSL Releases

2018-11-14 Thread Matt Caswell
The OpenSSL project team would like to announce the forthcoming release of OpenSSL versions 1.1.1a, 1.1.0j and 1.0.2q. These releases will be made available on 20th November 2018 between approximately 1300-1700 UTC. These are bug-fix releases. They also contain the fixes for three LOW severity

[openssl-project] Release scheduling

2018-11-14 Thread Matt Caswell
There are now no open PRs/issues with the 1.1.1a milestone so I think we should go ahead and do a release. The question is when? I propose next Tuesday (20th), with releases of 1.1.0 and 1.0.2 on the same day. It's been a while since they last had releases so I think its worthwhile doing them at

Re: [openssl-project] 1.1.1a milestone status

2018-11-12 Thread Matt Caswell
On 08/11/2018 13:21, Matt Caswell wrote: > There are currently 5 PRs and 1 issue with the 1.1.1a milestone set > against them. > > Of the 5 PRs, 3 are in the ready state: > > 7462: Test: link drbgtest statically against libcrypto > 7437: rand_unix.c: open random devi

[openssl-project] OpenSSL Security Advisory

2018-11-12 Thread Matt Caswell
OpenSSL Security Advisory [12 November 2018] Microarchitecture timing vulnerability in ECC scalar multiplication (CVE-2018-5407) === Severity: Low OpenSSL ECC scalar

Re: [openssl-project] 1.1.1a milestone status

2018-11-08 Thread Matt Caswell
On 08/11/2018 13:35, David Woodhouse wrote: > On Thu, 2018-11-08 at 13:21 +0000, Matt Caswell wrote: >> There are currently 5 PRs and 1 issue with the 1.1.1a milestone set >> against them. >> >> Of the 5 PRs, 3 are in the ready state: >> >> 7462: Test: lin

[openssl-project] 1.1.1a milestone status

2018-11-08 Thread Matt Caswell
There are currently 5 PRs and 1 issue with the 1.1.1a milestone set against them. Of the 5 PRs, 3 are in the ready state: 7462: Test: link drbgtest statically against libcrypto 7437: rand_unix.c: open random devices on first use only 7391: Unbreak SECLEVEL 3 regression causing it to not accept

[openssl-project] Monthly Status Report (October)

2018-11-05 Thread Matt Caswell
As well as normal reviews, responding to user queries, wiki user requests, OMC business, handling security reports, etc., key activities this month: - Ongoing work on the Design documentation for the FIPS release - Fixed some coverity issues - Fixed BIO callback return code handling - Fixed an

Re: [openssl-project] FYI: [postfix & TLS1.3 problems]

2018-10-16 Thread Matt Caswell
On 15/10/18 20:41, Viktor Dukhovni wrote: > On Mon, Oct 15, 2018 at 06:56:06PM +0100, Matt Caswell wrote: > >>> What do you make of the >>> idea of making it possible for servers to accept downgrades (to some >>> floor protocol version or all supported ver

Re: [openssl-project] FYI: [postfix & TLS1.3 problems]

2018-10-15 Thread Matt Caswell
On 15/10/18 18:54, Viktor Dukhovni wrote: > > >> On Oct 15, 2018, at 9:19 AM, Matt Caswell wrote: >> >>> Early, partial reports of the cause seem to indicate that the sending >>> side was using OpenSSL with: >>> >>> SSL_CTX_set_mod

Re: [openssl-project] FYI: [postfix & TLS1.3 problems]

2018-10-15 Thread Matt Caswell
On 12/10/18 16:50, Viktor Dukhovni wrote: > On Thu, Oct 11, 2018 at 07:03:21PM -0500, Benjamin Kaduk wrote: > >> I would guess that the misbehaving clients are early openssl betas >> that receive the real TLS 1.3 version and then try to interpret >> as whatever draft versino they actually

[openssl-project] Monthly Status Report (September)

2018-10-01 Thread Matt Caswell
As well as normal reviews, responding to user queries, wiki user requests, OMC business, handling security reports, etc., key activities this month: - Spent the week starting 3rd September attending the OpenSSL FIPS summit in Brisbane. Working on the OpenSSL strategy for FIPS and the design of

Re: [openssl-project] Release strategy updates & other policies

2018-09-28 Thread Matt Caswell
On 26/09/18 18:24, Viktor Dukhovni wrote: > > >> On Sep 25, 2018, at 9:51 AM, Matt Caswell wrote: >> >> 5.0.0 >> 5.0.1 (bug fix) >> 5.1.0 (add accessor) >> 6.0.0 (new feature) >> 6.0.1 (bug fix) &g

[openssl-project] Fwd: Release strategy updates & other policies

2018-09-26 Thread Matt Caswell
FYI Forwarded Message Subject: Re: [openssl-project] Release strategy updates & other policies Date: Tue, 25 Sep 2018 13:37:48 -0400 From: Michael Richardson To: Matt Caswell replying directly, because the list is closed, but this is not private. Matt Caswell w

Re: [openssl-project] Release strategy updates & other policies

2018-09-25 Thread Matt Caswell
On 25/09/18 14:30, Richard Levitte wrote: > In message on Tue, 25 Sep > 2018 14:15:32 +0100, Matt Caswell said: > >> On 25/09/18 14:09, Tim Hudson wrote: >>> It would also mean our LTS releases are MAJOR.MINOR - as the PATCH is >>> the fixes we will ap

Re: [openssl-project] Release strategy updates & other policies

2018-09-25 Thread Matt Caswell
On 25/09/18 14:21, Richard Levitte wrote: > In message on Tue, 25 Sep > 2018 14:11:11 +0100, Matt Caswell said: > >> >> >> On 25/09/18 13:54, Richard Levitte wrote: >>> In message <896ece72-8923-801e-b97d-5a1b21c9c...@openssl.org> on Tue, 25 >&

Re: [openssl-project] Release strategy updates & other policies

2018-09-25 Thread Matt Caswell
On 25/09/18 13:25, Richard Levitte wrote: > In message on Tue, 25 Sep > 2018 12:22:44 +0100, Matt Caswell said: > >> >> >> On 25/09/18 12:12, Richard Levitte wrote: >>> In message <98774a3e-d127-dcd9-c835-3b359d69b...@openssl.org> on Tue, 25 >&

Re: [openssl-project] Release strategy updates & other policies

2018-09-25 Thread Matt Caswell
On 25/09/18 14:09, Tim Hudson wrote: > On Tue, Sep 25, 2018 at 11:02 PM Matt Caswell <mailto:m...@openssl.org>> wrote: > > You're right on this one. I misread the diff. > > > Not a problem - you are doing the look-at-what-we-did and how it would > be impacte

Re: [openssl-project] Release strategy updates & other policies

2018-09-25 Thread Matt Caswell
On 25/09/18 13:54, Richard Levitte wrote: > In message <896ece72-8923-801e-b97d-5a1b21c9c...@openssl.org> on Tue, 25 Sep > 2018 13:37:45 +0100, Matt Caswell said: > >>> And that is what semantic versioning is about - it is about the API. >>> So if you add t

Re: [openssl-project] Release strategy updates & other policies

2018-09-25 Thread Matt Caswell
On 25/09/18 13:56, Tim Hudson wrote: > On Tue, Sep 25, 2018 at 10:37 PM Matt Caswell <mailto:m...@openssl.org>> wrote: > > - Added some new macros: > https://github.com/openssl/openssl/pull/6037 > > > No we didn't change our public API for th

Re: [openssl-project] Release strategy updates & other policies

2018-09-25 Thread Matt Caswell
On 25/09/18 13:03, Tim Hudson wrote: > On Tue, Sep 25, 2018 at 9:22 PM Matt Caswell <mailto:m...@openssl.org>> wrote: > > Lets imagine we release version 5.0.0. We create a branch for it and > declare a support period. Its an LTS release. This is a *stable*

Re: [openssl-project] Release strategy updates & other policies

2018-09-25 Thread Matt Caswell
On 25/09/18 12:12, Richard Levitte wrote: > In message <98774a3e-d127-dcd9-c835-3b359d69b...@openssl.org> on Tue, 25 Sep > 2018 11:53:48 +0100, Matt Caswell said: > >> >> >> On 25/09/18 11:48, Richard Levitte wrote: >>> In message on Tue, 25 >&

Re: [openssl-project] Release strategy updates & other policies

2018-09-25 Thread Matt Caswell
On 25/09/18 11:48, Richard Levitte wrote: > In message on Tue, 25 Sep > 2018 11:30:39 +0100, Matt Caswell said: > >> >> >> On 25/09/18 11:13, Tim Hudson wrote: >>> On Tue, Sep 25, 2018 at 8:07 PM Matt Caswell >> <mailto:m...@openssl.org>&g

Re: [openssl-project] Release strategy updates & other policies

2018-09-25 Thread Matt Caswell
On 25/09/18 11:13, Tim Hudson wrote: > On Tue, Sep 25, 2018 at 8:07 PM Matt Caswell <mailto:m...@openssl.org>> wrote: > > On 25/09/18 10:58, Tim Hudson wrote: > > On Tue, Sep 25, 2018 at 7:23 PM Richard Levitte > mailto:levi...@openssl.org> >

Re: [openssl-project] Release strategy updates & other policies

2018-09-25 Thread Matt Caswell
On 25/09/18 10:58, Tim Hudson wrote: > On Tue, Sep 25, 2018 at 7:23 PM Richard Levitte > wrote: > > So what you suggest (and what I'm leaning toward) means that we will > change our habits. > > > Adoption of semantic versioning will indeed require us to

Re: [openssl-project] [openssl-commits] FAILED build of OpenSSL branch master with options -d --strict-warnings enable-asan no-shared -DOPENSSL_SMALL_FOOTPRINT

2018-09-24 Thread Matt Caswell
I'm getting strange results for this. I can't recreate this locally. When I run this on the run-checker box every test fails. Running a test with V=1, give this: $ make TESTS=test_sanity V=1 test make depend && make _tests make[1]: Entering directory '/home/matt/enable-asan' make[1]: Leaving

Re: [openssl-project] A proposal for an updated OpenSSL version scheme (v2)

2018-09-21 Thread Matt Caswell
On 21/09/18 17:29, Viktor Dukhovni wrote: > > >> On Sep 21, 2018, at 12:14 PM, Matt Caswell wrote: >> >> I support Richard's proposal with an epoch of 1. >> Grudgingly I would accept an epoch in the 3-8 range. >> I would oppose an epoch of 2. > >

Re: [openssl-project] A proposal for an updated OpenSSL version scheme (v2)

2018-09-21 Thread Matt Caswell
On 21/09/18 17:04, Viktor Dukhovni wrote: > I think I've said everything I have to say on this topic. So I'll stop > for now. I continue to support Richard's proposal, but with an epoch > smaller than 8. > To summarise my position: I support Richard's proposal with an epoch of 1.

[openssl-project] Release strategy updates

2018-09-21 Thread Matt Caswell
I am very concerned about stability of our API moving forwards. There are various discussions about changing the version number to 1.2.0 (or possibly 2.0.0) - which according to our versioning scheme would allow breaking changes. Whilst this is true I think we need to be very wary about "opening

Re: [openssl-project] A proposal for an updated OpenSSL version scheme (v2)

2018-09-21 Thread Matt Caswell
On 21/09/18 14:01, Tim Hudson wrote: > Semantic versioning is about a consistent concept of version handling. > > And that concept of consistency should be in a forms of the version - be > it text string or numberic. > > That you see them as two somewhat independent concepts isn't something I

Re: [openssl-project] A proposal for an updated OpenSSL version scheme (v2)

2018-09-21 Thread Matt Caswell
On 21/09/18 13:52, Richard Levitte wrote: > Note that this is for the text form, which is separate from our > numeric encoding (something that isn't covered by semver at all). > That is the only place where I propose to have an epoch, and it's for > one purpose only, that the value of that

Re: [openssl-project] A proposal for an updated OpenSSL version scheme (v2)

2018-09-21 Thread Matt Caswell
On 21/09/18 11:48, Tim Hudson wrote: > On Fri, Sep 21, 2018 at 7:58 PM Richard Levitte > wrote: > > Our FAQ says that such changes *may* be part of a major > release (we don't guarantee that breaking changes won't happen), while > semantic versioning

Re: [openssl-project] OpenSSL 1.1.1 Blog

2018-09-12 Thread Matt Caswell
Paul Yang > Nicola Tuveri > " > > aehm, maybe we should fix the alphabetical order ? :-) Tim tells me it is alphabetic by github user id! ;-) Matt > > Bernd. > > ____ > From: openssl-project on behalf of Matt > Caswel

[openssl-project] OpenSSL 1.1.1 Blog

2018-09-11 Thread Matt Caswell
Our new Long Term Support release, OpenSSL 1.1.1, including TLSv1.3, has been released today. Please download and upgrade! There is a blog post about the new release and the status of the older releases here: https://www.openssl.org/blog/blog/2018/09/11/release111/ Matt

[openssl-project] 1.1.1 is released!

2018-09-11 Thread Matt Caswell
I've just finished the 1.1.1 release process and the repo is now unfrozen. There is now a new OpenSSL_1_1_1-stable branch. 1.1.0 is officially in security fixes only mode so generally we should not be cherry-picking fixes to OpenSSL_1_1_0-stable. Congratulations and thanks to everyone who has

[openssl-project] Final check against the release criteria

2018-09-10 Thread Matt Caswell
A final check against the release criteria: - 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) There are no 1.1.1 flagged issues. There is one 1.1.1 flagged PR which was

Re: [openssl-project] coverity defect release criteria (Fwd: New Defects reported by Coverity Scan for openssl/openssl)

2018-09-09 Thread Matt Caswell
On 09/09/18 19:31, Dr. Matthias St. Pierre wrote: > I am currently occupied with other things, so I won't be able to look at it > before later this evening or tomorrow. > > I also had a quick look at CID 1423323 (see below) but I was unable to see > why 'pkey' would be a NULL pointer > when

  1   2   3   >