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

-1 > On 9 Oct 2020, at 7:40 am, Dr Paul Dale wrote: > > +1 > > Pauli > -- > Dr Paul Dale | Distinguished Architect | Cryptographic Foundations > Phone +61 7 3031 7217 > Oracle Australia > > > > >> On 9 Oct 2020, at 12:27 am, Matt Caswell > > wrote: >> >> topic:

Re: VOTE: Technical Items still to be done

[to the project list this time] +1 Pauli -- Dr Paul Dale | Distinguished Architect | Cryptographic Foundations Phone +61 7 3031 7217 Oracle Australia > On 9 Oct 2020, at 12:47 am, Matt Caswell wrote: > > topic: The following items are required prerequisites for the first beta > release:

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

+1 Pauli -- Dr Paul Dale | Distinguished Architect | Cryptographic Foundations Phone +61 7 3031 7217 Oracle Australia > On 9 Oct 2020, at 12:27 am, Matt Caswell wrote: > > topic: We should accept the Fully Pluggable TLSv1.3 KEM functionality as > shown in PR #13018 into the 3.0 release >

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

Re: VOTE: Technical Items still to be done

+1 Tim. On Fri, Oct 9, 2020 at 12:47 AM 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. >-

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

+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

Re: VOTE: Technical Items still to be done

+1 On Thu, 8 Oct 2020 at 17:47, 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

Re: Vote proposal: Technical items still to be done

Thanks for the feedback on this thread. There was some feedback specifically on the vote text. I've made the amendment suggested by Tomas, and numbered the items as suggested by Nicola. I did not convert to markdown. The other discussions on this thread I think are useful things to think about

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

Re: Vote proposal: Technical items still to be done

>Of course the 3.0 release is kind of special because we are defining a completely new API - the providers API - with the intention to have it stable for many years to come. Any bugs in the API design for providers will have to live with us at least until the 4.0 release and so it

Re: Vote proposal: Technical items still to be done

On Thu, 2020-10-08 at 09:47 +0100, Matt Caswell wrote: > > On 07/10/2020 19:07, Kurt Roeckx wrote: > > On Wed, Oct 07, 2020 at 12:35:28PM +0100, Matt Caswell wrote: > > > The following items are required prerequisites for the first beta > > > release: > > [...] > > > * Address 3.0beta1

Re: Vote proposal: Technical items still to be done

On 07/10/2020 19:07, Kurt Roeckx wrote: > On Wed, Oct 07, 2020 at 12:35:28PM +0100, Matt Caswell wrote: >> The following items are required prerequisites for the first beta release: > [...] >> * Address 3.0beta1 milestones. > > So we now have a list here, with the last item pointing to a >

Re: Vote proposal: Technical items still to be done

+1 to that. There is a reason why almost all the major projects switched over to doing time based releases instead of feature completeness based ones. Of course the 3.0 release is kind of special because we are defining a completely new API - the providers API - with the intention to have it