From levitte at openssl.org  Mon May  6 07:40:17 2019
From: levitte at openssl.org (Richard Levitte)
Date: Mon, 06 May 2019 09:40:17 +0200
Subject: Fwd: Re: Any timeframe for the 1.1.1c release?
References: <c5ed60c1deb69ebf6ae44ed3ee5ce7208c6dbc7f.camel@redhat.com>
 <25d62169-37c3-3fd8-5e3b-041532ea2c4a@openssl.org>
 <3BECA507-6AE2-40CA-981A-C08400767957@dukhovni.org>
Message-ID: <87ef5c6nfi.wl-levitte@openssl.org>

Our last update release was by the end of February.  With our usual
3-ish month interval, end of May would be quite suitable, methinks.

I propose Tuesday May 28th as a release date for 1.1.1c.

Cheers,
Richard

-------------- next part --------------
An embedded message was scrubbed...
From: Viktor Dukhovni <openssl-users at dukhovni.org>
Subject: Re: Any timeframe for the 1.1.1c release?
Date: Fri, 3 May 2019 11:58:56 -0400
Size: 2298
URL: <http://mta.openssl.org/pipermail/openssl-project/attachments/20190506/bc0c1648/attachment.mht>

From paul.dale at oracle.com  Mon May  6 07:41:41 2019
From: paul.dale at oracle.com (Dr Paul Dale)
Date: Mon, 6 May 2019 17:41:41 +1000
Subject: Any timeframe for the 1.1.1c release?
In-Reply-To: <87ef5c6nfi.wl-levitte@openssl.org>
References: <c5ed60c1deb69ebf6ae44ed3ee5ce7208c6dbc7f.camel@redhat.com>
 <25d62169-37c3-3fd8-5e3b-041532ea2c4a@openssl.org>
 <3BECA507-6AE2-40CA-981A-C08400767957@dukhovni.org>
 <87ef5c6nfi.wl-levitte@openssl.org>
Message-ID: <8D1814F7-7A12-4653-A440-1140F085FCF2@oracle.com>

This seems reasonable to me.


Pauli

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



> On 6 May 2019, at 5:40 pm, Richard Levitte <levitte at openssl.org> wrote:
> 
> Our last update release was by the end of February.  With our usual
> 3-ish month interval, end of May would be quite suitable, methinks.
> 
> I propose Tuesday May 28th as a release date for 1.1.1c.
> 
> Cheers,
> Richard
> 
> 
> 
> There should perhaps be a 1.1.1c soonish...  There are indeed many useful
> improvements committed, but not yet released.
> 
> -- 
> 	Viktor.
> 
> -- 
> Richard Levitte         levitte at openssl.org
> OpenSSL Project         http://www.openssl.org/~levitte/
> 
> 

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

From matt at openssl.org  Tue May  7 14:44:39 2019
From: matt at openssl.org (Matt Caswell)
Date: Tue, 7 May 2019 15:44:39 +0100
Subject: Monthly Status Report (April)
Message-ID: <6feae788-073e-6770-2390-3f271b24d9ac@openssl.org>

As well as normal reviews, responding to user queries, wiki user
requests, OMC business, handling security reports, etc., key activities
this month:

- Worked on and pushed the PR to add SHA256 support to the FIPS provider
- Fixed no-sm2/no-sm3/no-ec
- Corrected some documentation for SSL_CIPHER_description()
- Worked on and pushed the PR to create a legacy provider and put MD2 in it
- Fixed a crash in X509_STORE_CTX_get_by_subject
- Significant review work on the CMP chunk 3 PR
- Came up with a proposed fix for possible mem leaks in custom
X509_LOOKUP_METHODs (later superseded by another fix)
- Investigated reported issues with AES-BIGE and later created a PR to improve
documentation/comments
- Significant work on creating a PR to move the basic AES ciphers into the
default provider
- Significant work on the PR making EVP available in the FIPS provider
- In response to CVE-2019-9498 and CVE-2019-9499 backported a hardening commit
to 1.0.2 to reject invalid EC point co-ords during EC_POINT_set_affine_coordinates_*
- Significant review work of the KTLS Sendfile PR
- Investigated and came up with PR to fix issues with OpenSSL being intolerant
to key_update while writes are pending
- Added some clarification to the ChaCha20 docs and added some new test vectors
- Fixed some KTLS issues
- Fixed no-ec2m
- Fixed an issue with EVP_CIPHER_CTX_rand_key
- Fixed a problem in rc5 where it would attempt to use a key length longer than
the maximum permissible
- Fixed no-srp


Matt

From kurt at roeckx.be  Sun May 12 09:06:28 2019
From: kurt at roeckx.be (Kurt Roeckx)
Date: Sun, 12 May 2019 11:06:28 +0200
Subject: Vote proposal: votes should get discussed first
Message-ID: <20190512090627.GA2766@roeckx.be>

Hi,

I would like to propose the following vote:
All public votes should be discussed on the openssl-project list
before a vote is called. The minimum time between a proposal
and calling for a vote is 1 week. If the proposal is changed, the
1 week period restarts.

From matt at openssl.org  Sun May 12 16:03:42 2019
From: matt at openssl.org (Matt Caswell)
Date: Sun, 12 May 2019 17:03:42 +0100
Subject: Vote proposal: votes should get discussed first
In-Reply-To: <20190512090627.GA2766@roeckx.be>
References: <20190512090627.GA2766@roeckx.be>
Message-ID: <03426c47-df38-bd32-35eb-8ace42a3e442@openssl.org>



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

I'm not in favour of this proposal for a few reasons:

1) I think this would actually work as a disincentive towards transparency. It
would work as an incentive to make votes private, because doing so is easier.

2) It unnecessarily slows down the voting process by adding an additional week
on to what can be quite a slow process anyway

3) It acts as a block in decision making in face-2-face scenarios. In our f2f
meetings we typically discuss an issue, formulate a possible vote to implement
some solution to that issue and then hold that vote fairly quickly. Doing things
the way you propose would make that very difficult to do.


Arguably this would require a change to the bylaws since it changes the voting
procedures.

Matt

From paul.dale at oracle.com  Sun May 19 23:18:23 2019
From: paul.dale at oracle.com (Paul Dale)
Date: Sun, 19 May 2019 23:18:23 +0000 (UTC)
Subject: Update
Message-ID: <1cc2fabf-2a61-445c-ab7e-fe96a4132dc8@default>

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_2Fw34OVBznS9v2zuRy9NWS8&e="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

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

From matt at openssl.org  Mon May 20 10:30:46 2019
From: matt at openssl.org (Matt Caswell)
Date: Mon, 20 May 2019 11:30:46 +0100
Subject: Welcoming our new committers
Message-ID: <528d4583-8b9a-e61e-dace-d06a36d96224@openssl.org>

Please welcome our four new committers as announced here:

https://www.openssl.org/blog/blog/2019/05/20/committers/

The new committers are:

Dmitry Belyavsky, Shane Lontis, Tom?? Mr?z and Patrick Steuer.

Welcome all!

Matt

From rsalz at akamai.com  Mon May 20 14:05:49 2019
From: rsalz at akamai.com (Salz, Rich)
Date: Mon, 20 May 2019 14:05:49 +0000
Subject: Update
In-Reply-To: <1cc2fabf-2a61-445c-ab7e-fe96a4132dc8@default>
References: <1cc2fabf-2a61-445c-ab7e-fe96a4132dc8@default>
Message-ID: <26E94780-7C96-4EE4-A960-4CEA1B3AEF0F@akamai.com>



  *   The current requirement for inclusion is ?national standard<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.openssl.org_blog_blog_2018_01_18_f2f-2Dlondon_&d=DwMFAg&c=96ZbZZcaMF4w0F4jpN6LZg&r=4LM0GbR0h9Fvx86FtsKI-w&m=8Tz4aKE8XnG6mHOAU9KEA6SD-nJLBxEnzMBMP9ucKn4&s=R4G92OrhB0izwXN4JATr9c5ZDdDB8H2swF3RU2N3VMw&e=>? 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-project/attachments/20190520/198bb29f/attachment-0001.html>

From matt at openssl.org  Mon May 20 14:17:24 2019
From: matt at openssl.org (Matt Caswell)
Date: Mon, 20 May 2019 15:17:24 +0100
Subject: Update
In-Reply-To: <26E94780-7C96-4EE4-A960-4CEA1B3AEF0F@akamai.com>
References: <1cc2fabf-2a61-445c-ab7e-fe96a4132dc8@default>
 <26E94780-7C96-4EE4-A960-4CEA1B3AEF0F@akamai.com>
Message-ID: <d7215c60-794b-0341-efa8-82e80db94e03@openssl.org>



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
protocol to standard TLS. It is not intended to interoperate with it in any way.
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 the intention was for it to interoperate then that would be an entirely
different matter.

Matt



From levitte at openssl.org  Mon May 20 14:28:11 2019
From: levitte at openssl.org (Richard Levitte)
Date: Mon, 20 May 2019 16:28:11 +0200
Subject: Update
In-Reply-To: <26E94780-7C96-4EE4-A960-4CEA1B3AEF0F@akamai.com>
References: <1cc2fabf-2a61-445c-ab7e-fe96a4132dc8@default>
 <26E94780-7C96-4EE4-A960-4CEA1B3AEF0F@akamai.com>
Message-ID: <87sgt92oas.wl-levitte@openssl.org>

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         levitte at openssl.org
OpenSSL Project         http://www.openssl.org/~levitte/

From rsalz at akamai.com  Mon May 20 14:23:10 2019
From: rsalz at akamai.com (Salz, Rich)
Date: Mon, 20 May 2019 14:23:10 +0000
Subject: Update
In-Reply-To: <d7215c60-794b-0341-efa8-82e80db94e03@openssl.org>
References: <1cc2fabf-2a61-445c-ab7e-fe96a4132dc8@default>
 <26E94780-7C96-4EE4-A960-4CEA1B3AEF0F@akamai.com>
 <d7215c60-794b-0341-efa8-82e80db94e03@openssl.org>
Message-ID: <24870A3F-42F5-407A-AAE8-BF0E19AEFC1A@akamai.com>

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

 


From matt at openssl.org  Mon May 20 14:49:21 2019
From: matt at openssl.org (Matt Caswell)
Date: Mon, 20 May 2019 15:49:21 +0100
Subject: Update
In-Reply-To: <24870A3F-42F5-407A-AAE8-BF0E19AEFC1A@akamai.com>
References: <1cc2fabf-2a61-445c-ab7e-fe96a4132dc8@default>
 <26E94780-7C96-4EE4-A960-4CEA1B3AEF0F@akamai.com>
 <d7215c60-794b-0341-efa8-82e80db94e03@openssl.org>
 <24870A3F-42F5-407A-AAE8-BF0E19AEFC1A@akamai.com>
Message-ID: <cd1adc12-5b70-e6c8-7d23-19b0474203cd@openssl.org>


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?

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



From yang.yang at baishancloud.com  Mon May 20 17:21:45 2019
From: yang.yang at baishancloud.com (Paul Yang)
Date: Mon, 20 May 2019 10:21:45 -0700
Subject: Update
In-Reply-To: <cd1adc12-5b70-e6c8-7d23-19b0474203cd@openssl.org>
References: <1cc2fabf-2a61-445c-ab7e-fe96a4132dc8@default>
 <26E94780-7C96-4EE4-A960-4CEA1B3AEF0F@akamai.com>
 <d7215c60-794b-0341-efa8-82e80db94e03@openssl.org>
 <24870A3F-42F5-407A-AAE8-BF0E19AEFC1A@akamai.com>
 <cd1adc12-5b70-e6c8-7d23-19b0474203cd@openssl.org>
Message-ID: <3344CC4E-108A-40ED-9A80-D3E3AA5F0140@baishancloud.com>



> On May 20, 2019, at 07:49, Matt Caswell <matt at openssl.org> 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 <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
> 
> 

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

