RE: Starting the QUIC Design

[Dr. Matthias St. Pierre]

Second attempt 😉

> #17184 - QUIC API Design
> https://github.com/openssl/openssl/pull/17184
> 
> #17185 - QUIC Event Loop Design
> https://github.com/openssl/openssl/pull/17185

> > -Original Message-
> > From: openssl-users  On Behalf Of Matt 
> > Caswell
> > Sent: Friday, December 3, 2021 1:05 PM
> > To: openssl-project@openssl.org; openssl-us...@openssl.org
> > Subject: Starting the QUIC Design
> >
> > Please see my blog post on starting the QUIC design here:
> >
> > https://www.openssl.org/blog/blog/2021/12/03/starting-the-quic-design/
> >
> > Matt
> >



smime.p7s
Description: S/MIME cryptographic signature

RE: Starting the QUIC Design

[Dr. Matthias St. Pierre]

Sorry, the links to the pull requests are broken. This will be fixed as soon as 
possible.

Here the correct links:

#17184 - QUIC API Design
https://github.com/openssl/openssl/pull/17184

#17185 - QUIC Event Loop Design
https://github.com/openssl/pull/17185


> -Original Message-
> From: openssl-users  On Behalf Of Matt 
> Caswell
> Sent: Friday, December 3, 2021 1:05 PM
> To: openssl-project@openssl.org; openssl-us...@openssl.org
> Subject: Starting the QUIC Design
> 
> Please see my blog post on starting the QUIC design here:
> 
> https://www.openssl.org/blog/blog/2021/12/03/starting-the-quic-design/
> 
> Matt
> 



smime.p7s
Description: S/MIME cryptographic signature

RE: OTC VOTE: Accept Policy change process proposal

[Dr. Matthias St. Pierre]

+1

> -Original Message-
> From: otc  On Behalf Of Tomas Mraz
> Sent: Tuesday, November 2, 2021 12:01 PM
> To: openssl-project@openssl.org
> Cc: OTC 
> Subject: Re: OTC VOTE: Accept Policy change process proposal
> 
> There are already enough votes to close this one, so I intend to close
> the vote tomorrow.
> 
> Tomas
> 
> 
> On Mon, 2021-11-01 at 11:23 +0100, Tomas Mraz wrote:
> > topic: Accept openssl/technical-policies PR#1 - the policy change
> > process proposal as of commit 3bccdf6. This will become an official
> > OTC
> > policy.
> >
> > comment: This will implement the formal policy change process so we
> > can
> > introduce and amend further policies as set by OTC via a public
> > process.
> >
> > Proposed by Tomáš Mráz
> > Public: yes
> > opened: 2021-11-01
> > closed: 2021-mm-dd
> > accepted:  yes/no  (for: X, against: Y, abstained: Z, not voted: T)
> >
> >    Dmitry [  ]
> >    Matt   [  ]
> >    Pauli  [  ]
> >    Tim    [  ]
> >    Richard    [  ]
> >    Shane  [  ]
> >    Tomas  [+1]
> >    Kurt   [  ]
> >    Matthias   [  ]
> >    Nicola [  ]
> >
> >
> >
> 
> --
> 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.]
> 
> 
> ___
> otc mailing list
> o...@openssl.org
> https://mta.openssl.org/mailman/listinfo/otc


smime.p7s
Description: S/MIME cryptographic signature

RE: OTC vote: include Keccak digests in OpenSSL

[Dr. Matthias St. Pierre]

+1

Note: please use the vote topic (as stated in votes.txt) as the mail subject 
line to avoid confusion for late voters

> -Original Message-
> From: openssl-project  On Behalf Of Dr 
> Paul Dale
> Sent: Tuesday, September 21, 2021 11:15 AM
> To: openssl-project@openssl.org
> Subject: OTC vote: include Keccak digests in OpenSSL
> 
> Accept PR#16594 into master subject to the normal review process
> 
> 
> 
> This doesn't meet the "is a standard" requirement but it is in use and
> we have the implementation.  It just isn't exposed.
> 
>    Dmitry [+1]
>    Matt   [ 0]
>    Pauli  [+1]
>    Tim    [+0]
>    Richard    [+1]
>    Shane  [+1]
>    Tomas  [+1]
>    Kurt   [  ]
>    Matthias   [  ]
>    Nicola [+0]
> 
> 
> The vote passed.



smime.p7s
Description: S/MIME cryptographic signature

RE: OTC VOTE: RSA public exponent validation in 3.0

[Dr. Matthias St. Pierre]

-1

> -Original Message-
> From: openssl-project  On Behalf Of Matt 
> Caswell
> Sent: Tuesday, August 10, 2021 12:54 PM
> To: openssl-project@openssl.org
> Subject: OTC VOTE: RSA public exponent validation in 3.0
> 
> topic: RSA public exponent validation in 3.0 for the default provider
> should be
> consistent with 1.1.1
> Comment: See issue #16255 for background
> Proposed by Matt Caswell
> Public: yes
> opened: 2021-08-10
> closed: 2021-mm-dd
> accepted:  yes/no  (for: X, against: Y, abstained: Z, not voted: T)
> 
>Dmitry [ 0]
>Matt   [+1]
>Pauli  [  ]
>Tim[+1]
>Richard[  ]
>Shane  [+1]
>Tomas  [+1]
>Kurt   [  ]
>Matthias   [  ]
>Nicola [-0]



smime.p7s
Description: S/MIME cryptographic signature

RE: OTC VOTE: Revert the commits merged from PR #16027 in 1.1.1

[Dr. Matthias St. Pierre]

+1

> -Original Message-
> From: openssl-project  On Behalf Of Matt 
> Caswell
> Sent: Tuesday, August 10, 2021 12:53 PM
> To: openssl-project@openssl.org
> Subject: OTC VOTE: Revert the commits merged from PR #16027 in 1.1.1
> 
> topic: Revert the commits merged from PR #16027 in 1.1.1
> Comment: Refer to issue #16266 for background
> Proposed by Tomas Mraz
> Public: yes
> opened: 2021-08-10
> closed: 2021-mm-dd
> accepted:  yes/no  (for: X, against: Y, abstained: Z, not voted: T)
> 
>Dmitry [+1]
>Matt   [+1]
>Pauli  [  ]
>Tim[-1]
>Richard[  ]
>Shane  [-1]
>Tomas  [+1]
>Kurt   [  ]
>Matthias   [  ]
>Nicola [-1]



smime.p7s
Description: S/MIME cryptographic signature

