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

[Pauli]

  Branch: refs/heads/master
  Home:   https://github.com/openssl/general-policies
  Commit: 5a51be15639d22f3beb648b20eafb16324abf431
  
https://github.com/openssl/general-policies/commit/5a51be15639d22f3beb648b20eafb16324abf431
  Author: Pauli 
  Date:   2022-11-22 (Tue, 22 Nov 2022)

  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

[Nicola Tuveri]

  Branch: refs/heads/master
  Home:   https://github.com/openssl/technical-policies
  Commit: 1fb420362b34b1481c7ab41f01bdba3d3139b10b
  
https://github.com/openssl/technical-policies/commit/1fb420362b34b1481c7ab41f01bdba3d3139b10b
  Author: Nicola Tuveri 
  Date:   2022-11-15 (Tue, 15 Nov 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.

[Mark J Cox]

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
Public: yes
Opened: 2022-05-25
Closed: -MM-DD
Accepted:  yes/no  (for: X, against: Y, abstained: Z, not voted: W)

   Kurt   [  ]
   Mark   [ +1]
   Matt   [  ]
   Pauli  [ +1]
   Richard[  ]
   Tim[  ]

OMC Vote: Update security prenotification policy to include MODERATE issues

[Mark J Cox]

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   [  ]
  Mark   [  ]
  Matt   [  ]
  Pauli  [  ]
  Richard[  ]
  Tim[  ]

OTC Vote for the voting policy update

[Matt Caswell]

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

[Matt Caswell]

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

[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

[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 all been clear what should happen regarding Received-By
tags.

I have personally never touched them when cherry-picking, even in this
scenario.  I do not know what others do in that case...>


In principle I agree with Matt, his arguments are reasonable.
Maybe a compromise would be to allow the practice of asking
for an informal reconfirmation when cherry-pick tags were forgotten,
but only if one receives reconfirmation from _all_ original reviewers?
(Otherwise, the missing approvers need to be from the Reviewed-by list
and additional approvals would be needed).

Matthias

Re: AW: [openssl] OpenSSL_1_1_1-stable update

[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 should happen regarding Received-By
> > tags.
> > 
> > I have personally never touched them when cherry-picking, even in this
> > scenario.  I do not know what others do in that case...>
> 
> In the vast majority of the cases the reviewers are the same.

Yes, because cherry-picking as an after-though rarely happens.  It's
mostly been along the lines of "hey, why was this bug-fix only applied
to master???"

> I wouldn't want other people putting my name in a reviewed-by tag
> where I have not approved it and I have not considered the
> implications of that change in that branch. What if it resulted in a
> critical CVE?

I haven't given possible CVEs much though, quite frankly.

But tell you what, I can certainly change my ways if this is what we
all think is the way to go.  Not a problem.  And I'm glad that we
talked about it, rather than staying with "I thought everyone else did
the same".

Cheers,
Richard

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

Re: AW: [openssl] OpenSSL_1_1_1-stable update

[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 applied to master only
> > should really also be applied to 1.1.1?  Should the approval process
> > start over from scratch, i.e. all approvals that went to master should
> > be scratched and replaced with a new set of approvals (in principle)?
> 
> No. If the PR was approved for master and applied to master then no problem - 
> it
> stays in master. If it is later realised that it needs to be backported to 
> other
> branches then, yes, new approvals need to be sought for that change to *those
> branches*.
> 
> As far as I was aware we've always done this.

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 should happen regarding Received-By
tags.

I have personally never touched them when cherry-picking, even in this
scenario.  I do not know what others do in that case...

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

AW: [openssl] OpenSSL_1_1_1-stable update

[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 cannot see a reason why they should
> > be removed.
> 
> You approved for master but did not approve for 1.1.1. This commit was merged 
> to
> 1.1.1 and so strictly speaking was not approved by you for that branch.
> Therefore you should have been removed, and I should have been added.
> 
> Matt

Re: Update

[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 exactly what Rich was worried about. I 
don't see
>IANA/IETF doing this anytime soon.
> 
> For the most part, getting IANA on board requires someone in authority 
email to tls-regis...@iana.org asking for code points and pointing to their 
spec.

’someone in authority’ here means the author of the spec who is asking for 
code points?


Yes.  Or someone involved with the spec.

Re: Update

[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 have no 
>> visibility
>>   of, i.e. we would be doing exactly what Rich was worried about. I don't see
>>   IANA/IETF doing this anytime soon.
>> 
>> For the most part, getting IANA on board requires someone in authority email 
>> to tls-regis...@iana.org asking for code points and pointing to their spec.
> 
>’someone in authority’ here means the author of the spec who is asking for 
> code points?
> 
> 
> Yes.  Or someone involved with the spec.

Hmmm, that would be someone involved in GM/T 0024...

> 

Re: Update

[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 have no 
> visibility
>of, i.e. we would be doing exactly what Rich was worried about. I don't see
>IANA/IETF doing this anytime soon.
> 
> For the most part, getting IANA on board requires someone in authority email 
> to tls-regis...@iana.org asking for code points and pointing to their spec.

’someone in authority’ here means the author of the spec who is asking for code 
points?

> 

Re: Update

[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 exactly what Rich was worried about. I don't see
IANA/IETF doing this anytime soon.
   
For the most part, getting IANA on board requires someone in authority email to 
tls-regis...@iana.org asking for code points and pointing to their spec.

Re: Update

[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 even an IETF name...the IETF call it TLS ;-)
> 
>>> It is not intended to interoperate with it in any way.
>> Is that true?  I didn't look closely at the protocol changes, but maybe 
>> you're right.  On the other hand, if so, then why keep the existing IETF 
>> numbers?
> 
> 
> That was my understanding.
> 
> But perhaps Paul Yang can confirm?

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 to 
do. But in reality, users may want to have a combination of both IETF TLS and 
Chinese TLS together when he launches a TLS server or client, to have the 
auto-selection functionality if a TLS client comes in. So the way of 
implementation would be tricky...

Another problem we are still facing nowadays is actually there *would* even be 
interoperability issues between Chinese TLS implementations (as we discussed 
earlier in Vancouver). The GM/T 0024 is not very strict and clear on several 
details in the protocol thus implementations have freedom to be diverse. So if 
OpenSSL finally picks up the Chinese TLS, we probably need to make sure the 
implementation should be widely tested against most Chinese TLS 
implementations. As what Tim has asked at: 
https://github.com/openssl/openssl/pull/8910#issuecomment-491964656 

> 
>>>   As a completely different protocol they can use whatever codepoints they 
>>> want to
>>use as they see fit - and there is no conflict with IETF specifications.
>> 
>> If you are correct, then yes I agree.  But that makes any OpenSSL 
>> integration that much harder, doesn't it?  Would the project take on the 
>> work of making things like the apps and tests work?  In particular, a new 
>> global flag saying "tnssl" (or such), and failing to interop with existing 
>> TLS, checking the modified cipher suites (and disallowing them for real 
>> TLS), etc.
>> 
>> 
> Yes, we would have to take care that the two really are separate.
> 
> Matt
> 
> 

Re: Update

[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 maybe you're 
right.  On the other hand, if so, then why keep the existing IETF numbers?

>As a completely different protocol they can use whatever codepoints they 
> want to
use as they see fit - and there is no conflict with IETF specifications.
  
If you are correct, then yes I agree.  But that makes any OpenSSL integration 
that much harder, doesn't it?  Would the project take on the work of making 
things like the apps and tests work?  In particular, a new global flag saying 
"tnssl" (or such), and failing to interop with existing TLS, checking the 
modified cipher suites (and disallowing them for real TLS), etc.

 

Re: Update

[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
> standard, it is also in conflict with the IETF specifications.

Did they?  For the protocol version, they used something that has
never seen the light of day (0x0003 - 0x02ff is "free" and will most
probably never be used for TLS), and the cipher suites they added are
in a range that's unassigned (0xE0xx).

You *are* correct on one point, though...  the Chinese standard isn't
TLS.  Like Matt says, it's a different protocol, even though it
resembles TLS v1.1 quite a bit.

Cheers,
Richard

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

Re: Update

[Salz, Rich]

  *   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 standard, it is also in conflict with the IETF 
specifications.

Update

[Paul Dale]

Rich made a good point:  HYPERLINK 
"https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_openssl_openssl_pull_8910-23discussion-5Fr283111312=DwMFaQ=96ZbZZcaMF4w0F4jpN6LZg=4LM0GbR0h9Fvx86FtsKI-w=CD4glOsr2177VCbCmwwcW44E7W9Fgpq1omQwWqU8RRI=5qMw3USMNfHa7EYgiJq_2Fw34OVBznS9v2zuRy9NWS8="https://github.com/openssl/openssl/pull/8910#discussion_r283111312

(China's modified TLS defined by GM/T 0024-2014).  The PR has been closed 
unmerged but it raises a question.

 

The current requirement for inclusion is "HYPERLINK 
"https://www.openssl.org/blog/blog/2018/01/18/f2f-london/"national standard" or 
better.  Thus, this change should be accepted.

 

For TLS, would it be better if the inclusion requirement were amended to also 
include "IETF codepoints allocated"?

Presumably DTLS and QUIC too.

 

 

Pauli

-- 

Oracle

Dr Paul Dale | Cryptographer | Network Security & Encryption 

Phone +61 7 3031 7217

Oracle Australia

 

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

[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 have these plans made up front.
> I think your posts should probably explain what happened to 2.x, and if this
> represents a move towards semantic versioning. (I think it does...?)
> 
> In the various things linked, in particular:
>https://www.openssl.org/docs/OpenSSL300Design.html
> 
> I think that there is a missing box.  Specifically, the PERL API wrappers

Later on you seem to clarify that by "PERL API" you mean "Net::SSLeay" but
I just want to double-check.

> that are used in the test bench.  I believe that the "applications" are
> a serious problem as there are (in 1.1.1) still many things that are very
> difficult (sometimes, it seems, impossible) to do programmatically, and which
> the test cases actually simply shell out to the application to do.
> An example of this is adding certain extensions to a certificate when
> generating it, which is only really possible by loading pieces of
> configuration file in.

It might we worth raising github issues to point out these omissions.

> So what I'd like to see is to remove many of the applications from the core
> of OpenSSL, put them into a seperate package using better-documented API
> calls.  Let them evolve according their own time-scale, probably taking
> patches faster without disrupting the underlying libraries.

In the vein of your later comment about "20 years of twisty code", I'm
actually somewhat inclined to clave off the applications and leave them
alone, so that people needing bug-for-bug compatibility can keep it.  Then
we could rewrite the functionality in question with a more maintainable
structure in a way that would also function as examplar API usage.

> My observation is that the Perl testing system is used to drive the tests,
> but the tests do not actually use the Perl API wrapper for OpenSSL, but
> rather rely on the vast number of .c files in test/*.
> In other (more purely agile) projects, the test cases often serve as
> documentation as to how to use the API.  In OpenSSL, the test cases
> rely too much on the openssl "applications", and the API is hidden.

So, when I write new code that requires tests (which is basically all new
code, try as I may to convince myself otherwise), the first thing I try to
do is put in an API-only test that's a "standalone" executable (ignore
sslapitest.c which is not standalone but functionally is so) to exercise
narrowly the functionality in question.  Only if it's a big hassle,
requires additional (certificate) input and/or configuration files, etc.,
do I fail over to using the "application" as the testbed.  There's a
tradeoff, and while the current playing field often biases that tradeoff in
a direction I'd rather not go, changing the playing field is more work than
I have time to take on while a sitting IETF AD.

> This would involve adopting some or all of Net::SSLeay.
> While there would be some initial duplication of effort, I think that over
> time it would sort itself out.  Perl is no longer as cool as it used to be (I
> still like it) and maybe someone would argue for Python3 or something, and
> frankly I don't care which.

I don't think that OpenSSL itself should adopt Net::SSLeay, even though we
do seem to have one of the higher perl usage fractions of the open-source
projects I interact with.  We have enough on our hands with the core C
libraries to modernize.

> What I care about is that the test cases actually test the API, rather than
> depend upon 20 years of twisty code in the "applications".
> And that the applications are permitted to grow/change/adapt to people's
> needs, rather than living in a hard spot between developer needs and end
> user needs, pissing off both groups.

I agree that mixing user needs and developer needs is a recipe for sadness.
I'm not sure that actually tearing them apart from the current "apps" is
something that we can realistically do while preserving our goal of
cross-release stability.

-Ben
___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project

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

[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 to 2.x, and if this
represents a move towards semantic versioning. (I think it does...?)

In the various things linked, in particular:
   https://www.openssl.org/docs/OpenSSL300Design.html

I think that there is a missing box.  Specifically, the PERL API wrappers
that are used in the test bench.  I believe that the "applications" are
a serious problem as there are (in 1.1.1) still many things that are very
difficult (sometimes, it seems, impossible) to do programmatically, and which
the test cases actually simply shell out to the application to do.
An example of this is adding certain extensions to a certificate when
generating it, which is only really possible by loading pieces of
configuration file in.

So what I'd like to see is to remove many of the applications from the core
of OpenSSL, put them into a seperate package using better-documented API
calls.  Let them evolve according their own time-scale, probably taking
patches faster without disrupting the underlying libraries.

My observation is that the Perl testing system is used to drive the tests,
but the tests do not actually use the Perl API wrapper for OpenSSL, but
rather rely on the vast number of .c files in test/*.
In other (more purely agile) projects, the test cases often serve as
documentation as to how to use the API.  In OpenSSL, the test cases
rely too much on the openssl "applications", and the API is hidden.

This would involve adopting some or all of Net::SSLeay.
While there would be some initial duplication of effort, I think that over
time it would sort itself out.  Perl is no longer as cool as it used to be (I
still like it) and maybe someone would argue for Python3 or something, and
frankly I don't care which.

What I care about is that the test cases actually test the API, rather than
depend upon 20 years of twisty code in the "applications".
And that the applications are permitted to grow/change/adapt to people's
needs, rather than living in a hard spot between developer needs and end
user needs, pissing off both groups.

--
]   Never tell me the odds! | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works|IoT architect   [
] m...@sandelman.ca  http://www.sandelman.ca/|   ruby on rails[







signature.asc
Description: PGP signature
___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project

[openssl-project] OpenSSL 3.0 and FIPS Update

[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

[Matthias St. Pierre]

Hi,

I just happened to notice that the Release Strategy [1] on our homepage is
outdated w.r.t. the versioning scheme: It still calls the 1.x.y versioning 
scheme
the 'improved' one, and does not mention the new 3.0.0+ scheme at all.


As of release 1.0.0 the OpenSSL  versioning scheme was improved

> to better meet developers' and vendors' expectations. Letter
> releases, such as 1.0.2a, exclusively contain bug and security
> fixes and no new features. Minor releases that change the last
> digit, e.g. 1.1.0 vs. 1.1.1, can and are likely to contain new
> features, 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.html` needs an update? You could also add a separate
`versioning.html` for versioning details, if you don't want to overload 
`releasestrats.html`.
The contents of `versioning.html` could be taken partially from [1] and [3].


Matthias

[1] https://www.openssl.org/policies/releasestrat.html
[2] https://www.openssl.org/blog/blog/2018/11/28/version/
[3] https://www.openssl.org/source/license.html


___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project

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

[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/web/pull/96
> 
> ----
> topic: Update security policy as per https://github.com/openssl/web/pull/96

This vote failed with 4 votes against and 3 people not voting.

The intend of voting against is to work on the wording and then
call a new vote.


Kurt

___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project

[openssl-project] Vote to update the security policy

[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/web/pull/96
comment: as discussed f2f
Proposed by Mark Cox
Public: yes
opened: 2018-11-29
closed: -mm-dd
ONE WEEK VOTE


___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project

Re: [openssl-project] Release Criteria Update

[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 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 is invalid) instead of 02 01 00
>>> (proper zero).  That's simply because the internal version number was
>>> changed from a LONG (custom ASN.1 type, mapping to a C long) to a INT32
>>> (new custom ASN.1 type, mapping to a C int32).
>>> (no, we don't want to go back to using LONG)
>>
>> So...that PR seems to be labelled for 1.1.0 too? So why is the problem
>> specific to 1.1.1?
> 
> Because of commit 6a32a3c058dbd9fa7cec5b020e4f027808972e4a, which is
> only present in master.  In that commit, we switch a number of uses of
> LONGs (all the remaining) to INT32.
> 
> Of course, one way would be to revert that commit, but that doesn't
> fix the actual issue with INT32 not reading in a backward compatible
> way (that issue exists in 1.1.0 as well).
> 
> So yeah, in summary, it's a regression that exists only in 1.1.1, but
> is really caused by a bug that exists in 1.1.0 as well.
> 
> I hope that's a good enough explanation.

Makes sense.

Matt

___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project

Re: [openssl-project] Release Criteria Update

[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 version indicator (zero) as
> 02 00 (zero length INTEGER, which is invalid) instead of 02 01 00
> (proper zero).  That's simply because the internal version number was
> changed from a LONG (custom ASN.1 type, mapping to a C long) to a INT32
> (new custom ASN.1 type, mapping to a C int32).
> (no, we don't want to go back to using LONG)

So...that PR seems to be labelled for 1.1.0 too? So why is the problem
specific to 1.1.1?

Matt


> 
> Cheers,
> Richard
> 
> In message  on Thu, 6 Sep 
> 2018 23:41:59 +0100, Matt Caswell  said:
> 
>> 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 (CIs are failing)
>>
>>
>> #7141 Ensure certificate callbacks work correctly in TLSv1.3
>>
>> Owner: Matt
>> Trivial change. Awaiting review
>>
>>
>> #7139 Remove a reference to SSL_force_post_handshake_auth()
>>
>> Owner: Matt
>> Trivial change. Awaiting review
>>
>>
>> #7114 Process KeyUpdate and NewSessionTicket messages after a close_notify
>> Alternative implementation for #7058
>>
>> Owner: Matt
>> Awaiting review. Anyone?
>>
>>
>> There 5 1.1.1 issues open - 3 of which should be solved by outstanding
>> PRS. The remaining 2 are:
>>
>>
>> #7014 TLSv1.2 SNI hostname works in 1.1.0h, not in 1.1.1 master (as of
>> 18-Aug)
>>
>> We thought we had a fix for this, but the PR in question does not seem
>> to have solved the OPs issue
>>
>>
>> #7133 X509_sign SIGSEGVs with NULL private key
>>
>> Should be an easy fix
>>
>>
>> Matt
>> ___
>> openssl-project mailing list
>> openssl-project@openssl.org
>> https://mta.openssl.org/mailman/listinfo/openssl-project
>>
> ___
> openssl-project mailing list
> openssl-project@openssl.org
> https://mta.openssl.org/mailman/listinfo/openssl-project
> 
___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project

Re: [openssl-project] Release Criteria Update

[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 that were accepted in 1.1.0 (because LONG is used)
that aren't accepted in 1.1.1.  A regression still, even though with
less drama.

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

Re: [openssl-project] Release Criteria Update

[Paul Dale]

PR for 7133 submitted.

 

 

Pauli

-- 

Oracle

Dr Paul Dale | Cryptographer | Network Security & Encryption 

Phone +61 7 3031 7217

Oracle Australia

 

From: Tim Hudson [mailto:t...@cryptsoft.com] 
Sent: Friday, 7 September 2018 8:51 AM
To: openssl-project@openssl.org
Subject: 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 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. 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 (CIs are failing)


#7141 Ensure certificate callbacks work correctly in TLSv1.3

Owner: Matt
Trivial change. Awaiting review


#7139 Remove a reference to SSL_force_post_handshake_auth()

Owner: Matt
Trivial change. Awaiting review


#7114 Process KeyUpdate and NewSessionTicket messages after a close_notify
Alternative implementation for #7058

Owner: Matt
Awaiting review. Anyone?


There 5 1.1.1 issues open - 3 of which should be solved by outstanding
PRS. The remaining 2 are:


#7014 TLSv1.2 SNI hostname works in 1.1.0h, not in 1.1.1 master (as of
18-Aug)

We thought we had a fix for this, but the PR in question does not seem
to have solved the OPs issue


#7133 X509_sign SIGSEGVs with NULL private key

Should be an easy fix


Matt
___
openssl-project mailing list
HYPERLINK "mailto:openssl-project@openssl.org"openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project

 
___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project

[openssl-project] Release Criteria Update

[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 (CIs are failing)


#7141 Ensure certificate callbacks work correctly in TLSv1.3

Owner: Matt
Trivial change. Awaiting review


#7139 Remove a reference to SSL_force_post_handshake_auth()

Owner: Matt
Trivial change. Awaiting review


#7114 Process KeyUpdate and NewSessionTicket messages after a close_notify
Alternative implementation for #7058

Owner: Matt
Awaiting review. Anyone?


There 5 1.1.1 issues open - 3 of which should be solved by outstanding
PRS. The remaining 2 are:


#7014 TLSv1.2 SNI hostname works in 1.1.0h, not in 1.1.1 master (as of
18-Aug)

We thought we had a fix for this, but the PR in question does not seem
to have solved the OPs issue


#7133 X509_sign SIGSEGVs with NULL private key

Should be an easy fix


Matt
___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project

Re: [openssl-project] Release Criteria Update

[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 CVEs, there's no compelling
reason to wait.  Barring specific concerns, I am not opposed to release
as planned.

-- 
Viktor.

___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project

Re: [openssl-project] Release Criteria Update

[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 drive I think helps for a lot of focus - and
more stuff has gone into 1.1.1 that we originally anticipated because we
held it open waiting on TLSv1.3 finalisation.

So a +1 for keeping to the release date.

Tim.


On Fri, Sep 7, 2018 at 8:25 AM, Matt Caswell  wrote:

>
>
> 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 not keen on that. What do others think?
>
> Matt
>
> ___
> openssl-project mailing list
> openssl-project@openssl.org
> https://mta.openssl.org/mailman/listinfo/openssl-project
>
___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project

Re: [openssl-project] Release Criteria Update

[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 not keen on that. What do others think?

Matt

___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project

Re: [openssl-project] Release Criteria Update

[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

___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project

Re: [openssl-project] Release Criteria Update

[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 noted two missing SM2err
calls on malloc failure and a typo in SM2.pod.
I've approved it conditional on those being fixed.

Tim.
___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project

Re: [openssl-project] Release Criteria Update

[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 #7014 has been opened.
> 
> There are still 2 open issues for 1.1.1 but both of these are now being
> addressed by one of the open PRs.
> 
> That means there are still 4 "critical path" PRs open:
> 
> #7115 Restore historical SSL_get_servername() behavior
> 
> Updates made following earlier review. Ready for another round of reviews??
> Owner: Ben.

I believe it's ready for another round of reviews, yes.
Do we think we want to wait for confirmation from @MSP-Greg?

-Ben
___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project

Re: [openssl-project] Release Criteria Update

[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
addressed by one of the open PRs.

That means there are still 4 "critical path" PRs open:

#7115 Restore historical SSL_get_servername() behavior

Updates made following earlier review. Ready for another round of reviews??
Owner: Ben.

#7114 Process KeyUpdate and NewSessionTicket messages after a close_notify
(an alternative to the older PR, #7058)

Currently in review. Awaiting some updates following review feedback.
Owner: Matt.

#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

#7073 Support EdDSA in apps/speed

Updates made following earlier review. Awaiting another round of reviews.
Owner: Paul Yang


Matt

On 04/09/18 17:11, Matt Caswell wrote:
> 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 and NewSessionTicket messages after a close_notify
> (an alternative to the older PR, #7058)
> 
> Awaiting review
> Owner: Matt
> 
> #7113 An alternative to address the SM2 ID issues
> (an alternative to the older PR, #6757)
> 
> Currently being reviewed
> Owner: Paul Yang
> 
> #7073 Support EdDSA in apps/speed
> 
> Awaiting updates following review comments
> Owner: Paul Yang
> 
> 
> 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 forward as yet.
> 
> Ben - any views?
> 
> 
> Matt
> 
___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project

Re: [openssl-project] Release Criteria Update

[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 forward as yet.
> 
> Ben - any views?

I'm thinking that the ABI stability argument is going to win me over and
we should continue to return the client's offered SNI in all cases until
1.2.0.  Hoping to get a patch out this morning (US pacific) -- yesterday
was a national holiday.

-Ben
___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project

[openssl-project] Release Criteria Update

[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 and NewSessionTicket messages after a close_notify
(an alternative to the older PR, #7058)

Awaiting review
Owner: Matt

#7113 An alternative to address the SM2 ID issues
(an alternative to the older PR, #6757)

Currently being reviewed
Owner: Paul Yang

#7073 Support EdDSA in apps/speed

Awaiting updates following review comments
Owner: Paul Yang


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 forward as yet.

Ben - any views?


Matt

___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project

[openssl-project] 1.1.1 Release criteria update

[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 weeks).
The most significant one is the PSK reuse issue. If we decide to make a
change then there is a PR there ready and waiting. All we really need to
do is decide whether to make that change or not. We've been waiting on
the TLS WG to make its mind up on what advice it's going to put into the
RFC on this. We also need to make a decision on what we will do about
the TLSv1.3 downgrade protection issue (with "do nothing" a possibility).

We also have 5 open PRs. One of these is blocked on the publication of
the RFC, and another is blocked on a decision being made on PSK reuse.
The other 3 are all in active development and I expect to see them
merged or closed very soon. Only the PR blocked on the RFC publication
is older than 2 weeks.

- Clean builds in Travis and Appveyor for two days

Status: Both Travis and Appveyor are currently green


- run-checker.sh to be showing as clean 2 days before release

Status: There has been one recent issue, but that should have been fixed
yesterday. I've not seen any run-checker reports since then.


- No open Coverity issues (not flagged as "False Positive" or "Ignore")

Status: There are no open issues not flagged as ignore


- TLSv1.3 RFC published (with at least one beta release after the
publicaction)

Status: The RFC has been imminent for a long time. The latest smoke
signals indicate that it is now imminently imminent :-)


My summary is that I think we are in a good place for the 1.1.1 release.
Once the PSK wording in the RFC is decided we should seek to make a
decision on the PSK reuse issue quickly. With that resolved and the RFC
published we should be able to get another beta release out quickly
afterwards. Assuming there are no significant issues raised during that
beta cycle I am hopeful we can get the 1.1.1 release out the door 2
weeks or so later.

Matt
___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project

[openssl-project] Apache update

[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

[Salz, Rich]

No mention of whether or not this will apply to EVERYTHING in a program, or 
will it be left to administrative guidance.  Your thoughts, for example, on a 
“FIPS mode” flag for SSL or SSL_CTX?  At a minimum, that needs to be listed as 
a stakeholder requirement (from Akamai).


From: "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 Wiki Update

https://wiki.openssl.org/index.php/FIPS_module_3.0<https://urldefense.proofpoint.com/v2/url?u=https-3A__wiki.openssl.org_index.php_FIPS-5Fmodule-5F3.0=DwMFaQ=96ZbZZcaMF4w0F4jpN6LZg=4LM0GbR0h9Fvx86FtsKI-w=_eDCHauz0_yvlroQYx4dezKXLU9Lc1eYfZlzseS6Mvw=4ntdPoDarQosCoGaVQMCiq9PGQ0oktGO7IgRZr7ntf0=>

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 of date information so I fixed at least that issue (hopefully).

Tim.

___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project

[openssl-project] OpenSSL FIPS Wiki Update

[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 out of date information so I fixed at least that issue (hopefully).

Tim.
___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project

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

[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 were multi-line and use
> > curly braces
> >
> >  
> >
> > if (test()) {
> >
> > /* already alerted */
> >
> > close();
> >
> > }
> >
> >  
> >
> 
> 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?
> 
> if (foo)
> do_this();
> else
> do_that();
> 
> vs.
> 
> if (foo) {
> /* some statements */
> ...
> } else {
> ...
> }

As already pointed out by others, it's mostly already in the style
guide. What is not in it is the combination with a comment:
if (foo)
/* some comment */
do_this();
else
do_that();

And it's been suggested to use curly braces for that.


Kurt

___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project

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

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

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

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

if (condition)
action();

and

if (condition)
do_this();
else
do_that();

If one of the branches is a compound statement, then use braces on both
parts:

if (condition) {
do_this();
do_that();
} else {
otherwise();
}




Matt

___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project

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

[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()) {
>
> /* already alerted */
>
> close();
>
> }
>
>  
>

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?

if (foo)
do_this();
else
do_that();

vs.

if (foo) {
/* some statements */
...
} else {
...
}


Matthias

___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project

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

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

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

[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 breaking long lines, if there are Boolean conditionals, put them at the 
start of the line.  Consider doing this consistently, and don’t merge even if 
they fit.  For example:
some_long_condition()
&& short1() && short2()
should be three lines.  Related conditions should be on one line if they fit, 
else given an extra level of indent
some_long_condition()
&& (short1() || short2())
&& some_other_flag != 0

If the expression for an if statement does not fit, indent the continuation 
lines an extra level

if (this_is_true()
&& !that_is_false()) {
code();
….

Try not to break long lines across a function call, but if you have to, indent 
the rest of the parameter list to be after the function’s opening paren.

Remember a blank line after variable declarations (even local ones).

Treat a single-statement with comment as if it were multi-line and use curly 
braces

if (test()) {
/* already alerted */
close();
}

Note that this could end up having “cascading curly” effects.

Arguments inside macro expansions should be parenthesized.

#define foo(a, b)  ((a) + (b))

Free routines should properly handle null; don’t check for null before calling 
a free routine.

When possible, use size_t for sizes of things (including array indicies)

[ Matt said “initialize in the declaration if appropriate; can someone provide 
wording? ]

This is controversial, so maybe drop it.  Don’t use else after return or goto 
unless it makes the flow more clear.

Argument names in function definition should match the declaration, but you can 
use “unused_” as a prefix in the definition for unused arguments.

Use ossl_assert, not assert.  Do not forget to handle the error condition as 
asserts are not compiled into production code.



___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project