From kurt at roeckx.be  Mon May 20 19:01:46 2019
From: kurt at roeckx.be (Kurt Roeckx)
Date: Mon, 20 May 2019 21:01:46 +0200
Subject: Update
In-Reply-To: <3344CC4E-108A-40ED-9A80-D3E3AA5F0140@baishancloud.com>
References: <1cc2fabf-2a61-445c-ab7e-fe96a4132dc8@default>
 <26E94780-7C96-4EE4-A960-4CEA1B3AEF0F@akamai.com>
 <d7215c60-794b-0341-efa8-82e80db94e03@openssl.org>
 <24870A3F-42F5-407A-AAE8-BF0E19AEFC1A@akamai.com>
 <cd1adc12-5b70-e6c8-7d23-19b0474203cd@openssl.org>
 <3344CC4E-108A-40ED-9A80-D3E3AA5F0140@baishancloud.com>
Message-ID: <20190520190146.GA26355@roeckx.be>

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

So I think there are 3 options:
- You use TLS, not some Chinese variant, and add things like Chinese
  ciphers to it.
- Use something that's not TLS at all, a Chinese variant, and
  don't support both protocols on the same port.
- Support both on the same port. This will require coordination
  with IANA and/or IETF.


Kurt


From paul.dale at oracle.com  Mon May 20 21:58:13 2019
From: paul.dale at oracle.com (Paul Dale)
Date: Mon, 20 May 2019 21:58:13 +0000 (UTC)
Subject: Welcoming our new committers
In-Reply-To: <528d4583-8b9a-e61e-dace-d06a36d96224@openssl.org>
References: <528d4583-8b9a-e61e-dace-d06a36d96224@openssl.org>
Message-ID: <93554c5d-6390-4477-bf77-1bb2e25774fa@default>

Welcome to the team.


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


-----Original Message-----
From: Matt Caswell [mailto:matt at openssl.org] 
Sent: Monday, 20 May 2019 8:31 PM
To: openssl-project at openssl.org
Subject: Welcoming our new committers

Please welcome our four new committers as announced here:

https://www.openssl.org/blog/blog/2019/05/20/committers/

The new committers are:

Dmitry Belyavsky, Shane Lontis, Tom?? Mr?z and Patrick Steuer.

Welcome all!

Matt

From matt at openssl.org  Mon May 20 22:20:52 2019
From: matt at openssl.org (Matt Caswell)
Date: Mon, 20 May 2019 23:20:52 +0100
Subject: Update
In-Reply-To: <20190520190146.GA26355@roeckx.be>
References: <1cc2fabf-2a61-445c-ab7e-fe96a4132dc8@default>
 <26E94780-7C96-4EE4-A960-4CEA1B3AEF0F@akamai.com>
 <d7215c60-794b-0341-efa8-82e80db94e03@openssl.org>
 <24870A3F-42F5-407A-AAE8-BF0E19AEFC1A@akamai.com>
 <cd1adc12-5b70-e6c8-7d23-19b0474203cd@openssl.org>
 <3344CC4E-108A-40ED-9A80-D3E3AA5F0140@baishancloud.com>
 <20190520190146.GA26355@roeckx.be>
Message-ID: <e1398acf-d147-ef5a-e1c8-54847ff96ecd@openssl.org>



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 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...
> 
> So I think there are 3 options:
> - You use TLS, not some Chinese variant, and add things like Chinese
>   ciphers to it.

That would be fine but my understanding is that the Chinese government mandate
this particular Chinese variant in some situations - so we'd also have to change
government policy which doesn't seem very likely ;-)

> - Use something that's not TLS at all, a Chinese variant, and
>   don't support both protocols on the same port.

If we decide to add support for the Chinese variant, then this would be my
preferred way of doing it.

> - Support both on the same port. This will require coordination
>   with IANA and/or IETF.

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.

Matt


From beldmit at gmail.com  Tue May 21 08:03:24 2019
From: beldmit at gmail.com (Dmitry Belyavsky)
Date: Tue, 21 May 2019 11:03:24 +0300
Subject: Welcoming our new committers
In-Reply-To: <93554c5d-6390-4477-bf77-1bb2e25774fa@default>
References: <528d4583-8b9a-e61e-dace-d06a36d96224@openssl.org>
 <93554c5d-6390-4477-bf77-1bb2e25774fa@default>
Message-ID: <CADqLbz++8myfPij+nbP5d2eb5kh6LS1VFHgGeOErybtk=5hR5A@mail.gmail.com>

Many thanks for a great honor to become an OpenSSL committer!

I hope to be useful after I understand the procedures.

On Tue, May 21, 2019 at 12:58 AM Paul Dale <paul.dale at oracle.com> wrote:

> Welcome to the team.
>
>
> Pauli
> --
> Oracle
> Dr Paul Dale | Cryptographer | Network Security & Encryption
> Phone +61 7 3031 7217
> Oracle Australia
>
>
> -----Original Message-----
> From: Matt Caswell [mailto:matt at openssl.org]
> Sent: Monday, 20 May 2019 8:31 PM
> To: openssl-project at openssl.org
> Subject: Welcoming our new committers
>
> Please welcome our four new committers as announced here:
>
> https://www.openssl.org/blog/blog/2019/05/20/committers/
>
> The new committers are:
>
> Dmitry Belyavsky, Shane Lontis, Tom?? Mr?z and Patrick Steuer.
>
> Welcome all!
>
> Matt
>


-- 
SY, Dmitry Belyavsky
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-project/attachments/20190521/4ea1afa1/attachment.html>

From psteuer9 at gmail.com  Tue May 21 09:58:41 2019
From: psteuer9 at gmail.com (Patrick Steuer)
Date: Tue, 21 May 2019 11:58:41 +0200
Subject: Welcoming our new committers
In-Reply-To: <528d4583-8b9a-e61e-dace-d06a36d96224@openssl.org>
References: <528d4583-8b9a-e61e-dace-d06a36d96224@openssl.org>
Message-ID: <20190521095841.GA23764@oc7773286020.ibm.com>

Hello and many thanks !

Im really looking forward to working on the project.

Patrick

From levitte at openssl.org  Tue May 21 11:38:16 2019
From: levitte at openssl.org (Richard Levitte)
Date: Tue, 21 May 2019 13:38:16 +0200
Subject: Planned server shutdown (move), June 3rd
Message-ID: <87h89o2g2f.wl-levitte@openssl.org>

Hi all,

Our main server will move to a different data center, and therefore
needs to be taken down for a couple of hours.

This is scheduled to happen on Monday June 3rd, between 10:00 and
13:00 CEST (08:00 - 11:00 UTC).

Cheers,
Richard

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

From rsalz at akamai.com  Tue May 21 14:13:32 2019
From: rsalz at akamai.com (Salz, Rich)
Date: Tue, 21 May 2019 14:13:32 +0000
Subject: Update
In-Reply-To: <e1398acf-d147-ef5a-e1c8-54847ff96ecd@openssl.org>
References: <1cc2fabf-2a61-445c-ab7e-fe96a4132dc8@default>
 <26E94780-7C96-4EE4-A960-4CEA1B3AEF0F@akamai.com>
 <d7215c60-794b-0341-efa8-82e80db94e03@openssl.org>
 <24870A3F-42F5-407A-AAE8-BF0E19AEFC1A@akamai.com>
 <cd1adc12-5b70-e6c8-7d23-19b0474203cd@openssl.org>
 <3344CC4E-108A-40ED-9A80-D3E3AA5F0140@baishancloud.com>
 <20190520190146.GA26355@roeckx.be>
 <e1398acf-d147-ef5a-e1c8-54847ff96ecd@openssl.org>
Message-ID: <5AC1D696-35C2-46E7-9EA4-FABE0B7501F6@akamai.com>

 
 >   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-registry at iana.org asking for code points and pointing to their spec.


From matt at openssl.org  Tue May 21 15:43:34 2019
From: matt at openssl.org (Matt Caswell)
Date: Tue, 21 May 2019 16:43:34 +0100
Subject: Forthcoming OpenSSL Releases
Message-ID: <24766385-ad0d-1da7-404b-34768c43b79c@openssl.org>

The OpenSSL project team would like to announce the forthcoming release
of OpenSSL versions 1.1.1c, 1.1.0k and 1.0.2s.

These releases will be made available on 28th May 2019 between approximately
1200-1600 UTC.

OpenSSL 1.1.0k and 1.0.2s contain security hardening bug fixes only but do not
address any CVEs. OpenSSL 1.1.1c is a bug-fix release (and contains the
equivalent security hardening fixes as for 1.1.0k and 1.0.2s where relevant).

Yours

The OpenSSL Project Team

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <http://mta.openssl.org/pipermail/openssl-project/attachments/20190521/585e9fb8/attachment-0001.sig>

From matt at openssl.org  Tue May 21 15:43:34 2019
From: matt at openssl.org (Matt Caswell)
Date: Tue, 21 May 2019 16:43:34 +0100
Subject: Forthcoming OpenSSL Releases
Message-ID: <24766385-ad0d-1da7-404b-34768c43b79c@openssl.org>

The OpenSSL project team would like to announce the forthcoming release
of OpenSSL versions 1.1.1c, 1.1.0k and 1.0.2s.

These releases will be made available on 28th May 2019 between approximately
1200-1600 UTC.

OpenSSL 1.1.0k and 1.0.2s contain security hardening bug fixes only but do not
address any CVEs. OpenSSL 1.1.1c is a bug-fix release (and contains the
equivalent security hardening fixes as for 1.1.0k and 1.0.2s where relevant).

Yours

The OpenSSL Project Team

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <http://mta.openssl.org/pipermail/openssl-project/attachments/20190521/585e9fb8/attachment-0002.sig>

From matt at openssl.org  Tue May 21 15:43:34 2019
From: matt at openssl.org (Matt Caswell)
Date: Tue, 21 May 2019 16:43:34 +0100
Subject: Forthcoming OpenSSL Releases
Message-ID: <24766385-ad0d-1da7-404b-34768c43b79c@openssl.org>

The OpenSSL project team would like to announce the forthcoming release
of OpenSSL versions 1.1.1c, 1.1.0k and 1.0.2s.

These releases will be made available on 28th May 2019 between approximately
1200-1600 UTC.

OpenSSL 1.1.0k and 1.0.2s contain security hardening bug fixes only but do not
address any CVEs. OpenSSL 1.1.1c is a bug-fix release (and contains the
equivalent security hardening fixes as for 1.1.0k and 1.0.2s where relevant).

Yours

The OpenSSL Project Team

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <http://mta.openssl.org/pipermail/openssl-project/attachments/20190521/585e9fb8/attachment-0003.sig>

From yang.yang at baishancloud.com  Wed May 22 02:09:44 2019
From: yang.yang at baishancloud.com (Paul Yang)
Date: Wed, 22 May 2019 10:09:44 +0800
Subject: Update
In-Reply-To: <e1398acf-d147-ef5a-e1c8-54847ff96ecd@openssl.org>
References: <1cc2fabf-2a61-445c-ab7e-fe96a4132dc8@default>
 <26E94780-7C96-4EE4-A960-4CEA1B3AEF0F@akamai.com>
 <d7215c60-794b-0341-efa8-82e80db94e03@openssl.org>
 <24870A3F-42F5-407A-AAE8-BF0E19AEFC1A@akamai.com>
 <cd1adc12-5b70-e6c8-7d23-19b0474203cd@openssl.org>
 <3344CC4E-108A-40ED-9A80-D3E3AA5F0140@baishancloud.com>
 <20190520190146.GA26355@roeckx.be>
 <e1398acf-d147-ef5a-e1c8-54847ff96ecd@openssl.org>
Message-ID: <39EAA479-B4C8-445C-96A3-DE76452537FB@baishancloud.com>



