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

Re: OpenSSL Logo

[Matthias St. Pierre]

Well then, if Tomáš manages to convert it to SVG and if there is no problem
with the font, you may raise a pull request. (BTW: what is the font's name?)

Please note that you might have to enlarge the bounding box to increase
the border around the text. Because GitHub will automatically scale the
image to full width on https://github.com/openssl/openssl and there is no
way to downsize the image if we restrict ourselves to plain markdown
(i.e. without adding inline HTML).  See [1] for an example.


Matthias


[1] https://github.com/openssl/openssl/blob/master/doc/images/openssl.svg



On 27.02.20 14:08, Paul Yang wrote:

Right, there is no 3D.

Regards,

Paul Yang


On Feb 27, 2020, at 6:54 PM, Tomas Mraz mailto:tm...@redhat.com>> wrote:

On Thu, 2020-02-27 at 11:28 +0100, Matthias St. Pierre wrote:

Thank you for the clarification, Mark.

So this means we have some artistic freedom in choosing the logo?

Personally, I'm not sure whether we really should aim at restoring
the historic logo. IMHO this ornate font with 3D appearance reminds
me of the nineties and has slightly gone out of style. Just take a
look
how the Google logo changed over time [1], for example.

I think it's time for a more modern layout. Let's have a competition.


I like the logo as sent by Paul. There is no "3D appearance" in it.

--
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: OpenSSL Logo

[Matthias St. Pierre]

Sorry for linking a german page (although the video is english).

This seems to be the corresponding english version.

https://googleblog.blogspot.com/2015/09/google-update.html



On 27.02.20 11:28, Matthias St. Pierre wrote:

Thank you for the clarification, Mark.

So this means we have some artistic freedom in choosing the logo?

Personally, I'm not sure whether we really should aim at restoring
the historic logo. IMHO this ornate font with 3D appearance reminds
me of the nineties and has slightly gone out of style. Just take a look
how the Google logo changed over time [1], for example.

I think it's time for a more modern layout. Let's have a competition.

Matthias



[1] https://germany.googleblog.com/2015/09/google-update.html

Re: OpenSSL Logo

[Matthias St. Pierre]

Thank you for the clarification, Mark.

So this means we have some artistic freedom in choosing the logo?

Personally, I'm not sure whether we really should aim at restoring
the historic logo. IMHO this ornate font with 3D appearance reminds
me of the nineties and has slightly gone out of style. Just take a look
how the Google logo changed over time [1], for example.

I think it's time for a more modern layout. Let's have a competition.

Matthias



[1] https://germany.googleblog.com/2015/09/google-update.html



On 27.02.20 11:16, Mark J Cox wrote:

On Thu, Feb 27, 2020 at 9:31 AM Matthias St. Pierre
 wrote:

Because after all, the shape of the logo is an
essential part of the OpenSSL 'trade mark'.

Although the current website logo as of January 2020 was used as the
specimen to show our use of the trademark at renewal time, our
official trademark registration is a standard character mark:  i.e.
"The mark consists of standard characters without claim to any
particular font style, size, or color.".

Regards, Mark

Re: OpenSSL Logo

[Matthias St. Pierre]

The logo on this site

https://unixblogger.com/how-to-convert-split-p12-certificates-into-single-files/

seems to be very similar to the one on your stickers, Paul.

According to that site, it used to be at

http://openssl.com/images/openssl-logo.png

It even has a (TM) marker. Can the OMC please clarify whether this is the
current official OpenSSL logo? And if it is, point us to a location where the
original file can be found?

Matthias




On 27.02.20 10:31, Matthias St. Pierre wrote:


The openssl.svg was chosen to match the current logo at

https://www.openssl.org/

as close as possible. According to the style sheet, the font of the logo
is HelveticaNeue-Light.

https://github.com/openssl/web/blob/master/inc/screen.css#L131-L158

While I'm not opposed to brush up the OpenSSL logo, I think this can't
be done simply be replacing it on the fly. I think this requires a general
discussion among the team members and finally an OMC decision,
and shouldn't be rushed. Because after all, the shape of the logo is an
essential part of the OpenSSL 'trade mark'.

If we we want to brush up the Logo, we should give everybody time to come up
with proposals and then have an open contest, ideally among all committers,
not only OMC or OTC.  (And you can be sure, I will come up with a proposal ;-) )

