OTC Vote: Backport PR #19681 to 3.0 as a bug fix

[Nicola Tuveri]

Topic: Backport PR #19681 to 3.0 as a bug fix
Comment: Fundamentally OTC must decide if in the 3.0 release we should
 honor OSSL_PKEY_PARAM_EC_POINT_CONVERSION_FORMAT as set (and
 default to UNCOMPRESSED) in our provider implementations, and
 apply corresponding changes for handling legacy keys.
Proposed by: Nicola Tuveri
Issue link: https://github.com/openssl/technical-policies/issues/60
Public: yes
Opened: 2022-12-01
Closed: -MM-DD
Accepted:  yes/no  (for: X, against: Y, abstained: Z, not voted: W)

  Dmitry [  ]
  Matt   [  ]
  Pauli  [  ]
  Tim[  ]
  Hugo   [  ]
  Richard[  ]
  Shane  [  ]
  Tomas  [  ]
  Kurt   [  ]
  Matthias   [  ]
  Nicola [+1]

Re: OTC Vote: Accept PR #19681 in 3.1 subject to normal review process

[Nicola Tuveri]

The vote is now closed as accepted.

As recorded [0], the final tally was:

~~~
Topic: Accept PR #19681 in 3.1 subject to normal review process
Comment: Fundamentally OTC must decide if in the 3.1 release we should
 honor OSSL_PKEY_PARAM_EC_POINT_CONVERSION_FORMAT as set (and
 default to UNCOMPRESSED) in our provider implementations, and
 apply corresponding changes for handling legacy keys.
Proposed by: Nicola Tuveri
Issue link: https://github.com/openssl/technical-policies/issues/59
Public: yes
Opened: 2022-11-15
Closed: 2022-11-27
Accepted:  yes  (for: 7, against: 0, abstained: 2, not voted: 2)

  Dmitry [+1]
  Matt   [+0]
  Pauli  [ 0]
  Tim[+1]
  Hugo   [+1]
  Richard[+1]
  Shane  [+1]
  Tomas  [+1]
  Kurt   [  ]
  Matthias   [  ]
  Nicola [+1]
~~~

[0]: 
https://github.com/openssl/technical-policies/blob/master/votes/vote-20221115-honor-point-conversion-format-in-3.1.txt

Re: [External] : OTC Vote: Accept PR #19681 in 3.1 subject to normal review process

[Tomas Mraz]

Hi Shane,

can you please cast the vote in the GH issue linked?

Tomas

On Tue, 2022-11-15 at 20:40 +, Shane Lontis wrote:
> Vote [+1]
> I view this as a bug fix.
> From: openssl-project  on behalf
> of Nicola Tuveri 
> Sent: Wednesday, November 16, 2022 1:00 AM
> To: OpenSSL Project 
> Subject: [External] : OTC Vote: Accept PR #19681 in 3.1 subject to
> normal review process
>  
> Topic: Accept PR #19681 in 3.1 subject to normal review process
> Comment: Fundamentally OTC must decide if in the 3.1 release we
> should
>  honor OSSL_PKEY_PARAM_EC_POINT_CONVERSION_FORMAT as set (and
>  default to UNCOMPRESSED) in our provider implementations,
> and
>  apply corresponding changes for handling legacy keys.
> Proposed by: Nicola Tuveri
> Issue link:
> https://urldefense.com/v3/__https://github.com/openssl/technical-policies/issues/59__;!!ACWV5N9M2RV99hQ!OqxV4GXROeksWaZKdnkB2ZxFaBT1TMeCLMYCMBN_CfR0LiFEzx5F_7W1GJsGD8ObcYVsuXTdGuyPaZKP$
> Public: yes
> Opened: 2022-11-15
> Closed: -MM-DD
> Accepted:  yes/no  (for: X, against: Y, abstained: Z, not voted: W)
> 
>   Dmitry [  ]
>   Matt   [  ]
>   Pauli  [  ]
>   Tim    [  ]
>   Hugo   [  ]
>   Richard    [  ]
>   Shane  [  ]
>   Tomas  [  ]
>   Kurt   [  ]
>   Matthias   [  ]
>   Nicola [+1]

-- 
Tomáš Mráz, OpenSSL

Re: [External] : OTC Vote: Accept PR #19681 in 3.1 subject to normal review process

[Shane Lontis]

Vote [+1]
I view this as a bug fix.

From: openssl-project  on behalf of Nicola 
Tuveri 
Sent: Wednesday, November 16, 2022 1:00 AM
To: OpenSSL Project 
Subject: [External] : OTC Vote: Accept PR #19681 in 3.1 subject to normal 
review process

Topic: Accept PR #19681 in 3.1 subject to normal review process
Comment: Fundamentally OTC must decide if in the 3.1 release we should
 honor OSSL_PKEY_PARAM_EC_POINT_CONVERSION_FORMAT as set (and
 default to UNCOMPRESSED) in our provider implementations, and
 apply corresponding changes for handling legacy keys.
Proposed by: Nicola Tuveri
Issue link: 
https://urldefense.com/v3/__https://github.com/openssl/technical-policies/issues/59__;!!ACWV5N9M2RV99hQ!OqxV4GXROeksWaZKdnkB2ZxFaBT1TMeCLMYCMBN_CfR0LiFEzx5F_7W1GJsGD8ObcYVsuXTdGuyPaZKP$
Public: yes
Opened: 2022-11-15
Closed: -MM-DD
Accepted:  yes/no  (for: X, against: Y, abstained: Z, not voted: W)

  Dmitry [  ]
  Matt   [  ]
  Pauli  [  ]
  Tim[  ]
  Hugo   [  ]
  Richard[  ]
  Shane  [  ]
  Tomas  [  ]
  Kurt   [  ]
  Matthias   [  ]
  Nicola [+1]

OTC Vote: Accept PR #19681 in 3.1 subject to normal review process

[Nicola Tuveri]

Topic: Accept PR #19681 in 3.1 subject to normal review process
Comment: Fundamentally OTC must decide if in the 3.1 release we should
 honor OSSL_PKEY_PARAM_EC_POINT_CONVERSION_FORMAT as set (and
 default to UNCOMPRESSED) in our provider implementations, and
 apply corresponding changes for handling legacy keys.
Proposed by: Nicola Tuveri
Issue link: https://github.com/openssl/technical-policies/issues/59
Public: yes
Opened: 2022-11-15
Closed: -MM-DD
Accepted:  yes/no  (for: X, against: Y, abstained: Z, not voted: W)

  Dmitry [  ]
  Matt   [  ]
  Pauli  [  ]
  Tim[  ]
  Hugo   [  ]
  Richard[  ]
  Shane  [  ]
  Tomas  [  ]
  Kurt   [  ]
  Matthias   [  ]
  Nicola [+1]

OTC VOTE: Accept PR #19400 in master and 3.0 subject to normal review process

[Tomas Mraz]

https://github.com/openssl/technical-policies/issues/56

This vote was immediately closed as the outcome was determined during
the OTC meeting already.
-- 
Tomáš Mráz, OpenSSL

Vote: Accept PR#18407 for backfit to 3.0 as a policy exception

[Nicola Tuveri]

