Re: AW: [openssl] OpenSSL_1_1_1-stable update

2019-05-24 Thread Nicola Tuveri
I have always implicitly assumed Matt view, but I am happy to conform to what the consensus is. I believe this discussion is very useful and could contribute a new entry in the commiter guidelines. Nicola On Fri, May 24, 2019, 07:21 Matt Caswell wrote: > > > On 24/05/2019 15:10, Richard

Re: AW: [openssl] OpenSSL_1_1_1-stable update

2019-05-24 Thread Matthias St. Pierre
I forgot one word: On 24.05.19 17:45, Matthias St. Pierre wrote: (Otherwise, the missing approvers need to be from the Reviewed-by list and additional approvals would be needed). need to be _removed_ from the Reviewed-by list

Re: AW: [openssl] OpenSSL_1_1_1-stable update

2019-05-24 Thread Matthias St. Pierre
On 24.05.19 16:54, Richard Levitte wrote: On Fri, 24 May 2019 16:39:51 +0200, Matt Caswell wrote: On 24/05/2019 15:30, Richard Levitte wrote: Not in practice. We *do* ask on the PR in question if it should be cherry-picked to 1.1.1 and seek approval for that action, but then it hasn't at

Re: AW: [openssl] OpenSSL_1_1_1-stable update

2019-05-24 Thread Richard Levitte
On Fri, 24 May 2019 16:39:51 +0200, Matt Caswell wrote: > > > > On 24/05/2019 15:30, Richard Levitte wrote: > > > > Not in practice. We *do* ask on the PR in question if it should be > > cherry-picked to 1.1.1 and seek approval for that action, but then it > > hasn't at all been clear what

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 happens if someone realises after

Re: AW: [openssl] OpenSSL_1_1_1-stable update

2019-05-24 Thread Richard Levitte
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 happens if someone realises after some > > time that a set of commits (a PR) that was

Re: AW: [openssl] OpenSSL_1_1_1-stable update

2019-05-24 Thread Dmitry Belyavsky
Hello, On Fri, May 24, 2019 at 5:21 PM 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 happens if someone realises after some > > time that a set of commits (a PR)

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: AW: [openssl] OpenSSL_1_1_1-stable update

2019-05-24 Thread Richard Levitte
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 set of patches, without regard for exact branches it ends

AW: [openssl] OpenSSL_1_1_1-stable update

2019-05-24 Thread Dr. Matthias St. Pierre
Matt and Richard, I think you are mixing up cherry-picking and nit-picking here. (Sorry for the pun ;-) Matthias > To be picky, may I assume that you meant a reviewed-by tag for you > > should be *added*? The commit itself (its contents) having been > > reviewed by those already there, I

Re: Update

2019-05-22 Thread Salz, Rich
>> I'd be opposed to this last option without IANA/IETF being on board. By doing so >we are effectively no longer compliant with IETF TLS since we're using certain >codepoints and version numbers to mean things that IETF/IANA have no visibility >of, i.e. we would be

Re: Update

2019-05-21 Thread Paul Yang
> On May 22, 2019, at 10:16, Salz, Rich wrote: > >>> I'd be opposed to this last option without IANA/IETF being on board. By >>> doing so >> we are effectively no longer compliant with IETF TLS since we're using >> certain >> codepoints and version numbers to mean things that IETF/IANA

Re: Update

2019-05-21 Thread Paul Yang
> On May 21, 2019, at 22:13, Salz, Rich wrote: > > >> I'd be opposed to this last option without IANA/IETF being on board. By >> doing so >we are effectively no longer compliant with IETF TLS since we're using > certain >codepoints and version numbers to mean things that IETF/IANA

Re: Update

2019-05-21 Thread Paul Yang
> On May 21, 2019, at 06:20, Matt Caswell wrote: > > > 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

Re: Update

2019-05-21 Thread Salz, Rich
> I'd be opposed to this last option without IANA/IETF being on board. By > doing so we are effectively no longer compliant with IETF TLS since we're using certain codepoints and version numbers to mean things that IETF/IANA have no visibility of, i.e. we would be doing

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 Kurt Roeckx
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 TLS. So I guess what Matt said would be

Re: Update

2019-05-20 Thread Paul Yang
> On May 20, 2019, at 07:49, Matt Caswell wrote: > > > 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

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 Salz, Rich
>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." > It is not intended to interoperate with it in any way. Is that true? I didn't look closely at the protocol changes, but

Re: Update

2019-05-20 Thread Richard Levitte
On Mon, 20 May 2019 16:05:49 +0200, Salz, Rich wrote: > > * The current requirement for inclusion is “national standard” or better. > Thus, this change > should be accepted. > > The problem is that they squatted on codepoints that the IETF controls. So > while it is a national >

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