> On May 21, 2019, at 06:20, Matt Caswell <matt at openssl.org> 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 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...
>> 
>> So I think there are 3 options:
>> - You use TLS, not some Chinese variant, and add things like Chinese
>>  ciphers to it.
> 
> That would be fine but my understanding is that the Chinese government mandate
> this particular Chinese variant in some situations - so we'd also have to change
> government policy which doesn't seem very likely ;-)

You are right. There is currently no official Chinese national standards that define cipher suites for IETF TLS yet.

> 
>> - Use something that's not TLS at all, a Chinese variant, and
>>  don't support both protocols on the same port.
> 
> If we decide to add support for the Chinese variant, then this would be my
> preferred way of doing it.
> 
>> - Support both on the same port. This will require coordination
>>  with IANA and/or IETF.
> 
> 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.
> 
> Matt
> 




From yang.yang at baishancloud.com  Wed May 22 02:12:28 2019
From: yang.yang at baishancloud.com (Paul Yang)
Date: Wed, 22 May 2019 10:12:28 +0800
Subject: Update
In-Reply-To: <5AC1D696-35C2-46E7-9EA4-FABE0B7501F6@akamai.com>
References: <1cc2fabf-2a61-445c-ab7e-fe96a4132dc8@default>
 <26E94780-7C96-4EE4-A960-4CEA1B3AEF0F@akamai.com>
 <d7215c60-794b-0341-efa8-82e80db94e03@openssl.org>
 <24870A3F-42F5-407A-AAE8-BF0E19AEFC1A@akamai.com>
 <cd1adc12-5b70-e6c8-7d23-19b0474203cd@openssl.org>
 <3344CC4E-108A-40ED-9A80-D3E3AA5F0140@baishancloud.com>
 <20190520190146.GA26355@roeckx.be>
 <e1398acf-d147-ef5a-e1c8-54847ff96ecd@openssl.org>
 <5AC1D696-35C2-46E7-9EA4-FABE0B7501F6@akamai.com>
Message-ID: <AD174E1C-33CF-487C-8E72-C4587B317BA7@baishancloud.com>



> On May 21, 2019, at 22:13, Salz, Rich <rsalz at akamai.com> 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-registry at 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?

> 




From yang.yang at baishancloud.com  Wed May 22 03:19:00 2019
From: yang.yang at baishancloud.com (Paul Yang)
Date: Wed, 22 May 2019 11:19:00 +0800
Subject: Update
In-Reply-To: <A5F9FE65-EFED-49CE-95BC-C0F7CC5B1D84@akamai.com>
References: <1cc2fabf-2a61-445c-ab7e-fe96a4132dc8@default>
 <26E94780-7C96-4EE4-A960-4CEA1B3AEF0F@akamai.com>
 <d7215c60-794b-0341-efa8-82e80db94e03@openssl.org>
 <24870A3F-42F5-407A-AAE8-BF0E19AEFC1A@akamai.com>
 <cd1adc12-5b70-e6c8-7d23-19b0474203cd@openssl.org>
 <3344CC4E-108A-40ED-9A80-D3E3AA5F0140@baishancloud.com>
 <20190520190146.GA26355@roeckx.be>
 <e1398acf-d147-ef5a-e1c8-54847ff96ecd@openssl.org>
 <5AC1D696-35C2-46E7-9EA4-FABE0B7501F6@akamai.com>
 <AD174E1C-33CF-487C-8E72-C4587B317BA7@baishancloud.com>
 <A5F9FE65-EFED-49CE-95BC-C0F7CC5B1D84@akamai.com>
Message-ID: <79995F25-372F-400A-9D03-1F81261B967B@baishancloud.com>



> On May 22, 2019, at 10:16, Salz, Rich <rsalz at akamai.com> 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-registry at 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...

> 




From rsalz at akamai.com  Wed May 22 02:16:55 2019
From: rsalz at akamai.com (Salz, Rich)
Date: Wed, 22 May 2019 02:16:55 +0000
Subject: Update
In-Reply-To: <AD174E1C-33CF-487C-8E72-C4587B317BA7@baishancloud.com>
References: <1cc2fabf-2a61-445c-ab7e-fe96a4132dc8@default>
 <26E94780-7C96-4EE4-A960-4CEA1B3AEF0F@akamai.com>
 <d7215c60-794b-0341-efa8-82e80db94e03@openssl.org>
 <24870A3F-42F5-407A-AAE8-BF0E19AEFC1A@akamai.com>
 <cd1adc12-5b70-e6c8-7d23-19b0474203cd@openssl.org>
 <3344CC4E-108A-40ED-9A80-D3E3AA5F0140@baishancloud.com>
 <20190520190146.GA26355@roeckx.be>
 <e1398acf-d147-ef5a-e1c8-54847ff96ecd@openssl.org>
 <5AC1D696-35C2-46E7-9EA4-FABE0B7501F6@akamai.com>
 <AD174E1C-33CF-487C-8E72-C4587B317BA7@baishancloud.com>
Message-ID: <A5F9FE65-EFED-49CE-95BC-C0F7CC5B1D84@akamai.com>

    >>  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-registry at 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.


From rsalz at akamai.com  Thu May 23 14:25:07 2019
From: rsalz at akamai.com (Salz, Rich)
Date: Thu, 23 May 2019 14:25:07 +0000
Subject: No two reviewers from same company
Message-ID: <F606CC7A-3060-4E8C-800F-1DBB7B77CD57@akamai.com>

I understand that OpenSSL is changing things so that, by mechanism (and maybe by policy although it?s not published yet), two members of the same company cannot approve the same PR.  That?s great.  (I never approved Akamai requests unless it was trivial back when I was on the OMC.)

Should this policy be extended to OpenSSL?s fellows?

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

From matt at openssl.org  Thu May 23 14:45:48 2019
From: matt at openssl.org (Matt Caswell)
Date: Thu, 23 May 2019 15:45:48 +0100
Subject: No two reviewers from same company
In-Reply-To: <F606CC7A-3060-4E8C-800F-1DBB7B77CD57@akamai.com>
References: <F606CC7A-3060-4E8C-800F-1DBB7B77CD57@akamai.com>
Message-ID: <70872e8f-b531-9ebe-62e3-1040e815ceab@openssl.org>



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

No such decision has been made as far as I know although it has been discussed
at various times.

> Should this policy be extended to OpenSSL?s fellows?

IMO, no.

Matt

From levitte at openssl.org  Thu May 23 15:17:20 2019
From: levitte at openssl.org (Richard Levitte)
Date: Thu, 23 May 2019 17:17:20 +0200
Subject: No two reviewers from same company
In-Reply-To: <F606CC7A-3060-4E8C-800F-1DBB7B77CD57@akamai.com>
References: <F606CC7A-3060-4E8C-800F-1DBB7B77CD57@akamai.com>
Message-ID: <87woih19q7.wl-levitte@openssl.org>

On Thu, 23 May 2019 16:25:07 +0200,
Salz, Rich wrote:
> I understand that OpenSSL is changing things so that, by mechanism (and maybe by policy although
> it?s not published yet), two members of the same company cannot approve the same PR.  That?s
> great.  (I never approved Akamai requests unless it was trivial back when I was on the OMC.)

We mostly seem to agree that it's morally dubious to approve stuff
from people of the same company, and as far as I've heard so far, it's
to ensure that the project's interests are over-ridden by company
interests (including involuntary bias, which no one is really free
from).

> Should this policy be extended to OpenSSL?s fellows?

I believe it's assumed that fellows have the project's interests in
mind before any other work, so no conflicting bias there, i.e. not
quite the same.  If this is a possible point of dispute, we should
discuss it, of course.

Cheers,
Richard

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

From rsalz at akamai.com  Thu May 23 15:01:29 2019
From: rsalz at akamai.com (Salz, Rich)
Date: Thu, 23 May 2019 15:01:29 +0000
Subject: No two reviewers from same company
In-Reply-To: <70872e8f-b531-9ebe-62e3-1040e815ceab@openssl.org>
References: <F606CC7A-3060-4E8C-800F-1DBB7B77CD57@akamai.com>
 <70872e8f-b531-9ebe-62e3-1040e815ceab@openssl.org>
Message-ID: <DB57BDC2-CD6A-4BCC-B900-1A69E594715A@akamai.com>

    > I understand that OpenSSL is changing things so that, by mechanism (and maybe by
    > policy although it?s not published yet), two members of the same company cannot
    > approve the same PR.  That?s great.  (I never approved Akamai requests unless it
    > was trivial back when I was on the OMC.)
    
    No such decision has been made as far as I know although it has been discussed
    at various times.

In private email, and https://github.com/openssl/openssl/pull/8886#issuecomment-494624313 the implication is that this was a policy.
    
    > Should this policy be extended to OpenSSL?s fellows?
    
    IMO, no.

Why not?  I understand build process is always handled by Matt and Richard (despite many attempts in the past to expand this), but I think if Oracle or Akamai can't "force a change" then it seems to me that the OMC shouldn't either.



From matt at openssl.org  Thu May 23 15:27:00 2019
From: matt at openssl.org (Matt Caswell)
Date: Thu, 23 May 2019 16:27:00 +0100
Subject: No two reviewers from same company
In-Reply-To: <DB57BDC2-CD6A-4BCC-B900-1A69E594715A@akamai.com>
References: <F606CC7A-3060-4E8C-800F-1DBB7B77CD57@akamai.com>
 <70872e8f-b531-9ebe-62e3-1040e815ceab@openssl.org>
 <DB57BDC2-CD6A-4BCC-B900-1A69E594715A@akamai.com>
Message-ID: <fc4809f5-7e9d-c451-be2c-20043162a5c3@openssl.org>



On 23/05/2019 16:01, Salz, Rich wrote:
>     > I understand that OpenSSL is changing things so that, by mechanism (and maybe by
>     > policy although it?s not published yet), two members of the same company cannot
>     > approve the same PR.  That?s great.  (I never approved Akamai requests unless it
>     > was trivial back when I was on the OMC.)
>     
>     No such decision has been made as far as I know although it has been discussed
>     at various times.
> 
> In private email, and https://github.com/openssl/openssl/pull/8886#issuecomment-494624313 the implication is that this was a policy.

AFAIK this is not the case.

>     
>     > Should this policy be extended to OpenSSL?s fellows?
>     
>     IMO, no.
> 
> Why not?  I understand build process is always handled by Matt and Richard (despite many attempts in the past to expand this), but I think if Oracle or Akamai can't "force a change" then it seems to me that the OMC shouldn't either.

The only reason to have the "no two reviewers from the same company" policy is
to avoid a potential conflict of interest, i.e. where the interests of said
company conflict with the interests of openssl, two people from the same company
could collude to push a change through. In the case of the fellows, they
represent the project directly so there can be no conflict.

Matt


From rsalz at akamai.com  Thu May 23 15:31:32 2019
From: rsalz at akamai.com (Salz, Rich)
Date: Thu, 23 May 2019 15:31:32 +0000
Subject: No two reviewers from same company
In-Reply-To: <fc4809f5-7e9d-c451-be2c-20043162a5c3@openssl.org>
References: <F606CC7A-3060-4E8C-800F-1DBB7B77CD57@akamai.com>
 <70872e8f-b531-9ebe-62e3-1040e815ceab@openssl.org>
 <DB57BDC2-CD6A-4BCC-B900-1A69E594715A@akamai.com>
 <fc4809f5-7e9d-c451-be2c-20043162a5c3@openssl.org>
Message-ID: <75504EFF-71AB-4B03-B4AB-42E43C6A57A1@akamai.com>

    > In private email, and https://github.com/openssl/openssl/pull/8886#issuecomment-494624313 the implication is that this was a policy.
    
    AFAIK this is not the case.

Is the comment wrong, either factually or because it is implementing something that isn't an official policy?
    
> In the case of the fellows, they
    represent the project directly so there can be no conflict.
  
The OMC represents the project not individual fellows.  Fellows are employees of the OMC.  Therefore there can be conflicts. A hypothetical example, some hires a fellow or two to port OpenSSL to a new unique platform, not currently supported. The OMC doesn't want to support this platform, but it ends up in the source.