Topic: Accept PR#18407 for backfit to 3.0 as a policy exception.
Proposed by: Nicola
Issue link: https://github.com/openssl/technical-policies/issues/52
Public: yes
Opened: 2022-05-31
Closed:
Accepted:(for: , against: , abstained: , not voted: )

   Dmitry [+1]
   Matt   [-1]
   Pauli  [+1]
   Tim[ 0]
   Richard[ 0]
   Shane  [-1]
   Tomas  [ 0]
   Kurt   [  ]
   Matthias   [-0]
   Nicola [+1]

The vote was opened during the weekly OTC meeting, and is still open.
OTC members, please vote.

Nicola Tuveri

VOTE: Accept PR #17998 into master and 3.0 branches

[Tomas Mraz]

There is a vote opened for the subject at:
https://github.com/openssl/technical-policies/issues/41

-- 
Tomáš Mráz, OpenSSL

Re: OTC VOTE: Accept PR #16705 into 3.0

[Matt Caswell]

I forgot I was now supposed to record these votes as issues in the 
technical policies repository.


I have now done so:
https://github.com/openssl/technical-policies/issues/12

Matt


On 07/12/2021 10:35, Matt Caswell wrote:

topic: Accept PR #16705 into 3.0 subject to the normal review process
Proposed by Matt Caswell
Public: yes
opened: 2021-12-07
closed: 2021-12-07
accepted:  yes  (for: 4, against: 1, abstained: 3, not voted: 2)

   Dmitry [+0]
   Matt   [+1]
   Pauli  [-0]
   Tim    [-1]
   Richard    [+1]
   Shane  [+1]
   Tomas  [+1]
   Kurt   [  ]
   Matthias   [+0]
   Nicola [  ]

Re: OTC VOTE: Accept PR #16705 into 3.0

[Kurt Roeckx]

On Wed, Dec 08, 2021 at 09:17:05AM +0100, Tomas Mraz wrote:
> On Tue, 2021-12-07 at 19:18 +0100, Kurt Roeckx wrote:
> > On Tue, Dec 07, 2021 at 10:35:02AM +, Matt Caswell wrote:
> > > topic: Accept PR #16705 into 3.0 subject to the normal review
> > > process
> > 
> > -1
> > 
> > From what I understand, this breaks our provider API. Providers
> > that work with 3.0.0 will not work when that PR is applied, and
> > providers that do the same implementation as that PR will not work
> > with 3.0.0. That might be something that can be fixed in the PR.
> > 
> > We might want to make changes like that, but we clearly need better
> > rules for when it's acceptable to make such change, and how to make
> > sure it's compatible.
> 
> Kurt, can you please explain why do you think this breaks the provider
> API compatibility with 3.0.0? I do not see any such breakage possible
> from the PR.

I was at least confused by:
# define OSSL_KEYMGMT_SELECT_KEYPAIR\
( OSSL_KEYMGMT_SELECT_PRIVATE_KEY | OSSL_KEYMGMT_SELECT_PUBLIC_KEY )

I assumed this was a different bit rather than the combination of 2
bits, and that we stopped calling it with the existing bit and called
it with a new bit instead. But we're just calling it with an extra bit
set.


Kurt

Re: OTC VOTE: Accept PR #16705 into 3.0

[Tomas Mraz]

On Tue, 2021-12-07 at 19:18 +0100, Kurt Roeckx wrote:
> On Tue, Dec 07, 2021 at 10:35:02AM +, Matt Caswell wrote:
> > topic: Accept PR #16705 into 3.0 subject to the normal review
> > process
> 
> -1
> 
> From what I understand, this breaks our provider API. Providers
> that work with 3.0.0 will not work when that PR is applied, and
> providers that do the same implementation as that PR will not work
> with 3.0.0. That might be something that can be fixed in the PR.
> 
> We might want to make changes like that, but we clearly need better
> rules for when it's acceptable to make such change, and how to make
> sure it's compatible.

Kurt, can you please explain why do you think this breaks the provider
API compatibility with 3.0.0? I do not see any such breakage possible
from the PR.

-- 
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: Accept PR #16705 into 3.0

[Kurt Roeckx]

On Tue, Dec 07, 2021 at 10:35:02AM +, Matt Caswell wrote:
> topic: Accept PR #16705 into 3.0 subject to the normal review process

-1

>From what I understand, this breaks our provider API. Providers
that work with 3.0.0 will not work when that PR is applied, and
providers that do the same implementation as that PR will not work
with 3.0.0. That might be something that can be fixed in the PR.

We might want to make changes like that, but we clearly need better
rules for when it's acceptable to make such change, and how to make
sure it's compatible.

Kurt

OTC VOTE: Accept PR #16705 into 3.0

[Matt Caswell]

topic: Accept PR #16705 into 3.0 subject to the normal review process
Proposed by Matt Caswell
Public: yes
opened: 2021-12-07
closed: 2021-12-07
accepted:  yes  (for: 4, against: 1, abstained: 3, not voted: 2)

  Dmitry [+0]
  Matt   [+1]
  Pauli  [-0]
  Tim[-1]
  Richard[+1]
  Shane  [+1]
  Tomas  [+1]
  Kurt   [  ]
  Matthias   [+0]
  Nicola [  ]

Re: OTC VOTE: Accept PR#16725

[Matt Caswell]

I have now closed this vote:


topic: Accept PR#16725 as a bug fix for backport into 3.0 subject to the 
normal

   review process
Proposed by Matt Caswell
Public: yes
opened: 2021-10-19
closed: 2021-10-20
accepted:  yes  (for: 4, against: 2, abstained: 4, not voted: 0)

  Dmitry [+0]
  Matt   [+1]
  Pauli  [ 0]
  Tim[ 0]   # Vote changed 2021-10-20
  Richard[+0]
  Shane  [+1]
  Tomas  [+1]
  Kurt   [+1]
  Matthias   [-1]
  Nicola [-1]


On 20/10/2021 09:43, Dr Paul Dale wrote:

0

Pauli

On 19/10/21 8:07 pm, Matt Caswell wrote:
topic: Accept PR#16725 as a bug fix for backport into 3.0 subject to 
the normal review process

Proposed by Matt Caswell
Public: yes
opened: 2021-10-19
closed: 2021-mm-dd
accepted:  yes/no  (for: X, against: Y, abstained: Z, not voted: T)

  Dmitry [+0]
  Matt   [+1]
  Pauli  [  ]
  Tim    [-1]
  Richard    [+0]
  Shane  [+1]
  Tomas  [+1]
  Kurt   [  ]
  Matthias   [-1]
  Nicola [-1]

Re: OTC VOTE: Accept PR#16725

[Dr Paul Dale]

0

Pauli

On 19/10/21 8:07 pm, Matt Caswell wrote:
topic: Accept PR#16725 as a bug fix for backport into 3.0 subject to 
the normal review process

Proposed by Matt Caswell
Public: yes
opened: 2021-10-19
closed: 2021-mm-dd
accepted:  yes/no  (for: X, against: Y, abstained: Z, not voted: T)

  Dmitry [+0]
  Matt   [+1]
  Pauli  [  ]
  Tim    [-1]
  Richard    [+0]
  Shane  [+1]
  Tomas  [+1]
  Kurt   [  ]
  Matthias   [-1]
  Nicola [-1]

Re: OTC VOTE: Accept PR#16725

[Tim Hudson]