RE: OTC quick votes [WAS: RE: OTC vote PR #16171: config_diagnostic]

[Dr. Matthias St. Pierre]

You probably all noticed my mistake: I meant to say 'quorum', not 'quota'.

Matthias

> -Original Message-
> From: openssl-project  On Behalf Of Dr. 
> Matthias St. Pierre
> Sent: Tuesday, August 3, 2021 9:26 PM
> To: Kurt Roeckx ; Dr Paul Dale 
> Cc: openssl-project@openssl.org
> Subject: OTC quick votes [WAS: RE: OTC vote PR #16171: config_diagnostic]
>
> > I'm starting to vote -1 on anything has a vote text that looks like that, 
> > so -1.
>
> I perfectly understand Kurt's dislike of this kind of votes. The text is not 
> very informative for OTC members who
> weren't able to participate at the weekly video meetings.
>
> IMHO it proves that the current voting mechanism does not scale well with the 
> number of decisions that have to be made.
> The rate of those decision has increased heavily during the final phase of 
> the 3.0 development and the weekly video meetings
> were an attempt to improve agility and get those decisions made. On the other 
> side, the voting scheme has remained unchanged,
> mailing '+-1' replies to the mailing list within a certain time interval and 
> recording them arduously in a GitHub repository.
>
> Maybe we need to overthink the online voting rules and optimize them 
> slightly. For example, we could require an online
> quota in which case the online votes can be held immediately, but they would 
> need to be documented properly with
> a meaningful subject line and ideally also a rationale. We could switch to 
> publishing meeting protocols which document all
> online votes properly, including the rationale. Maybe those online votes 
> could be excluded from the official participation count
> mentioned in the bylaws as indicator for OTC activity.
>
> These are just some wild thoughts for the moment. I doubt we will have time 
> to discuss it in detail before the final 3.0 release.
> But maybe it would be a good subject for the next OTC face-to-face meeting.
>
> Matthias
>
>
> > -Original Message-
> > From: otc  On Behalf Of Kurt Roeckx
> > Sent: Tuesday, August 3, 2021 6:36 PM
> > To: Dr Paul Dale 
> > Cc: o...@openssl.org
> > Subject: Re: OTC vote PR #16171: config_diagnostic
> >
> > On Tue, Aug 03, 2021 at 07:03:14PM +1000, Dr Paul Dale wrote:
> > > topic: Accept PR 16171 in 3.0 subject to our normal review process.
> >
> > I'm starting to vote -1 on anything has a vote text that looks
> > like that, so -1.
> >
> > This is also send to the wrong list.
> >
> >
> > Kurt
> >
> > ___
> > otc mailing list
> > o...@openssl.org
> > https://mta.openssl.org/mailman/listinfo/otc

smime.p7s
Description: S/MIME cryptographic signature

RE: OTC vote on accepting #16203: TLS 1.3 KDF

[Dr. Matthias St. Pierre]

0

From: openssl-project  On Behalf Of Dr 
Paul Dale
Sent: Tuesday, August 3, 2021 11:03 AM
To: openssl-project@openssl.org
Subject: OTC vote on accepting #16203: TLS 1.3 KDF

Accept PR 16203 in 3.0 subject 
to our normal review process.

This one is still undergoing early review.


Pauli


smime.p7s
Description: S/MIME cryptographic signature

RE: OTC vote on accepting #16171: config_diagnostic

[Dr. Matthias St. Pierre]

0

From: openssl-project  On Behalf Of Dr 
Paul Dale
Sent: Tuesday, August 3, 2021 11:03 AM
To: openssl-project@openssl.org
Subject: OTC vote on accepting #16171: config_diagnostic

Accept PR 16171 in 3.0 subject 
to our normal review process.

Pauli


smime.p7s
Description: S/MIME cryptographic signature

OTC quick votes [WAS: RE: OTC vote PR #16171: config_diagnostic]

[Dr. Matthias St. Pierre]

> I'm starting to vote -1 on anything has a vote text that looks like that, so 
> -1.

I perfectly understand Kurt's dislike of this kind of votes. The text is not 
very informative for OTC members who
weren't able to participate at the weekly video meetings.

IMHO it proves that the current voting mechanism does not scale well with the 
number of decisions that have to be made.
The rate of those decision has increased heavily during the final phase of the 
3.0 development and the weekly video meetings
were an attempt to improve agility and get those decisions made. On the other 
side, the voting scheme has remained unchanged,
mailing '+-1' replies to the mailing list within a certain time interval and 
recording them arduously in a GitHub repository.

Maybe we need to overthink the online voting rules and optimize them slightly. 
For example, we could require an online
quota in which case the online votes can be held immediately, but they would 
need to be documented properly with
a meaningful subject line and ideally also a rationale. We could switch to 
publishing meeting protocols which document all
online votes properly, including the rationale. Maybe those online votes could 
be excluded from the official participation count
mentioned in the bylaws as indicator for OTC activity.

These are just some wild thoughts for the moment. I doubt we will have time to 
discuss it in detail before the final 3.0 release.
But maybe it would be a good subject for the next OTC face-to-face meeting.

Matthias


> -Original Message-
> From: otc  On Behalf Of Kurt Roeckx
> Sent: Tuesday, August 3, 2021 6:36 PM
> To: Dr Paul Dale 
> Cc: o...@openssl.org
> Subject: Re: OTC vote PR #16171: config_diagnostic
>
> On Tue, Aug 03, 2021 at 07:03:14PM +1000, Dr Paul Dale wrote:
> > topic: Accept PR 16171 in 3.0 subject to our normal review process.
>
> I'm starting to vote -1 on anything has a vote text that looks
> like that, so -1.
>
> This is also send to the wrong list.
>
>
> Kurt
>
> ___
> otc mailing list
> o...@openssl.org
> https://mta.openssl.org/mailman/listinfo/otc

smime.p7s
Description: S/MIME cryptographic signature

RE: OTC VOTE: Accept PR 16128

[Dr. Matthias St. Pierre]

+1

> -Original Message-
> From: openssl-project  On Behalf Of 
> Tomas Mraz
> Sent: Thursday, July 22, 2021 3:06 PM
> To: openssl-project@openssl.org
> Subject: Re: OTC VOTE: Accept PR 16128
> 
> +1 it is a safe change and it improves consistency
> 
> On Thu, 2021-07-22 at 13:51 +0100, Matt Caswell wrote:
> > topic: Accept PR 16128 in 3.0 subject to our normal review process
> > Proposed by Matt Caswell
> > Public: yes
> > opened: 2021-07-22
> > closed: 2021-mm-dd
> > accepted:  yes/no  (for: X, against: Y, abstained: Z, not voted: T)
> >
> >    Matt   [+1]
> >    Pauli  [  ]
> >    Tim    [  ]
> >    Richard    [  ]
> >    Shane  [  ]
> >    Tomas  [  ]
> >    Kurt   [  ]
> >    Matthias   [  ]
> >    Nicola [  ]
> 
> --
> 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.]



smime.p7s
Description: S/MIME cryptographic signature

RE: VOTE: 3.0 beta1 readiness

[Dr. Matthias St. Pierre]

+1

> -Original Message-
> From: openssl-project  On Behalf Of Matt 
> Caswell
> Sent: Tuesday, June 15, 2021 11:53 AM
> To: openssl-project@openssl.org
> Subject: VOTE: 3.0 beta1 readiness
> 
> topic: OTC approve the release of 3.0 beta1 on Thursday 17th June on the
> basis
> that: 1) all current approved PRs with the beta1 milestone are
> merged
> 2) issues #15755 and #15756 are resolved 3) We accept that VMS
> does not
> currently pass tests but expect it to do so before 3.0 final (issue
> #15757)
> Proposed by Matt Caswell
> Public: yes
> opened: 2021-06-15
> closed: 2021-06-15
> accepted:  yes  (for: 7, against: 0, abstained: 0, not voted: 2)
> 
>Matt   [+1]
>Pauli  [+1]
>Tim[+1]
>Richard[+1]
>Shane  [+1]
>Tomas  [+1]
>Kurt   [  ]
>Matthias   [  ]
>Nicola [+1]



smime.p7s
Description: S/MIME cryptographic signature

RE: OTC Vote: Remove the RSA_SSLV23_PADDING and related functions completely

[Dr. Matthias St. Pierre]

+1

> -Original Message-
> From: openssl-project  On Behalf Of 
> Tomas Mraz
> Sent: Tuesday, February 23, 2021 11:26 AM
> To: openssl-project@openssl.org
> Subject: Re: OTC Vote: Remove the RSA_SSLV23_PADDING and related functions 
> completely
> 
> +1 from me of course
> 
> On Tue, 2021-02-23 at 11:21 +0100, Tomas Mraz wrote:
> > topic: The RSA_SSLV23_PADDING and related functions should be
> > completely removed from OpenSSL 3.0 code.
> >
> > comment: The padding mode and the related functions (which are
> > already
> > deprecated in the current master branch) is useless outside of SSLv2
> > support. We do not support SSLv2 and we do not expect anybody using
> > OpenSSL 3.0 to try to support SSLv2 by calling those functions.
> >
> > Proposed by Tomas Mraz.
> >
> > public: yes
> > opened: 2021-02-23
> >
> >
> >
> 



smime.p7s
Description: S/MIME cryptographic signature

RE: OTC Vote: EVP init functions should accept an OSSL_PARAM array to set parameters.

[Dr. Matthias St. Pierre]

+1

I recall that in our discussion the OSSL_PARAM array pointer was intended to be 
optional,
i.e., NULL pointers allowed. Maybe the word 'optional' should be added as 
follows?

   EVP init functions should accept an *optional* OSSL_PARAM array to set 
parameters.


> -Original Message-
> From: openssl-project  On Behalf Of Dr 
> Paul Dale
> Sent: Tuesday, February 2, 2021 10:18 AM
> To: openssl-project@openssl.org
> Subject: OTC Vote: EVP init functions should accept an OSSL_PARAM array to 
> set parameters.
> 
> topic: EVP init functions should accept an OSSL_PARAM array to set
> parameters.
> comment: This will mostly avoid calling the equivalent set_param call.
> Proposed by pauli.
> Public: yes
> opened: 2020-02-02
> closed: 2020-02-02
> accepted:  yes  (for: 8, against: 0, abstained: 1, not voted: 2)


smime.p7s
Description: S/MIME cryptographic signature

RE: OTC VOTE: functions not conforming to the TYPE_NAME_action_name naming scheme are defects

[Dr. Matthias St. Pierre]

+1

> -Original Message-
> From: openssl-project  On Behalf Of Dr 
> Paul Dale
> Sent: Tuesday, February 2, 2021 10:07 AM
> To: openssl-project@openssl.org
> Subject: OTC VOTE: functions not conforming to the TYPE_NAME_action_name 
> naming scheme are defects
> 
> topic: Where a function does not use the TYPE_NAME_action_name naming
> scheme,
>     it is considered to be a defect.
> comment: These are not considered blockers for 3.0 if the function
> existed in
>   1.1.1.  New functions that do not conform must be fixed before
> release.
> Proposed by pauli.
> Public: yes
> opened: 2020-02-02
> closed: 2020-02-02
> accepted:  yes  (for: 5, against: 0, abstained: 3, not voted: 3)


smime.p7s
Description: S/MIME cryptographic signature

RE: OTC Vote: Moving forwards we will use TYPE_NAME_action_name for function names.

[Dr. Matthias St. Pierre]

+1

> -Original Message-
> From: openssl-project  On Behalf Of Dr 
> Paul Dale
> Sent: Tuesday, February 2, 2021 9:52 AM
> To: openssl-project@openssl.org
> Subject: OTC Vote: Moving forwards we will use TYPE_NAME_action_name for 
> function names.
> 
> topic: Moving forwards we will use TYPE_NAME_action_name for function names.
> comment: Not camel case, underscores separating words.  I.e. EVP_MAC_update
>   not EVP_MACUpdate or EVP_MAC_Update.
> Proposed by pauli.
> Public: yes
> opened: 2020-02-02
> closed: 2020-02-02
> accepted:  yes  (for: 7, against: 0, abstained: 1, not voted: 3)



smime.p7s
Description: S/MIME cryptographic signature

RE: OTC VOTE: Keeping API compatibility with missing public key

[Dr. Matthias St. Pierre]

+1

> -Original Message-
> From: openssl-project  On Behalf Of Matt 
> Caswell
> Sent: Monday, December 7, 2020 10:46 AM
> To: openssl-project@openssl.org
> Subject: Re: OTC VOTE: Keeping API compatibility with missing public key
> 
> +1
> 
> On 04/12/2020 12:45, Tomas Mraz wrote:
> > Vote background
> > ---
> >
> > The vote on relaxing the conceptual model in regards to required public
> > component for EVP_PKEY has passed with the following text:
> >
> > For 3.0 EVP_PKEY keys, the OTC accepts the following resolution:
> > * relax the conceptual model to allow private keys to exist without
> > public components;
> > * all implementations apart from EC require the public component to be
> > present;
> > * relax implementation for EC key management to allow private keys that
> > do not contain public keys and
> > * our decoders unconditionally generate the public key (where
> > possible).
> >
> > However since then the issue 13506 [1] was reported.
> >
> > During OTC meeting we concluded that we might need to relax also other
> > public key algorithm implementations to allow private keys without
> > public component.
> >
> > Vote
> > 
> >
> > topic: For 3.0 EVP_PKEY keys all algorithm implementations that were usable
> >with 1.1.1 EVP_PKEY API or low level APIs without public component 
> > must
> >stay usable.
> >
> >This overrules the
> >  * all implementations apart from EC require the public component 
> > to be present;
> >part of the vote closed on 2020-11-17.
> >
> > Proposed by Tomas Mraz
> > Public: yes
> > opened: 2020-12-04
> >
> > Tomas Mraz
> >
> >



smime.p7s
Description: S/MIME cryptographic signature

RE: OTC VOTE: Fixing missing failure exit status is a bug fix

[Dr. Matthias St. Pierre]

+1

> -Original Message-
> From: openssl-project  On Behalf Of 
> Nicola Tuveri
> Sent: Monday, November 30, 2020 1:03 PM
> To: OpenSSL Project 
> Subject: OTC VOTE: Fixing missing failure exit status is a bug fix
> 
> Vote background
> ---
> 
> This follows up on a [previous proposal] that was abandoned in favor of
> an OMC vote on the behavior change introduced in [PR#13359].
> Within today's OTC meeting this was further discussed with the attending
> members that also sit in the OMC.
> 
> The suggestion was to improve the separation of the OTC and OMC domains
> here, by having a more generic OTC vote to qualify as bug fixes the
> changes to let any OpenSSL app return an (early) failure exit status
> when a called function fails.
> 
> The idea is that, if we agree on this technical definition, then no OMC
> vote to allow a behavior change in the apps would be required in
> general, unless, on a case-by-case basis, the "OMC hold" process is
> invoked for whatever reason on the specific bug fix, triggering the
> usual OMC decision process.
> 
> [previous proposal]:
> 
> [PR#13359]: 
> 
> 
> 
> Vote text
> -
> 
> topic: In the context of the OpenSSL apps, the OTC qualifies as bug
>fixes the changes to return a failure exit status when a called
>function fails with an unhandled return value.
>Even when these bug fixes change the apps behavior triggering
>early exits (compared to previous versions of the apps), as bug
>fixes, they do not qualify as behavior changes that require an
>explicit OMC approval.
> Proposed by Nicola Tuveri
> Public: yes
> opened: 2020-11-30



smime.p7s
Description: S/MIME cryptographic signature

RE: OpenSSL Cookbook is being updated soon

[Dr. Matthias St. Pierre]

typo: “your user base” -> “our user base”

From: openssl-project  On Behalf Of Dr. 
Matthias St. Pierre
Sent: Monday, November 16, 2020 9:08 PM
To: Ivan Ristic ; openssl-project@openssl.org
Subject: RE: OpenSSL Cookbook is being updated soon

Ivan,

thank you very much for giving us the opportunity to preview your next 
publication of the OpenSSL cookbook. Even if your mail was unanswered (until 
know), I’m sure your announcement did not go unnoticed.

I would like to take the opportunity to thank you for your continuous efforts 
during the past years to provide the OpenSSL community with an excellent 
introduction to the OpenSSL command line tool. It has always been available as 
a free download and is a valuable source of information for your user base. And 
it’s excellent news that there is an update coming. Enough reasons IMHO to 
propose you as an “OpenSSL Team member h.c.” if such a role would already exist 
in our bylaws (maybe we should add it 😉).

Regards,

Matthias

@openssl/committers: please take the time to take a look at the preprint and 
provide your feedback.


From: openssl-project 
mailto:openssl-project-boun...@openssl.org>>
 On Behalf Of Ivan Ristic
Sent: Friday, November 6, 2020 11:29 AM
To: openssl-project@openssl.org<mailto:openssl-project@openssl.org>
Subject: OpenSSL Cookbook is being updated soon

Apologies for starting a new thread, but I had no previous message to reply to. 
Matt alerted me to the mention of OpenSSL Cookbook here and I was previously 
not on this list.

I am committed to maintaining OpenSSL Cookbook. In fact, we've just completed 
the 3rd edition. This time I had Matt help me as a technical reviewer and that 
led to many improvements. We're currently updating our web site and will 
release the new edition as soon as that's done.

The 3rd edition required many changes because of TLS 1.3. Now that it's done, 
going forward I will aim for continuous updates as needed.

Additionally, we wish to make the content more useful by splitting it into 
smaller chunks. At the moment, it's presented as one page per chapter, which is 
not ideal. We will look into this at some point after the release.

If you'd like to see the 3rd edition before it's officially out, you can 
actually get it immediately by registering for an account here 
https://www.feistyduck.com/account/register If you already have an account, it 
should be offered to you at the bottom of the library page 
https://www.feistyduck.com/library/ I would certainly welcome any thoughts 
about the content and the possible improvements. The scope is generally 
command-line usage.

--
Ivan


smime.p7s
Description: S/MIME cryptographic signature

RE: OpenSSL Cookbook is being updated soon

[Dr. Matthias St. Pierre]

Ivan,

thank you very much for giving us the opportunity to preview your next 
publication of the OpenSSL cookbook. Even if your mail was unanswered (until 
know), I’m sure your announcement did not go unnoticed.

I would like to take the opportunity to thank you for your continuous efforts 
during the past years to provide the OpenSSL community with an excellent 
introduction to the OpenSSL command line tool. It has always been available as 
a free download and is a valuable source of information for your user base. And 
it’s excellent news that there is an update coming. Enough reasons IMHO to 
propose you as an “OpenSSL Team member h.c.” if such a role would already exist 
in our bylaws (maybe we should add it 😉).

Regards,

Matthias

@openssl/committers: please take the time to take a look at the preprint and 
provide your feedback.


From: openssl-project  On Behalf Of Ivan 
Ristic
Sent: Friday, November 6, 2020 11:29 AM
To: openssl-project@openssl.org
Subject: OpenSSL Cookbook is being updated soon

Apologies for starting a new thread, but I had no previous message to reply to. 
Matt alerted me to the mention of OpenSSL Cookbook here and I was previously 
not on this list.

I am committed to maintaining OpenSSL Cookbook. In fact, we've just completed 
the 3rd edition. This time I had Matt help me as a technical reviewer and that 
led to many improvements. We're currently updating our web site and will 
release the new edition as soon as that's done.

The 3rd edition required many changes because of TLS 1.3. Now that it's done, 
going forward I will aim for continuous updates as needed.

Additionally, we wish to make the content more useful by splitting it into 
smaller chunks. At the moment, it's presented as one page per chapter, which is 
not ideal. We will look into this at some point after the release.

If you'd like to see the 3rd edition before it's officially out, you can 
actually get it immediately by registering for an account here 
https://www.feistyduck.com/account/register If you already have an account, it 
should be offered to you at the bottom of the library page 
https://www.feistyduck.com/library/ I would certainly welcome any thoughts 
about the content and the possible improvements. The scope is generally 
command-line usage.

--
Ivan


smime.p7s
Description: S/MIME cryptographic signature

RE: OTC VOTE: EVP_PKEY private/public key components

[Dr. Matthias St. Pierre]

0

> -Original Message-
> From: openssl-project  On Behalf Of Matt 
> Caswell
> Sent: Tuesday, November 3, 2020 1:11 PM
> To: openssl-project@openssl.org
> Subject: OTC VOTE: EVP_PKEY private/public key components
> 
> Background to the vote:
> 
> The OTC meeting today discussed the problems raised by issue #12612. In
> summary the problem is that there has been a long standing, widespread
> and documented assumption that an EVP_PKEY with a private key will
> always also have the public key component.
> 
> In spite of this it turns out that in the EC implementation in 1.1.1 it
> was perfectly possible to create an EVP_PKEY with only a private key and
> no public key - and it was also possible to use such an EVP_PKEY in a
> signing operation.
> 
> The current 3.0 code in master introduced an explicit check (in line
> with the long held assumption) that the public key was present and
> rejected keys where this was not the case. This caused a backwards
> compatibility break for some users (as discussed at length in #12612).
> 
> The OTC discussed a proposal that we should relax our conceptual model
> in this regards and conceptually allow EVP_PKEYs to exist that only have
> the private component without the public component - although individual
> algorithm implementations may still require both.
> 
> It is possible to automatically generate the public component from the
> private for many algorithms, although this may come at a performance and
> (potentially) a security cost.
> 
> The proposal discussed was that while relaxing the conceptual model,
> most of the existing implementations would still require both. The EC
> implementation would be relaxed however. This essentially gives largely
> compatible behaviour between 1.1.1 and 3.0.
> 
> The vote text is as follows:
> 
> topic: For 3.0 EVP_PKEY keys, the OTC accepts the following resolution:
> * relax the conceptual model to allow private keys to exist without public
>   components;
> * all implementations apart from EC require the public component to be
> present;
> * relax implementation for EC key management to allow private keys that
> do not
>   contain public keys and
> * our decoders unconditionally generate the public key (where possible).
> 
> Proposed by Matt Caswell
> Public: yes
> opened: 2020-11-03
> closed: 2020-mm-dd
> accepted:  yes/no  (for: X, against: Y, abstained: Z, not voted: T)
> 
>   Matt   [+1]
>   Mark   [  ]
>   Pauli  [+1]
>   Viktor [  ]
>   Tim[  ]
>   Richard[+1]
>   Shane  [+1]
>   Tomas  [+1]
>   Kurt   [  ]
>   Matthias   [  ]
>   Nicola [-1]



smime.p7s
Description: S/MIME cryptographic signature

RE: Hacktoberfest

[Dr. Matthias St. Pierre]

Given the fact that only one person asked for it and that only ten days are 
left in October,
I think the label solution might be the simpler one for the moment. (Assuming 
that adding
Topics to the project requires a vote?) The label has already been created and 
is ready
to be applied, to make the person happy which asked for it. In November, the 
label can
be removed again.

[cid:image003.png@01D6A77C.74236BB0]

In general, I agree that GitHub Topics are a better solution. If we decide to 
participate
officially next year, we should take the time to inform ourselves in advance 
and announce
our participation in form of a blog post (I volunteer). Also, GitHub Topics 
should be discussed
in more generality, i.e.,  what's our benefit of using GitHub Topics, and which 
topics we
should add to the project. Up to yesterday, I didn't give GitHub Topics much 
thought.

Matthias


From: openssl-project  On Behalf Of Dr 
Paul Dale
Sent: Wednesday, October 21, 2020 5:31 AM
To: openssl-project@openssl.org
Subject: Hacktoberfest

There has been a request in 
#13172 to tag the PR for 
Hacktoberfest.
There are two ways 
to do this: add a tag to the PR or a topic to the project.

Is either something the project is interested in doing?

Rather than polluting our already busy tags menu, the topic seems the easier 
path to me.


Pauli
--
Dr Paul Dale | Distinguished Architect | Cryptographic Foundations
Phone +61 7 3031 7217
Oracle Australia

Assigning OpenSSL 3.0.0 beta1 issues

[Dr. Matthias St. Pierre]

A lot of GitHub issues were created by Nicola (@romen) today to keep track of 
the
[Technical Items still to be done][tbd] list. On the same occasion, we assigned
some of the tasks internally. For more transparency, I converted the assignments
on the internal spreadsheet into GitHub assignments of the corresponding [beta1 
issues].

Note that there remain a lot of [unassigned beta1 issues].

Matthias


[tbd]:
https://www.mail-archive.com/openssl-project@openssl.org/msg02141.html
[beta1 issues]:

https://github.com/openssl/openssl/issues?q=is%3Aopen+is%3Aissue+milestone%3A%223.0.0+beta1%22
[unassigned beta1 issues]:

https://github.com/openssl/openssl/issues?q=is%3Aopen+is%3Aissue+milestone%3A%223.0.0+beta1%22+no%3Aassignee

RE: VOTE: Weekly OTC meetings until 3.0 beta1 is released

[Dr. Matthias St. Pierre]

+1

> -Original Message-
> From: openssl-project  On Behalf Of Mark 
> J Cox
> Sent: Saturday, October 10, 2020 9:34 AM
> To: openssl-project@openssl.org
> Subject: Re: VOTE: Weekly OTC meetings until 3.0 beta1 is released
> 
> +1
> 
> On Fri, Oct 9, 2020 at 1:03 PM Tomas Mraz  wrote:
> >
> > +1
> >
> > On Fri, 2020-10-09 at 15:00 +0300, Nicola Tuveri wrote:
> > > topic: Hold online weekly OTC meetings starting on Tuesday 2020-10-13
> > >and until 3.0 beta1 is released, in lieu of the weekly
> > > "developer
> > >meetings".
> > > Proposed by Nicola Tuveri
> > > Public: yes
> > > opened: 2020-10-09
> > > closed: 2020-mm-dd
> > > accepted:  yes/no  (for: X, against: Y, abstained: Z, not voted: T)
> > >
> > >   Matt   [  ]
> > >   Mark   [  ]
> > >   Pauli  [  ]
> > >   Viktor [  ]
> > >   Tim[  ]
> > >   Richard[  ]
> > >   Shane  [  ]
> > >   Tomas  [  ]
> > >   Kurt   [  ]
> > >   Matthias   [  ]
> > >   Nicola [+1]
> > --
> > 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.]
> >
> >

RE: OTC VOTE: The PR #11359 (Allow to continue with further checks on UNABLE_TO_VERIFY_LEAF_SIGNATURE) is acceptable for 1.1.1 branch

[Dr. Matthias St. Pierre]

0

> -Original Message-
> From: openssl-project  On Behalf Of 
> Tomas Mraz
> Sent: Friday, October 9, 2020 2:02 PM
> To: openssl-project@openssl.org
> Subject: OTC VOTE: The PR #11359 (Allow to continue with further checks on 
> UNABLE_TO_VERIFY_LEAF_SIGNATURE) is acceptable for
> 1.1.1 branch
> 
> topic: The PR #11359 (Allow to continue with further checks on
>  UNABLE_TO_VERIFY_LEAF_SIGNATURE) is acceptable for 1.1.1 branch
> As the change is borderline on bug fix/behaviour change OTC needs
> to decide whether it is acceptable for 1.1.1 branch.
> Proposed by Tomas Mraz
> Public: yes
> opened: 2020-10-09
> closed: 2020-mm-dd
> accepted:  yes/no  (for: X, against: Y, abstained: Z, not voted: T)
> 
>   Matt   [  ]
>   Mark   [  ]
>   Pauli  [  ]
>   Viktor [  ]
>   Tim[  ]
>   Richard[  ]
>   Shane  [  ]
>   Tomas  [+1]
>   Kurt   [  ]
>   Matthias   [  ]
>   Nicola [  ]
> 
> --
> 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.]