I encourage the OMC to consider this question carefully.



From matt at openssl.org  Thu May 23 15:42:46 2019
From: matt at openssl.org (Matt Caswell)
Date: Thu, 23 May 2019 16:42:46 +0100
Subject: No two reviewers from same company
In-Reply-To: <75504EFF-71AB-4B03-B4AB-42E43C6A57A1@akamai.com>
References: <F606CC7A-3060-4E8C-800F-1DBB7B77CD57@akamai.com>
 <70872e8f-b531-9ebe-62e3-1040e815ceab@openssl.org>
 <DB57BDC2-CD6A-4BCC-B900-1A69E594715A@akamai.com>
 <fc4809f5-7e9d-c451-be2c-20043162a5c3@openssl.org>
 <75504EFF-71AB-4B03-B4AB-42E43C6A57A1@akamai.com>
Message-ID: <488e99cd-7f77-86b1-8ae0-70b5e64715cf@openssl.org>



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

There have been no votes on changing official policy. I'm not aware of any
planned changes to the tooling, but maybe there are conversations I am unaware of.

>     
>> In the case of the fellows, they
>     represent the project directly so there can be no conflict.
>   
> The OMC represents the project not individual fellows.  Fellows are employees of the OMC.  Therefore there can be conflicts. A hypothetical example, some hires a fellow or two to port OpenSSL to a new unique platform, not currently supported. The OMC doesn't want to support this platform, but it ends up in the source.

In that example the potential conflict of interest comes from the individual's
employment with the third party organisation, not because they are fellows.

Matt

From matt at openssl.org  Thu May 23 16:11:29 2019
From: matt at openssl.org (Matt Caswell)
Date: Thu, 23 May 2019 17:11:29 +0100
Subject: No two reviewers from same company
In-Reply-To: <5ED4F7B3-2A32-4FCE-A1B8-4DB7480FCEBA@akamai.com>
References: <F606CC7A-3060-4E8C-800F-1DBB7B77CD57@akamai.com>
 <70872e8f-b531-9ebe-62e3-1040e815ceab@openssl.org>
 <DB57BDC2-CD6A-4BCC-B900-1A69E594715A@akamai.com>
 <fc4809f5-7e9d-c451-be2c-20043162a5c3@openssl.org>
 <75504EFF-71AB-4B03-B4AB-42E43C6A57A1@akamai.com>
 <488e99cd-7f77-86b1-8ae0-70b5e64715cf@openssl.org>
 <5ED4F7B3-2A32-4FCE-A1B8-4DB7480FCEBA@akamai.com>
Message-ID: <b45342eb-bcc9-5c0d-0f83-0d0c01686871@openssl.org>



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

The OMC represents the official voice of the project. The OMC contracts the
fellows to work on the project and in the interests of the project. Any
interests that the fellows have by virtue of the fact that they are fellows
*are* the interests of the project.

They may have other interests external to that (e.g. personal interests). This
is true of any committer, except most committers also have an additional set of
interests they inherit from their employer. This is not the case for the fellows.

What is important is that there should be no conflict between the interests of
the project and any other interests an individual may have.

If a fellow has a conflict of interest then it will not be *because* they are a
fellow. It will be because of some external factor. Therefore making a policy
that requires the fellows to not review each others code just because they are
fellows is pointless and counter productive. A broader policy about conflicts of
interests in general that could apply to any committer (that might include
fellows in certain circumstances such as your hypothetical example), may be
appropriate.

Matt

From tmraz at redhat.com  Thu May 23 17:14:51 2019
From: tmraz at redhat.com (Tomas Mraz)
Date: Thu, 23 May 2019 19:14:51 +0200
Subject: No two reviewers from same company
In-Reply-To: <87woih19q7.wl-levitte@openssl.org>
References: <F606CC7A-3060-4E8C-800F-1DBB7B77CD57@akamai.com>
 <87woih19q7.wl-levitte@openssl.org>
Message-ID: <624e4d4d3e7805e92b1a74a62b6e2cd74cd01811.camel@redhat.com>

On Thu, 2019-05-23 at 17:17 +0200, Richard Levitte wrote:
> On Thu, 23 May 2019 16:25:07 +0200,
> Salz, Rich wrote:
> > I understand that OpenSSL is changing things so that, by mechanism
> > (and maybe by policy although
> > it?s not published yet), two members of the same company cannot
> > approve the same PR.  That?s
> > great.  (I never approved Akamai requests unless it was trivial
> > back when I was on the OMC.)
> 
> We mostly seem to agree that it's morally dubious to approve stuff
> from people of the same company, and as far as I've heard so far,
> it's
> to ensure that the project's interests are over-ridden by company
> interests (including involuntary bias, which no one is really free
> from).

Does this also apply to non-committers submitting a PR being the same
company as one of the two required reviewers? I would have a problem if
there was only a single review required for non-committers but given
there are two reviews required one of them being from OMC member I
would not see much conflict of interest.

> > Should this policy be extended to OpenSSL?s fellows?
> 
> I believe it's assumed that fellows have the project's interests in
> mind before any other work, so no conflicting bias there, i.e. not
> quite the same.  If this is a possible point of dispute, we should
> discuss it, of course.

+1 - I also don't see the reasons for conflict of interest applying to
fellows.

-- 
Tom?? Mr?z
No matter how far down the wrong road you've gone, turn back.
                                              Turkish proverb
[You'll know whether the road is wrong if you carefully listen to your
conscience.]



From matt at openssl.org  Thu May 23 17:20:11 2019
From: matt at openssl.org (Matt Caswell)
Date: Thu, 23 May 2019 18:20:11 +0100
Subject: No two reviewers from same company
In-Reply-To: <624e4d4d3e7805e92b1a74a62b6e2cd74cd01811.camel@redhat.com>
References: <F606CC7A-3060-4E8C-800F-1DBB7B77CD57@akamai.com>
 <87woih19q7.wl-levitte@openssl.org>
 <624e4d4d3e7805e92b1a74a62b6e2cd74cd01811.camel@redhat.com>
Message-ID: <59249b2b-ddac-e534-78df-f284add22a7c@openssl.org>



On 23/05/2019 18:14, Tomas Mraz wrote:
> On Thu, 2019-05-23 at 17:17 +0200, Richard Levitte wrote:
>> On Thu, 23 May 2019 16:25:07 +0200,
>> Salz, Rich wrote:
>>> I understand that OpenSSL is changing things so that, by mechanism
>>> (and maybe by policy although
>>> it?s not published yet), two members of the same company cannot
>>> approve the same PR.  That?s
>>> great.  (I never approved Akamai requests unless it was trivial
>>> back when I was on the OMC.)
>>
>> We mostly seem to agree that it's morally dubious to approve stuff
>> from people of the same company, and as far as I've heard so far,
>> it's
>> to ensure that the project's interests are over-ridden by company
>> interests (including involuntary bias, which no one is really free
>> from).
> 
> Does this also apply to non-committers submitting a PR being the same
> company as one of the two required reviewers?

IMO: no it should not apply.

Matt

From matt at openssl.org  Thu May 23 17:25:35 2019
From: matt at openssl.org (Matt Caswell)
Date: Thu, 23 May 2019 18:25:35 +0100
Subject: Committers Day Blog
Message-ID: <3dc4aa9a-6edc-a9e3-b640-2f8611108f59@openssl.org>

Please see the following blog post by Matthias about the recent committers day:

https://www.openssl.org/blog/blog/2019/05/23/f2f-committers-day/

Matt

From matt at openssl.org  Thu May 23 17:26:59 2019
From: matt at openssl.org (Matt Caswell)
Date: Thu, 23 May 2019 18:26:59 +0100
Subject: Committers Day Blog
In-Reply-To: <3dc4aa9a-6edc-a9e3-b640-2f8611108f59@openssl.org>
References: <3dc4aa9a-6edc-a9e3-b640-2f8611108f59@openssl.org>
Message-ID: <ffc39d95-69dd-79de-aa27-fd428f6c53a6@openssl.org>



On 23/05/2019 18:25, Matt Caswell wrote:
> Please see the following blog post by Matthias about the recent committers day:
> 
> https://www.openssl.org/blog/blog/2019/05/23/f2f-committers-day/

I should point out BTW that eating vegemite is not a requirement for becoming a
committer. :-)

Matt


From levitte at openssl.org  Thu May 23 18:05:42 2019
From: levitte at openssl.org (Richard Levitte)
Date: Thu, 23 May 2019 20:05:42 +0200
Subject: No two reviewers from same company
In-Reply-To: <488e99cd-7f77-86b1-8ae0-70b5e64715cf@openssl.org>
References: <F606CC7A-3060-4E8C-800F-1DBB7B77CD57@akamai.com>
 <70872e8f-b531-9ebe-62e3-1040e815ceab@openssl.org>
 <DB57BDC2-CD6A-4BCC-B900-1A69E594715A@akamai.com>
 <fc4809f5-7e9d-c451-be2c-20043162a5c3@openssl.org>
 <75504EFF-71AB-4B03-B4AB-42E43C6A57A1@akamai.com>
 <488e99cd-7f77-86b1-8ae0-70b5e64715cf@openssl.org>
Message-ID: <87v9y111xl.wl-levitte@openssl.org>

On Thu, 23 May 2019 17:42:46 +0200,
Matt Caswell wrote:
> 
> On 23/05/2019 16:31, Salz, Rich wrote:
> >     > In private email, and https://github.com/openssl/openssl/pull/8886#issuecomment-494624313 the implication is that this was a policy.
> >     
> >     AFAIK this is not the case.
> > 
> > Is the comment wrong, either factually or because it is implementing something that isn't an official policy?
> 
> There have been no votes on changing official policy. I'm not aware of any
> planned changes to the tooling, but maybe there are conversations I am unaware of.

I have been asked privately if it's possible to adjust the tooling to
allow that level of control.  It certainly is possible to do!  That
is, however, as far as it has come from my perspective.


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

From levitte at openssl.org  Thu May 23 18:09:41 2019
From: levitte at openssl.org (Richard Levitte)
Date: Thu, 23 May 2019 20:09:41 +0200
Subject: Committers Day Blog
In-Reply-To: <ffc39d95-69dd-79de-aa27-fd428f6c53a6@openssl.org>
References: <3dc4aa9a-6edc-a9e3-b640-2f8611108f59@openssl.org>
 <ffc39d95-69dd-79de-aa27-fd428f6c53a6@openssl.org>
Message-ID: <87tvdl11qy.wl-levitte@openssl.org>

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

... or remaining one.  I'm quite happy that is the case ;-)

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

From openssl-users at dukhovni.org  Thu May 23 18:33:34 2019
From: openssl-users at dukhovni.org (Viktor Dukhovni)
Date: Thu, 23 May 2019 14:33:34 -0400
Subject: No two reviewers from same company
In-Reply-To: <70872e8f-b531-9ebe-62e3-1040e815ceab@openssl.org>
References: <F606CC7A-3060-4E8C-800F-1DBB7B77CD57@akamai.com>
 <70872e8f-b531-9ebe-62e3-1040e815ceab@openssl.org>
Message-ID: <20190523183334.GD67454@straasha.imrryr.org>

On Thu, May 23, 2019 at 03:45:48PM +0100, Matt Caswell wrote:

> IMO, no.

I also don't see a need for this at present, and it is not clear
that there are enough active part-time reviewers in place to keep
up with commits from the fellows in a timely manner.

-- 
	Viktor.

From Matthias.St.Pierre at ncp-e.com  Thu May 23 19:42:55 2019
From: Matthias.St.Pierre at ncp-e.com (Dr. Matthias St. Pierre)
Date: Thu, 23 May 2019 19:42:55 +0000
Subject: AW: No two reviewers from same company
In-Reply-To: <70872e8f-b531-9ebe-62e3-1040e815ceab@openssl.org>
References: <F606CC7A-3060-4E8C-800F-1DBB7B77CD57@akamai.com>
 <70872e8f-b531-9ebe-62e3-1040e815ceab@openssl.org>