On the basis of further discussion I'm changing my vote to 0 which enables
this to pass now.

Tim.


On Wed, Oct 20, 2021 at 5:18 PM Matt Caswell  wrote:

>
>
> On 19/10/2021 19:31, Nicola Tuveri wrote:
> > I believe Matt will find the time at some point to post the minutes
> > from today's meeting, but until then here is my recap.
>
> We decided in the meeting that posting the minutes to the list wasn't
> necessary and we would just push them to the repo:
>
>
> https://git.openssl.org/gitweb/?p=otc.git;a=blob;f=meeting-minutes/minutes-2021-10-19.txt;h=8bae2b86ecd7c4f967ba2aa822535dc0facbbfa9;hb=HEAD
>
> Matt
>
> >
> > The discussion mostly focused on why the changes in #16725 are a
> > bugfix and not a new feature, which would be a prerequisite to be
> > admissible to be merged in the 3.0 branch.
> > As I recall it, there were no objections to the final outcome of the
> > PR to be desirable, the vote is entirely about this being a bugfix or
> > not.
> >
> > It would be on those who voted +1 to properly argument why this is a
> > bugfix and not a new feature, but the short version of that argument
> > is that the outcome of #16725 was the "intended behavior" for 3.0.0.
> > The counterargument is that we could not find written evidence (i.e.,
> > GH issues/PRs, documentation, and/or tests) that indeed the project
> > ever committed to have this behavior in 3.0.0.
> >
> >
> > The Strategic Architecture document has some text that could be
> > somewhat related and used to support the "intend behavior" view, but
> > the document clearly states
> >
> >> This document outlines the OpenSSL strategic architecture. It will take
> multiple releases, starting from 3.0.0, to move the architecture from the
> current "as-is" (1.1.1), to the future "to-be" architecture.
> >
> > Hence, it does not really prove that this functionality was always
> > planned for the 3.0.0 release.
> >
> > Accepting this PR for the next minor release would not require a vote.
> >
> >
> >
> > I hope this recap is helpful to inform your decision.
> >
> >
> >
> > Cheers,
> >
> > Nicola
> >
> > On Tue, Oct 19, 2021 at 9:10 PM Kurt Roeckx  wrote:
> >>
> >> On Tue, Oct 19, 2021 at 11:07:26AM +0100, Matt Caswell wrote:
> >>> topic: Accept PR#16725 as a bug fix for backport into 3.0 subject to
> the
> >>> normal review process
> >>
> >> So we have various people voting -1. Does someone want to explain
> >> why they vote -1?
> >>
> >>
> >> Kurt
> >>
> >
>

Re: OTC VOTE: Accept PR#16725

[Matt Caswell]

On 19/10/2021 19:31, Nicola Tuveri wrote:

I believe Matt will find the time at some point to post the minutes
from today's meeting, but until then here is my recap.


We decided in the meeting that posting the minutes to the list wasn't 
necessary and we would just push them to the repo:


https://git.openssl.org/gitweb/?p=otc.git;a=blob;f=meeting-minutes/minutes-2021-10-19.txt;h=8bae2b86ecd7c4f967ba2aa822535dc0facbbfa9;hb=HEAD

Matt



The discussion mostly focused on why the changes in #16725 are a
bugfix and not a new feature, which would be a prerequisite to be
admissible to be merged in the 3.0 branch.
As I recall it, there were no objections to the final outcome of the
PR to be desirable, the vote is entirely about this being a bugfix or
not.

It would be on those who voted +1 to properly argument why this is a
bugfix and not a new feature, but the short version of that argument
is that the outcome of #16725 was the "intended behavior" for 3.0.0.
The counterargument is that we could not find written evidence (i.e.,
GH issues/PRs, documentation, and/or tests) that indeed the project
ever committed to have this behavior in 3.0.0.


The Strategic Architecture document has some text that could be
somewhat related and used to support the "intend behavior" view, but
the document clearly states


This document outlines the OpenSSL strategic architecture. It will take multiple releases, starting 
from 3.0.0, to move the architecture from the current "as-is" (1.1.1), to the future 
"to-be" architecture.


Hence, it does not really prove that this functionality was always
planned for the 3.0.0 release.

Accepting this PR for the next minor release would not require a vote.



I hope this recap is helpful to inform your decision.



Cheers,

Nicola

On Tue, Oct 19, 2021 at 9:10 PM Kurt Roeckx  wrote:


On Tue, Oct 19, 2021 at 11:07:26AM +0100, Matt Caswell wrote:

topic: Accept PR#16725 as a bug fix for backport into 3.0 subject to the
normal review process


So we have various people voting -1. Does someone want to explain
why they vote -1?


Kurt

Re: OTC VOTE: Accept PR#16725

[Kurt Roeckx]

On Tue, Oct 19, 2021 at 11:07:26AM +0100, Matt Caswell wrote:
> topic: Accept PR#16725 as a bug fix for backport into 3.0 subject to the
> normal review process

+1


Kurt

Re: OTC VOTE: Accept PR#16725

[Nicola Tuveri]

I believe Matt will find the time at some point to post the minutes
from today's meeting, but until then here is my recap.

The discussion mostly focused on why the changes in #16725 are a
bugfix and not a new feature, which would be a prerequisite to be
admissible to be merged in the 3.0 branch.
As I recall it, there were no objections to the final outcome of the
PR to be desirable, the vote is entirely about this being a bugfix or
not.

It would be on those who voted +1 to properly argument why this is a
bugfix and not a new feature, but the short version of that argument
is that the outcome of #16725 was the "intended behavior" for 3.0.0.
The counterargument is that we could not find written evidence (i.e.,
GH issues/PRs, documentation, and/or tests) that indeed the project
ever committed to have this behavior in 3.0.0.


The Strategic Architecture document has some text that could be
somewhat related and used to support the "intend behavior" view, but
the document clearly states

> This document outlines the OpenSSL strategic architecture. It will take 
> multiple releases, starting from 3.0.0, to move the architecture from the 
> current "as-is" (1.1.1), to the future "to-be" architecture.

Hence, it does not really prove that this functionality was always
planned for the 3.0.0 release.

Accepting this PR for the next minor release would not require a vote.



I hope this recap is helpful to inform your decision.



Cheers,

Nicola

On Tue, Oct 19, 2021 at 9:10 PM Kurt Roeckx  wrote:
>
> On Tue, Oct 19, 2021 at 11:07:26AM +0100, Matt Caswell wrote:
> > topic: Accept PR#16725 as a bug fix for backport into 3.0 subject to the
> > normal review process
>
> So we have various people voting -1. Does someone want to explain
> why they vote -1?
>
>
> Kurt
>

Re: OTC VOTE: Accept PR#16725

[Kurt Roeckx]

On Tue, Oct 19, 2021 at 11:07:26AM +0100, Matt Caswell wrote:
> topic: Accept PR#16725 as a bug fix for backport into 3.0 subject to the
> normal review process

So we have various people voting -1. Does someone want to explain
why they vote -1?


Kurt

OTC VOTE: Accept PR#16725

[Matt Caswell]

topic: Accept PR#16725 as a bug fix for backport into 3.0 subject to the 
normal review process