Finally, the OMC can run a vote, for example whether to pick the winner of the
contest or to leave the logo as it is.

Regards,

Matthias



On 27.02.20 09:58, Paul Yang wrote:

Sent

Regards,

Paul Yang


On Feb 27, 2020, at 3:15 PM, Tomas Mraz mailto:tm...@redhat.com>> wrote:

Could you, please, send me the .ai file? I'll try converting it. Is the
font freely available?

Tomas

On Thu, 2020-02-27 at 14:17 +0800, Paul Yang wrote:

The logo could be changed to the 'correct-font' version -as the one
printed on the stickers I brought to Nuremberg

I have an '.ai’ image file at hand an I think someone needs to figure
how to extract the image then include it in the markdown file...

Regards,

Paul Yang

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

[Matthias St. Pierre]

The openssl.svg was chosen to match the current logo at

https://www.openssl.org/

as close as possible. According to the style sheet, the font of the logo
is HelveticaNeue-Light.

https://github.com/openssl/web/blob/master/inc/screen.css#L131-L158

While I'm not opposed to brush up the OpenSSL logo, I think this can't
be done simply be replacing it on the fly. I think this requires a general
discussion among the team members and finally an OMC decision,
and shouldn't be rushed. Because after all, the shape of the logo is an
essential part of the OpenSSL 'trade mark'.

If we we want to brush up the Logo, we should give everybody time to come up
with proposals and then have an open contest, ideally among all committers,
not only OMC or OTC.  (And you can be sure, I will come up with a proposal ;-) )

Finally, the OMC can run a vote, for example whether to pick the winner of the
contest or to leave the logo as it is.

Regards,

Matthias



On 27.02.20 09:58, Paul Yang wrote:

Sent

Regards,

Paul Yang


On Feb 27, 2020, at 3:15 PM, Tomas Mraz mailto:tm...@redhat.com>> wrote:

Could you, please, send me the .ai file? I'll try converting it. Is the
font freely available?

Tomas

On Thu, 2020-02-27 at 14:17 +0800, Paul Yang wrote:

The logo could be changed to the 'correct-font' version -as the one
printed on the stickers I brought to Nuremberg

I have an '.ai’ image file at hand an I think someone needs to figure
how to extract the image then include it in the markdown file...

Regards,

Paul Yang

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

[Matthias St. Pierre]

On 14.02.20 10:21, Matthias St. Pierre wrote:


Because deprecation without removal is futile, it increases complexity of the 
code
instead of reducing it.

Matthias



To underlinie my last statement, I added the initial release dates:

    OPENSSL_NO_DEPRECATED_0_9_8  # 05 Jul 2005
    OPENSSL_NO_DEPRECATED_1_0_0  # 29 Mar 2010
    OPENSSL_NO_DEPRECATED_1_0_1  # 14 Mar 2012

Re: Deprecation

[Matthias St. Pierre]

On 14.02.20 08:24, Tomas Mraz wrote:


I do not understand the pushback too much - Perhaps it could be
resolved by proper explanation that deprecation does not mean a
removal?

Also even if some stuff deprecated in 3.0 is removed in 4.0, it does
not necessarily mean that engines must be removed in the same release.
They can continue to be supported (just deprecated) until 5.0 for
example.

I think that doing the deprecation as early as possible is better - it
properly gives the signal that the engine interface is legacy and it
will disappear at some point. It provides more time for 3rd party
engines to transform into providers.



I agree with Tomas. In addition, I think it is high time to publish a definite 
timescale
for actually *removing* the older deprecated APIs, at least for the first three 
entries
in the list below:

    OPENSSL_NO_DEPRECATED_0_9_8  #
    OPENSSL_NO_DEPRECATED_1_0_0  #
    OPENSSL_NO_DEPRECATED_1_0_1  #

    OPENSSL_NO_DEPRECATED_1_0_2
    OPENSSL_NO_DEPRECATED_1_1_0
    OPENSSL_NO_DEPRECATED_1_1_1
    OPENSSL_NO_DEPRECATED_3_0