Message-ID: <8044993225244e019a3b1cb9373473b7@Ex13.ncp.local>

> No such decision has been made as far as I know although it has been discussed
> at various times.
> 
> > Should this policy be extended to OpenSSL?s fellows?
> 
> IMO, no.

I agree with Matt: While this policy makes sense for employers of third party companies,
because these companies might have conflicting interests in theory, It's a different case
for OpenSSL fellows. In my opinion, such a rule would only block Matt's and Richard's
daily work unnecessarily. Also, I see no danger of misuse, because the OMC members
still have the possibility to block a merge with their veto.

Matthias


From paul.dale at oracle.com  Thu May 23 22:16:08 2019
From: paul.dale at oracle.com (Paul Dale)
Date: Thu, 23 May 2019 22:16:08 +0000 (UTC)
Subject: No two reviewers from same company
In-Reply-To: <DB57BDC2-CD6A-4BCC-B900-1A69E594715A@akamai.com>
References: <F606CC7A-3060-4E8C-800F-1DBB7B77CD57@akamai.com>
 <70872e8f-b531-9ebe-62e3-1040e815ceab@openssl.org>
 <DB57BDC2-CD6A-4BCC-B900-1A69E594715A@akamai.com>
Message-ID: <3def936f-ad25-4c83-b788-7ab8c6d9fbbd@default>

There hasn't been a vote about this, however both Shane and I have committed to not approve each other's PRs.

I also asked Richard if this could be mechanically enforced, which I expect will happen eventually.


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


-----Original Message-----
From: Salz, Rich [mailto:rsalz at akamai.com] 
Sent: Friday, 24 May 2019 1:01 AM
To: openssl-project at openssl.org
Subject: Re: No two reviewers from same company

    > I understand that OpenSSL is changing things so that, by mechanism (and maybe by
    > policy although it?s not published yet), two members of the same company cannot
    > approve the same PR.  That?s great.  (I never approved Akamai requests unless it
    > was trivial back when I was on the OMC.)
    
    No such decision has been made as far as I know although it has been discussed
    at various times.

In private email, and https://github.com/openssl/openssl/pull/8886#issuecomment-494624313 the implication is that this was a policy.
    
    > Should this policy be extended to OpenSSL?s fellows?
    
    IMO, no.

Why not?  I understand build process is always handled by Matt and Richard (despite many attempts in the past to expand this), but I think if Oracle or Akamai can't "force a change" then it seems to me that the OMC shouldn't either.



From tjh at openssl.org  Thu May 23 22:27:36 2019
From: tjh at openssl.org (Tim Hudson)
Date: Fri, 24 May 2019 08:27:36 +1000
Subject: No two reviewers from same company
In-Reply-To: <3def936f-ad25-4c83-b788-7ab8c6d9fbbd@default>
References: <F606CC7A-3060-4E8C-800F-1DBB7B77CD57@akamai.com>
 <70872e8f-b531-9ebe-62e3-1040e815ceab@openssl.org>
 <DB57BDC2-CD6A-4BCC-B900-1A69E594715A@akamai.com>
 <3def936f-ad25-4c83-b788-7ab8c6d9fbbd@default>
Message-ID: <CAHEJ-S6eh7=70BnmF1YZHyofY=YDJvBN2hnNa3eVd2BDxK_P_g@mail.gmail.com>

We have discussed this at numerous OMC meetings in terms of how to managed
potential *perceived *conflicts of interest that might arise if people
outside of the fellows come from the same company and hence can effectively
turn the OMC review control mechanism into a single control rather than a
dual control.

We discussed tooling changes to make checking this possible given that in
each instance we have had the individuals involved make a commitment to
avoid that situation (through their own actions).
Occasionally that didn't happen and the person "corrected" it when pointed
out.

We haven't formally voted to make such a change - however it is something
that I think we should have in place and I do support.
Making a formal policy change of course will go through our usual decision
making process.

What I was expecting tooling-wise is that the scripts would detect this
situation and advise - at the very least warn - and potentially blocking
things.

The OpenSSL fellows are in a completely different context - the company
they work for is directed by the OMC - so there isn't a separate external
third party source of influence so there is no reasonable mechanism to
*perceive* a potential conflict of interest.

Note - this is all about *perceptions* of a *potential* situation - not
about something we are actually concerned about for the individuals
involved.
However it is prudent to address even the perception of a path for
potential conflicts of interest in my view.

Tim.




On Fri, May 24, 2019 at 8:16 AM Paul Dale <paul.dale at oracle.com> wrote:

> There hasn't been a vote about this, however both Shane and I have
> committed to not approve each other's PRs.
>
> I also asked Richard if this could be mechanically enforced, which I
> expect will happen eventually.
>
>
> Pauli
> --
> Oracle
> Dr Paul Dale | Cryptographer | Network Security & Encryption
> Phone +61 7 3031 7217
> Oracle Australia
>
>
> -----Original Message-----
> From: Salz, Rich [mailto:rsalz at akamai.com]
> Sent: Friday, 24 May 2019 1:01 AM
> To: openssl-project at openssl.org
> Subject: Re: No two reviewers from same company
>
>     > I understand that OpenSSL is changing things so that, by mechanism
> (and maybe by
>     > policy although it?s not published yet), two members of the same
> company cannot
>     > approve the same PR.  That?s great.  (I never approved Akamai
> requests unless it
>     > was trivial back when I was on the OMC.)
>
>     No such decision has been made as far as I know although it has been
> discussed
>     at various times.
>
> In private email, and
> https://github.com/openssl/openssl/pull/8886#issuecomment-494624313 the
> implication is that this was a policy.
>
>     > Should this policy be extended to OpenSSL?s fellows?
>
>     IMO, no.
>
> Why not?  I understand build process is always handled by Matt and Richard
> (despite many attempts in the past to expand this), but I think if Oracle
> or Akamai can't "force a change" then it seems to me that the OMC shouldn't
> either.
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-project/attachments/20190524/1f7cb3cd/attachment.html>

From tjh at openssl.org  Fri May 24 08:49:40 2019
From: tjh at openssl.org (Tim Hudson)
Date: Fri, 24 May 2019 18:49:40 +1000
Subject: proposed change to committers policy
Message-ID: <CAHEJ-S63RgwpFt_SrFomtPLbOcRSL6KHR=4jgRgxNwh47-Rfog@mail.gmail.com>

As part of various discussions, I've drafted a proposed (not yet put to a
formal vote) change to the committers policy to address the perception of a
potential conflict-of-interest situation. I don't believe that we have
actually encountered a conflict of interest in our current policy, but
avoiding the perception that the potential is there I think is worthwhile.

It also would encode formally the practice that individuals have been
following on an informal basis as a number of those individuals have noted.

Note the OSF and the OSS are noted in the bylaws - I haven't expanded that
here - but effectively that covers the organisations that are governed by
the OMC which means resources like the OpenSSL fellows are not impacted by
this policy change. i.e. one OpenSSL fellow can approve another OpenSSL
fellow proposed change (as is our regular practice).

I've tried to keep it simple and precise.

Tim.

diff --git a/policies/committers.html b/policies/committers.html
index 80e31c8..22d78b2 100644
--- a/policies/committers.html
+++ b/policies/committers.html
@@ -77,6 +77,11 @@
                 including one from the OMC.</li>
               </ul>

+       <p>In considering approvals, the combined approvals must come
+       from individuals who work for separate organisations.
+       This condition does not apply where the organisation is the
+       OSF or OSS.
+
               <p>This process may seem a little heavy, but OpenSSL is a
large,
               complicated codebase, and we think two reviews help prevent
               security bugs, as well as disseminate knowledge to the
growing
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-project/attachments/20190524/15202d74/attachment.html>

From Matthias.St.Pierre at ncp-e.com  Fri May 24 09:21:18 2019
From: Matthias.St.Pierre at ncp-e.com (Matthias St. Pierre)
Date: Fri, 24 May 2019 11:21:18 +0200
Subject: proposed change to committers policy
In-Reply-To: <CAHEJ-S63RgwpFt_SrFomtPLbOcRSL6KHR=4jgRgxNwh47-Rfog@mail.gmail.com>
References: <CAHEJ-S63RgwpFt_SrFomtPLbOcRSL6KHR=4jgRgxNwh47-Rfog@mail.gmail.com>
Message-ID: <fe3555c3-1971-ba85-bf4e-3065ece94fd4@ncp-e.com>



 >?????? <p>In considering approvals, the combined approvals must come
 >?????? from individuals who work for separate organisations.
 >?????? This condition does not apply where the organisation is the
 >?????? OSF or OSS.


IMHO an important clarification needs to be made: The rule should not be about
_prohibiting_ double approvals. It should only be about _counting_ them.
I would not deprive people of the right to state their opinions.

Also, if Shane has already approved, then Pauli should still have the right
to approve, since his approval counts as OMC approval and Shane's not.

How about using a formulation like the following?

 ??????? <p>In considering approvals, approvals from individuals being
 ??? ??? employed by the same third party company or organization should
 ??? ??? be counted as a single approval. If one of the individuals is
 ??? ??? an OMC member, the combined approval counts as an OMC approval.
 ??????? This condition does not apply where the organisation is the
 ??????? OSF or OSS.


An editorial comment: I think that the amendmend should be made inside the
unordered list, not following it.

https://github.com/openssl/web/blob/master/policies/committers.html#L72-L78

Apart from that: Tim, could you (or someone else of the OMC) please raise a PR
for your proposal? That would make it easier to discuss the details.

Matthias



From shane.lontis at oracle.com  Fri May 24 09:28:23 2019
From: shane.lontis at oracle.com (SHANE LONTIS)
Date: Fri, 24 May 2019 19:28:23 +1000
Subject: proposed change to committers policy
In-Reply-To: <fe3555c3-1971-ba85-bf4e-3065ece94fd4@ncp-e.com>
References: <CAHEJ-S63RgwpFt_SrFomtPLbOcRSL6KHR=4jgRgxNwh47-Rfog@mail.gmail.com>
 <fe3555c3-1971-ba85-bf4e-3065ece94fd4@ncp-e.com>
Message-ID: <F7C38AB1-9220-4269-A084-524CA3E16597@oracle.com>

It doesn?t stop us both reviewing a PR. That doesn?t mean we both need to approve.


> On 24 May 2019, at 7:21 pm, Matthias St. Pierre <Matthias.St.Pierre at ncp-e.com> wrote:
> 
> 
> 
> >       <p>In considering approvals, the combined approvals must come
> >       from individuals who work for separate organisations.
> >       This condition does not apply where the organisation is the
> >       OSF or OSS.
> 
> 
> IMHO an important clarification needs to be made: The rule should not be about
> _prohibiting_ double approvals. It should only be about _counting_ them.
> I would not deprive people of the right to state their opinions.
> 
> Also, if Shane has already approved, then Pauli should still have the right
> to approve, since his approval counts as OMC approval and Shane's not.
> 
> How about using a formulation like the following?
> 
>         <p>In considering approvals, approvals from individuals being
>         employed by the same third party company or organization should
>         be counted as a single approval. If one of the individuals is
>         an OMC member, the combined approval counts as an OMC approval.
>         This condition does not apply where the organisation is the
>         OSF or OSS.
> 
> 
> An editorial comment: I think that the amendmend should be made inside the
> unordered list, not following it.
> 
> https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_openssl_web_blob_master_policies_committers.html-23L72-2DL78&d=DwIDaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=b1aL1L-m41VGkedIk-9Q7taAEKIshTBwq95Iah07uCk&m=DYHGYucybgbeMHQn9pS8SBhh_dvJkYrDgKu9gU2l9H4&s=jT3VTidhpkkMAwUuiu_JgqW9mBpD4PP-3Qc8D3KZDdU&e=
> 
> Apart from that: Tim, could you (or someone else of the OMC) please raise a PR
> for your proposal? That would make it easier to discuss the details.
> 
> Matthias
> 
> 

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