Proposed by Matt Caswell
Public: yes
opened: 2021-10-19
closed: 2021-mm-dd
accepted:  yes/no  (for: X, against: Y, abstained: Z, not voted: T)

  Dmitry [+0]
  Matt   [+1]
  Pauli  [  ]
  Tim[-1]
  Richard[+0]
  Shane  [+1]
  Tomas  [+1]
  Kurt   [  ]
  Matthias   [-1]
  Nicola [-1]

Re: OTC VOTE: Accept PR#16286 into 3.0 subject to the normal review process

[Dmitry Belyavsky]

On Sun, Aug 29, 2021 at 1:36 PM Kurt Roeckx  wrote:

> On Tue, Aug 17, 2021 at 02:19:08PM +0100, Matt Caswell wrote:
> > topic: Accept PR#16286 into 3.0 subject to the normal review process
>
> -1
>
> Do we need some general policy for such changes after the 3.0
> release?
>
>
I think we need some sort of definition of missing features.

Some features (e.g. SRP) were deliberately excluded from 3.0,
but I tend to treat all the other features available in 1.1.1 and missing
in 3.0 as bugs.


-- 
SY, Dmitry Belyavsky

Re: OTC VOTE: Accept PR#16286 into 3.0 subject to the normal review process

[Kurt Roeckx]

On Tue, Aug 17, 2021 at 02:19:08PM +0100, Matt Caswell wrote:
> topic: Accept PR#16286 into 3.0 subject to the normal review process

-1

Do we need some general policy for such changes after the 3.0
release?


Kurt

Re: OTC VOTE: Accept PR#16286 into 3.0 subject to the normal review process

[Tomas Mraz]

-1 post closing of the vote for the record

Tomas

On Tue, 2021-08-17 at 14:19 +0100, Matt Caswell wrote:
> topic: Accept PR#16286 into 3.0 subject to the normal review process
> Proposed by Shane Lontis
> Public: yes
> opened: 2021-08-17
> closed: 2021-mm-dd
> accepted:  yes/no  (for: X, against: Y, abstained: Z, not voted: T)
> 
>    Dmitry [  ]
>    Matt   [-1]
>    Pauli  [+1]
>    Tim    [ 0]
>    Richard    [+1]
>    Shane  [+1]
>    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: Accept PR#16286 into 3.0 subject to the normal review process

[Dr Paul Dale]

The vote has closed and passed.

Pauli

   topic: Accept PR#16286 into 3.0 subject to the normal review process
   Proposed by Shane Lontis
   Public: yes
   opened: 2021-08-17
   closed: 2021-08-18
   accepted:  yes  (for: 5, against: 1, abstained: 1, not voted: 3)

  Dmitry [+1]
  Matt   [-1]
  Pauli  [+1]
  Tim    [ 0]
  Richard    [+1]
  Shane  [+1]
  Tomas  [  ]
  Kurt   [  ]
  Matthias   [  ]
  Nicola [+1]



On 17/8/21 11:19 pm, Matt Caswell wrote:

topic: Accept PR#16286 into 3.0 subject to the normal review process
Proposed by Shane Lontis
Public: yes
opened: 2021-08-17
closed: 2021-mm-dd
accepted:  yes/no  (for: X, against: Y, abstained: Z, not voted: T)

  Dmitry [  ]
  Matt   [-1]
  Pauli  [+1]
  Tim    [ 0]
  Richard    [+1]
  Shane  [+1]
  Tomas  [  ]
  Kurt   [  ]
  Matthias   [  ]
  Nicola [+1]

Re: OTC VOTE: Accept PR#16286 into 3.0 subject to the normal review process

[Dmitry Belyavsky]

+1

On Tue, Aug 17, 2021 at 3:19 PM Matt Caswell  wrote:

> topic: Accept PR#16286 into 3.0 subject to the normal review process
> Proposed by Shane Lontis
> Public: yes
> opened: 2021-08-17
> closed: 2021-mm-dd
> accepted:  yes/no  (for: X, against: Y, abstained: Z, not voted: T)
>
>Dmitry [  ]
>Matt   [-1]
>Pauli  [+1]
>Tim[ 0]
>Richard[+1]
>Shane  [+1]
>Tomas  [  ]
>Kurt   [  ]
>Matthias   [  ]
>Nicola [+1]
>


-- 
SY, Dmitry Belyavsky

OTC VOTE: Accept PR#16286 into 3.0 subject to the normal review process

[Matt Caswell]

topic: Accept PR#16286 into 3.0 subject to the normal review process
Proposed by Shane Lontis
Public: yes
opened: 2021-08-17
closed: 2021-mm-dd
accepted:  yes/no  (for: X, against: Y, abstained: Z, not voted: T)

  Dmitry [  ]
  Matt   [-1]
  Pauli  [+1]
  Tim[ 0]
  Richard[+1]
  Shane  [+1]
  Tomas  [  ]
  Kurt   [  ]
  Matthias   [  ]
  Nicola [+1]

Re: OTC VOTE: Accept PR 16050 in 3.0

[Kurt Roeckx]

On Tue, Jul 27, 2021 at 10:10:27AM +0100, Matt Caswell wrote:
> topic: Accept PR 16050 in 3.0 subject to our normal review process
> Proposed by Tim Hudson
> Public: yes
> opened: 2021-07-20
> closed: 2021-07-27
> accepted:  no  (for: 1, against: 3, abstained: 4, not voted: 1)

I don't find a call for vote on this.

-1


Kurt

Re: OTC VOTE: Accept PR 16128

[Kurt Roeckx]

On Thu, Jul 22, 2021 at 01:51:27PM +0100, Matt Caswell wrote:
> topic: Accept PR 16128 in 3.0 subject to our normal review process

+1


Kurt

Re: OTC Vote: Accept PR #16118

[Kurt Roeckx]

On Tue, Jul 20, 2021 at 11:18:27AM +0100, Matt Caswell wrote:
> topic: We should accept PR #16118 into 3.0 when completed and subject to the
>normal review process

This already seems to be merged, so I'll vote 0.


Kurt

OTC VOTE: Accept PR 16050 in 3.0

[Matt Caswell]

topic: Accept PR 16050 in 3.0 subject to our normal review process
Proposed by Tim Hudson
Public: yes
opened: 2021-07-20
closed: 2021-07-27
accepted:  no  (for: 1, against: 3, abstained: 4, not voted: 1)

Re: OTC VOTE: Accept PR 16128

[Matt Caswell]

This vote is now closed:

accepted:  yes  (for: 8, against: 0, abstained: 0, not voted:1)

On 22/07/2021 13:51, 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 [  ]

Re: [External] : OTC VOTE: Accept PR 16128

[Shane Lontis]

+1


From: openssl-project  on behalf of Matt 
Caswell 
Sent: Thursday, July 22, 2021 10:51 PM
To: openssl-project@openssl.org 
Subject: [External] : OTC VOTE: Accept PR 16128

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

Re: OTC VOTE: Accept PR 16128

[Nicola Tuveri]

+1

On Thu, Jul 22, 2021, 16:56 Dr. Matthias St. Pierre <
matthias.st.pie...@ncp-e.com> wrote:

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

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: OTC VOTE: Accept PR 16128

[Tomas Mraz]

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

Re: OTC VOTE: Accept PR 16128

[Dr Paul Dale]

+1

Pauli

On 22/7/21 10:51 pm, 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 [  ]

Re: OTC VOTE: Accept PR 16128