Because deprecation without removal is futile, it increases complexity of the 
code
instead of reducing it.

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

[Matthias St. Pierre]

Well, nobody else seems to care; In this case, I would like to suggest that you
disable the enable-msan build and create an issue for fixing it.

Matthias

On 07.02.20 10:53, Matt Caswell wrote:


On 03/02/2020 19:19, Matthias St. Pierre wrote:

Mission accomplished, Travis just turned green again on master  :-)

Every one of the last 12 master jobs have failed to complete
successfully due to a travis timeout. Apart from the build that is
timing out (enable-msan), all the other builds in the job are green.

Matt


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


Thanks to Matt, Richard and everybody else who participated in fixing it.


Matthias

Re: Travis in solid red mode again

[Matthias St. Pierre]

Mission accomplished, Travis just turned green again on master  :-)

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

Thanks to Matt, Richard and everybody else who participated in fixing it.


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

Travis in solid red mode again

[Matthias St. Pierre]

After a much to short green period, Travis has turned to solid red mode again:

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

This fact causes a lot of pain for reviewers, because every failing job needs 
to be checked manually.
I would be happy to fix some of the failures if I could, but in most cases I 
have no clue what the problem is,
because I can't reproduce the issue locally. Could we try to fix them in a 
joint effort?  For your convenience,
I added a summary of all failing jobs of Build #31837 below.

Since this is not the first time that this happens, I think it is overdue that 
the OTC discusses those constant
build failures and proposes some measures to raise the priority for fixing CI 
errors. One drastic possibility
would be to allow only CI fixing pull requests to be merged as long as master 
and the stable branches are red.
But I am sure there is a golden middle way between such an extreme sanction and 
our current indifference.


Regards,

Matthias






Last Successful Build: #31583 (10 days ago!)
https://travis-ci.org/openssl/openssl/builds/639939072?utm_medium=notification&utm_source=github_status

Recent Build: #31837
https://travis-ci.org/openssl/openssl/builds/644238908?utm_medium=notification&utm_source=github_status


SSL TESTS
=

* 
https://travis-ci.org/openssl/openssl/jobs/644238919?utm_medium=notification&utm_source=github_status
* 
https://travis-ci.org/openssl/openssl/jobs/644238926?utm_medium=notification&utm_source=github_status
* 
https://travis-ci.org/openssl/openssl/jobs/644238929?utm_medium=notification&utm_source=github_status

>  Test Summary Report
> ---
>  80-test_ssl_new.t    (Wstat: 256 Tests: 30 Failed: 1)
>    Failed test:  4
>    Non-zero exit status: 1
>  80-test_ssl_old.t    (Wstat: 256 Tests: 6 Failed: 1)
>    Failed test:  2
>    Non-zero exit status: 1



BORINGSSL AND KRB5
==

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

> Test Summary Report
> ---

> 95-test_external_boringssl.t (Wstat: 256 Tests: 1 Failed: 1)
>   Failed test:  1
>   Non-zero exit status: 1
> 95-test_external_krb5.t (Wstat: 256 Tests: 1 Failed: 1)
>   Failed test:  1
>   Non-zero exit status: 1



95-test_external_boringssl.t:
---

    grep 'go.*FAILED' t
    go test: FAILED (SSL3-Client-ClientAuth-RSA)
    go test: FAILED (SSL3-Server-ClientAuth-RSA)
    go test: FAILED (ClientAuth-Sign-RSA-SSL3)
    go test: FAILED (ClientAuth-InvalidSignature-RSA-SSL3)
    go test: FAILED (CertificateVerificationSucceed-Server-SSL3-Sync)
    go test: FAILED 
(CertificateVerificationSucceed-Server-SSL3-Sync-SplitHandshakeRecords)
    go test: FAILED 
(CertificateVerificationSucceed-Server-SSL3-Sync-PackHandshakeFlight)
    go test: FAILED (CertificateVerificationSucceed-Server-SSL3-Async)
    go test: FAILED 
(CertificateVerificationSucceed-Server-SSL3-Async-SplitHandshakeRecords)
    go test: FAILED 
(CertificateVerificationSucceed-Server-SSL3-Async-PackHandshakeFlight)