From matt at openssl.org  Fri May 24 09:34:31 2019
From: matt at openssl.org (Matt Caswell)
Date: Fri, 24 May 2019 10:34:31 +0100
Subject: proposed change to committers policy
In-Reply-To: <F7C38AB1-9220-4269-A084-524CA3E16597@oracle.com>
References: <CAHEJ-S63RgwpFt_SrFomtPLbOcRSL6KHR=4jgRgxNwh47-Rfog@mail.gmail.com>
 <fe3555c3-1971-ba85-bf4e-3065ece94fd4@ncp-e.com>
 <F7C38AB1-9220-4269-A084-524CA3E16597@oracle.com>
Message-ID: <b4c921a8-2686-5bca-1f46-f72e71d69ae2@openssl.org>

On 24/05/2019 10:28, SHANE LONTIS wrote:
> It doesn?t stop us both reviewing a PR. That doesn?t mean we both need to approve.

Right...but in Matthias's version if you raise a PR, and then Pauli approves it,
then you only then need to get a second committer approval. Otherwise you would
need to get an OMC approval.

That sounds ok to me.

Matt

> 
> 
>> On 24 May 2019, at 7:21 pm, Matthias St. Pierre <Matthias.St.Pierre at ncp-e.com
>> <mailto:Matthias.St.Pierre at ncp-e.com>> wrote:
>>
>>
>>
>> >?????? <p>In considering approvals, the combined approvals must come
>> >?????? from individuals who work for separate organisations.
>> >?????? This condition does not apply where the organisation is the
>> >?????? OSF or OSS.
>>
>>
>> IMHO an important clarification needs to be made: The rule should not be about
>> _prohibiting_ double approvals. It should only be about _counting_ them.
>> I would not deprive people of the right to state their opinions.
>>
>> Also, if Shane has already approved, then Pauli should still have the right
>> to approve, since his approval counts as OMC approval and Shane's not.
>>
>> How about using a formulation like the following?
>>
>> ??????? <p>In considering approvals, approvals from individuals being
>> ??? ??? employed by the same third party company or organization should
>> ??? ??? be counted as a single approval. If one of the individuals is
>> ??? ??? an OMC member, the combined approval counts as an OMC approval.
>> ??????? This condition does not apply where the organisation is the
>> ??????? OSF or OSS.
>>
>>
>> An editorial comment: I think that the amendmend should be made inside the
>> unordered list, not following it.
>>
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_openssl_web_blob_master_policies_committers.html-23L72-2DL78&d=DwIDaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=b1aL1L-m41VGkedIk-9Q7taAEKIshTBwq95Iah07uCk&m=DYHGYucybgbeMHQn9pS8SBhh_dvJkYrDgKu9gU2l9H4&s=jT3VTidhpkkMAwUuiu_JgqW9mBpD4PP-3Qc8D3KZDdU&e=
>>
>> Apart from that: Tim, could you (or someone else of the OMC) please raise a PR
>> for your proposal? That would make it easier to discuss the details.
>>
>> Matthias
>>
>>
> 

From tjh at cryptsoft.com  Fri May 24 09:53:52 2019
From: tjh at cryptsoft.com (Tim Hudson)
Date: Fri, 24 May 2019 19:53:52 +1000
Subject: proposed change to committers policy
In-Reply-To: <b4c921a8-2686-5bca-1f46-f72e71d69ae2@openssl.org>
References: <CAHEJ-S63RgwpFt_SrFomtPLbOcRSL6KHR=4jgRgxNwh47-Rfog@mail.gmail.com>
 <fe3555c3-1971-ba85-bf4e-3065ece94fd4@ncp-e.com>
 <F7C38AB1-9220-4269-A084-524CA3E16597@oracle.com>
 <b4c921a8-2686-5bca-1f46-f72e71d69ae2@openssl.org>
Message-ID: <CAHEJ-S6Ec=-PG6Z6dGM0W5RwvNk520CkoCEs9hZ4=km=Ra2jnQ@mail.gmail.com>

On Fri, May 24, 2019 at 7:34 PM Matt Caswell <matt at openssl.org> wrote:

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

It works that way in the original wording too - which is more simply stated
IMHO.
You choose which approvals you combine. If there are three - select which
ever two make the set you want to "combine" as such.

I also didn't see a need for a separate OMC approval if a committer
submitted something and a same-organisation OMC member approved it - it
just needs one more -  so the combination of approvals can be made from
not-the-same-organisation.

Tim.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-project/attachments/20190524/81b452db/attachment.html>

From levitte at openssl.org  Fri May 24 12:30:58 2019
From: levitte at openssl.org (Richard Levitte)
Date: Fri, 24 May 2019 14:30:58 +0200
Subject: proposed change to committers policy
In-Reply-To: <fe3555c3-1971-ba85-bf4e-3065ece94fd4@ncp-e.com>
References: <CAHEJ-S63RgwpFt_SrFomtPLbOcRSL6KHR=4jgRgxNwh47-Rfog@mail.gmail.com>
 <fe3555c3-1971-ba85-bf4e-3065ece94fd4@ncp-e.com>
Message-ID: <87pno811bx.wl-levitte@openssl.org>

On Fri, 24 May 2019 11:21:18 +0200,
Matthias St. Pierre wrote:
> 
> >?????? <p>In considering approvals, the combined approvals must come
> >?????? from individuals who work for separate organisations.
> >?????? This condition does not apply where the organisation is the
> >?????? OSF or OSS.
> 
> 
> IMHO an important clarification needs to be made: The rule should not be about
> _prohibiting_ double approvals. It should only be about _counting_ them.
> I would not deprive people of the right to state their opinions.

Isn't that an implementation detail?

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

From Matthias.St.Pierre at ncp-e.com  Fri May 24 13:22:45 2019
From: Matthias.St.Pierre at ncp-e.com (Dr. Matthias St. Pierre)
Date: Fri, 24 May 2019 13:22:45 +0000
Subject: AW: proposed change to committers policy
In-Reply-To: <87pno811bx.wl-levitte@openssl.org>
References: <CAHEJ-S63RgwpFt_SrFomtPLbOcRSL6KHR=4jgRgxNwh47-Rfog@mail.gmail.com>
 <fe3555c3-1971-ba85-bf4e-3065ece94fd4@ncp-e.com>
 <87pno811bx.wl-levitte@openssl.org>
Message-ID: <c1f25c1b23ac4e40ae367b9b30d08b77@Ex13.ncp.local>


> > IMHO an important clarification needs to be made: The rule should not be about
> > _prohibiting_ double approvals. It should only be about _counting_ them.
> > I would not deprive people of the right to state their opinions.
> 
> Isn't that an implementation detail?

You're right, it should be. But current discussions and current practice show that Pauli
avoids to approve on GitHub when Shane is involved and vice versa. IMHO it should
be valid to approve (and also recorded in the commit message), even if the vote is not
counted. Because it documents that both have reviewed the code.

Matthias


From Matthias.St.Pierre at ncp-e.com  Fri May 24 13:24:48 2019
From: Matthias.St.Pierre at ncp-e.com (Dr. Matthias St. Pierre)
Date: Fri, 24 May 2019 13:24:48 +0000
Subject: AW: [openssl] OpenSSL_1_1_1-stable update
In-Reply-To: <5c4c25a9-6e86-9f08-676d-5652779a9658@openssl.org>
References: <1558691079.520008.32101.nullmailer@dev.openssl.org>
 <39433428-3a43-e720-d39b-bf3dcefbef81@openssl.org>
 <87mujc10pp.wl-levitte@openssl.org>
 <5c4c25a9-6e86-9f08-676d-5652779a9658@openssl.org>
Message-ID: <bf55e3736b0c4241a29fd80cb576bf94@Ex13.ncp.local>

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


From levitte at openssl.org  Fri May 24 14:10:38 2019
From: levitte at openssl.org (Richard Levitte)
Date: Fri, 24 May 2019 16:10:38 +0200
Subject: AW: [openssl] OpenSSL_1_1_1-stable update
In-Reply-To: <bf55e3736b0c4241a29fd80cb576bf94@Ex13.ncp.local>
References: <1558691079.520008.32101.nullmailer@dev.openssl.org>
 <39433428-3a43-e720-d39b-bf3dcefbef81@openssl.org>
 <87mujc10pp.wl-levitte@openssl.org>
 <5c4c25a9-6e86-9f08-676d-5652779a9658@openssl.org>
 <bf55e3736b0c4241a29fd80cb576bf94@Ex13.ncp.local>
Message-ID: <87lfyw0wpt.wl-levitte@openssl.org>

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
up in.  With the in mind, the exact branches it gets applied to is a
*separate* question.

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)?
So far, we have never acted that way.

On Fri, 24 May 2019 15:24:48 +0200,
Dr. Matthias St. Pierre wrote:
> 
> 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
> 
-- 
Richard Levitte         levitte at openssl.org
OpenSSL Project         http://www.openssl.org/~levitte/

From matt at openssl.org  Fri May 24 14:20:59 2019
From: matt at openssl.org (Matt Caswell)
Date: Fri, 24 May 2019 15:20:59 +0100
Subject: AW: [openssl] OpenSSL_1_1_1-stable update
In-Reply-To: <87lfyw0wpt.wl-levitte@openssl.org>
References: <1558691079.520008.32101.nullmailer@dev.openssl.org>
 <39433428-3a43-e720-d39b-bf3dcefbef81@openssl.org>
 <87mujc10pp.wl-levitte@openssl.org>
 <5c4c25a9-6e86-9f08-676d-5652779a9658@openssl.org>
 <bf55e3736b0c4241a29fd80cb576bf94@Ex13.ncp.local>
 <87lfyw0wpt.wl-levitte@openssl.org>
Message-ID: <7ea0e8f0-e4c7-759f-ae75-82ff338fe0a0@openssl.org>



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 set of patches, without regard for exact branches it ends
> up in.  With the in mind, the exact branches it gets applied to is a
> *separate* question.

That's not the way I've ever thought of it. In my mind an approval is for a
change applied to a specific branch. Where a PR lists more than one branch in it
and you approve the PR then effectively you are approving it multiple times all
in one go - once for each branch.


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

This is essential in my mind. A change for one branch does not always make sense
in another branch. So you can't just say "I approve this change" and *then*
worry about what branches it applies to. A change only makes sense in the
context of the branch it applies to.

Matt

From beldmit at gmail.com  Fri May 24 14:25:57 2019
From: beldmit at gmail.com (Dmitry Belyavsky)
Date: Fri, 24 May 2019 17:25:57 +0300
Subject: AW: [openssl] OpenSSL_1_1_1-stable update
In-Reply-To: <7ea0e8f0-e4c7-759f-ae75-82ff338fe0a0@openssl.org>
References: <1558691079.520008.32101.nullmailer@dev.openssl.org>
 <39433428-3a43-e720-d39b-bf3dcefbef81@openssl.org>
 <87mujc10pp.wl-levitte@openssl.org>
 <5c4c25a9-6e86-9f08-676d-5652779a9658@openssl.org>
 <bf55e3736b0c4241a29fd80cb576bf94@Ex13.ncp.local>
 <87lfyw0wpt.wl-levitte@openssl.org>
 <7ea0e8f0-e4c7-759f-ae75-82ff338fe0a0@openssl.org>
Message-ID: <CADqLbz+JQsTXoJQtKAp0P0FNOYhFAAvdO1BSX5Axcz4XmB8E=A@mail.gmail.com>

Hello,

On Fri, May 24, 2019 at 5:21 PM Matt Caswell <matt at openssl.org> 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.
>
> This is essential in my mind. A change for one branch does not always make
> sense
> in another branch. So you can't just say "I approve this change" and *then*
> worry about what branches it applies to. A change only makes sense in the
> context of the branch it applies to.
>
>
I agree with Matt. For example, a patch providing new functionality cat be
cleanly applicable
to master and stable branches, but if it is applied to a stable branch, it
breaks the policy.