[Tim Hudson]

+1 as this is consistent with previous OTC post-beta decisions to accept
such changes (subject to OTC vote).

Tim.


On Thu, Jul 22, 2021 at 10:51 PM 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 [  ]
>

OTC VOTE: Accept PR 16128

[Matt Caswell]

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

OTC Vote: Accept PR #16118

[Matt Caswell]

topic: We should accept PR #16118 into 3.0 when completed and subject to 
the

   normal review process
Proposed by Matt Caswell
Public: yes
opened: 2021-07-21
closed: 2021-07-21
accepted:  yes  (for: 5, against: 0, abstained: 3, not voted: 1)

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

Re: OTC VOTE: Accept PR #15763

[Kurt Roeckx]

On Tue, Jun 29, 2021 at 10:50:36AM +0100, Matt Caswell wrote:
> topic: Accept PR #15763 for 1.1.1 subject to the normal review process

+1


Kurt

OTC VOTE: Accept PR #15763

[Matt Caswell]

topic: Accept PR #15763 for 1.1.1 subject to the normal review process
Proposed by Matt Caswell
Public: yes
opened: 2021-06-29
closed: 2021-06-29
accepted:  yes  (for: 7, against: 0, abstained: 0, not voted: 2)

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

Re: OTC VOTE: Set PR 13817 milestone to Post 3.0

[Tomas Mraz]

This vote is now closed.

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

On Thu, 2021-04-22 at 23:28 +0200, Kurt Roeckx wrote:
> On Tue, Apr 20, 2021 at 12:17:17PM +0200, Tomas Mraz wrote:
> > topic: Set PR 13817 milestone to Post 3.0
> 
> 0
> 
> 
> Kurt
> 
-- 
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: Reject PR#14759

[Nicola Tuveri]

The vote is now closed: it passed, and PR#14759 is rejected.


topic: Reject PR#14759
Proposed by Nicola Tuveri
Public: yes
opened: 2021-04-20
closed: 2021-05-04
accepted:  yes  (for: 3, against: 2, abstained: 4, not voted: 2)
  Matt   [ 0]
  Mark   [  ]
  Pauli  [-0]
  Viktor [  ]
  Tim[-1]
  Richard[ 0]
  Shane  [+1]
  Tomas  [-1]
  Kurt   [+1]
  Matthias   [ 0]
  Nicola [+1]


Best regards,

Nicola Tuveri

Re: OTC VOTE: Reject PR#14759

[Richard Levitte]

0

On Tue, 20 Apr 2021 12:23:56 +0200,
Nicola Tuveri wrote:
> 
> Following up on 
> https://www.mail-archive.com/openssl-project@openssl.org/msg02407.html we had 
> a
> discussion on this during last week OTC meeting, and opened a vote limited 
> exclusively to the
> matter of rejecting PR#14759.
> 
> We lost the record of the votes collected during the call, so opening it 
> officially today with a
> clean slate.
> 
> 
> topic: Reject PR#14759
> Proposed by Nicola Tuveri
> Public: yes
> opened: 2021-04-20
> closed: 2021-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]
> 
> 
-- 
Richard Levitte levi...@openssl.org
OpenSSL Project http://www.openssl.org/~levitte/

Re: OTC VOTE: Reject PR#14759

[Kurt Roeckx]

On Tue, Apr 20, 2021 at 01:23:56PM +0300, Nicola Tuveri wrote:
> Following up on
> https://www.mail-archive.com/openssl-project@openssl.org/msg02407.html we
> had a discussion on this during last week OTC meeting, and opened a vote
> limited exclusively to the matter of rejecting PR#14759.
> 
> We lost the record of the votes collected during the call, so opening it
> officially today with a clean slate.
> 
> 
> 
> topic: Reject PR#14759

+1


Kurt

Re: OTC VOTE: Set PR 13817 milestone to Post 3.0

[Kurt Roeckx]

On Tue, Apr 20, 2021 at 12:17:17PM +0200, Tomas Mraz wrote:
> topic: Set PR 13817 milestone to Post 3.0

0


Kurt

Re: [External] : OTC VOTE: Reject PR#14759

[SHANE LONTIS]

+1

Shane


> On 20 Apr 2021, at 8:23 pm, Nicola Tuveri  wrote:
> 
> Following up on 
> https://www.mail-archive.com/openssl-project@openssl.org/msg02407.html 
> 
>  we had a discussion on this during last week OTC meeting, and opened a vote 
> limited exclusively to the matter of rejecting PR#14759.
> 
> We lost the record of the votes collected during the call, so opening it 
> officially today with a clean slate.
> 
> 
> 
> topic: Reject PR#14759
> Proposed by Nicola Tuveri
> Public: yes
> opened: 2021-04-20
> closed: 2021-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]
> 
> 

Re: OTC VOTE: Reject PR#14759

[Matt Caswell]

0

On 20/04/2021 11:23, Nicola Tuveri wrote:
Following up on 
https://www.mail-archive.com/openssl-project@openssl.org/msg02407.html 
 
we had a discussion on this during last week OTC meeting, and opened a 
vote limited exclusively to the matter of rejecting PR#14759.


We lost the record of the votes collected during the call, so opening it 
officially today with a clean slate.




topic: Reject PR#14759
Proposed by Nicola Tuveri
Public: yes
opened: 2021-04-20
closed: 2021-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]

Re: OTC VOTE: Reject PR#14759

[Tim Hudson]

On the call the votes were very clear to accept the PR (not reject it).
So I'm again rejecting the request to reject the PR -  it would be better
to express such votes in positive terms.

-1

Tim.



On Wed, Apr 21, 2021 at 9:06 AM Dr Paul Dale  wrote:

> -0
>
> Pauli
>
> On 20/4/21 8:23 pm, Nicola Tuveri wrote:
> > Following up on
> > https://www.mail-archive.com/openssl-project@openssl.org/msg02407.html
> > 
>
> > we had a discussion on this during last week OTC meeting, and opened a
> > vote limited exclusively to the matter of rejecting PR#14759.
> >
> > We lost the record of the votes collected during the call, so opening
> > it officially today with a clean slate.
> >
> >
> > 
> > topic: Reject PR#14759
> > Proposed by Nicola Tuveri
> > Public: yes
> > opened: 2021-04-20
> > closed: 2021-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]
> >
> >
>
>

Re: OTC VOTE: Reject PR#14759

[Dr Paul Dale]

-0

Pauli

On 20/4/21 8:23 pm, Nicola Tuveri wrote:
Following up on 
https://www.mail-archive.com/openssl-project@openssl.org/msg02407.html 
 
we had a discussion on this during last week OTC meeting, and opened a 
vote limited exclusively to the matter of rejecting PR#14759.


We lost the record of the votes collected during the call, so opening 
it officially today with a clean slate.




topic: Reject PR#14759
Proposed by Nicola Tuveri
Public: yes
opened: 2021-04-20
closed: 2021-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]

Re: OTC VOTE: Set PR 13817 milestone to Post 3.0

[Dr Paul Dale]

+0

On 20/4/21 8:17 pm, Tomas Mraz wrote:

topic: Set PR 13817 milestone to Post 3.0
Proposed by Tim Hudson
Public: yes
opened: 2021-04-20
closed: 2021-mm-dd
accepted:  yes/no  (for: X, against: Y, abstained: Z, not voted: T)

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