RE: VOTE: Technical Items still to be done

[Dr. Matthias St. Pierre]

+1

> -Original Message-
> From: openssl-project  On Behalf Of 
> Tomas Mraz
> Sent: Thursday, October 8, 2020 6:21 PM
> To: Matt Caswell ; openssl-project@openssl.org
> Subject: Re: VOTE: Technical Items still to be done
> 
> +1
> 
> On Thu, 2020-10-08 at 15:47 +0100, Matt Caswell wrote:
> > topic: The following items are required prerequisites for the first
> > beta
> > release:
> >  1) EVP is the recommended API, it must be feature-complete compared
> > with
> > the functionality available using lower-level APIs.
> >- Anything that isn’t available must be put to an OTC vote to
> > exclude.
> >- The apps are the minimum bar for this, subject to exceptions
> > noted
> > below.
> >  2) Deprecation List Proposal: DH_, DSA_, ECDH_, ECDSA_, EC_KEY_,
> > RSA_,
> > RAND_METHOD_.
> >- Does not include macros defining useful constants (e.g.
> >  SHA512_DIGEST_LENGTH).
> >- Excluded from Deprecation: `EC_`, `DSA_SIG_`, `ECDSA_SIG_`.
> >- There might be some others.
> >- Review for exceptions.
> >- The apps are the minimum bar to measure feature completeness for
> > the EVP
> >  interface: rewrite them so they do not use internal nor
> > deprecated
> >  functions (except speed, engine, list, passwd -crypt and the
> > code
> > to handle
> >  the -engine CLI option).  That is, remove the suppression of
> > deprecated
> >  define.
> >  - Proposal: drop passwd -crypt (OMC vote required)
> >- Compile and link 1.1.1 command line app against the master
> > headers and
> >  library.  Run 1.1.1 app test cases against the chimera.  Treat
> > this
> > as an
> >  external test using a special 1.1.1 branch. Deprecated functions
> > used by
> >  libssl should be moved to independent file(s), to limit the
> > suppression of
> >  deprecated defines to the absolute minimum scope.
> >  3) Draft documentation (contents but not pretty)
> >- Need a list of things we know are not present - including things
> > we
> > have
> >  removed.
> >- We need to have mapping tables for various d2i/i2d functions.
> >- We need to have a mapping table from “old names” for things into
> > the
> >  OSSL_PARAMS names.
> >  - Documentation addition to old APIs to refer to new ones
> > (man7).
> >  - Documentation needs to reference name mapping.
> >  - All the legacy interfaces need to have their documentation
> > pointing to
> >the replacement interfaces.
> >  4) Review (and maybe clean up) legacy bridge code.
> >  5) Review TODO(3.0) items #12224.
> >  6) Source checksum script.
> >  7) Review of functions previously named _with_libctx.
> >  8) Encoder fixes (PKCS#8, PKCS#1, etc).
> >  9) Encoder DER to PEM refactor.
> > 10) Builds and passes tests on all primary, secondary and FIPS
> > platforms.
> > 11) Query provider parameters (name, version, ...) from the command
> > line.
> > 12) Setup buildbot infrastructure and associated instructions.
> > 13) Complete make fipsinstall.
> > 14) More specific decoding selection (e.g. params or keys).
> > 15) Example code covering replacements for deprecated APIs.
> > 16) Drop C code output options from the apps (OMC approval required).
> > 17) Address issues and PRs in the 3.0beta1 milestone.
> > Proposed by .
> > Public: yes
> > opened: 2020-10-08
> > closed: 2020-mm-dd
> > accepted:  yes/no  (for: X, against: Y, abstained: Z, not voted: T)
> >
> >   Matt   [+1]
> >   Mark   [  ]
> >   Pauli  [  ]
> >   Viktor [  ]
> >   Tim[  ]
> >   Richard[  ]
> >   Shane  [  ]
> >   Tomas  [  ]
> >   Kurt   [  ]
> >   Matthias   [  ]
> >   Nicola [  ]
> --
> 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.]

RE: VOTE: Accept the Fully Pluggable TLSv1.3 KEM functionality

[Dr. Matthias St. Pierre]

+1

> -Original Message-
> From: openssl-project  On Behalf Of Matt 
> Caswell
> Sent: Thursday, October 8, 2020 4:27 PM
> To: openssl-project@openssl.org
> Subject: VOTE: Accept the Fully Pluggable TLSv1.3 KEM functionality
> 
> topic: We should accept the Fully Pluggable TLSv1.3 KEM functionality as
> shown in PR #13018 into the 3.0 release
> Proposed by Matt Caswell
> Public: yes
> opened: 2020-10-08
> closed: 2020-mm-dd
> accepted:  yes/no  (for: X, against: Y, abstained: Z, not voted: T)
> 
>   Matt   [+1]
>   Mark   [  ]
>   Pauli  [  ]
>   Viktor [  ]
>   Tim[  ]
>   Richard[  ]
>   Shane  [  ]
>   Tomas  [  ]
>   Kurt   [  ]
>   Matthias   [  ]
>   Nicola [  ]

RE: Would this be interesting to the project?

[Dr. Matthias St. Pierre]

> Do you have ideas on how to properly set it up?

Congratulations, Dmitry! You just won the price of being assigned the job to 
figure it out.  ;-)

Matthias

From: openssl-project  On Behalf Of Dmitry 
Belyavsky
Sent: Friday, October 2, 2020 2:51 PM
To: Dr Paul Dale 
Cc: openssl-project@openssl.org
Subject: Re: Would this be interesting to the project?

Do you have ideas on how to properly set it up?

On Thu, Oct 1, 2020 at 11:36 AM Dr Paul Dale 
mailto:paul.d...@oracle.com>> wrote:
https://github.blog/2020-09-30-code-scanning-is-now-available/

Pauli
--
Dr Paul Dale | Distinguished Architect | Cryptographic Foundations
Phone +61 7 3031 7217
Oracle Australia






--
SY, Dmitry Belyavsky

RE: VOTE: OTC meeting will be called for next Tuesday

[Dr. Matthias St. Pierre]

> +1, but wondering why this needs a vote.

Because we decided to follow our own bylaws more closely. In particular the 
following two items:

> All OTC decisions are taken on the basis of a vote
https://www.openssl.org/policies/omc-bylaws.html#OTC

> ### OTC Transparency
> The majority of the activity of the OTC will take place in public.
https://www.openssl.org/policies/omc-bylaws.html#transparency


Matthias



> -Original Message-
> From: Kurt Roeckx 
> Sent: Wednesday, September 30, 2020 6:07 PM
> To: Dr. Matthias St. Pierre 
> Cc: openssl-project@openssl.org
> Subject: Re: VOTE: OTC meeting will be called for next Tuesday
> 
> On Wed, Sep 30, 2020 at 01:57:34PM +, Dr. Matthias St. Pierre wrote:
> > topic: OTC meeting will be called for next Tuesday
> 
> 
> 
> Kurt
> 

VOTE: OTC meeting will be called for next Tuesday

[Dr. Matthias St. Pierre]

The following vote has been proposed and voted on at the vF2F today:

topic: OTC meeting will be called for next Tuesday

It has been closed immediately by Tim, the verdict is

accepted:  yes  (for: 7, against: 0, abstained: 0, not voted: 4)

(Note: the OTC meeting will be held in place of the weekly OpenSSL 3.0 Planning
meeting next Tuesday (2020-10-06) at 08:00 UTC. Pauli will send out a separate
invitation to the OTC list.)

Matthias


topic: OTC meeting will be called for next Tuesday (2020-10-06)
Proposed by Matthias St. Pierre
Public: yes
opened: 2020-09-30
closed: 2020-09-30
accepted:  yes  (for: 7, against: 0, abstained: 0, not voted: 4)

  Matt   [+1]
  Mark   [  ]
  Pauli  [+1]
  Viktor [  ]
  Tim[+1]
  Richard[+1]
  Shane  [+1]
  Tomas  [  ]
  Kurt   [  ]
  Matthias   [+1]
  Nicola [+1]

RE: VOTE: Accept the OTC voting policy as defined:

[Dr. Matthias St. Pierre]

The vote has been closed, the verdict is

accepted:  yes  (for: 9, against: 0, abstained: 0, not voted: 2)


topic: Accept the OTC voting policy as defined:

   The proposer of a vote is ultimately responsible for updating the 
votes.txt
   file in the repository.  Outside of a face to face meeting, voters MUST 
reply
   to the vote email indicating their preference and optionally their 
reasoning.
   Voters MAY update the votes.txt file in addition.

   The proposed vote text SHOULD be raised for discussion before calling 
the vote.

   Public votes MUST be called on the project list, not the OTC list and the
   subject MUST begin with "VOTE:".  Private votes MUST be called on the
   OTC list with "PRIVATE VOTE:" beginning subject.

Proposed by Matthias St. Pierre (on behalf of the OTC)
Public: yes
opened: 2020-09-28
closed: 2020-09-29
accepted:  yes/no  (for: 9, against: 0, abstained: 0, not voted: 2)

  Matt   [+1]
  Mark   [+1]
  Pauli  [+1]
  Viktor [  ]
  Tim[+1]
  Richard[+1]
  Shane  [+1]
  Tomas  [+1]
  Kurt   [  ]
  Matthias   [+1]
  Nicola [+1]

RE: VOTE: Accept the OTC voting policy as defined:

[Dr. Matthias St. Pierre]

See pull request

#198 - Add 'OpenSSL Technical Policies' page with a 'Voting Policy' section
https://github.com/openssl/web/pull/198

Matthias

Add 'OpenSSL Technical Policies' page to openssl.org?

[Dr. Matthias St. Pierre]

Hi,

Pauli added the following action item for me to the OTC vF2F spreadsheet:

> Matthias: create web PR for OTC voting policy.

I wouldn't mind to add the content, but currently there seems to be no
appropriate place yet to put it. The voting process is currently described
only in the OMC bylaws,

   OpenSSL Bylaws
   openssl/web:policies/omc-bylaws.html

and there is no specific document for implementary regulations, or more 
generally,
technical policies decided by the OTC.  The web page needs a name and an URL,
something like

OpenSSL Technical Policies
openssl/web:policies/otc-policies.html

and it needs to be referenced by the Policies page 
.
If you agree with the name and URL, I can add that part to the web PR as well.

Matthias

RE: VOTE: Accept the OTC voting policy as defined:

[Dr. Matthias St. Pierre]

Now with the votes already cast filled in :-)

topic: Accept the OTC voting policy as defined:

   The proposer of a vote is ultimately responsible for updating the 
votes.txt
   file in the repository.  Outside of a face to face meeting, voters MUST 
reply
   to the vote email indicating their preference and optionally their 
reasoning.
   Voters MAY update the votes.txt file in addition.

   The proposed vote text SHOULD be raised for discussion before calling 
the vote.

   Public votes MUST be called on the project list, not the OTC list and the
   subject MUST begin with "VOTE:".  Private votes MUST be called on the
   OTC list with "PRIVATE VOTE:" beginning subject.

Proposed by Matthias St. Pierre (on behalf of the OTC)
Public: yes
opened: 2020-09-28
closed: 2020-mm-dd
accepted:  yes/no  (for: X, against: Y, abstained: Z, not voted: T)

  Matt   [+1]
  Mark   [+1]
  Pauli  [+1]
  Viktor [  ]
  Tim[+1]
  Richard[+1]
  Shane  [+1]
  Tomas  [+1]
  Kurt   [  ]
  Matthias   [+1]
  Nicola [+1]

