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

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

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

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

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

o: 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_

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

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

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

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

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

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

VOTE: Accept PR #17998 into master and 3.0 branches

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

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

Re: OTC VOTE: Accept PR #16705 into 3.0

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

Re: OTC VOTE: Accept PR #16705 into 3.0

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

Re: OTC VOTE: Accept PR #16705 into 3.0

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

OTC VOTE: Accept PR #16705 into 3.0

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

Re: OTC VOTE: Accept PR#16725

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

Re: OTC VOTE: Accept PR#16725

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)  

Re: OTC VOTE: Accept PR#16725

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

Re: OTC VOTE: Accept PR#16725

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:

Re: OTC VOTE: Accept PR#16725

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

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.

Re: OTC VOTE: Accept PR#16725

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

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

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

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

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

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

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

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

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]  

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

+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

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

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

Re: OTC VOTE: Accept PR 16050 in 3.0

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

Re: OTC VOTE: Accept PR 16128

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

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

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

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 

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

+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

Re: OTC VOTE: Accept PR 16128

+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@openss

RE: OTC VOTE: Accept PR 16128

+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

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:

Re: OTC VOTE: Accept PR 16128

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

Re: OTC VOTE: Accept PR 16128

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

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 [

OTC Vote: Accept PR #16118

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

Re: OTC VOTE: Accept PR #15763

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

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

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

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

Re: OTC VOTE: Reject PR#14759

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]

Re: OTC VOTE: Reject PR#14759

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.

Re: OTC VOTE: Reject PR#14759

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

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

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

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

Re: OTC VOTE: Reject PR#14759

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

Re: OTC VOTE: Reject PR#14759

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,

Re: OTC VOTE: Reject PR#14759

-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

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

+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

Re: OTC VOTE: Reject PR#14759

-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

OTC VOTE: Reject PR#14759

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

OTC VOTE: Set PR 13817 milestone to Post 3.0

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]

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

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 >

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

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

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

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

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

+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

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

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

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

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

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

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

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

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

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

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 a

Vote on PR

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

Re: VOTE Apply PR#9084 reverting DEVRANDOM_WAIT

> 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

VOTE Apply PR#9084 reverting DEVRANDOM_WAIT

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

Re: VOTE Apply PR#9084 reverting DEVRANDOM_WAIT

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

Re: VOTE Apply PR#9084 reverting DEVRANDOM_WAIT

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

Re: VOTE Apply PR#9084 reverting DEVRANDOM_WAIT

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

Re: VOTE Apply PR#9084 reverting DEVRANDOM_WAIT

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

Re: VOTE Apply PR#9084 reverting DEVRANDOM_WAIT

> 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

Re: VOTE Apply PR#9084 reverting DEVRANDOM_WAIT

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

Re: VOTE Apply PR#9084 reverting DEVRANDOM_WAIT

> 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

Re: VOTE Apply PR#9084 reverting DEVRANDOM_WAIT

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

Re: VOTE Apply PR#9084 reverting DEVRANDOM_WAIT

> 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

AW: VOTE Apply PR#9084 reverting DEVRANDOM_WAIT

> 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

Re: VOTE Apply PR#9084 reverting DEVRANDOM_WAIT

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

Re: VOTE Apply PR#9084 reverting DEVRANDOM_WAIT

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,

Re: VOTE Apply PR#9084 reverting DEVRANDOM_WAIT

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 >

Re: VOTE Apply PR#9084 reverting DEVRANDOM_WAIT

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