Re: OTC VOTE: Reject PR#14759

[Tomas Mraz]

-1

On Tue, 2021-04-20 at 13:23 +0300, Nicola Tuveri wrote:
> Following up on 
> https://www.mail-archive.com/openssl-project@openssl.org/msg02407.html
> we had a discussion on this during last week OTC meeting, and opened
> a vote limited exclusively to the matter of rejecting PR#14759.
> 
> We lost the record of the votes collected during the call, so opening
> it officially today with a clean slate.
> 
-- 
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 VOTE: Reject PR#14759

[Nicola Tuveri]

Following up on
https://www.mail-archive.com/openssl-project@openssl.org/msg02407.html we
had a discussion on this during last week OTC meeting, and opened a vote
limited exclusively to the matter of rejecting PR#14759.

We lost the record of the votes collected during the call, so opening it
officially today with a clean slate.



topic: Reject PR#14759
Proposed by Nicola Tuveri
Public: yes
opened: 2021-04-20
closed: 2021-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]

OTC VOTE: Set PR 13817 milestone to Post 3.0

[Tomas Mraz]

topic: Set PR 13817 milestone to Post 3.0
Proposed by Tim Hudson
Public: yes
opened: 2021-04-20
closed: 2021-mm-dd
accepted:  yes/no  (for: X, against: Y, abstained: Z, not voted: T)

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

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

[Tomas Mraz]

I have closed the vote now.

The vote was accepted, although with a very narrow margin.

accepted:  yes  (for: 3, against: 2, abstained: 5, not voted: 1)

Tomas

On Fri, 2020-10-09 at 14:02 +0200, Tomas Mraz wrote:
> 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: OTC VOTE: The PR #11359 (Allow to continue with further checks on UNABLE_TO_VERIFY_LEAF_SIGNATURE) is acceptable for 1.1.1 branch

[Kurt Roeckx]

On Fri, Oct 09, 2020 at 02:02:29PM +0200, Tomas Mraz wrote:
> 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

0


Kurt

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

[Richard Levitte]

Cancel that, wrong vote.

For this, 0

On Tue, 13 Oct 2020 10:09:12 +0200,
Richard Levitte wrote:
> 
> +1
> 
> On Fri, 09 Oct 2020 14:02:29 +0200,
> Tomas Mraz wrote:
> > 
> > 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.]
> > 
> > 
> -- 
> Richard Levitte levi...@openssl.org
> OpenSSL Project http://www.openssl.org/~levitte/
> 
-- 
Richard Levitte levi...@openssl.org
OpenSSL Project http://www.openssl.org/~levitte/

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

[Richard Levitte]

+1

On Fri, 09 Oct 2020 14:02:29 +0200,
Tomas Mraz wrote:
> 
> 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.]
> 
> 
-- 
Richard Levitte levi...@openssl.org
OpenSSL Project http://www.openssl.org/~levitte/

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

[Mark J Cox]

0

On Fri, Oct 9, 2020 at 1:02 PM Tomas Mraz  wrote:
>
> 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: OTC VOTE: The PR #11359 (Allow to continue with further checks on UNABLE_TO_VERIFY_LEAF_SIGNATURE) is acceptable for 1.1.1 branch

[Matt Caswell]

On 11/10/2020 11:34, Nicola Tuveri wrote:
> I am basing my vote on the feedback provided by @DDvO [0] and @t8m [1].
> In particular I am convinced to vote in favor, as I can see this as a
> bug fix, fixing an undocumented inconsistency, and that it is very
> unlikely it would affect existing applications.

IMO this is not a bug fix. It does correct an undocumented inconsistency
and so I have no problem with this being applied to master. But I think
it is a stretch to describe it as a bug fix.

Matt


> 
> 
> Nicola
> 
> 
> [0]: https://github.com/openssl/openssl/pull/11359#issuecomment-706189632
> [1]: https://github.com/openssl/openssl/pull/11359#issuecomment-706191205
> 
> 
> On Fri, 9 Oct 2020 at 15:02, Tomas Mraz  wrote:
>>
>> 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: OTC VOTE: The PR #11359 (Allow to continue with further checks on UNABLE_TO_VERIFY_LEAF_SIGNATURE) is acceptable for 1.1.1 branch

[Matt Caswell]

-1

On 09/10/2020 13:02, Tomas Mraz wrote:
> 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 [  ]
> 

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

[Nicola Tuveri]

+1

I am basing my vote on the feedback provided by @DDvO [0] and @t8m [1].
In particular I am convinced to vote in favor, as I can see this as a
bug fix, fixing an undocumented inconsistency, and that it is very
unlikely it would affect existing applications.


Nicola


[0]: https://github.com/openssl/openssl/pull/11359#issuecomment-706189632
[1]: https://github.com/openssl/openssl/pull/11359#issuecomment-706191205


On Fri, 9 Oct 2020 at 15:02, Tomas Mraz  wrote:
>
> 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: 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.]

Vote on PR

[Dr Paul Dale]

The following vote passed 6 to 0.

topic: Accept the changes to the OpenSSL policies as per PR#133 (openssl/web).
comment: The definition of trivial being clarified and moved to the web page
 that the missing CLA note references.


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

Re: VOTE Apply PR#9084 reverting DEVRANDOM_WAIT

[Viktor Dukhovni]

> On Jun 7, 2019, at 7:24 PM, Kurt Roeckx  wrote:
> 
> That's all very nice, but nobody is going to run that.

They also don't have to upgrade their kernel, or deploy new
versions of OpenSSL.  If platform release engineers don't
deploy core services that ensure reliably CSPRNG seeding,
then their platform is less secure at boot.  This is their
choice.  Users can vote with their feet for more secure
O/S distributions.

Secure CSPRNG seeding is a platform responsibility, OpenSSL
then runs secure PRNGs seeded from the platform.  There's
only so much we can reasonably do.  The rest has to happen
outside of OpenSSL, as a pre-requisite.

And yes, fallback on RDSEED/RDRAND + TPM (real or virtual)
+ whatever is available, but ideally not in libcrypto, but
rather a service that that seeds the system at boot.

Those other mechanisms are often either not fully trusted in
isolation, not always available, or too expensive at every
process start.  The logic to identify which are available,
and how many are enough, ... is best extracted to run separately
at boot, with the library using either getentropy() or read
/dev/urandom (older kernels).

-- 
Viktor.

VOTE Apply PR#9084 reverting DEVRANDOM_WAIT

[Dr Paul Dale]

This vote has been closed, it passed 5 votes to 2 with no abstentions.


Up for discussion is the text of the next vote.  I’m proposing this:

Topic: The OpenSSL 3.0.0 release will include mitigation for the low entropy on 
boot and first boot problems.
Comment: PR#9084 removed such mitigation due to the negative side effects.


I’ll make this formal in a day or so, so if anyone wants to suggest alternative 
wording, that’s the time line.  The vote text is the “topic” line, the comment 
is explanatory only.

Note: I’m not mentioning the mechanism used, that still needs to be decided on. 
 This is just saying that 3.0.0 *will* have some mechanism.


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

Re: VOTE Apply PR#9084 reverting DEVRANDOM_WAIT

[Kurt Roeckx]