From: openssl-project  On Behalf Of Dr. 
Matthias St. Pierre
Sent: Monday, September 28, 2020 2:17 PM
To: Dr Paul Dale ; Nicola Tuveri (nic@gmail.com) 
; openssl-project@openssl.org
Subject: RE: VOTE: Accept the OTC voting policy as defined:

Oh, sorry, you are right! The participants of the face to face already voted, 
but I forgot to fill in the votes. Apologies, I'll make up for it in a minute!

Matthias


From: openssl-project 
mailto:openssl-project-boun...@openssl.org>>
 On Behalf Of Dr Paul Dale
Sent: Monday, September 28, 2020 2:10 PM
To: openssl-project@openssl.org<mailto:openssl-project@openssl.org>
Subject: Re: VOTE: Accept the OTC voting policy as defined:

+1

Pauli
--
Dr Paul Dale | Distinguished Architect | Cryptographic Foundations
Phone +61 7 3031 7217
Oracle Australia





On 28 Sep 2020, at 10:02 pm, Dr. Matthias St. Pierre 
mailto:matthias.st.pie...@ncp-e.com>> wrote:

topic: Accept the OTC voting policy as defined:

  The proposer of a vote is ultimately responsible for updating the 
votes.txt
  file in the repository.  Outside of a face to face meeting, voters MUST 
reply
  to the vote email indicating their preference and optionally their 
reasoning.
  Voters MAY update the votes.txt file in addition.

  The proposed vote text SHOULD be raised for discussion before calling the 
vote.

  Public votes MUST be called on the project list, not the OTC list and the
  subject MUST begin with "VOTE:".  Private votes MUST be called on the
  OTC list with "PRIVATE VOTE:" beginning subject.

Proposed by Matthias St. Pierre (on behalf of the OTC)
Public: yes
opened: 2020-09-28
closed: 2020-mm-dd
accepted:  yes/no  (for: X, against: Y, abstained: Z, not voted: T)

 Matt   [  ]
 Mark   [  ]
 Pauli  [  ]
 Viktor [  ]
 Tim[  ]
 Richard[  ]
 Shane  [  ]
 Tomas  [  ]
 Kurt   [  ]
 Matthias   [+1]
 Nicola [  ]

RE: VOTE: Accept the OTC voting policy as defined:

[Dr. Matthias St. Pierre]

Oh, sorry, you are right! The participants of the face to face already voted, 
but I forgot to fill in the votes. Apologies, I'll make up for it in a minute!

Matthias


From: openssl-project  On Behalf Of Dr 
Paul Dale
Sent: Monday, September 28, 2020 2:10 PM
To: openssl-project@openssl.org
Subject: Re: VOTE: Accept the OTC voting policy as defined:

+1

Pauli
--
Dr Paul Dale | Distinguished Architect | Cryptographic Foundations
Phone +61 7 3031 7217
Oracle Australia





On 28 Sep 2020, at 10:02 pm, Dr. Matthias St. Pierre 
mailto:matthias.st.pie...@ncp-e.com>> wrote:

topic: Accept the OTC voting policy as defined:

  The proposer of a vote is ultimately responsible for updating the 
votes.txt
  file in the repository.  Outside of a face to face meeting, voters MUST 
reply
  to the vote email indicating their preference and optionally their 
reasoning.
  Voters MAY update the votes.txt file in addition.

  The proposed vote text SHOULD be raised for discussion before calling the 
vote.

  Public votes MUST be called on the project list, not the OTC list and the
  subject MUST begin with "VOTE:".  Private votes MUST be called on the
  OTC list with "PRIVATE VOTE:" beginning subject.

Proposed by Matthias St. Pierre (on behalf of the OTC)
Public: yes
opened: 2020-09-28
closed: 2020-mm-dd
accepted:  yes/no  (for: X, against: Y, abstained: Z, not voted: T)

 Matt   [  ]
 Mark   [  ]
 Pauli  [  ]
 Viktor [  ]
 Tim[  ]
 Richard[  ]
 Shane  [  ]
 Tomas  [  ]
 Kurt   [  ]
 Matthias   [+1]
 Nicola [  ]

VOTE: Accept the OTC voting policy as defined:

[Dr. Matthias St. Pierre]

topic: Accept the OTC voting policy as defined:

   The proposer of a vote is ultimately responsible for updating the 
votes.txt
   file in the repository.  Outside of a face to face meeting, voters MUST 
reply
   to the vote email indicating their preference and optionally their 
reasoning.
   Voters MAY update the votes.txt file in addition.

   The proposed vote text SHOULD be raised for discussion before calling 
the vote.

   Public votes MUST be called on the project list, not the OTC list and the
   subject MUST begin with "VOTE:".  Private votes MUST be called on the
   OTC list with "PRIVATE VOTE:" beginning subject.

Proposed by Matthias St. Pierre (on behalf of the OTC)
Public: yes
opened: 2020-09-28
closed: 2020-mm-dd
accepted:  yes/no  (for: X, against: Y, abstained: Z, not voted: T)

  Matt   [  ]
  Mark   [  ]
  Pauli  [  ]
  Viktor [  ]
  Tim[  ]
  Richard[  ]
  Shane  [  ]
  Tomas  [  ]
  Kurt   [  ]
  Matthias   [+1]
  Nicola [  ]

RE: New GitHub label for release blockers

[Dr. Matthias St. Pierre]

> I fail to see why the milestones '3.0.0' / '3.0.0 beta1' must be 1:1
> with the '3.0 New Core + FIPS' project.  

Sorry for the misunderstanding, Richard. I did not intend to mess around with 
your project organization.
Since it was the only active GitHub project, I misinterpreted it as the "3.0.0" 
project and did not read
the fine print.

All I intended to do is to obtain an accurate overwiew of what remains to be 
done.
Because listing them on the otc mailing list is not very maintainable, and the 
google spreadsheet is not viewable by the public.

> If we make them the same, what's the reason to have both?

I completely agree. According to my understanding,  it would have made more 
sense if we had created
an "OpenSSL 3.0" project for managing all what needs to go into this major 
release and three milestones
'3.0.0 alpha',  '3.0.0 beta', '3.0.0' associated with the major events.

Regards,
Matthias

RE: New GitHub label for release blockers

[Dr. Matthias St. Pierre]

Conversely, there were also pull requests associated with the '3.0.0' or '3.0.0 
beta1' milestone,
without  being associated to the  '3.0 New Core + FIPS' project. This has been 
fixed now.

RE: New GitHub label for release blockers

[Dr. Matthias St. Pierre]

> when your time permits, could you please double-check whether all important 
> tickets
> for beta1 were moved correctly from '3.0.0' to '3.0.0 beta1'?

The '3.0 New Core + FIPS' project currently lists 21 open pull requests,

[is:open is:pr project:openssl/openssl/2]:

https://github.com/openssl/openssl/pulls?q=is%3Aopen+is%3Apr+project%3Aopenssl%2Fopenssl%2F2+

ten of which are not associated with any milestone yet

[is:open is:pr project:openssl/openssl/2 no:milestone]:

https://github.com/openssl/openssl/pulls?q=is%3Aopen+is%3Apr+project%3Aopenssl%2Fopenssl%2F2+no%3Amilestone

It would be helpful if someone of the core team could check and assigne them.

Matthias

RE: New GitHub label for release blockers

[Dr. Matthias St. Pierre]

That's a very nice summary,  Matt.

when your time permits, could you please double-check whether all important 
tickets
for beta1 were moved correctly from '3.0.0' to '3.0.0 beta1'?

Thanks,

Matthias

RE: New GitHub label for release blockers

[Dr. Matthias St. Pierre]

Since we were able to collect some experiences working on the ‘3.0 New Core + 
FIPS’ project, I think that’s a perfect subject
to be discussed on the face-to-face meeting. I will add it to the list of 
proposed topics. As for the official documentation you
mentioned, are you talking about this one? 
https://github.com/features/project-management

Matthias


From: Nicola Tuveri  
Sent: Sunday, September 13, 2020 4:17 PM
To: Dr. Matthias St. Pierre 
Cc: openssl-project@openssl.org
Subject: Re: New GitHub label for release blockers

Matthias overcredits me: I just wanted to know his opinion about when we should 
use labels and when milestones (and that is why I wrote to him off-list, as a 
very confused and shy pupil asking a sensei for wisdom pearls).

All the alleged convincing was self-inflicted :P


And now that my ignorance is out of the closet... 
... I still have very confused ideas regarding the "best" conventional usage of 
github features like labels, milestones and projects: I read the official 
documentation about them and I grasp the general ideas behind them, but too 
often the boundaries are too foggy for me to navigate and pick the right tool 
for the job in a consistent and organic manner. 

Nicola

RE: New GitHub label for release blockers

[Dr. Matthias St. Pierre]

Nicola suggested and convinced me, that it would be better to have a dedicated
milestone for the 3.0.0 beta1 release instead of adding a new label.

So here it is, I already added all the tickets with the release blocker label 
and will
remove the label again.

https://github.com/openssl/openssl/milestone/17

Matthias



> -Original Message-
> From: Dr. Matthias St. Pierre
> Sent: Sunday, September 13, 2020 3:17 PM
> To: openssl-project@openssl.org
> Subject: New GitHub label for release blockers
> 
> Hi all,
> 
> taking up again the discussion from openssl-project where I suggested to 
> (ab)use
> the 3.0.0 milestone for release blockers, (see link and citation at the end 
> of the mail),
> I propose to add a new label for this purpose instead. In fact, I already 
> created the label
> 
>   [urgent: release blocker]   (see link below)
> 
> and will add the mentioned tickets within shortly. So you can take a look and 
> tell
> me whether you like it or not. (If not, no problem. I'll just delete the 
> label again.)
> 
> Matthias
> 
> 
> BTW: It took me all my force of will to resist the temptation of making a pun
>  by naming the label [urgent: beta blocker].
> 
> 
> References:
> ==
> 
> [urgent: release blocker]:
>   https://github.com/openssl/openssl/labels/urgent%3A%20release%20blocker
> 
> [openssl-project message]:
>   
> https://mta.openssl.org/pipermail/openssl-project/2020-September/002191.html
> 
> 
> > > > For a more accurate and timely public overview over the current state 
> > > > of the blockers,
> > > > it might be helpful to manage them via the 3.0.0  milestone
> > > >
> > > > https://github.com/openssl/openssl/milestone/15
> > > >
> > > > Some of the tickets listed below were already associated to the 
> > > > milestone, the others
> > > > were added by me now.
> > >
> > > I think the 3.0.0 milestone is what we expect to be in the
> > > 3.0.0 release, not the beta release. That is bug fixes don't need
> > > to be in the beta release, but if it adds new functionallity it
> > > needs to be in the beta release.
> >
> > I was aware of this subtlety but I thought that we just could (ab-)use the 
> > milestone for
> > the beta1 release and reuse it later for the final release, instead of 
> > creating a new milestone.
> >
> > Practically all of the relevant PRs are associated to the [3.0 New Core + 
> > FIPS] GitHub Project
> > anyway, so it would be possible to remove the post-beta PRs from the 
> > milestone and restore
> > them later.  (In my mind, I see project managers running away screeming...)
> >
> > Matthias
> >
> >
> > [3.0 New Core + FIPS]:  https://github.com/openssl/openssl/projects/2

RE: New GitHub label for release blockers

[Dr. Matthias St. Pierre]

I added some issues mentioned in the  'Beta1 PR deadline' thread to the new 
label.
Feel free to extend and modify the list as necessary.

New GitHub label for release blockers

[Dr. Matthias St. Pierre]

Hi all,

taking up again the discussion from openssl-project where I suggested to (ab)use
the 3.0.0 milestone for release blockers, (see link and citation at the end of 
the mail),
I propose to add a new label for this purpose instead. In fact, I already 
created the label

[urgent: release blocker]   (see link below)

and will add the mentioned tickets within shortly. So you can take a look and 
tell
me whether you like it or not. (If not, no problem. I'll just delete the label 
again.)

Matthias


BTW: It took me all my force of will to resist the temptation of making a pun
 by naming the label [urgent: beta blocker].


References:
==

[urgent: release blocker]:
https://github.com/openssl/openssl/labels/urgent%3A%20release%20blocker

[openssl-project message]:

https://mta.openssl.org/pipermail/openssl-project/2020-September/002191.html


> > > For a more accurate and timely public overview over the current state of 
> > > the blockers,
> > > it might be helpful to manage them via the 3.0.0  milestone
> > >
> > > https://github.com/openssl/openssl/milestone/15
> > >
> > > Some of the tickets listed below were already associated to the 
> > > milestone, the others
> > > were added by me now.
> > 
> > I think the 3.0.0 milestone is what we expect to be in the
> > 3.0.0 release, not the beta release. That is bug fixes don't need
> > to be in the beta release, but if it adds new functionallity it
> > needs to be in the beta release.
> 
> I was aware of this subtlety but I thought that we just could (ab-)use the 
> milestone for
> the beta1 release and reuse it later for the final release, instead of 
> creating a new milestone.
> 
> Practically all of the relevant PRs are associated to the [3.0 New Core + 
> FIPS] GitHub Project
> anyway, so it would be possible to remove the post-beta PRs from the 
> milestone and restore
> them later.  (In my mind, I see project managers running away screeming...)
> 
> Matthias
> 
> 
> [3.0 New Core + FIPS]:  https://github.com/openssl/openssl/projects/2

RE: Beta1 PR deadline

[Dr. Matthias St. Pierre]

> > For a more accurate and timely public overview over the current state of 
> > the blockers,
> > it might be helpful to manage them via the 3.0.0  milestone
> >
> > https://github.com/openssl/openssl/milestone/15
> >
> > Some of the tickets listed below were already associated to the milestone, 
> > the others
> > were added by me now.
> 
> I think the 3.0.0 milestone is what we expect to be in the
> 3.0.0 release, not the beta release. That is bug fixes don't need
> to be in the beta release, but if it adds new functionallity it
> needs to be in the beta release.

I was aware of this subtlety but I thought that we just could (ab-)use the 
milestone for
the beta1 release and reuse it later for the final release, instead of creating 
a new milestone.

Practically all of the relevant PRs are associated to the [3.0 New Core + FIPS] 
GitHub Project
anyway, so it would be possible to remove the post-beta PRs from the milestone 
and restore
them later.  (In my mind, I see project managers running away screeming...)

Matthias


[3.0 New Core + FIPS]:  https://github.com/openssl/openssl/projects/2

RE: Beta1 PR deadline

[Dr. Matthias St. Pierre]

For a more accurate and timely public overview over the current state of the 
blockers,
it might be helpful to manage them via the 3.0.0  milestone 

https://github.com/openssl/openssl/milestone/15

Some of the tickets listed below were already associated to the milestone, the 
others
were added by me now.

Just a suggestion.

Matthias