Re: Update

2019-05-20 Thread Salz, Rich
* The current requirement for inclusion is “national

Update

2019-05-19 Thread Paul Dale
Rich made a good point: HYPERLINK

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

2019-02-15 Thread Salz, Rich
>We won't be offering the service to add new platforms onto our own > certificate, but you should be able perform your own validation for your own platforms based on ours (I forget the correct FIPS term for this...perhaps someone more FIPSy than I am can chip in).

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

2019-02-14 Thread Matt Caswell
sl-us...@openssl.org; > openssl-project@openssl.org > *Subject:* [openssl-project] OpenSSL 3.0 and FIPS Update >   > 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 > __

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

2019-02-14 Thread Zeke Evans
; openssl-project@openssl.org Subject: [openssl-project] OpenSSL 3.0 and FIPS Update 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

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

2019-02-14 Thread Benjamin Kaduk
On Wed, Feb 13, 2019 at 03:28:30PM -0500, Michael Richardson wrote: > > Matt Caswell wrote: > > Please see my blog post for an OpenSSL 3.0 and FIPS Update: > > > https://www.openssl.org/blog/blog/2019/02/13/FIPS-update/ > > Thank you, it is very useful to hav

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

2019-02-14 Thread Michael Richardson
Matt Caswell wrote: > Please see my blog post for an OpenSSL 3.0 and FIPS Update: > https://www.openssl.org/blog/blog/2019/02/13/FIPS-update/ Thank you, it is very useful to have these plans made up front. I think your posts should probably explain what happened

[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

[openssl-project] Update release strategy to document new versioning scheme

2019-01-09 Thread Matthias St. Pierre
a way that does not break binary > compatibility. ... In fact, the only official mentions of the new versioning scheme are the blog post [2] from November 28 and (indirectly) the License page [3] because it has been updated for the Apache relicensing. So maybe `releasestrat.html` needs an update?

Re: [openssl-project] Vote to update the security policy

2018-12-06 Thread Kurt Roeckx
On Thu, Nov 29, 2018 at 03:34:29PM +, Mark J Cox wrote: > Changes to policies require an OMC vote which I've called to approve an > update to the security policy. This was as discussed at the face to face > and the details and diff are at https://github.com/openssl/we

[openssl-project] Vote to update the security policy

2018-11-29 Thread Mark J Cox
Changes to policies require an OMC vote which I've called to approve an update to the security policy. This was as discussed at the face to face and the details and diff are at https://github.com/openssl/web/pull/96 topic: Update security policy as per https://github.com/openssl

[openssl-project] Release Criteria Update

2018-09-08 Thread Matt Caswell
We have 2 outstanding 1.1.1 PRs. These are: #7144 ASN.1 DER: Make INT32 / INT64 types read badly encoded LONG zeroes Owner: Richard Awaiting updates following review feedback #7145 SipHash: add separate setter for the hash size Owner: Richard Awaiting updates following review feedback

Re: [openssl-project] Release Criteria Update

2018-09-08 Thread Matt Caswell
On 07/09/18 10:09, Richard Levitte wrote: > In message on Fri, 7 Sep > 2018 09:56:01 +0100, Matt Caswell said: > >> >> >> On 07/09/18 01:51, Richard Levitte wrote: >>> I think this one should be part of the lot as well: >>> >>> #7144 >>> ASN.1 DER: Make INT32 / INT64 types read badly

Re: [openssl-project] Release Criteria Update

2018-09-08 Thread Richard Levitte
In message on Fri, 7 Sep 2018 09:56:01 +0100, Matt Caswell said: > > > On 07/09/18 01:51, Richard Levitte wrote: > > I think this one should be part of the lot as well: > > > > #7144 > > ASN.1 DER: Make INT32 / INT64 types read badly encoded LONG zeroes > > > > For example, *all* two-prime

Re: [openssl-project] Release Criteria Update

2018-09-08 Thread Matt Caswell
On 07/09/18 01:51, Richard Levitte wrote: > I think this one should be part of the lot as well: > > #7144 > ASN.1 DER: Make INT32 / INT64 types read badly encoded LONG zeroes > > For example, *all* two-prime RSA keys from pre-1.1.1 become unreadable > in 1.1.1, because pre-1.1.1 encodes the

Re: [openssl-project] Release Criteria Update

2018-09-06 Thread Richard Levitte
In message <20180907.025152.1131079938025695690.levi...@openssl.org> on Fri, 07 Sep 2018 02:51:52 +0200 (CEST), Richard Levitte said: > For example, *all* two-prime RSA keys from pre-1.1.1 become unreadable That was a bit of an over-statement... but it seems that there are things in the wild

Re: [openssl-project] Release Criteria Update

2018-09-06 Thread Richard Levitte
I think this one should be part of the lot as well: #7144 ASN.1 DER: Make INT32 / INT64 types read badly encoded LONG zeroes For example, *all* two-prime RSA keys from pre-1.1.1 become unreadable in 1.1.1, because pre-1.1.1 encodes the version indicator (zero) as 02 00 (zero length INTEGER,

Re: [openssl-project] Release Criteria Update

2018-09-06 Thread Paul Dale
nssl-project] Release Criteria Update   All PRs except #7145 now reviewed and marked ready.   Tim    On Fri, Sep 7, 2018 at 8:41 AM, Matt Caswell mailto:m...@openssl.org"m...@openssl.org> wrote: We currently have 8 1.1.1 PRs that are open. 3 of which are in the "ready" st