On Fri, Jun 07, 2019 at 07:04:57PM -0400, Viktor Dukhovni wrote:
> On Sat, Jun 08, 2019 at 12:54:36AM +0200, Kurt Roeckx wrote:
> 
> > On Fri, Jun 07, 2019 at 03:37:07PM -0400, Viktor Dukhovni wrote:
> > > > On Jun 7, 2019, at 3:25 PM, Kurt Roeckx  wrote:
> > > > 
> > > > For older kernels you install rng-tools that feeds the hwrng in
> > > > the kernel.
> > > 
> > > Which works for me, and is pretty much the point I'm trying to make.
> > > Then, read /dev/random once early at boot, and do nothing special
> > > libcrypto (safely use /dev/urandom).
> > 
> > The only thing rng-tools will actually solve is the starvation
> > issue. No service will depend on it, since they don't have any
> > relationship with it. Nor can you wait for it, it's not because
> > it's started that it has initialized the kernel. I think I've also
> > seen reports that it got started too late, actually after a
> > services that wants to ask the kernel for random numbers.
> 
> Then a different service can be developed that does block just once
> at boot, and tries to obtain entropy from a configurable set of
> sources (to avoid or reduce unbounded delay, and mix in more
> independent sources).

That's all very nice, but nobody is going to run that.


Kurt

Re: VOTE Apply PR#9084 reverting DEVRANDOM_WAIT

[Viktor Dukhovni]

On Sat, Jun 08, 2019 at 12:54:36AM +0200, Kurt Roeckx wrote:

> On Fri, Jun 07, 2019 at 03:37:07PM -0400, Viktor Dukhovni wrote:
> > > On Jun 7, 2019, at 3:25 PM, Kurt Roeckx  wrote:
> > > 
> > > For older kernels you install rng-tools that feeds the hwrng in
> > > the kernel.
> > 
> > Which works for me, and is pretty much the point I'm trying to make.
> > Then, read /dev/random once early at boot, and do nothing special
> > libcrypto (safely use /dev/urandom).
> 
> The only thing rng-tools will actually solve is the starvation
> issue. No service will depend on it, since they don't have any
> relationship with it. Nor can you wait for it, it's not because
> it's started that it has initialized the kernel. I think I've also
> seen reports that it got started too late, actually after a
> services that wants to ask the kernel for random numbers.

Then a different service can be developed that does block just once
at boot, and tries to obtain entropy from a configurable set of
sources (to avoid or reduce unbounded delay, and mix in more
independent sources).

-- 
Viktor.

Re: VOTE Apply PR#9084 reverting DEVRANDOM_WAIT

[Kurt Roeckx]

On Fri, Jun 07, 2019 at 03:37:07PM -0400, Viktor Dukhovni wrote:
> > On Jun 7, 2019, at 3:25 PM, Kurt Roeckx  wrote:
> > 
> > For older kernels you install rng-tools that feeds the hwrng in
> > the kernel.
> 
> Which works for me, and is pretty much the point I'm trying to make.
> Then, read /dev/random once early at boot, and do nothing special
> libcrypto (safely use /dev/urandom).

The only thing rng-tools will actually solve is the starvation
issue. No service will depend on it, since they don't have any
relationship with it. Nor can you wait for it, it's not because
it's started that it has initialized the kernel. I think I've also
seen reports that it got started too late, actually after a
services that wants to ask the kernel for random numbers.

An other solution might be that we enable rdrand/rdseed by default
as entropy source, after getentropy() and before /dev/urandom.


Kurt

Re: VOTE Apply PR#9084 reverting DEVRANDOM_WAIT

[Kurt Roeckx]

On Fri, Jun 07, 2019 at 07:01:30PM +, Salz, Rich wrote:
> 
> >The kernel actually already does this in recent versions, if
> configured to do it.
>   
> "The" kernel. Which one is that?  Which operating system?
> 
> Modern Linux is fine.  Is that all we care about?

This whole discussion has only been about Linux, we only define
DEVRANDOM_WAIT on Linux.

I think all other OSs have a sane /dev/urandom, but I'm not sure
about NetBSD.

> 1.1.1c made Solaris (and possibly others) more secure. I would be 
> disappointed if 1.1.1d took that away and tried to rationalize that "it's not 
> my job."  *YOU'RE A CRYPTOGRAPHIC LIBRARY* 

Do you have a reference that Solaris allows reading from
/dev/urandom before it's been initialized?


Kurt

Re: VOTE Apply PR#9084 reverting DEVRANDOM_WAIT

[Viktor Dukhovni]

> On Jun 7, 2019, at 3:25 PM, Kurt Roeckx  wrote:
> 
> For older kernels you install rng-tools that feeds the hwrng in
> the kernel.

Which works for me, and is pretty much the point I'm trying to make.
Then, read /dev/random once early at boot, and do nothing special
libcrypto (safely use /dev/urandom).

-- 
Viktor.

Re: VOTE Apply PR#9084 reverting DEVRANDOM_WAIT

[Kurt Roeckx]

On Fri, Jun 07, 2019 at 03:08:24PM -0400, Viktor Dukhovni wrote:
> > On Jun 7, 2019, at 2:41 PM, Kurt Roeckx  wrote:
> > 
> >> This is not the sort of thing to bolt into the kernel, but is not
> >> unreasonable for systemd and the like.
> > 
> > The kernel actually already does this in recent versions, if
> > configured to do it.
> 
> We're talking about what to do with for older kernels.

For older kernels you install rng-tools that feeds the hwrng in
the kernel.


Kurt

Re: VOTE Apply PR#9084 reverting DEVRANDOM_WAIT

[Viktor Dukhovni]

> On Jun 7, 2019, at 2:41 PM, Kurt Roeckx  wrote:
> 
>> This is not the sort of thing to bolt into the kernel, but is not
>> unreasonable for systemd and the like.
> 
> The kernel actually already does this in recent versions, if
> configured to do it.

We're talking about what to do with for older kernels, and in
cases when the kernel cannot promptly obtain sufficient entropy
without external sources.  The kernel's job is to mix in entropy
from natural activity.  Boot-time acquisition of non-trivial entropy
by other means falls outside the kernel, and may be needed when
the kernel cannot obtain sufficient entropy on its own in a timely
manner.

-- 
Viktor.

Re: VOTE Apply PR#9084 reverting DEVRANDOM_WAIT

[Kurt Roeckx]

On Fri, Jun 07, 2019 at 02:31:54PM -0400, Viktor Dukhovni wrote:
> 
> That's a different issue.  What I was suggesting was a service that
> waits for seeding to be ready.  So that other services can depend
> on that service, with that service using various sources to adequately
> seed the kernel RNG, with configurable additional sources beyond the
> save file, possibly with a non-zero entropy estimate.  Thus, for example,
> a virtual machine or container might make use of an interface to get a
> a trusted seed from the host hypervisor/OS.  Or a physical host might
> trust its TPM, ...
> 
> This is not the sort of thing to bolt into the kernel, but is not
> unreasonable for systemd and the like.

The kernel actually already does this in recent versions, if
configured to do it.


Kurt

Re: VOTE Apply PR#9084 reverting DEVRANDOM_WAIT

[Viktor Dukhovni]

