[openssl/technical-policies] d47609: Update to use @ syntax rather than \ syntax

) Changed paths: M policies/coding-style.md Log Message: --- Update to use @ syntax rather than \ syntax Reviewed-by: Paul Dale Reviewed-by: Richard Levitte Reviewed-by: Matt Caswell Reviewed-by: Tomas Mraz To unsubscribe from these emails, change your notification

[openssl/general-policies] cc8d9d: Update platform information related to AIX

) Changed paths: M policy-supplemental/platforms.md Log Message: --- Update platform information related to AIX Related to https://github.com/openssl/openssl/pull/24609 PR, a new configuration is added for aix platform to support openxl compiler. This includes the new platform in the

[openssl/general-policies] 5a51be: Update votes

) Changed paths: M votes/vote-2022-sensitive-info.txt M votes/vote-2022-travel-policy.txt Log Message: --- Update votes

[openssl/technical-policies] 1fb420: [VOTE][late update] test labelling policy

2022) Changed paths: M votes/vote-20221107-test-labels.txt Log Message: --- [VOTE][late update] test labelling policy

OMC VOTE: Update the security policy to include MODERATE issues in prenotifications.

The vote is as shown below. OMC members should cast their vote here: https://github.com/openssl/general-policies/pull/21 Mark Topic: Accept the security policy as of 314ef25aa50e6f0c6a5b026251a06a1c4941e5a2 Proposed by: Mark Cox Issue link: https://github.com/openssl/general-policies/pull/21 P

OMC Vote: Update security prenotification policy to include MODERATE issues

Topic: Update security prenotification policy to include MODERATE issues Proposed by: Mark Cox Issue link: https://github.com/openssl/general-policies/pull/20 Public: yes Opened: 2022-05-11 Closed: -MM-DD Accepted: yes/no (for: X, against: Y, abstained: Z, not voted: W) Kurt

OTC Vote for the voting policy update

The OTC vote for this policy proposal has now started. OTC members please cast your votes here: https://github.com/openssl/technical-policies/pull/17 Matt

Update on 3.0 release

FYI, OTC met today to discuss the 3.0 final release. Due to the security release taking place later today they decided that 3.0 final will not be released this week. Matt

Re: AW: [openssl] OpenSSL_1_1_1-stable update

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 Levitt

Re: AW: [openssl] OpenSSL_1_1_1-stable update

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

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

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 sho

Re: AW: [openssl] OpenSSL_1_1_1-stable update

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 som

Re: AW: [openssl] OpenSSL_1_1_1-stable update

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 app

Re: AW: [openssl] OpenSSL_1_1_1-stable update

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

Re: AW: [openssl] OpenSSL_1_1_1-stable update

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

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 u

AW: [openssl] OpenSSL_1_1_1-stable update

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 cannot

Re: Update

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

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

Re: Update

> 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

> 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

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

Re: Update

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

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 feasible

Re: Update

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

Re: Update

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 intende

Re: Update

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

Re: Update

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

Re: Update

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 proto

Re: Update

* The current requirement for inclusion is “national standard

Update

Rich made a good point: HYPERLINK "https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_openssl_openssl_pull_8910-23discussion-5Fr283111312&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=4LM0GbR0h9Fvx86FtsKI-w&m=CD4glOsr2177VCbCmwwcW44E7W9Fgpq1omQwWqU8RRI&s=5qMw3USMNfHa7EYgiJq_2Fw34OVBznS9v2zuRy9

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

>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). Vendor-affir

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

org; openssl-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

; 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

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

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 to 2.x, and i

[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@openssl.org https://mta.openssl.org/mailman/listinfo/openssl-project

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

eatures, but in 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.htm

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

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

[openssl-project] Vote to update the security policy

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

[openssl-project] Release Criteria Update

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 There

Re: [openssl-project] Release Criteria Update

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 encoded

Re: [openssl-project] Release Criteria Update

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

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 ve

Re: [openssl-project] Release Criteria Update

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 t

Re: [openssl-project] Release Criteria Update

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

Re: [openssl-project] Release Criteria Update

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

Re: [openssl-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 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 issu

[openssl-project] Release Criteria Update

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

Re: [openssl-project] Release Criteria Update

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

Re: [openssl-project] Release Criteria Update

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

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 n

Re: [openssl-project] Release Criteria Update

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

Re: [openssl-project] Release Criteria Update

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

Re: [openssl-project] Release Criteria Update

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 note

Re: [openssl-project] Release Criteria Update

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 #7014 has bee

Re: [openssl-project] Release Criteria Update

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

Re: [openssl-project] Release Criteria Update

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 for

[openssl-project] Release Criteria Update

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

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

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

uot;t...@openssl.org" Reply-To: "openssl-project@openssl.org" Date: Wednesday, March 14, 2018 at 5:33 AM To: "openssl-project@openssl.org" Subject: [openssl-project] OpenSSL FIPS Wiki Update https://wiki.openssl.org/index.php/FIPS_module_3.0<https://urldefe

[openssl-project] OpenSSL FIPS Wiki Update

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 out

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

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 w

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

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

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

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

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

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

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

➢ 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 https://mta.openssl.org/mailman/lis

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

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

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 br