Re: [openssl-project] Release Criteria Update

2018-09-06 Thread Tim Hudson
All PRs except #7145 now reviewed and marked ready. Tim On Fri, Sep 7, 2018 at 8:41 AM, Matt Caswell wrote: > We currently have 8 1.1.1 PRs that are open. 3 of which are in the > "ready" state. There are 2 which are alternative implementations of the > same thing - so there are really on 4

[openssl-project] Release Criteria Update

2018-09-06 Thread Matt Caswell
We currently have 8 1.1.1 PRs that are open. 3 of which are in the "ready" state. There are 2 which are alternative implementations of the same thing - so there are really on 4 issues currently being addressed: #7145 SipHash: add separate setter for the hash size Owner: Richard Awaiting review

Re: [openssl-project] Release Criteria Update

2018-09-06 Thread Viktor Dukhovni
> On Sep 6, 2018, at 6:25 PM, Matt Caswell wrote: > > I'm not keen on that. What do others think? No objections to issuing a release. We're unlikely to have to change the API/ABI or feature set based on further beta feedback. Any late bugs can be fixed in 1.1.1a, and unless they trigger

Re: [openssl-project] Release Criteria Update

2018-09-06 Thread Tim Hudson
We need to get this release out and available - there are a lot of people waiting on the "production"release - and who won't go forward on a beta (simple fact of life there). I don't see the outstanding items as release blockers - and they will be wrapped up in time. Having the release date as a

Re: [openssl-project] Release Criteria Update

2018-09-06 Thread Matt Caswell
On 06/09/18 17:32, Kurt Roeckx wrote: > On Tue, Sep 04, 2018 at 05:11:41PM +0100, Matt Caswell wrote: >> Current status of the 1.1.1 PRs/issues: > > Since we did make a lot of changes, including things that > applications can run into, would it make sense to have an other > beta release? I'm

Re: [openssl-project] Release Criteria Update

2018-09-06 Thread Kurt Roeckx
On Tue, Sep 04, 2018 at 05:11:41PM +0100, Matt Caswell wrote: > Current status of the 1.1.1 PRs/issues: Since we did make a lot of changes, including things that applications can run into, would it make sense to have an other beta release? Kurt ___

Re: [openssl-project] Release Criteria Update

2018-09-06 Thread Benjamin Kaduk
On Wed, Sep 05, 2018 at 06:04:08PM -0500, Benjamin Kaduk wrote: > On Wed, Sep 05, 2018 at 11:59:34PM +0100, Matt Caswell wrote: > > Today's update is that we still have 6 open PRs for 1.1.1. 5 of these > > are the same as yesterday. The 1 that was marked as "ready" y

Re: [openssl-project] Release Criteria Update

2018-09-05 Thread Tim Hudson
On Thu, Sep 6, 2018 at 8:59 AM, Matt Caswell wrote: > #7113 An alternative to address the SM2 ID issues > (an alternative to the older PR, #6757) > > Updates made following earlier review. Awaiting another round of reviews. > Owner: Paul Yang All the previous comments have been addressed. I

Re: [openssl-project] Release Criteria Update

2018-09-05 Thread Benjamin Kaduk
On Wed, Sep 05, 2018 at 11:59:34PM +0100, Matt Caswell wrote: > Today's update is that we still have 6 open PRs for 1.1.1. 5 of these > are the same as yesterday. The 1 that was marked as "ready" yesterday > has now been merged, and a new PR addressing issue #7

Re: [openssl-project] Release Criteria Update

2018-09-05 Thread Matt Caswell
Today's update is that we still have 6 open PRs for 1.1.1. 5 of these are the same as yesterday. The 1 that was marked as "ready" yesterday has now been merged, and a new PR addressing issue #7014 has been opened. There are still 2 open issues for 1.1.1 but both of these are now being

Re: [openssl-project] Release Criteria Update