> -Original Message-
> From: openssl-project  On Behalf Of Matt 
> Caswell
> Sent: Thursday, September 10, 2020 1:24 PM
> To: openssl-project@openssl.org
> Subject: Re: Beta1 PR deadline
> 
> 
> 
> On 10/09/2020 11:40, Matt Caswell wrote:
> >
> >
> > On 09/09/2020 13:03, Kurt Roeckx wrote:
> >> On Wed, Aug 26, 2020 at 04:58:26PM +0100, Matt Caswell wrote:
> >>> Please can anyone with PRs that they wish to have included in OpenSSL
> >>> 3.0 beta1 ensure that they are merged to master by 8th September.
> >>
> >> So that date has passed now. Can someone give an overview of what
> >> we think is still needed to be done before the beta 1 release? Are
> >> there open PRs for everything? Do we a milestone on github to
> >> indicate which PRs need to go in before beta1?
> >
> >
> > I believe the "blockers" to be:
> >
> > https://github.com/openssl/openssl/pull/12536
> > https://github.com/openssl/openssl/pull/12754
> > https://github.com/openssl/openssl/pull/12750
> > https://github.com/openssl/openssl/pull/12781
> > https://github.com/openssl/openssl/pull/12801
> >
> > Aside from these there are potential PRs not yet opened but slated for
> > beta1 regarding:
> > - Refactor serialization? (owner: Richard)
> > - lhash refactor? (owner: Me)
> > - IG D.9 update? (owner: Shane)
> 
> Oh, I think this last one might be:
> 
> https://github.com/openssl/openssl/pull/12835
> 
> Matt
> 
> >
> > There's also this issue - but I'm not sure that it needs to be resolved
> > for beta1:
> > https://github.com/openssl/openssl/issues/12195
> >
> > Matt
> >

RE: More GitHub labels

[Dr. Matthias St. Pierre]

> ... I think we should change that. This does not mean that a reviewer who 
> made a change request
> two months ago and lost interest is forced to re-review, only that such stale 
> reviews must be dismissed
> explicitly, if the reviewer does not respond to a re-review request within a 
> certain time period.

I would refine this procedure as follows: the team member who intends to do the 
merge (the "merger"),
needs to issue re-review requests for all unresolved change requests (there is 
a spinning button next the
name of the reviewer to do this). The person who receives the re-review request 
can either dismiss its
review or indicate that it intends to review within x hours. Otherwise, the 
merger can dismiss the stale review.
 
Matthias

RE: More GitHub labels

[Dr. Matthias St. Pierre]

> Your suggestion seems workable too.  PRs are merged with outstanding change 
> requests indicated
> — a reviewer comments, the comments are addressed then a different reviewer 
> approves without
> the original review being removed.  The labels are a bit more in your face.  
> A hybrid “hold: required changes see review/comments” might be workable.

GitHub can be configured to require approval. It then gives a clear visual 
indication that the PR is
not ready to be merged, and the Merge button is greyed out. This should be 
obvious enough,
even more obvious than a label, which can also easily be ignored.

Of course, our merge procedure circumvents the merge button, I'm only talking 
about the visual
indicator. Alternatively, the pre-receive-hook on the git.openssl.org server 
could enforce the policy
by checking the  reviewer state via GitHub API queries.

Matthias

RE: More GitHub labels

[Dr. Matthias St. Pierre]

> Just wondering if we should have two new labels: “hold: tests needed” and 
> “hold: documentation needed” labels?
> There are a number of PRs that come through where one or both of these are 
> missing missing.

The two use cases you mention are actually better handled by a change request 
(via GitHub review) instead of a label:
A team member can formulate a change request to block the merging. Here he has 
more freedom to formulate what
needs to be done. This includes your two use cases, as well as the use case for 
the label [hold: need rebase].

The problem with it is that currently we count only approvals and don’t 
consider unresolved change requests
as a blocker. I think we should change that. This does not mean that a reviewer 
who made a change request
two months ago and lost interest is forced to re-review, only that such stale 
reviews must be dismissed
explicitly, if the reviewer does not respond to a re-review request within a 
certain time period.

Matthias

RE: Reordering new API's that have a libctx, propq

[Dr. Matthias St. Pierre]

Both suggestions make sense to me and they were discussed several times in the 
weekly calls.
So you have my support whether there will be the need for a formal vote or not.

> An otc_hold was put on this.. Do we need to have a formal vote?

Since Tim placed the hold, only he can remove it. If he doesn’t, an OTC vote is 
inevitable.

https://github.com/openssl/openssl/pull/12778#issuecomment-686348526

In that case, let’s just have the vote and finish it quickly.

Matthias


From: openssl-project  On Behalf Of SHANE 
LONTIS
Sent: Saturday, September 5, 2020 5:48 AM
To: openssl-project@openssl.org
Subject: Reordering new API's that have a libctx, propq

PR #12778 reorders all the API’s of the form:
EVP_XX_fetch(libctx, algname, propq)
So that the algorithm name appears first..
e.g: EVP_MD_fetch(digestname, libctx, propq);
This now logically reads as 'search for this algorithm using these parameters’.

The libctx, propq should always appear together as a pair of parameters.
There are only a few places where only the libctx is needed, which means that 
if there is no propq it is likely to cause a bug in a fetch at some point.
This keeps the API’s more consistent with other existing XXX_with_libctx API’s 
that put the libctx, propq at the end of the parameter list..
The exception to this rule is that callback(s) and their arguments occur after 
the libctx, propq..

e.g:
typedef OSSL_STORE_LOADER_CTX *(*OSSL_STORE_open_with_libctx_fn)
(const OSSL_STORE_LOADER *loader,
 const char *uri, OPENSSL_CTX *libctx, const char *propq,
 const UI_METHOD *ui_method, void *ui_data);

An otc_hold was put on this.. Do we need to have a formal vote?
This really needs to be sorted out soon so the API’s can be locked down for 
beta.


Also discussed in a weekly meeting and numerous PR discussions was the removal 
of the long winded API’s ending with ‘with_libctx’
e.g CMS_data_create_with_libctx
The proposed renaming for this was to continue with the _ex notation.. If there 
is an existing _ex name then it becomes _ex2, etc.
There will most likely be additional parameters in the future for some API’s, 
so this notation would be more consistent with current API’s.
Does this also need a vote?

Regards,
Shane

RE: OTC vote on PR11188

[Dr. Matthias St. Pierre]

-0

> -Original Message-
> From: openssl-project  On Behalf Of Matt 
> Caswell
> Sent: Thursday, August 27, 2020 12:06 PM
> To: openssl-project@openssl.org
> Subject: OTC vote on PR11188
> 
> FYI, I have initiated the following vote on PR11188. Please see the
> comments in that PR for the background. I will report back with the
> result of the vote once known.
> 
> topic: The performance improvements provided in PR11188 should be
>considered a bug fix and therefore acceptable for backport to
>1.1.1
> Proposed by Matt Caswell
> Public: yes
> opened: 2020-08-27
> closed: 2020-mm-dd
> 
> 
> Matt
> 