-- 
SY, Dmitry Belyavsky
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-project/attachments/20190524/1a9023f9/attachment.html>

From levitte at openssl.org  Fri May 24 14:30:22 2019
From: levitte at openssl.org (Richard Levitte)
Date: Fri, 24 May 2019 16:30:22 +0200
Subject: AW: [openssl] OpenSSL_1_1_1-stable update
In-Reply-To: <7ea0e8f0-e4c7-759f-ae75-82ff338fe0a0@openssl.org>
References: <1558691079.520008.32101.nullmailer@dev.openssl.org>
 <39433428-3a43-e720-d39b-bf3dcefbef81@openssl.org>
 <87mujc10pp.wl-levitte@openssl.org>
 <5c4c25a9-6e86-9f08-676d-5652779a9658@openssl.org>
 <bf55e3736b0c4241a29fd80cb576bf94@Ex13.ncp.local>
 <87lfyw0wpt.wl-levitte@openssl.org>
 <7ea0e8f0-e4c7-759f-ae75-82ff338fe0a0@openssl.org>
Message-ID: <87imu00vsx.wl-levitte@openssl.org>

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         levitte at openssl.org
OpenSSL Project         http://www.openssl.org/~levitte/

From matt at openssl.org  Fri May 24 14:39:51 2019
From: matt at openssl.org (Matt Caswell)
Date: Fri, 24 May 2019 15:39:51 +0100
Subject: AW: [openssl] OpenSSL_1_1_1-stable update
In-Reply-To: <87imu00vsx.wl-levitte@openssl.org>
References: <1558691079.520008.32101.nullmailer@dev.openssl.org>
 <39433428-3a43-e720-d39b-bf3dcefbef81@openssl.org>
 <87mujc10pp.wl-levitte@openssl.org>
 <5c4c25a9-6e86-9f08-676d-5652779a9658@openssl.org>
 <bf55e3736b0c4241a29fd80cb576bf94@Ex13.ncp.local>
 <87lfyw0wpt.wl-levitte@openssl.org>
 <7ea0e8f0-e4c7-759f-ae75-82ff338fe0a0@openssl.org>
 <87imu00vsx.wl-levitte@openssl.org>
Message-ID: <51db9d5f-0733-56ea-13c1-891683562585@openssl.org>



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

In the vast majority of the cases the reviewers are the same. In the rare
circumstances where they are different I have always changed them. I thought
everyone did. IMO that is the correct action. By putting your name as a reviewer
against a PR you are effectively saying "I have reviewed this and agree that it
is appropriate for this to be merged". 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?

Matt

From levitte at openssl.org  Fri May 24 14:54:00 2019
From: levitte at openssl.org (Richard Levitte)
Date: Fri, 24 May 2019 16:54:00 +0200
Subject: AW: [openssl] OpenSSL_1_1_1-stable update
In-Reply-To: <51db9d5f-0733-56ea-13c1-891683562585@openssl.org>
References: <1558691079.520008.32101.nullmailer@dev.openssl.org>
 <39433428-3a43-e720-d39b-bf3dcefbef81@openssl.org>
 <87mujc10pp.wl-levitte@openssl.org>
 <5c4c25a9-6e86-9f08-676d-5652779a9658@openssl.org>
 <bf55e3736b0c4241a29fd80cb576bf94@Ex13.ncp.local>
 <87lfyw0wpt.wl-levitte@openssl.org>
 <7ea0e8f0-e4c7-759f-ae75-82ff338fe0a0@openssl.org>
 <87imu00vsx.wl-levitte@openssl.org>
 <51db9d5f-0733-56ea-13c1-891683562585@openssl.org>
Message-ID: <87h89j299z.wl-levitte@openssl.org>

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         levitte at openssl.org
OpenSSL Project         http://www.openssl.org/~levitte/

From Matthias.St.Pierre at ncp-e.com  Fri May 24 15:45:46 2019
From: Matthias.St.Pierre at ncp-e.com (Matthias St. Pierre)
Date: Fri, 24 May 2019 17:45:46 +0200
Subject: AW: [openssl] OpenSSL_1_1_1-stable update
In-Reply-To: <87h89j299z.wl-levitte@openssl.org>
References: <1558691079.520008.32101.nullmailer@dev.openssl.org>
 <39433428-3a43-e720-d39b-bf3dcefbef81@openssl.org>
 <87mujc10pp.wl-levitte@openssl.org>
 <5c4c25a9-6e86-9f08-676d-5652779a9658@openssl.org>
 <bf55e3736b0c4241a29fd80cb576bf94@Ex13.ncp.local>
 <87lfyw0wpt.wl-levitte@openssl.org>
 <7ea0e8f0-e4c7-759f-ae75-82ff338fe0a0@openssl.org>
 <87imu00vsx.wl-levitte@openssl.org>
 <51db9d5f-0733-56ea-13c1-891683562585@openssl.org>
 <87h89j299z.wl-levitte@openssl.org>
Message-ID: <be9b9022-6918-3549-4abd-8885ce53d572@ncp-e.com>



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


From Matthias.St.Pierre at ncp-e.com  Fri May 24 15:47:10 2019
From: Matthias.St.Pierre at ncp-e.com (Matthias St. Pierre)
Date: Fri, 24 May 2019 17:47:10 +0200
Subject: AW: [openssl] OpenSSL_1_1_1-stable update
In-Reply-To: <be9b9022-6918-3549-4abd-8885ce53d572@ncp-e.com>
References: <1558691079.520008.32101.nullmailer@dev.openssl.org>
 <39433428-3a43-e720-d39b-bf3dcefbef81@openssl.org>
 <87mujc10pp.wl-levitte@openssl.org>
 <5c4c25a9-6e86-9f08-676d-5652779a9658@openssl.org>
 <bf55e3736b0c4241a29fd80cb576bf94@Ex13.ncp.local>
 <87lfyw0wpt.wl-levitte@openssl.org>
 <7ea0e8f0-e4c7-759f-ae75-82ff338fe0a0@openssl.org>
 <87imu00vsx.wl-levitte@openssl.org>
 <51db9d5f-0733-56ea-13c1-891683562585@openssl.org>
 <87h89j299z.wl-levitte@openssl.org>
 <be9b9022-6918-3549-4abd-8885ce53d572@ncp-e.com>
Message-ID: <a8d6cfc4-3389-01d0-416c-aadc2218aa86@ncp-e.com>

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


From rsalz at akamai.com  Thu May 23 15:54:37 2019
From: rsalz at akamai.com (Salz, Rich)
Date: Thu, 23 May 2019 15:54:37 +0000
Subject: No two reviewers from same company
In-Reply-To: <488e99cd-7f77-86b1-8ae0-70b5e64715cf@openssl.org>
References: <F606CC7A-3060-4E8C-800F-1DBB7B77CD57@akamai.com>
 <70872e8f-b531-9ebe-62e3-1040e815ceab@openssl.org>
 <DB57BDC2-CD6A-4BCC-B900-1A69E594715A@akamai.com>
 <fc4809f5-7e9d-c451-be2c-20043162a5c3@openssl.org>
 <75504EFF-71AB-4B03-B4AB-42E43C6A57A1@akamai.com>
 <488e99cd-7f77-86b1-8ae0-70b5e64715cf@openssl.org>
Message-ID: <5ED4F7B3-2A32-4FCE-A1B8-4DB7480FCEBA@akamai.com>

>   In that example the potential conflict of interest comes from the individual's
    employment with the third party organisation, not because they are fellows.
  
Do you disagree with my contention that the OMC represents the project, and not the fellows?

Regardless of where the conflict of interest comes from, the end result is the same, and I encourage the OMC to make the same policy for *its* employees that it does for other companies's employees.  Or perhaps this is a matter for the foundation to make for its employees.



From nic.tuv at gmail.com  Fri May 24 15:47:36 2019
From: nic.tuv at gmail.com (Nicola Tuveri)
Date: Fri, 24 May 2019 08:47:36 -0700
Subject: AW: [openssl] OpenSSL_1_1_1-stable update
In-Reply-To: <7ea0e8f0-e4c7-759f-ae75-82ff338fe0a0@openssl.org>
References: <1558691079.520008.32101.nullmailer@dev.openssl.org>
 <39433428-3a43-e720-d39b-bf3dcefbef81@openssl.org>
 <87mujc10pp.wl-levitte@openssl.org>
 <5c4c25a9-6e86-9f08-676d-5652779a9658@openssl.org>
 <bf55e3736b0c4241a29fd80cb576bf94@Ex13.ncp.local>
 <87lfyw0wpt.wl-levitte@openssl.org>
 <7ea0e8f0-e4c7-759f-ae75-82ff338fe0a0@openssl.org>
Message-ID: <CANm5x_PHhGS_1XpQ9M2SG4y2LXdkxn6GWCHAp3KehUsMtXrZcA@mail.gmail.com>

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 <matt at openssl.org> wrote:

>
>
> 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 set of patches, without regard for exact branches it ends
> > up in.  With the in mind, the exact branches it gets applied to is a
> > *separate* question.
>
> That's not the way I've ever thought of it. In my mind an approval is for a
> change applied to a specific branch. Where a PR lists more than one branch
> in it
> and you approve the PR then effectively you are approving it multiple
> times all
> in one go - once for each branch.
>
>
> > 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.
>
> This is essential in my mind. A change for one branch does not always make
> sense
> in another branch. So you can't just say "I approve this change" and *then*
> worry about what branches it applies to. A change only makes sense in the
> context of the branch it applies to.
>
> Matt
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-project/attachments/20190524/bce3603b/attachment.html>

From rsalz at akamai.com  Fri May 24 16:01:31 2019
From: rsalz at akamai.com (Salz, Rich)
Date: Fri, 24 May 2019 16:01:31 +0000
Subject: proposed change to committers policy
In-Reply-To: <CAHEJ-S63RgwpFt_SrFomtPLbOcRSL6KHR=4jgRgxNwh47-Rfog@mail.gmail.com>
References: <CAHEJ-S63RgwpFt_SrFomtPLbOcRSL6KHR=4jgRgxNwh47-Rfog@mail.gmail.com>
Message-ID: <EF53587F-AC37-4716-B274-BF62AF827286@akamai.com>

Nicely worded.  It doesn?t go as far as I?d like, but it?s a step.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-project/attachments/20190524/1eb8cd60/attachment.html>

From matt at openssl.org  Mon May 27 18:34:40 2019
From: matt at openssl.org (Matt Caswell)
Date: Mon, 27 May 2019 19:34:40 +0100
Subject: Repo frozen
Message-ID: <01d75072-d492-a763-992e-83d92aa243f4@openssl.org>

In preparation for tomorrow's release the repo has been frozen.

We'll let you know when you can do pushes again.

Matt