95-test_external_krb5.t:
---

    LD_LIBRARY_PATH=`echo -L../../../lib | sed -e "s/-L//g" -e "s/ /:/g"` 
KRB5_CONFIG=../../../config-files/krb5.conf LC_ALL=C ./t_nfold
    N-fold
    Input:    "basch"
    192-Fold: 1aab6b42 964b98b2 1f8cde2d 2448ba34 55d7862c 9731643f
    Input:    "eichin"
    192-Fold: 65696368 696e4b73 2b4b1b43 da1a5b99 5a58d2c6 d0d2dcca
    Input:    "sommerfeld"
    192-Fold: 2f7a9855 7c6ee4ab adf4e711 92dd442b d4ff5325 a5def75c
    Input:    "MASSACHVSETTS INSTITVTE OF TECHNOLOGY"
    192-Fold: db3b0d8f 0b061e60 3282b308 a5084122 9ad798fa b9540c1b
    RFC tests:

    ...

    Generating random keyblock: . . . OK
    Creating opaque key from keyblock: . . . OK
    Encrypting (c): . . . Failed: Cannot allocate memory <===ALLOC FAILURE==
    Aborted (core dumped) 
<===CORE DUMPED==
    Makefile:684: recipe for target 'check-unix' failed
    make[5]: *** [check-unix] Error 134
    make[5]: Leaving directory 
'/home/travis/build/openssl/openssl/krb5/src/lib/crypto/crypto_tests'
    Makefile:1107: recipe for target 'check-recurse' failed
    make[4]: *** [check-recurse] Error 1
    make[4]: Leaving directory 
'/home/travis/build/openssl/openssl/krb5/src/lib/crypto'
    Makefile:992: recipe for target 'check-recurse' failed
    make[3]: *** [check-recurse] Error 1
    make[3]: Leaving directory '/home/travis/build/openssl/openssl/krb5/src/lib'
    Makefile:1533: recipe for target 'check-recurse' failed
    make[2]: *** [check-recurse] Error 1
    make[2]: Leaving directory '/home/travis/build/openssl/openssl/krb5/src'
    ../../util/shlib_wrap.sh ../recipes/95-test_external_krb5_data/krb5.sh => 2
    not ok 1 - running krb5 tests

Re: New Committer

[Matthias St. Pierre]

Congratulations, David! And welcome to the team!

Matthias


On 31.01.20 15:48, Matt Caswell wrote:

I'd like to announce that David von Oheimb has joined our team of
committers! David has been particularly active recently with the CMP
contribution - but also has numerous other PRs and commits to his name.

Welcome David!

Matt

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: fips mode and key management

[Matthias St. Pierre]

BTW: the following build time constant with the remarkably long name seems to 
be intended for
a related purpose,  but it is currently completely unused?

    Configurations/00-base-templates.conf:  lib_defines => [ 
'OPENSSL_BUILDING_OPENSSL' ],

Re: fips mode and key management

[Matthias St. Pierre]

On 21.01.20 10:36, Richard Levitte wrote:

I think that the misunderstanding lies in when FIPS_MODE is defined.


Reading this sentence it occurred to me that the misunderstanding comes from
the fact that the define is indeed misnamed. The term "FIPS mode" is a relict
from FIPS 2.0, where the OpenSSL 1.0.x library had an API to enable FIPS mode
*at runtime*.

(Note that the *compile time* option to include the FOM was called OPENSSL_FIPS,
not FIPS_MODE. So the misleading name must have crept in only recently.)


It's defined when the FIPS provider module is being built, never otherwise.


Exactly, in OpenSSL 3.0 the DEFAULT and the FIPS provider are partially built 
from
the same source files, which is the reason why we need a build time constant to
distinguish those two cases. Maybe the name OSSL_FIPS_PROVIDER would be
more fitting than FIPS_MODE?


    #ifdef OSSL_FIPS_PROVIDER
    ...
    #endif


Matthias


P.S: Even though it is an internal define, it should have an OSSL_ prefix IMHO.
P.P.S: Optionally, one could also #define an OSSL_DEFAULT_PROVIDER, 
OSSL_LEGACY_PROVIDER, ...

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.