Re: VOTE: Rename OPENSSL_CTX to OSSL_LIB_CTX (as proposed by pull request #12621)

[Dr. Matthias St. Pierre]

The vote has been closed, the verdict is:

    accepted:  yes  (for: 5, against: 0, abstained: 4, not voted: 2)


On 18.08.20 13:12, Dr. Matthias St. Pierre wrote:

The main rationale behind this change is consistency, because many of the new
OpenSSL 3.0 types have an OSSL_ prefix, and OPENSSL_CTX is a notable exception.
More details can be found in the description and thread of pull request #12621.

There was a discussion on openssl-committers and an initial poll on doodle 
about the
favourite replacements for OPENSSL_CTX 
(https://doodle.com/poll/drku9ziwvkp6tw25).

Matthias

VOTE: Rename OPENSSL_CTX to OSSL_LIB_CTX (as proposed by pull request #12621)

[Dr. Matthias St. Pierre]

The main rationale behind this change is consistency, because many of the new
OpenSSL 3.0 types have an OSSL_ prefix, and OPENSSL_CTX is a notable exception.
More details can be found in the description and thread of pull request #12621.

There was a discussion on openssl-committers and an initial poll on doodle 
about the
favourite replacements for OPENSSL_CTX 
(https://doodle.com/poll/drku9ziwvkp6tw25).

Matthias

RE: TLS 1.3 illustrated

[Dr. Matthias St. Pierre]

Nice, thank you for the link. FWIW, there is also a TLS 1.2 illustrated page:

https://tls12.ulfheim.net

Matthias


From: openssl-project  On Behalf Of Dr 
Paul Dale
Sent: Sunday, August 16, 2020 8:19 AM
To: openssl-project@openssl.org
Subject: TLS 1.3 illustrated

This might be interesting to some:

https://tls13.ulfheim.net

Pauli
--
Dr Paul Dale | Distinguished Architect | Cryptographic Foundations
Phone +61 7 3031 7217
Oracle Australia

RE: RAND_DRBG

[Dr. Matthias St. Pierre]

> The RAND_DRBG (crypto/rand/drbg_lib) APIs are quite some mess and sit badly 
> with the move to provider based infrastructure.

Actually, it is not the RAND_DRBG API itself (as it is in 1.1.1) which is 
messy. It’s the fact that part of its interface is very low level
and that the EVP_RAND interface tries to move away from that. In particular, in 
the future seed sources will be pluggable by chaining
the primary DRBG to an entropy source which is provided as a fetchable EVP_RAND 
interface, not by replacing some internal callbacks.
(Note however, that fetchable entropy sources,  in particular sources of low 
quality, are not implemented yet and won’t be implemented
in time for version 3.0. But as far as I’m concerned, I can wait for 3.1, since 
my company is still transitioning from 1.0.2 to 1.1.1. )

Moving to the new approach while at the same time having to retain 
compatibility to the old approach, that’s what is creating the mess
under the hood. Most notably, it’s the two functions RAND_DRBG_set_callbacks() 
and RAND_DRBG_set() which are creating the problems.
Pull Request #12509 attempts to untangle the two RNG interfaces by providing 
two unrelated triples of RNGs (option 2 in Pauli’s proposal),
an EVP_RAND triple and a RAND_DRBG triple. This does not work out well, as 
pointed out by me in [1]. There might be a variant of option (2)
however to fix the problem described in [1], which could provide better 
compatibility:

4. Offer legacy RAND_METHOD (e.g. RAND_drbg_method(), RAND_OpenSSL_legacy(), …) 
as an alternative to RAND_OpenSSL()

Anybody who currently uses the RAND_DRBG callback mechanism, could activate 
this legacy RAND_METHOD to switch from the new
EVP_RAND triple to the legacy RAND_DRBG triple of random generators, and their 
callbacks would continue to work as expected.

I still favour option (1), but (4) might be a reasonable compromise. It comes 
at a price, because both RAND_METHODs need to be fully
supported  and tested thoroughly.

Matthias


[1] https://github.com/openssl/openssl/pull/12509#pullrequestreview-455396828

From: openssl-project  On Behalf Of Dr 
Paul Dale
Sent: Monday, July 27, 2020 3:08 AM
To: openssl-project@openssl.org
Subject: RAND_DRBG

The RAND_DRBG (crypto/rand/drbg_lib) APIs are quite some mess and sit badly 
with the move to provider based infrastructure.
They are definitely being deprecated in master but without more, the extra 
layer of indirection and additional complexity generating random numbers will 
remain.

The option I see are:

1. Remove, rather than deprecate, RAND_DRBG in 3.0.  This is a breaking change.
2. Bypass RAND_DRBG and live with a breaking change (refer: 
https://github.com/openssl/openssl/pull/12509#pullrequestreview-455396828)
3. Leave things as they currently are in master.

The first two are breaking changes and will require an OMC vote.


Some pertinent points:

1. RAND_bytes will continue to work as is — this API is perfect for almost 
everyone.
2. The RAND_METHOD functionality remains — this allows wholesale replacement of 
OpenSSL’s RNGs if desired.
3. The name EVP_RAND is the working name and might change — this is not 
relevant to this discussion.
4. The RAND_DRBG APIs are unlikely to be widely used — they were introduced in 
1.1.1.  The two users I know of (Akamai and NCP) are both fine with them being 
removed.


Thoughts anyone?


Pauli
--
Dr Paul Dale | Distinguished Architect | Cryptographic Foundations
Phone +61 7 3031 7217
Oracle Australia

RE: API renaming

[Dr. Matthias St. Pierre]

> They also correspond directly to EVP_MAC and EVP_KDF types. Would the types 
> change as well?

Yes, if we would decide to change the EVP_MAC and EVP_KDF prefix, then this 
would not only
apply to the functions, but to the types as well.

Matthias

RE: API renaming

[Dr. Matthias St. Pierre]

> I was thinking OSSL_LIBCTX?

That's a good choice and consistent with how we name the variable in most (but 
not all) places:

OPENSSL_CTX *libctx;

I volunteer to raise a pull request which does a scripted bulk rename, as soon 
as we have made
a decision. Ideally, the bulk renaming should go in shortly before the next 
alpha. Having it
automated by a script would ease rebasing of other still unmerged pull requests 
over the change.

Matthias

> -Original Message-
> From: SHANE LONTIS 
> Sent: Friday, July 24, 2020 9:43 AM
> To: Dr. Matthias St. Pierre 
> Cc: Richard Levitte ; openssl-project@openssl.org
> Subject: Re: API renaming
> 
> I was thinking OSSL_LIBCTX?
> 

RE: API renaming

[Dr. Matthias St. Pierre]

> I think the KDF and MAC got back ported also...

In this case it would be no question that we should keep the names EVP_KDF and 
EVP_MAC.

RE: API renaming

[Dr. Matthias St. Pierre]

I like the OSSL_ prefix for new APIs as proposed by Richard. And I agree with 
Shane
that we should go for a single prefix and not have two alternatives. Existing 
prefixes
for things like feature macros should remain as they are, but if the OSSL_ 
prefix is
our choice for the future, we should start using it consistently for _all_ new 
APIs in 3.0.
And not make it a random choice (pun intended) depending on whether the API went
into master early or late. So my favorite choice is a consistent renaming, i.e.

OSSL_MAC, OSSL_KDF, OSSL_RAND, OSSL_CTX, ...

OTOH, it would be ok for me if we would make an exception for EVP_MAC and 
EVP_KDF,
because they have a long EVP history, as Matt pointed out. But using the EVP_ 
prefix
for the new RAND interface never made sense to me.

What bothers me about OPENSSL_CTX in particular is the fact that it is a 
mixture of
a non-abbreviated and an abbreviated word. IMHO it should be either OSSL_CTX or
OPENSSL_CONTEXT, and the former is obviously preferrable for its length.

Matthias


> -Original Message-
> From: openssl-project  On Behalf Of 
> Richard Levitte
> Sent: Friday, July 24, 2020 8:34 AM
> To: openssl-project@openssl.org
> Subject: Re: API renaming
> 
> I'm fine with that, really.
> 
> I have a preference for OSSL_, but if we look through the source,
> there's reason for either.  So far, we've majorly used OPENSSL_ for
> things like feature macros (disabling macros, really), environment
> variables, that sort of thing, while OSSL_ has become the primary
> choice for new APIs ("less klunky", I think the judgement was in that
> past discussion I keep referring to).
> 
> And yeah, I hear you from all the way around the planet, there are
> some recent name choice that were made that give pause and are
> arguably a mistake in this regard.  EVP_MAC and EVP_KDF could have
> been OSSL_MAC and OSSL_KDF.  OPENSSL_CTX could have been OSSL_CTX.
> I have no problem recognising that.  But, they are there, even though
> only in master (*).  This is question of what we do going forward (a
> yet unmerged PR with a new API is as good a target as any).
> 
> Cheers,
> Richard
> 
> (*) I'm not sure I see master as something untouchable in this regard,
> as the development is still not frozen (alpha), so I for one could
> easily see a rename fest happening, should we decide for it.  That
> must happen before we enter the beta phase, though...
>

RE: Cherry-pick proposal

[Dr. Matthias St. Pierre]

Independently of the outcome of the vote I think we should adopt the habit to 
wait with the
merging of a backport PR until the original PR has been approved and merged. As 
an indicator
and reminder, I added a new label (hold: wait for master), which I applied to 
#12417.

https://github.com/openssl/openssl/labels/hold%3A%20wait%20for%20master

Matthias


> -Original Message-
> From: openssl-project  On Behalf Of Matt 
> Caswell
> Sent: Thursday, July 9, 2020 11:13 AM
> To: openssl-project@openssl.org
> Subject: Re: Cherry-pick proposal
> 
> 
> 
> On 02/06/2020 15:29, Matt Caswell wrote:
> >
> > There's been no further discussion on this for quite a while, so I will
> > start an OTC vote based on the vote text proposed by Matthias and report
> > back the results here.
> 
> Sorry, I forgot to report back. The final result was:
> 
> +1: 4
> -1: 4
>  0: 3
> 
> So the result was tied. According to our bylaws this means that the vote
> does not pass.
> 
> Matt

RE: Backports to 1.1.1 and what is allowed

[Dr. Matthias St. Pierre]

Since already a few backporting requests to 1.1.1 have accumulated which are 
controversial
or not allowed for an LTS release, would it make sense to consider creating a 
new 1.1.2 STS
branch which could then receive such changes?

Matthias

RE: Reducing the security bits for MD5 and SHA1 in TLS - OTC or OMC vote?

[Dr. Matthias St. Pierre]

> I mean I am definitely not against having a vote if someone feels it
> should be done but if nobody requires it, I do not think it would be a
> violation of anything if this is merged without a vote.

Tomáš I dont't mind following your viewpoint at all, and if the OMC thinks
the same, that's fine. Also, I agree that an OTC/OMC discussion does not
automatically have to be resolved by an OTC/OMC vote.

Maybe my original post was a bit misleading. The main motivation behind it
was my impression that we tend to start many technical discussions with a
general discussion about whether it should be discussed/decided by the
OMC or the OTC.

Matthias

RE: Reducing the security bits for MD5 and SHA1 in TLS - OTC or OMC vote?

[Dr. Matthias St. Pierre]

> IMO it seems appropriate to have an OMC vote on this topic (or should it
> be OTC?). Possible wording:

Personally, I would prefer if technical questions would by default be discussed 
(and voted on)
by the OTC, unless an OMC member explicitly puts in his veto and claims that 
higher level
strategical interests of the OpenSSL project are affected.

But according to the current wording of the bylaws, I would say it is a 
'feature requirement' and
requires an OMC vote:

> The OMC:
>
> * makes all decisions regarding management and strategic direction of the 
> project; including:
> - business requirements;
> - feature requirements;
> - platform requirements;
> - roadmap requirements and priority;
> - end-of-life decisions;
> - release timing and requirement decisions;

Matthias

RE: Cherry-pick proposal

[Dr. Matthias St. Pierre]

I completely agree with Nicolas reasoning. But we should try to keep things 
simple and not
add too many regulations. What do you think of the following formulation?

>
For change requests which target both the master and the OpenSSL_1_1_1-stable 
branch,
the following procedure should be followed:

- First, a pull request needs to be opened against the master branch for 
discussion.
  Only after that pull request has received the necessary amount of approvals,
  a separate pull request can be opened  against the OpenSSL_1_1_1-stable 
branch.

- A separate pull request against the OpenSSL_1_1_1-stable branch is required.
  This holds - contrary to common practice - even if the change can be 
cherry-picked
  without conflicts from the master branch. The only exception from this rule 
are
  changes which are considered 'CLA: trivial', like e.g. typographical fixes.
>

Matthias


From: openssl-project  On Behalf Of Nicola 
Tuveri
Sent: Wednesday, April 29, 2020 3:05 PM
To: openssl-project@openssl.org
Subject: Re: Cherry-pick proposal

I can agree it is a good idea to always require backport as a separate PR, with 
the following conditions:
- unless it's a 1.1.1 only issue, we MUST always wait to open the 
backport-to-111 PR until after the master PR has been approved and merged (to 
avoid splitting the discussions among different PRs, which make review and 
revisiting our history very hard)
- trivial documentation changes, such as fixing typos, can be exempted

It must be clear that although things have changed a lot in the inner 
plumbings, we have so far managed to keep crypto implementations very much in 
sync between 1.1.1 and master, by applying the policy of "first merge to 
master, then possibly backport".

What I am afraid of in Bernd's proposal, and recent discussions, is that 
committers might be tempted to open PRs changing implementations against 1.1.1 
first (to avoid frequent rebases due to unrelated changes) and let the `master` 
PR stagnate indefinitely because it feels like too much hassle to keep up with 
the development pace of master if your PR collaterally changes certain files.

An example of what can go wrong if we open a 1.1.1 PR concurrently with a PR 
for master can be seen here:
- `master` PR: https://github.com/openssl/openssl/pull/10828
- `1.1.1` PR: https://github.com/openssl/openssl/pull/11411

I highlight the following problems related to the above example:
- as you can see the `1.1.1` has been merged, even though the `master` one has 
stalled while discussing which implementation we should pick. (this was my 
fault, I should have applied the `hold` label after stating that my approval 
for 1.1.1 was conditional to approving the `master` counterpart)
- discussion that is integral part of the decision process was split among the 
2 PRs, with over 40 comments each
- there is no clear link between the `master` PR and the `1.1.1` PR for the 
same feature (this makes it very difficult to review what is the state of the 
"main" PR, and if we or someone else in some months or years needs to go check 
why we did things the way we did, will have a hard time connecting the dots)

I also think that the proposal as written is a bit misleading: I would very 
like to keep seeing in 1.1.1 a majority of commits cherry-picked from commits 
merged to master, with explicit tags in the 1.1.1 commit messages (this helps 
keeping the git history self-contained without a too strong dependency on 
GitHub).
I would rephrase the proposal as follows:

Merge to 1.1.1 should only happen after approval of a dedicated PR 
targeting the OpenSSL_1_1_1-stable branch.

Potential amendments that I'd like the OTC to consider are:
a) before the end of the sentence add ", with the optional exclusion of trivial 
documentation-only changes"
b) after the end of the sentence add "In composing backport pull requests, 
explicit cherry-picking (`git cherry-pick -x`) of relevant commits merged to 
`master` or another stable branch is recommended and encouraged whenever 
possible."
c) adopt a more general statement:

Merge to any stable branch should only happen after approval of a dedicated 
PR targeting specifically that branch.




So, in summary, I would agree with the proposal, as I definitely think Bernd 
has a good point about running the 1.1.1 CI for things we think should be 
backported, but requires careful consideration of additional requirements to 
avoid duplicating review efforts, splitting discussions that should be kept 
together, or disrupting our processes making 1.1.1 and master diverge more than 
necessary.


Cheers,


Nicola

On Wed, 29 Apr 2020 at 14:08, Matt Caswell 
mailto:m...@openssl.org>> wrote:

The OTC have received this proposal and a request that we vote on it:

I would like to request that we do not allow cherry-picks between master
and 1.1.1-stable because these two versions are now very different, if a
cherry-pic

RE: Revisiting tradition: branches and tags

[Dr. Matthias St. Pierre]

> > We change the GitHub setup such that pull requests to stable
> > branches need to be based onto the new-style branches, but keep the
> > old-style stable branches in sync with the new-style branches for a
> > little while.
> 
> Er...  how do you change that Github setup?  I thought it simply
> showed a list of all available branches regardless.  So if we got a
> duplicate set, it's going to show both, isn't it?  Considering that
> the github repo is a --mirror of the git.openssl.org repo, I'm not
> sure how the old branch refs would be filtered out...

You are right, I thought it was possible using protected branches, but that
doesn't seem to be the case.

> 
> It seems to me like this discussion is splitting into two:
> 
> 1)  Start with new names for 3.0 and on (I can only see positive
> responses so far, even with Matt's hesitance)
> 2)  Rename of the old names.
>
> As far as I can see, those two don't have to be in absolute sync, even
> though that would be desirable.  In other words, we can figure out the
> details of 2 even after we've started 1.

Agreed.

The best thing would be to publicly announce the branch renaming in a blog post
with a sufficient notice time  (3-6 months) and with detailed instructions
how to rename the local branches and how to reset the upstream branches
(using `git branch --set-upstream-to=...`). Just as we did for the grand code 
reformatting. We might even provide a smart helper script for users to do the
local conversion.


Matthias

RE: Revisiting tradition: branches and tags

[Dr. Matthias St. Pierre]

> > Is it possible to set up alias names for the historical branches?
> 
> It's possible yes.  The hard part is 1.1.1.  There *is* something
> called 'git symbolic-ref', but they can only be added in repos we have
> physical access to, so while can add those on our git server, and they
> will work, we cannot add them in github.
> 
> Ref git help symbolic-ref

Symbolic references are *not* the right solution to the problem IMO. They are 
not equivalent to branches.
Checking out a symbolic reference leaves you in the 'detached HEAD' state:

msp@msppc:~/src/openssl$ git symbolic-ref ossl111 
refs/heads/OpenSSL_1_1_1-stable
msp@msppc:~/src/openssl$ cd ../openssl-1.1.1
msp@msppc:~/src/openssl-1.1.1$ git checkout ossl111
Note: switching to 'ossl111'.

You are in 'detached HEAD' state. You can look around, make experimental
changes and commit them, and you can discard any commits you make in this
state without impacting any branches by switching back to a branch.

The proper way to do it IMO is to create new branch and tag references for all 
the stable branches
resp. release tags. We change the GitHub setup such that pull requests to 
stable branches need to
be based onto the new-style branches, but keep the old-style stable branches in 
sync with the new-style
branches for a little while. Currently, the only old-style branch which needs 
to be synchronized is
` OpenSSL_1_1_1-stable`. This could easily be done by the git post-receive hook 
on git.openssl.org.
In fact, all old-style branch and tag references for all eol-branches could be 
removed immediately.

Matthias

RE: Revisiting tradition: branches and tags

[Dr. Matthias St. Pierre]

> Is it possible to set up alias names for the historical branches?

... and tags, of course. All one needs to do is to write a little script which 
creates the
additional references and pushes them.


Matthias

RE: Revisiting tradition: branches and tags

[Dr. Matthias St. Pierre]

I love the new naming scheme, in particular the fact that it's all-lowercase 
and does not
mix dashes and underscores anymore. I don't recall how often I cursed about the 
current
scheme which is so typer unfriendly.

I'd like to see *all* stable branch names and release tags converted to 
new-style uniformly
(keeping the old names for compatibility), so we have an overall consistent 
scheme and people
don't need to switch back and forth between naming conventions in the future 
when doing
historical investigations. The old names could be deprecated for later removal.

Matthias



> -Original Message-
> From: openssl-project  On Behalf Of 
> Richard Levitte
> Sent: Friday, April 10, 2020 8:28 PM
> To: openssl-project@openssl.org
> Subject: Revisiting tradition: branches and tags
> 
> Once upon a time, there was CVS (*).
> 
> The story could stop there, but since CVS was what was available,
> OpenSSL was versioned with CVS.
> 
> Among limitations that came with CVS was the allowed syntax in tag and
> branch names; letters, digits, dashes and underscores.  At the time,
> eveyone that wanted to encode a version number in a tag had to convert
> periods to some other character.  We chose underscores, ending up with
> tags like this:
> 
> OpenSSL_0_9_7-beta2
> OpenSSL_0_9_7a
> 
> Furthermore, the culture that we have with git, where branches are
> being pulled between repositories...  where you can actually have a
> multitude of repositories and pull data between them, was very hard if
> not practically impossible with CVS.  So, we occasionally had feature
> branches for longer term work.  To distinguish our so called stable
> branches, we had branch names with '-stable' added at the end:
> 
> OpenSSL_0_9_7-stable
> 
> We *could* have had something shorter, like 'OpenSSL_0_9_7xx', but
> I guess that was too easy to mix up with our letter releases.
> 
> With git, however, there's no technical reason why we must maintain
> what was originally a technical limitation.  I therefore propose that
> we start using tags like this starting with OpenSSL 3.0:
> 
> openssl-3.0.0-alpha1
> openssl-3.0.0-beta2
> openssl-3.0.0
> openssl-3.0.1
> openssl-3.1.0
> 
> This is a little more than just avoiding to change the periods with
> underscores.  However, if you look at the tar files we've released for
> a long time, that's the naming format they use, and I can see benefits
> in having the tags for a release match the tar file of the same
> release:
> 
> openssl-0.9.7a.tar.gz
> openssl-0.9.7a.tar.gz.asc
> openssl-0.9.7a.tar.gz.md5
> 
> Future tar files would be numbered with the new version scheme, of
> course:
> 
> openssl-3.0.0-alpha1.tar.gz
> openssl-3.0.0-beta2.tar.gz
> openssl-3.0.0.tar.gz
> openssl-3.0.1.tar.gz
> openssl-3.1.0.tar.gz
> 
> So what about release branches?  We could actually follow a very
> similar new pattern, just replace the last digit with, say, an 'x', to
> signify that this branch will contain a series of patch releases:
> 
> openssl-3.0.x
> 
> In this branch, one would expect to see the tags 'openssl-3.0.0',
> 'openssl-3.0.1', 'openssl-3.0.2', ...
> 
> Earlier today, I submitted a new release script that codifies exactly
> this:  https://github.com/openssl/openssl/pull/11516
> 
> Thoughts?
> 
> Cheers,
> Richard
> 
> (*) Well, not quite, there was RCS, there was SCCS, and a few other
> versioning systems that would make your skin crawl by today's
> standards, even more so than CVS.
> 
> --
> Richard Levitte levi...@openssl.org
> OpenSSL Project http://www.openssl.org/~levitte/

RE: 1.1.1f

[Dr. Matthias St. Pierre]

> Please also consider reverting the change for the 3.0 alpha release as well, 
> see Daniel Stenbergs comment
> https://github.com/openssl/openssl/issues/11378#issuecomment-603730581

Never mind my last comment. I noticed a lot of discussion has been going on in 
issue #11378 and I was not
quite up-to-date.

Matthias

RE: 1.1.1f

[Dr. Matthias St. Pierre]

I agree, go ahead.

Please also consider reverting the change for the 3.0 alpha release as well, 
see Daniel Stenbergs comment
https://github.com/openssl/openssl/issues/11378#issuecomment-603730581

Matthias