From openssl at openssl.org  Tue May 28 13:28:18 2019
From: openssl at openssl.org (OpenSSL)
Date: Tue, 28 May 2019 13:28:18 +0000
Subject: OpenSSL version 1.0.2s published
Message-ID: <20190528132818.GA24924@openssl.org>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512


   OpenSSL version 1.0.2s released
   ===============================

   OpenSSL - The Open Source toolkit for SSL/TLS
   https://www.openssl.org/

   The OpenSSL project team is pleased to announce the release of
   version 1.0.2s of our open source toolkit for SSL/TLS. For details
   of changes and known issues see the release notes at:

        https://www.openssl.org/news/openssl-1.0.2-notes.html

   OpenSSL 1.0.2s is available for download via HTTP and FTP from the
   following master locations (you can find the various FTP mirrors under
   https://www.openssl.org/source/mirror.html):

     * https://www.openssl.org/source/
     * ftp://ftp.openssl.org/source/

   The distribution file name is:

    o openssl-1.0.2s.tar.gz
      Size: 5349149
      SHA1 checksum: cf43d57a21e4baf420b3628677ebf1723ed53bc1
      SHA256 checksum: cabd5c9492825ce5bd23f3c3aeed6a97f8142f606d893df216411f07d1abab96

   The checksums were calculated using the following commands:

    openssl sha1 openssl-1.0.2s.tar.gz
    openssl sha256 openssl-1.0.2s.tar.gz

   Yours,

   The OpenSSL Project Team.

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEEeVOsH7w9yLOykjk+1enkP3357owFAlztMAcACgkQ1enkP335
7ozPdRAAnUKK6jxlMa3O2GeVDU0ZZNS3A3zyMJd2yPCB3I3b0BMxy/ZWw4A6Vtyd
l1M+GhP7/SG+kom9f6Ky2QXTW29lYQT4ImNZwU/hRI/nLKCqFw9Kzq4wqZnwlavx
pI54Loz86Ysp2PIAtWJrOPxWT7HEculhhR0yOXxWAlAkRmrbrG3JdTba3UIH0T2P
3xoncvI0ODXWE6eW3hNCtxb/npo/czcAolO/EEN60tRcZm849ODgzNqpiV5zegoF
cogfVaQFGcOncv4bYdxQIPBDBLWVEEkT+05agnFfZkv6hpIL8h2jrG4b46ULs+ZM
4iNznwLEVNVhF6Qm6RIffC3xrKIhmDZkGH8Y/ypBOTVk/vUhvot+a7Ab05fvnqeR
O5BwxUVwNsxQdZ4v4BKJM/RE1ApHuQoezOCwfPfMT2NZd3StVueQxkwSrRhtEx8k
ZnRrgtqYM8zCjqW7uVOvSIB08EZvJpIhMofIMqlfEixdTvmSvHQ8iPCQrKS0dmjA
CtWdSgFbc7NYXwj5lqfr58brKhhoap/B8MFvVaGkcqhsCp5pE/a8JO79ESI7TVQD
uxs28qhEj7RXNH61m9viOvu75ph6lfVxI/4Hat7yi/pzr4jpYYJXWM6Iz9PTf2PS
admaUdGLOUB7L51Z7/uTHuACV16SwXryJn4b0OwuTmUQ9rsdDRA=
=aI2x
-----END PGP SIGNATURE-----

From openssl at openssl.org  Tue May 28 13:28:24 2019
From: openssl at openssl.org (OpenSSL)
Date: Tue, 28 May 2019 13:28:24 +0000
Subject: OpenSSL version 1.1.0k published
Message-ID: <20190528132824.GA24994@openssl.org>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512


   OpenSSL version 1.1.0k released
   ===============================

   OpenSSL - The Open Source toolkit for SSL/TLS
   https://www.openssl.org/

   The OpenSSL project team is pleased to announce the release of
   version 1.1.0k of our open source toolkit for SSL/TLS. For details
   of changes and known issues see the release notes at:

        https://www.openssl.org/news/openssl-1.1.0-notes.html

   OpenSSL 1.1.0k is available for download via HTTP and FTP from the
   following master locations (you can find the various FTP mirrors under
   https://www.openssl.org/source/mirror.html):

     * https://www.openssl.org/source/
     * ftp://ftp.openssl.org/source/

   The distribution file name is:

    o openssl-1.1.0k.tar.gz
      Size: 5287321
      SHA1 checksum: aaa2ddad0285575da7c9fa8021c26e5c8433ab15
      SHA256 checksum: efa4965f4f773574d6cbda1cf874dbbe455ab1c0d4f906115f867d30444470b1

   The checksums were calculated using the following commands:

    openssl sha1 openssl-1.1.0k.tar.gz
    openssl sha256 openssl-1.1.0k.tar.gz

   Yours,

   The OpenSSL Project Team.

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEEeVOsH7w9yLOykjk+1enkP3357owFAlztMKgACgkQ1enkP335
7ozB7BAArso7v+Yy6+3TiPPaH+EAYkEr2J+WQ2D17s7M9kpW8errvyX7B/yMIVSh
1ZEPfWWtmDdd9CDqfpM/P2ttipjHvrPvwh01+Re8sm+pE8me3j9N1UkqXLpRPQuW
eSAwjSYcVTgGlDlJnsDW7Yxf1vibfjA7hDHL+7MY3tdPna2rb2TICOmX1TmwR4ha
Xc6E6JAH049Rjzh9NCgcxANnembTnPqRAVmxyf6ziMmvHeDe6voYQZrtagC1CHbY
x1Y+Q3GMLtvebm7YRqoy3o29WFMPUPErcfPsun9aizmTR+UgePjQ9Tjq6bF9umTL
5Z1lt4JJsC0gUmKLTpPL0SNhAf1/TS59Usvk4pMefSq7ejteSzX1xoHY/VQ4U8pO
pO8Vsn7k8U4azuRgi3diprYhgtMDeK4udyepFTI53Bqk/H7Gm0v+R7tYYH2Zbwqm
49UuvMlP/7XHKwo0hIoV6Ul3xrNprxoXQmTG+Tm4+AoA4Qn9jELvMe96CaeLAPxG
V7NjqK7Tr4Iosso4h+Pq2oEsu3GLzXVdFYA5RORkakuX60Y8+jznKAP4WNhPS/rs
zPr8fVghb0kpctodvq2px47DVQSsUf2nYGVwu205bHpGyTKuB1ZWkYbC6cQEg3yB
SPlFyHmHWYjqk8RSmSKZSiN33x0ysG8kwr3PEJOEEe8bvF3r7cM=
=go9J
-----END PGP SIGNATURE-----

From openssl at openssl.org  Tue May 28 13:28:29 2019
From: openssl at openssl.org (OpenSSL)
Date: Tue, 28 May 2019 13:28:29 +0000
Subject: OpenSSL version 1.1.1c published
Message-ID: <20190528132829.GA25063@openssl.org>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512


   OpenSSL version 1.1.1c released
   ===============================

   OpenSSL - The Open Source toolkit for SSL/TLS
   https://www.openssl.org/

   The OpenSSL project team is pleased to announce the release of
   version 1.1.1c of our open source toolkit for SSL/TLS. For details
   of changes and known issues see the release notes at:

        https://www.openssl.org/news/openssl-1.1.1-notes.html

   OpenSSL 1.1.1c is available for download via HTTP and FTP from the
   following master locations (you can find the various FTP mirrors under
   https://www.openssl.org/source/mirror.html):

     * https://www.openssl.org/source/
     * ftp://ftp.openssl.org/source/

   The distribution file name is:

    o openssl-1.1.1c.tar.gz
      Size: 8864262
      SHA1 checksum: 71b830a077276cbeccc994369538617a21bee808
      SHA256 checksum: f6fb3079ad15076154eda9413fed42877d668e7069d9b87396d0804fdb3f4c90

   The checksums were calculated using the following commands:

    openssl sha1 openssl-1.1.1c.tar.gz
    openssl sha256 openssl-1.1.1c.tar.gz

   Yours,

   The OpenSSL Project Team.

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEEeVOsH7w9yLOykjk+1enkP3357owFAlztM8MACgkQ1enkP335
7ow2lRAAirwJYIX4XunYXMV88tQILxAB6iCDiN04c5r5ayJqmF5Zr3QKGDG7Vj+l
q6NEmKIYpyjAxZau3orl0OC5L4Us+URFpyFpCe8BOpXjasFQYk7jycr3MI1BHYcO
dl9gVx09BZriR+q9w5xBJad34leCvuCD950+9eG/DY3+xSSWLDeagzz+dhOgTnOj
+YyMo+o/f+VucjsYddL2ehL5v744xdqu6Pu4JMceLaRdSfmKXRqwlob2w2UtCgoD
roy4+pPVLA9FYBOOYy1n2PFGopp/c67xfQX1yB35mjAB5y3FSJAWFS0gvPaHvzj1
D+zbQSxYVksOyUSrK33KnJmouaml5+CQgYRS+Umn8549A2apkIB/yRLo2K65Iuqd
KHgZGbI4cGUBEdbIxUDtvhsIr/+JlujJPvs5Eyiwm8+K/WPiZ3Hw8EXmdqTl9ITK
7URwWM4thq1sikD7RKHl4h9gEzvB6iqTd+dPbUE8jIc29HD7rPJWCw3m+gOGEoAu
L0rU4palNa1Ab6kMZ2SYsXv/rH4pl0iHBBrzVOStay/k4zPYS3eD6kytyB0vLt6g
f0u4heD4G4QiohqIFaDHjs8eSq1Paz3eA3Ylly8JKweBFTrHHssyz22ItGDCcQwz
cOb7H3o/AdXGZOSHxHtLBQqxsUcCuUID0YTyUB43bRuLnVmWs6I=
=EHRv
-----END PGP SIGNATURE-----

From matt at openssl.org  Tue May 28 14:04:30 2019
From: matt at openssl.org (Matt Caswell)
Date: Tue, 28 May 2019 15:04:30 +0100
Subject: Repo frozen
In-Reply-To: <01d75072-d492-a763-992e-83d92aa243f4@openssl.org>
References: <01d75072-d492-a763-992e-83d92aa243f4@openssl.org>
Message-ID: <15990219-6765-711a-e853-7317ce67a434@openssl.org>

Repo is now unfrozen!

Matt

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

From levitte at openssl.org  Tue May 28 15:08:04 2019
From: levitte at openssl.org (Richard Levitte)
Date: Tue, 28 May 2019 17:08:04 +0200
Subject: Repo frozen
In-Reply-To: <15990219-6765-711a-e853-7317ce67a434@openssl.org>
References: <01d75072-d492-a763-992e-83d92aa243f4@openssl.org>
 <15990219-6765-711a-e853-7317ce67a434@openssl.org>
Message-ID: <875zpu1usr.wl-levitte@openssl.org>

Thank you Matt for the reviews et al!

Cheers,
Richard

On Tue, 28 May 2019 16:04:30 +0200,
Matt Caswell wrote:
> 
> Repo is now unfrozen!
> 
> Matt
> 
> On 27/05/2019 19:34, Matt Caswell wrote:
> > In preparation for tomorrow's release the repo has been frozen.
> > 
> > We'll let you know when you can do pushes again.
> > 
> > Matt
> > 
> 
-- 
Richard Levitte         levitte at openssl.org
OpenSSL Project         http://www.openssl.org/~levitte/

From matt at openssl.org  Wed May 29 09:11:34 2019
From: matt at openssl.org (Matt Caswell)
Date: Wed, 29 May 2019 10:11:34 +0100
Subject: Forthcoming OpenSSL Releases
In-Reply-To: <24766385-ad0d-1da7-404b-34768c43b79c@openssl.org>
References: <24766385-ad0d-1da7-404b-34768c43b79c@openssl.org>
Message-ID: <c3fa63ba-9c8a-306e-d961-055b46b1a081@openssl.org>



On 21/05/2019 16:43, Matt Caswell wrote:
> The OpenSSL project team would like to announce the forthcoming release
> of OpenSSL versions 1.1.1c, 1.1.0k and 1.0.2s.
> 
> These releases will be made available on 28th May 2019 between approximately
> 1200-1600 UTC.
> 
> OpenSSL 1.1.0k and 1.0.2s contain security hardening bug fixes only but do not
> address any CVEs. OpenSSL 1.1.1c is a bug-fix release (and contains the
> equivalent security hardening fixes as for 1.1.0k and 1.0.2s where relevant).

Correction to this announcement: OpenSSL 1.1.1c and OpenSSL 1.1.0k (released
yesterday) do not address any new CVEs. They do however contain a fix for a
previously announced low severity CVE (CVE-2019-1543). See the original security
advisory here:

https://www.openssl.org/news/secadv/20190306.txt

Matt

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <http://mta.openssl.org/pipermail/openssl-project/attachments/20190529/d6ab02b6/attachment.sig>