2018-09-04 Thread Benjamin Kaduk
On Tue, Sep 04, 2018 at 05:11:41PM +0100, Matt Caswell wrote: > There are 2 open issues for 1.1.1. One of these is being addressed by > PR#7073 above. The other one is: > > #7014 TLSv1.2 SNI hostname works in 1.1.0h, not in 1.1.1 master (as of > 18-Aug) > > This one seems stuck!! No clear way

[openssl-project] Release Criteria Update

2018-09-04 Thread Matt Caswell
Current status of the 1.1.1 PRs/issues: There are currently 6 open PRs for 1.1.1. However in 2 cases there are 2 alternative implementations for the same thing - so really there are only 4 issues being addressed. One of these is in the "ready" state. The remaining 3 are: #7114 Process KeyUpdate

[openssl-project] 1.1.1 Release criteria update

2018-08-02 Thread Matt Caswell
A quick update on the status of the 1.1.1 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 Status: We have 5 open issues (4 of which were opened within the last 2

[openssl-project] Apache update

2018-03-28 Thread Salz, Rich
Apache trunk now supports OpenSSL’s TLS 1.3 Woo hoo! ___ openssl-project mailing list openssl-project@openssl.org https://mta.openssl.org/mailman/listinfo/openssl-project

Re: [openssl-project] OpenSSL FIPS Wiki Update

2018-03-14 Thread Salz, Rich
uot;t...@openssl.org" <t...@openssl.org> Reply-To: "openssl-project@openssl.org" <openssl-project@openssl.org> Date: Wednesday, March 14, 2018 at 5:33 AM To: "openssl-project@openssl.org" <openssl-project@openssl.org> Subject: [openssl-project] OpenSSL FIPS

[openssl-project] OpenSSL FIPS Wiki Update

2018-03-14 Thread Tim Hudson
https://wiki.openssl.org/index.php/FIPS_module_3.0 I've edited that to be closer to the list of items we are discussing and to remove things which looked like commitments that are out of scope of our current plans. As always, feedback is welcome - but we have had a few people referencing that

Re: [openssl-project] Style guide update -- summary so far

2018-02-05 Thread Kurt Roeckx
On Mon, Feb 05, 2018 at 08:43:04PM +0100, Dr. Matthias St. Pierre wrote: > > > Am 05.02.2018 um 19:13 schrieb Salz, Rich: > > > > > > Do not put a size after sizeof; do use parens. > > > > nit: Do not put a /space /after sizeof. > > > > > > > Treat a single-statement with comment as if it

Re: [openssl-project] Style guide update -- summary so far

2018-02-05 Thread Paul Dale
> Arguments inside macro expansions should be parenthesized. >     #define foo(a, b)  ((a) + (b)) Except when token concatenating a ## b and stringifying # a. As an aside, should there be spaces on either size of the ## concatenator? The current code mostly doesn't -- which means

Re: [openssl-project] Style guide update -- summary so far

2018-02-05 Thread Salz, Rich
* nit: Do not put a space after sizeof. fixed. * Wasn't there also the suggestion by someone that if one part of an if-else statements needs braces that the other part should get some, too? It already says that. ___ openssl-project mailing

Re: [openssl-project] Style guide update -- summary so far

2018-02-05 Thread Matt Caswell
On 05/02/18 19:43, Dr. Matthias St. Pierre wrote: > > Wasn't there also the suggestion by someone that if one part of an > if-else statements needs braces that the other part should get some, too? That's already in the style guide: Do not unnecessarily use braces around a single statement:

Re: [openssl-project] Style guide update -- summary so far

2018-02-05 Thread Dr. Matthias St. Pierre
Am 05.02.2018 um 19:13 schrieb Salz, Rich: > > > Do not put a size after sizeof; do use parens. > nit: Do not put a /space /after sizeof. > > > Treat a single-statement with comment as if it were multi-line and use > curly braces > > > > if (test()) { > >

Re: [openssl-project] Style guide update -- summary so far

2018-02-05 Thread Salz, Rich
➢ In general we should prefer ossl_assert over assert. Never use OPENSSL_assert() in libcrypto or libssl. Maybe that’s all to put into the guide, then. ___ openssl-project mailing list openssl-project@openssl.org

Re: [openssl-project] Style guide update -- summary so far

2018-02-05 Thread Matt Caswell
On 05/02/18 18:13, Salz, Rich wrote: > Use ossl_assert, not assert.  Do not forget to handle the error > condition as asserts are not compiled into production code. It's slightly more nuanced than that. There are occasions where assert is ok, e.g. switch(my_expression) { case 1: /* do

[openssl-project] Style guide update -- summary so far

2018-02-05 Thread Salz, Rich
A summary of the discussion thread so far. Not surprisingly, it’s all about the whitespace. :) The descriptions here were written to be understandable stand-alone. Once we come to a conclusion, we’ll wordsmith them into the coding style. Do not put a size after sizeof; do use parens. When