> On Jun 7, 2019, at 2:11 PM, Dr. Matthias St. Pierre 
>  wrote:
> 
>> The init system would
>> need to create this kind of service, and then all software not using
>> getentropy()/getrandom() would need to depend on that service. It
> 
> FWIW: systemd already has a service for saving and restoring a random seed.
> If I understood Tomas correctly, the saved seed is added to the random pool,
> but without crediting any entropy to it (which sounds reasonable to me).

That's a different issue.  What I was suggesting was a service that
waits for seeding to be ready.  So that other services can depend
on that service, with that service using various sources to adequately
seed the kernel RNG, with configurable additional sources beyond the
save file, possibly with a non-zero entropy estimate.  Thus, for example,
a virtual machine or container might make use of an interface to get a
a trusted seed from the host hypervisor/OS.  Or a physical host might
trust its TPM, ...

This is not the sort of thing to bolt into the kernel, but is not
unreasonable for systemd and the like.

Applications can then use getentropy() and not even block at boot
time, if the system collects entropy at boot automatically and
without excessive delay.  The job of improving the source quality
and eliminating avoidable delay is then (correctly IMHO) the
responsibility of the platform's init system.

As for what to do on older platforms, ... add an entropy gathering
service to the system start up configuration, and make applications
that need early seed material depend on that service.

Perhaps the OpenSSL project can curate some examples of such service
configurations/scripts.  The simplest might be just DEVRANDOM_WAIT
as a service that runs at boot, and only reports "ready" once
/dev/random is ready.  After that applications can just use
/dev/urandom with some confidence of adequate seeding.

-- 
Viktor.

AW: VOTE Apply PR#9084 reverting DEVRANDOM_WAIT

[Dr. Matthias St. Pierre]

> The reason I think nothing will change is that the problem is
> already solved, use getentropy()/getrandom(). 

I agree completely.

> The init system would
> need to create this kind of service, and then all software not using
> getentropy()/getrandom() would need to depend on that service. It

FWIW: systemd already has a service for saving and restoring a random seed.
If I understood Tomas correctly, the saved seed is added to the random pool,
but without crediting any entropy to it (which sounds reasonable to me).

https://www.freedesktop.org/software/systemd/man/systemd-random-seed.service.html


Matthias

Re: VOTE Apply PR#9084 reverting DEVRANDOM_WAIT

[Kurt Roeckx]

On Fri, Jun 07, 2019 at 01:28:30PM -0400, Viktor Dukhovni wrote:
> 
> I think that having the RNG behaviour capriciously different on
> different systems based on the whims of whoever built the library
> for that system is not a good idea.  OpenSSL should provide an RNG
> that does not block "unexpectedly", indefinitely, and unpredictably.
> 
> Where "unexpectedly", means except possibly early at boot time, but
> ideally waiting for boot-time entropoy is something that systemd
> and the like take care of, and application start scripts can just
> register a dependency on some sort of "entropy" service, whose
> successful initialization is sufficient to ensure adequately secure
> non-blocking seeding of applications via one of getentropy(),
> getrandom(), /dev/urandom...
> 
> That is, I'd expect most of the work for ensuring adequate entropy
> to happen outside libcrypto, except for perhaps enabling some
> additional sources that may be available on various systems.

It seems unlikely that anything related to this will ever change,
but we can always ask.

The reason I think nothing will change is that the problem is
already solved, use getentropy()/getrandom(). The init system would
need to create this kind of service, and then all software not using
getentropy()/getrandom() would need to depend on that service. It
would be eaier to just switch that software to use
getentropy()/getrandom().

Changing the init system, means that this will only work for new
versions of an OS. But on those new versions we already use
getentropy()/getrandom(). What we want to support is people that
use an old OS, but run a new version of OpenSSL on it. That is,
people that do not use the OS provided OpenSSL version.


Kurt

Re: VOTE Apply PR#9084 reverting DEVRANDOM_WAIT

[Kurt Roeckx]

On Fri, Jun 07, 2019 at 10:18:32AM +0200, Tomas Mraz wrote:
> 
> From the point of view of distribution maintainer of OpenSSL I would
> say what we had in 1.1.1 before the introduction of DEVRANDOM_WAIT had
> no real problems for us.

Introducing DEVRANDOM_WAIT didn't cause any change for us, because
we use getentropy(), and a recent kernel. But even systems that
use getentropy() with an older kernel can have a large delay after
boot.


Kurt

Re: VOTE Apply PR#9084 reverting DEVRANDOM_WAIT

[Viktor Dukhovni]

On Fri, Jun 07, 2019 at 11:09:45AM +0200, Matthias St. Pierre wrote:

> See the discussion on openssl-users:
> 
> https://mta.openssl.org/pipermail/openssl-users/2019-May/010585.html
> https://mta.openssl.org/pipermail/openssl-users/2019-May/010593.html
> https://mta.openssl.org/pipermail/openssl-users/2019-May/010595.html
> 
> If desired, I can provide an alternative (competing) pull request which
> makes the DEVRANDOM_WAIT feature configurable in a proper and
> reasonable way. The default will be whatever the OMC decides.

I think that having the RNG behaviour capriciously different on
different systems based on the whims of whoever built the library
for that system is not a good idea.  OpenSSL should provide an RNG
that does not block "unexpectedly", indefinitely, and unpredictably.

Where "unexpectedly", means except possibly early at boot time, but
ideally waiting for boot-time entropoy is something that systemd
and the like take care of, and application start scripts can just
register a dependency on some sort of "entropy" service, whose
successful initialization is sufficient to ensure adequately secure
non-blocking seeding of applications via one of getentropy(),
getrandom(), /dev/urandom...

That is, I'd expect most of the work for ensuring adequate entropy
to happen outside libcrypto, except for perhaps enabling some
additional sources that may be available on various systems.

--
Viktor.

Re: VOTE Apply PR#9084 reverting DEVRANDOM_WAIT

[Tomas Mraz]

On Fri, 2019-06-07 at 10:18 +0200, Tomas Mraz wrote:
> On Fri, 2019-06-07 at 18:03 +1000, Dr Paul Dale wrote:
> > 
> > Viktor replied:
> > 
> > > I just want to make sure we don't lock ourselves in to a single
> > > potentially clumsy solution in the library.  Various strategies
> > > may be appropriate depending on the platform, and ultimately the
> > > cooperation of the system administrator to enable the required
> > > mechanisms.
> > > 
> > > Potential additional sources for initial entropy on systems
> > > without getrandom(2) might include:
> > > 
> > >   RDSEED/RDRAND
> > >   TPM (or Virtualized TPM which is sometimes better!)
> > >   RNG state saved across reboots.
> > >   ...
> > > 
> > > This requires knowledge of various platforms, and potential
> > > help from the platform vendors.  It might, for example, make
> > > sense to delegate initial seeding to systemd on platforms
> > > that use systemd, and work with the systemd maintainers to
> > > provide a set of sensible entropy sources for initial boot.
> > > 
> > > Exposing a decent RNG to virtual guests and containers is
> > > would be another area of focus.
> 
> From the point of view of distribution maintainer of OpenSSL I would
> say what we had in 1.1.1 before the introduction of DEVRANDOM_WAIT
> had
> no real problems for us.

And to clarify myself - we have no problem with the DEVRANDOM_WAIT
introduction either as the -DDEVRANDOM=/dev/urandom works nicely for
us.

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