From: openssl-project  On Behalf Of Dmitry 
Belyavsky
Sent: Thursday, March 26, 2020 3:48 PM
To: Matt Caswell 
Cc: openssl-project@openssl.org
Subject: Re: 1.1.1f


On Thu, Mar 26, 2020 at 5:14 PM Matt Caswell 
mailto:m...@openssl.org>> wrote:
The EOF issue (https://github.com/openssl/openssl/issues/11378) has
resulted in us reverting the original EOF change in the 1.1.1 branch
(https://github.com/openssl/openssl/pull/11400).

Given that this seems to have broken quite a bit of stuff, I propose
that we do a 1.1.1f soon (possibly next Tuesday - 31st March).

Thoughts?

I strongly support this idea.

--
SY, Dmitry Belyavsky

RE: Release done

[Dr. Matthias St. Pierre]

Unfortunately, the server side hooks are not published anywhere. So I was not 
able to figure out
that there might be a problem. I should have given you a heads-up nevertheless, 
sorry for the omission.

Matthias


> -Original Message-
> From: Matt Caswell 
> Sent: Tuesday, March 17, 2020 8:29 PM
> To: Dr. Matthias St. Pierre ; 
> openssl-project@openssl.org
> Subject: Re: Release done
> 
> 
> 
> On 17/03/2020 18:53, Dr. Matthias St. Pierre wrote:
> >> Problems were due to:
> >> ...
> >> - Rename of CHANGES/NEWS to CHANGES.md/NEWS.md
> >
> > Strange  what exactly was your problem?
> 
> The website is supposed to update itself automatically when we push
> stuff, so things like release notes etc get automatically generated.
> From tools/release/README.md:
> 
> Verify that the release notes, which are built from the CHANGES file
> in the release, have been updated. This is done automatically by the
> commit-hook, but if you see a problem, try the following steps:
> 
> cd /var/www/openssl
> sudo -u openssl -H make relupd
> sudo -u openssl ./bin/purge-one-hour
> 
> This didn't happen unfortunately. When I ran "make relupd" manually I got:
> 
> make: *** No rule to make target
> '/var/cache/openssl/checkouts/openssl/CHANGES', needed by
> 'news/changelog.txt'.  Stop.
> 
> That particular make target is related to the *master* CHANGES file
> (there are similar targets I think for other branches).
> 
> Matt

RE: Release done

[Dr. Matthias St. Pierre]

> Problems were due to:
> ...
> - Rename of CHANGES/NEWS to CHANGES.md/NEWS.md

Strange  what exactly was your problem?

I anticipated this problem on the weekend and checked the release scripts.
After some investigation, I came to the conclusion that it wouldn't be a problem
for the OpenSSL_1_1_1-stable branch yet, because the markdown revamping
happened only on master. What did I miss?

Matthias


P.S.: As a byproduct of my investigations I created 
https://github.com/openssl/tools/pull/64

RE: My next step in handling stale PRs

[Dr. Matthias St. Pierre]

Hi Mark,

your proposal sounds reasonable, and I let me take the opportunity to pay a 
compliment to your bot,
he is doing a great job :-).

I have just a tiny little nit: since the sender is clearly identified as 
"openssl-machine", it is not necessary
to add a special prefix to the text of the message to indicate the message was 
automated. In fact, the
"ready-to-merge" reminder, which started it all, doesn't have a prefix.  But 
recently you started to
add various prefixes like "Automated Ping:" and now "openssl-machine:". I'd 
prefer if the messages
were consistently without a prefix, because they only distract from the gist of 
the message IMHO,
in particular consistency junkies like me.

Matthias

RE: OpenSSL Logo (was: New GitHub Project Landing Page)

[Dr. Matthias St. Pierre]

> On Thu, Feb 27, 2020 at 01:23:16PM +, Salz, Rich wrote:
> > Tony Arceri sent me a pure-CSS solution that worked and looked similar.
> 
> I was about to mention that the website it just text+css.
> 
> 
> Kurt

FYI: there is another discussion about the OpenSSL logo going on in pr #11200.
In particular this post contains a link to text+css of the OpenSSL logo:

https://github.com/openssl/openssl/pull/11200#issuecomment-592673575

Matthias

RE: OpenSSL Logo

[Dr. Matthias St. Pierre]

> According to that site, it used to be at
> 
> http://openssl.com/images/openssl-logo.png
>

Thanks to the Wayback Machine, nothing gets lost: Here is the historical 
OpenSSL Logo:

https://web.archive.org/web/20141231112717/http://openssl.com/images/openssl-logo.png

Matthias

New GitHub Project Landing Page

[Dr. Matthias St. Pierre]

The OpenSSL Project GitHub has a new landing page:

https://github.com/openssl/openssl

Scroll down. Enjoy.


Matthias

RE: Github PR label automation

[Dr. Matthias St. Pierre]

> check.  It will not move to 'ready to merge' state automatically
> unless (or until) all CI passes.  (I'll do a PR for the tool with that
> change shortly).

If the does not automatically remove the "ready to merge" label, but only
refrains from setting it automatically, that's a good compromise I can live 
with.

Matthias

RE: Github PR label automation

[Dr. Matthias St. Pierre]

> > Does it also check that the CI says that everything is OK?
>
> Do we want it to?  I assumed that Approval: done was not being applied
> unless tests past (but looking that's not always the case). Can we
> assume that something in "approval: ready to merge" but that failed CI
> won't get merged?  Otherwise I could add a CI check on the move to
> "ready to merge".

It does not check and I don't think it should attempt to do it. The only task of
this script should be to automatically promote the [approval: done] state to 
[approval: ready to merge] after the grace period has expired, because humans
tend to forget that. Anything beyond that, in particular an attempt to judge
whether the approval is valid or not, and whether a CI failure can be ignored or
not, should be left to humans.

Matthias

RE: Github PR label automation

[Dr. Matthias St. Pierre]

> -Original Message-
> From: openssl-project  On Behalf Of Mark 
> J Cox
> Sent: Saturday, February 8, 2020 8:52 PM
> To: Dmitry Belyavsky 
> Cc: openssl-project@openssl.org
> Subject: Re: Github PR label automation
> 
> Thanks Dmitry; I hope that the comment triggers notifications to the
> creator without mentioning them?  (let me know if you get something
> changed labels that doesn't)   Mark

In fact, it was my suggestion *not* to add personal mentions. Since anybody who 
has posted 
comments to the pull request (which includes the submitter and all reviewers) 
will be subscribed
to the pull request's thread, I think a general comment which addresses nobody 
specific (just like
our "ping" messages) is less intrusive.

Matthias

RE: Github PR label automation

[Dr. Matthias St. Pierre]

First of all, thank you Mark for implementing the notification daemon. You did 
a great job
and I think it's very useful. Here are some comments and thoughts about your 
last mail.

>  No doubt we'll use some tool user for this in the future.

Can't you just use an API-token generated for the openssl-machine account,
as the issue closing bot does?

A propos bot: I thought that GitHub provides official support for this kind of 
watch-bots
we are seeking and that they can be configured or programmed in an event driven 
fashion.
Executing specific actions (like setting labels or posting messages) in 
response to specific
GitHub events (approval added, change requested, timer expired, etc.) would 
have some
advantages compared to an external timer based approach. Did someone of you 
consider
this option and do some investigations in that direction? Please don't 
misinterpret my
question, I think that the current cron job solution is already a great 
improvement and
a big step forward.

> 2 If there were comments made after "approval: done" then I think we
> really ought to drop the "approval: done" label as the comments likely
> invalidated the approval. ...

I don't think that an *arbitrary comment* should automatically reset the 
approval state.
Anybody could just post a "nice job" comment or some side note. Resetting the 
approval
state could happen automatically if a *team member* posts a review with *change 
requests*.
But not in any other case (e.g. a change requests by a non-team member or an 
additional
approving review).

Also, I am strongly convinced that making the transition from the [approval: * 
review pending]
to the [approval:done] state should remain a *purely manual* state. I don't 
think it's a good idea
to leave this decision to an "artificial intelligence" whatsoever. And just 
counting whether the
number of approvals has reached the required minimum is too simplistic anyway.

Just imagine the pull request has reached the required number of reviews, but 
the
submitter or a reviewer is still waiting for another important outstanding 
review.
Do you really want the bot to interfere?

What about the existing approvals? They need to be dismissed if 'too much' has 
changed,
but not if the author pushed a trivial fixup addressing an approving review. Do 
you really
want to leave this decision to a bot?

This approach will just not work.

It is really almost no extra effort if we demand that the second reviewer sets 
the
[approval: done] label manually, unless he sees that there are still unresolved 
discussions
in progress. Only the grace period handling should be automated IMHO.

Regards,
Matthias

RE: Travis in solid red mode again

[Dr. Matthias St. Pierre]

> -Original Message-
> From: Matt Caswell 
> Sent: Sunday, February 2, 2020 12:58 AM
> To: Dr Paul Dale ; Dr. Matthias St. Pierre 
> 
> Cc: Salz, Rich ; openssl-project@openssl.org
> Subject: Re: Travis in solid red mode again
> 
> 
> 
> On 01/02/2020 10:39, Dr Paul Dale wrote:
> > I thought I was subscribed but don’t seem to see the failures.
> > I do get the (very many) PR activity emails….
> 
> Oh, actually, maybe I'm wrong. Is it just Appveyor that posts failures
> and not Travis?

I see both CI's posting in January:

https://mta.openssl.org/pipermail/openssl-commits/2020-January/thread.html

Broken: openssl/openssl#30961 (master - 2de5a5f)   Travis CI
Broken: openssl/openssl#30962 (OpenSSL_1_1_1-stable - 10e166a)   Travis CI
Build failed: openssl master.30389   AppVeyor
Build completed: openssl OpenSSL_1_1_1-stable.30390   AppVeyor
Fixed: openssl/openssl#30966 (master - e7b834b)   Travis CI
Fixed: openssl/openssl#30967 (OpenSSL_1_1_1-stable - 2c52a36)   Travis CI
Build failed: openssl master.30394   AppVeyor
Build completed: openssl OpenSSL_1_1_1-stable.30395   AppVeyor
Build failed: openssl master.30405   AppVeyor
Build completed: openssl master.30406   AppVeyor
Build failed: openssl master.30411   AppVeyor
Build failed: openssl master.30412   AppVeyor

RE: Travis in solid red mode again

[Dr. Matthias St. Pierre]

> I thought I was subscribed but don’t seem to see the failures.
> I do get the (very many) PR activity emails….

You are right, those “[openssl]  update” mails generate a lot
of noise. Do we really need them? If not, we could just deactivate them.
Alternatively, we could move the CI failures to a separate openssl-ci list.

Matthias

RE: Travis in solid red mode again

[Dr. Matthias St. Pierre]

> -Original Message-
> On 01/02/2020 00:34, Salz, Rich wrote:
> >
> >   >  Could we add a CI check for PRs that confirms that the target branch is
> > green in travis?
> >
> > Looking at 
> > https://docs.travis-ci.com/user/notifications/#conditional-notifications 
> > and https://config.travis-
> ci.com/ref/notifications/email it seems like it should be fairly easy 
> configure builds to do "send email to openssl-commits when builds on
> master fail"
> 
> We already have that.

Maybe we should make it a requirement that at least all OTC members subscribe 
to openssl-commits?

Matthias

RE: fips mode and key management

[Dr. Matthias St. Pierre]

> >distinguish those two cases. Maybe the name OSSL_FIPS_PROVIDER would be
> more fitting than FIPS_MODE?
> 
> 
> Or perhaps OPENSSL_BUILDING_FIPS, since a couple of PR's already have and use 
> OPENSSL_BUILDING_OPENSSL ...

OPENSSL_BUILDING_OPENSSL is really a remarkably long name.  I hope this does 
not blow up any commandline
length limits 😉. How about using OSSL_LIBRARY library instead? This would fit 
nicely to OSSL_FIPS_PROVIDER:

#ifdef OSSL_LIBRARY
...
#endif

#ifdef OSSL_FIPS_PROVIDER
...
#endif

> There's no reason to use OSSL for internal macros.

But it avoids unnecessary name clashes with system headers. Just today, I saw 
this collision with Windows headers:

include/openssl/types.h:74:#  undef OCSP_REQUEST
include/openssl/types.h:75:#  undef OCSP_RESPONSE

(Yes I know, Window headers are really polluting the global namespace).

RE: Build failures on master?!

[Dr. Matthias St. Pierre]

> With apologies for being a week behind on mail, but I didn't see any
> commits in the past week that look like they were targetted to fix external
> tests, and I see (E.g.)
> https://travis-ci.org/openssl/openssl/jobs/628003784?utm_medium=notification&utm_source=github_status
> succeeding (as well as my local build with the krb5 tests).  Are the
> external tests still failing?

I don't really understand what's going on, but it looks like job 19 fails 
intermittently: Job #30814.19 (the one you 
pointet out) succeeded, but #30827.19 failed. And afterwards #30846.19 
succeeded again.

- #30814.19 (two days ago): SUCCEEDED
  
https://travis-ci.org/openssl/openssl/jobs/628003784?utm_medium=notification&utm_source=github_status


- #30827.19 (23 hours ago): FAILED
  
https://travis-ci.org/openssl/openssl/jobs/628205488?utm_medium=notification&utm_source=github_status

Test Summary Report
---
95-test_external_krb5.t (Wstat: 256 Tests: 1 Failed: 1)
  Failed test:  1
  Non-zero exit status: 1
95-test_external_pyca.t (Wstat: 256 Tests: 1 Failed: 1)
  Failed test:  1
  Non-zero exit status: 1
Files=3, Tests=3, 225 wallclock secs ( 0.67 usr  0.05 sys + 112.06 cusr 
29.38 csys = 142.16 CPU)
Result: FAIL
Makefile:2893: recipe for target '_tests' failed
make[1]: *** [_tests] Error 1
make[1]: Leaving directory '/home/travis/build/openssl/openssl'
Makefile:2891: recipe for target 'tests' failed
make: *** [tests] Error 2
** FAILED -- MAKE TEST

- #30846.19 (2 hours ago) SUCCEEDED
  
https://travis-ci.org/openssl/openssl/jobs/628466771?utm_medium=notification&utm_source=github_status

There are other tests failing, too. If you look at the build history, you will 
hardly see any successful builds on
master and 1.1.1.

https://travis-ci.org/openssl/openssl/builds?utm_medium=notification&utm_source=github_status


Matthias

AW: Build failures on master?!

[Dr. Matthias St. Pierre]

Gentle reminder: it's almost a month since a started this thread, but the 
external pyca and krb5 
tests are still failing. Apart from complicating the review process, it also 
happens that people
are noticing the failures and are hesitating to update to the current tip of 
master [1].

IMHO chronically failing tests should be deactivated and an issue created for 
fixing them.

Matthias

[1] https://github.com/openssl/openssl/issues/9866#issuecomment-565714221

AW: Flaw in our process for dealing with trivial changes

[Dr. Matthias St. Pierre]

> On Thu, 12 Dec 2019 22:31:10 +0100,
> Dr Paul Dale wrote:
> >
> > A red blocker along the lines of: "Triviality Unconfirmed". One of
> > the reviewers needs to remove this before the PR can be merged.
> >
> > It's in our face, it prevent accidental merges and its low overhead.
> 
> I still think simply adding the label should be sufficient.  I dunno
> about you, but I look at labels all the time, for all sorts of
> reasons, and one saying [cla: trivial] would certainly attract my
> attention.
> 
> Let's make it bright red-orange, that'll catch anyone's eye (even mine)
> 
> Also, removing that label will rapidly be annoying as soon as someone
> closes and re-opens a PR...  or whatever other action that triggers
> the "pull_request" event (and there's a lot that does that...  our
> script is being kept busy!).
> 
> Cheers,
> Richard


This seems to be implied already by my last proposal, with just one color 
changed:   ;-)

> Add three mutually exclusive [cla: *] labels:

>   [cla: ok] (green)
>   [cla: trivial]   (orange)
>   [cla: missing](red)
>
> The CLA bot  *always* sets the [cla: ok] label if it finds a  CLA on file. 
> Otherwise, it sets the
> [cla: missing] label, unless the [cla: trivial] label is already set.
>
> The [cla: trivial] label can only be set manually by a committer, and only 
> after the consent
> between contributor and both reviewers has been reached.

Re: Flaw in our process for dealing with trivial changes

[Dr. Matthias St. Pierre]

> > The server-side commit hook ensures that
> >
> > - the "CLA: trivial" annotation is present in *all* commits of the PR if 
> > and only if the [cla: trivial]
> >   label is set.
> > - the [cla: ok] label is set if and only if the CLA is on file
> > - the pull request is accepted only if the [cla: ok] or [cla: trivial] 
> > label is set
> 
> 
> One issue with this bit is that it requires the git hooks to connect to
> github to check the labels. AFAIK we don't do that at present. Does it
> add too much complexity to the hooks?

Actually, the consistency checks could be done entirely by the addrev script, 
which already uses the GitHub API.

addrev:
=

Ensure that

- the [cla: ok] label is set if and only if the CLA is on file
- the [cla: trivial] label is set if and only if the "CLA: trivial" annotation 
is present in *all* commits of the PR

git commit hook
=

Accept pull request if and only if the CLA is on file or *all* commits have the 
"CLA: trivial" annotation.


(The git commit hook would need only a minimal change, if it does not check 
*all* commits yet.)

AW: Flaw in our process for dealing with trivial changes

[Dr. Matthias St. Pierre]

> On 12/12/2019 09:43, Paul Yang wrote:
> > Would it be better if 'CLA: trivial’ is in the commit message but no CLA
> > on file, then a new label like ’warn: no CLA but trivial’ is added? This
> > can inform the committer who will merge the PR for the CLA condition of
> > the commits.
> >
> 
> Yes, I think that would be a really good idea. At least then its very
> visible what is happening.

Reusing Tim's words I'd like to argue that we should avoid rushing for a 
premature optimization.

- Just adding new labels does not solve anything, at least as long as those 
labels
  are not enforced automatically. (via GitHub bot & git hook)

- This is the first time in quite a while that a pull request with a 
questionable
  trivial CLA has slipped in and it is no problem to revert a commit if 
necessary.
  So I wouldn't consider it a significant problem. The best countermeasure IMHO
  is to adopt the habit of skimming over the last GitHub messages of the PR and
  to reread the final commit messages (after the "Reviewed-by:" annotations have
  been added) before pushing the final commit.


As for a possible semi-automated solution:

The problem is more fundamental: currently both the GitHub bot and the git 
commit hook
only watch out for the 'CLA: trivial' marker. But this marker is intended to be 
added
by the *contributor* himself, so it expresses only his opinion, not ours. Only 
if all three,
the contributor and the two reviewers agree, then the pull request can be 
considered
trivial.

One possible solution to this problem could be the following procedure: 

Add three mutually exclusive [cla: *] labels:

  [cla: ok] (green)
  [cla: trivial]   (green)
  [cla: missing](red)

The CLA bot  *always* sets the [cla: ok] label if it finds a  CLA on file. 
Otherwise, it sets the
[cla: missing] label, unless the [cla: trivial] label is already set.

The [cla: trivial] label can only be set manually by a committer, and only 
after the consent
between contributor and both reviewers has been reached.

The server-side commit hook ensures that

- the "CLA: trivial" annotation is present in *all* commits of the PR if and 
only if the [cla: trivial]
  label is set.
- the [cla: ok] label is set if and only if the CLA is on file
- the pull request is accepted only if the [cla: ok] or [cla: trivial] label is 
set


Matthias

AW: Check NULL pointers or not...

[Dr. Matthias St. Pierre]

FYI: there was a related discussion a year ago on GitHub about an 
ossl_is_null() macro,

https://github.com/openssl/openssl/pull/7218

which ended up undecided.

Matthias

AW: AW: Build failures on master?!

[Dr. Matthias St. Pierre]

> > Yes I know. I was just counting the last consecutive failures. What 
> > actually wonders
> > me is the fact that the tests do not fail throughout. In between there are 
> > always short
> > periods where the tests succced. Why is this?
> 
> Really? I don't see that. The travis dashboard shows red for as far back
> as I checked:
> 
> https://travis-ci.org/openssl/openssl/builds
> 

Interesting. I was just scrolling down the commits in the timeline of master:

https://github.com/openssl/openssl/commits/master

there are a lot of (clickable) red crosses next to the commits.

The last commits without red crosses are some of yours:

https://github.com/openssl/openssl/commits/11d876df50d90ec4b26364c4b7d317ea19139e13

Note that they don't show any sign of success, only the red cross is missing.

I have no idea what the difference between those commits with and without red 
crosses is,
if travis is failing all the time.

Natthias

AW: Build failures on master?!

[Dr. Matthias St. Pierre]

> > The last 19 commits on https://github.com/openssl/openssl/commits/master,
> > starting from Nov 14 have a red cross from the CIs. What's going on again?
> > My personal impression is that builds on master are failing 50% of the time.
> 
> The builds on master have been failing for *much* longer than that. They
> should be succeeded on the PRs, but its the extended tests that fail.

Yes I know. I was just counting the last consecutive failures. What actually 
wonders
me is the fact that the tests do not fail throughout. In between there are 
always short
periods where the tests succced. Why is this?

The reason why I issued this cry for help is because after watching it for a 
long time I
got the impression that due to the ongoing failures everybody has become dull 
and
indifferent agains the red crosses.

Matthias

Build failures on master?!

[Dr. Matthias St. Pierre]

The last 19 commits on https://github.com/openssl/openssl/commits/master,
starting from Nov 14 have a red cross from the CIs. What's going on again?
My personal impression is that builds on master are failing 50% of the time.

It is really tedious to check pull requests for build errors just to find that 
those errors
are well known failures from master. In particular, the krb5 an pyca tests are 
notoriously
failing. Are there any plans to fix them or disable them?

  95-test_external_krb5.t (Wstat: 256 Tests: 1 Failed: 1)
  95-test_external_pyca.t (Wstat: 256 Tests: 1 Failed: 1)

Clean builds on master should have highest priority. Because if there are too 
many red
crosses, nobody cares about them anymore.

Matthias

AW: Re-requesting reviews on GitHub

[Dr. Matthias St. Pierre]

> Independently of the new 'approval: *' state labelling I was wondering 
> whether it wouldn't
> be a good idea to adopt the habit of explicitly requesting a re-review from 
> the other reviewers
> after significant changes, using the mechanism provided by GitHub (i.e. the 
> button with the two

To be more precise: not all reviews need to be invalidated by requesting a 
re-review, only the approvals.

Re-requesting reviews on GitHub

[Dr. Matthias St. Pierre]

Independently of the new 'approval: *' state labelling I was wondering whether 
it wouldn't
be a good idea to adopt the habit of explicitly requesting a re-review from the 
other reviewers
after significant changes, using the mechanism provided by GitHub (i.e. the 
button with the two
circling arrows next to the reviewer entry). In that way, outdated reviews 
would become more
visible, and outdated reviews wouldn't be addrev'ed to the commit message when 
merging,
unless they are renewed before the 24h grace period expires.  For nit changes, 
the current informal
way of re-approval could be kept of course.

What's your opinion?

Matthias

AW: Confirmed bug labels

[Dr. Matthias St. Pierre]

A similar problem applies to 'issue: feature request'.  Just having a 
'confirmed' label for bugs
wouldn't help in that case.

So what do you think about adding a new 'triaged: *' family of labels, in 
addition to 'issue: *'?

'triaged: bug'
'triaged: feature'
etc.

If this seems too verbose, then we could just omit the triaged prefix:

'bug'
'feature'
etc.

Matthias

> -Ursprüngliche Nachricht-
> Von: openssl-project  Im Auftrag von 
> Matt Caswell
> Gesendet: Dienstag, 29. Oktober 2019 10:23
> An: openssl-project@openssl.org
> Betreff: Confirmed bug labels
> 
> Do we need a "confirmed bug" or similar label? I was looking at #10283
> which is labelled with "issue: bug report". But this only tells us that
> the reporter thought it was a bug. I wanted to add a label confirming
> that it really is a bug...but nothing suitable seems to be there.
> 
> Matt

Re: New GitHub labels for pull request and issues - 24 hour grace period

[Dr. Matthias St. Pierre]

Note: names might still undergo some fine tuning. For example, 

[issue: missing documentation]

was just changed to 

[issue: documentation]

to encompass both missing documentation and errors in documentation.

Matthias


> -Ursprüngliche Nachricht-
> Von: openssl-project  Im Auftrag von Dr. 
> Matthias St. Pierre
> Gesendet: Samstag, 26. Oktober 2019 15:40
> An: openssl-project@openssl.org
> Betreff: New GitHub labels for pull request and issues - 24 hour grace period
> 
> Hi all,
> 
> some of you contributors might have already noticed that the labels which
> are attached to the GitHub pull requests and issues have changed.
> During the face to face meeting it was decided to cleanup some of the
> unused labels and to organize the labelling more systematically to match
> our review and merging process.
> 
> The following gives you a brief outline of the changes. Wordings are mine
> and not authoritative. An official policy update by the OMC will follow.
> 
> It was decided by the OMC that starting from now on all committers need
> to wait for a grace period of (currently) 24 hours after the approval of
> a pull request has completed (which happens when it has the necessary
> number of approvals) before they are allowed to merge the pull request
> to the target branch(es). The two different states are indicated by labels
> ([approval: done] and [ready to merge]). The 24 hour policy will be endorsed
> by a server side git hook and a github bot which which controls the
> [ready to merge] label. There are limited exceptional cases in which a
> committer can manually set the [ready to merge] label to merge earlier.
> (e.g. during the release process).
> 
> Below is a brief overview over the most important new labels. For a full list
> and for explaining comments, see
> 
> https://github.com/openssl/openssl/labels
> 
> Matthias
> 
> 
> --
> 
> 
> *Branch labels*
> 
> [branch: master]
> [branch: x.y.z]
> 
> Branch labels serve as indication of all target branches to
> which the pull request is going to be merged. Approval of
> reviewers applies to all target branches, provided the commits
> can be cherry-picked cleanly. If that's not the case, a separate
> pull request needs to be made.
> 
> If there is no branch label, then the github target branch of the
> pull request is assumed. However, in the future we try to be explicit
> by allways adding the target branch (e.g., [branch: master]).
> 
> 
> * Review progress labels*
> 
>   [approval: review pending]
>   [approval: omc review pending]
>   [approval: done]
> 
>   ...24 hour grace period...
>   [ready to merge]
> 
> 
> * Hold labels*
> 
> Those labels act as blockers and prevent a pull request from
> being merged.
> 
>   [hold: cla required]  (set by the cla bot, replaces [need-cla], WIP)
>   [hold: license clash]
>   [hold: need omc decision]
> 
> 
> * Issue type labels*
> 
> The following labels are going to be set automatically by the issue templates
> (see pull request https://github.com/openssl/openssl/pull/10266)
> Templates for the starred labels are still to be done.
> 
>   [issue: bug report]
>   [issue: feature request]
>   [issue: missing documentation] *
>   [issue: question] *

Correction: New GitHub labels for pull request and issues - 24 hour grace period

[Dr. Matthias St. Pierre]

One small error happened w.r.t. branch labels: they are

*Branch labels*

[branch: master]
[branch: x.y.z]

New GitHub labels for pull request and issues - 24 hour grace period

[Dr. Matthias St. Pierre]

Hi all,

some of you contributors might have already noticed that the labels which
are attached to the GitHub pull requests and issues have changed.
During the face to face meeting it was decided to cleanup some of the
unused labels and to organize the labelling more systematically to match
our review and merging process.

The following gives you a brief outline of the changes. Wordings are mine
and not authoritative. An official policy update by the OMC will follow.

It was decided by the OMC that starting from now on all committers need
to wait for a grace period of (currently) 24 hours after the approval of
a pull request has completed (which happens when it has the necessary
number of approvals) before they are allowed to merge the pull request
to the target branch(es). The two different states are indicated by labels
([approval: done] and [ready to merge]). The 24 hour policy will be endorsed
by a server side git hook and a github bot which which controls the
[ready to merge] label. There are limited exceptional cases in which a
committer can manually set the [ready to merge] label to merge earlier.
(e.g. during the release process).

Below is a brief overview over the most important new labels. For a full list
and for explaining comments, see

https://github.com/openssl/openssl/labels

Matthias


--


*Branch labels*

[branch.x.y.z]

Branch labels serve as indication of all target branches to
which the pull request is going to be merged. Approval of
reviewers applies to all target branches, provided the commits
can be cherry-picked cleanly. If that's not the case, a separate
pull request needs to be made.

If there is no branch label, then the github target branch of the
pull request is assumed. However, in the future we try to be explicit
by allways adding the target branch (e.g., [branch: master]).


* Review progress labels*

[approval: review pending]
[approval: omc review pending]
[approval: done]

...24 hour grace period...
[ready to merge]


* Hold labels*

Those labels act as blockers and prevent a pull request from
being merged.

[hold: cla required]  (set by the cla bot, replaces [need-cla], WIP)
[hold: license clash]
[hold: need omc decision]


* Issue type labels*

The following labels are going to be set automatically by the issue templates
(see pull request https://github.com/openssl/openssl/pull/10266)
Templates for the starred labels are still to be done.

[issue: bug report]
[issue: feature request]
[issue: missing documentation] * 
[issue: question] *

Commit access to openssl/tools and openssl/web

[Dr. Matthias St. Pierre]

Dear OMC,

while the process of merging and committing to openssl/openssl has been 
formalized,
no similar (official) rules for pull requests by non-OMC-member seem to apply 
to the
other two repositories openssl/tools and openssl/web. Probably it's because 
hardly
anybody outside the OMC else ever raises them? Or is it the other way around?

I would like to raise the question whether it wouldn't be beneficial for all of 
us,
if we would apply the same rules (commit access for all committers, plus the 
well
known approval rules) to all of our repos. After all, the openssl/openssl 
repository
is the most valuable of the three and I see no reason why the others would need
more protection. In the case of the openssl/web repository which targets the
official website, you might want to consider a 2OMC approval rule, but even 
there
I don't see why the usual OMC veto rule wouldn't be sufficient.

Regards,
Matthias