Re: Status of the remaining beta1 PRs

2020-09-18 Thread Matt Caswell



On 18/09/2020 16:59, Tomas Mraz wrote:
> On Fri, 2020-09-18 at 16:24 +0100, Matt Caswell wrote:
>>
>> 1 PR which is in a state of "its unclear what we do with this":
>> [WIP] Rename some XXX_ex() related methods to XXX_with_libctx()
>> https://github.com/openssl/openssl/pull/12701
>> With no agreement on a naming convention its unclear if this should
>> go
>> ahead or not
> 
> We should do something consistent - either rename the _ex functions
> that just add libctx (and property query) or rename the existing
> with_libctx functions to _ex functions.
> 
> The current state is a mess having some functions with _ex and some
> with _with_libctx.
> 

The current vote on the policy is still ongoing (the subject of this PR
is the one covered by chapter 6.2 in the proposed coding style).
Unfortunately there is currently no clear outcome on that vote and there
are still a significant number of outstanding votes.

Without a clear decision one way or another on that vote we cannot
decide a way forward. If the vote passes, then it is clear what we have
to do. If the vote fails then we will probably have to make a one off
vote about what to do about existing _with_libctx vs _ex discrepancies
without making a policy out of it.

Please can I encourage OTC members to vote one way or the other so that
we can move forward.

Matt


Re: Status of the remaining beta1 PRs

2020-09-18 Thread Tomas Mraz
On Fri, 2020-09-18 at 16:24 +0100, Matt Caswell wrote:
> 
> 1 PR which is in a state of "its unclear what we do with this":
> [WIP] Rename some XXX_ex() related methods to XXX_with_libctx()
> https://github.com/openssl/openssl/pull/12701
> With no agreement on a naming convention its unclear if this should
> go
> ahead or not

We should do something consistent - either rename the _ex functions
that just add libctx (and property query) or rename the existing
with_libctx functions to _ex functions.

The current state is a mess having some functions with _ex and some
with _with_libctx.

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




Status of the remaining beta1 PRs

2020-09-18 Thread Matt Caswell
As of right now we have 13 PRs with the beta1 milestone against them.

Of these there are 4 which really need our focused attention. These are

2 PRs which are in a state of "written but still in review":
WIP: Implement Provider side SM2 Asymmetric Cipher support
https://github.com/openssl/openssl/pull/12913
Needed to complete the SM2 support (WIP because dependent on 12536,
which is in "approval done" status but not yet merged)

ENCODER: Refactor the OSSL_ENCODER API to be more like OSSL_DECODER
https://github.com/openssl/openssl/pull/12873
Still in review

1 PR which is in a state of "we really need to do something about this":
[WIP, Parked] EVP: Adapt EVP_PKEY_set_alias_type() for provider-native
EVP_PKEYs
https://github.com/openssl/openssl/pull/12675
Since this affects a public API we probably really do need to figure out
what to do with the EVP_PKEY_set_alias_type()

1 PR which is in a state of "its unclear what we do with this":
[WIP] Rename some XXX_ex() related methods to XXX_with_libctx()
https://github.com/openssl/openssl/pull/12701
With no agreement on a naming convention its unclear if this should go
ahead or not


The remaining 9 PRs can be split into 2 groups:

6 are in the "approval done" state, so can be pushed soon (one of these
we are actually deliberately holding back until nearer the beta release).

3 PRs are in a state of "probably can be dropped altogether":
WIP: Fix the DRBG reseed propagation [master]
https://github.com/openssl/openssl/pull/12871
This is a bug fix so may not be needed for beta1 at all. Matthias says:
"I put the beta1 milestone against it because I wasn't sure whether I
need to change some public API or not. Currently, I don't think it's
necessary, but I need to check it once more. That will probably not
happen before the weekend, but I'll remember to move the ticket from the
beta1 milestone to the release milestone, if it's not urgent."

Reorder algorithm parameter to be first in *_FETCH() operations.
https://github.com/openssl/openssl/pull/12778
Disputed, and probably not needed. Probably can be dropped.

RAND: allow the primary, public and private of DRBGs to be overriden and
replaced.
https://github.com/openssl/openssl/pull/12754
A feature that current discussion on the PR seems to suggest we may drop
because it may not be needed for 3.0 after all.

Matt




Re: 3.0 beta 1 milestone

2020-09-18 Thread Richard Levitte
I've found what's going wrong there, and I agree that it needs to be
fixed ASAP, although I don't view it per se as a beta 1 blocker.

Either way, a fix is coming up.

Cheers,
Richard

On Thu, 17 Sep 2020 19:21:50 +0200,
Dmitry Belyavsky wrote:
> 
> 
> Dear Matt,
> 
> I think #12891 is a significant problem. I'd suggest fixing it before beta1 
> or at least discuss
> it.
> 
> Many thanks!
> 
> On Thu, Sep 17, 2020 at 3:48 PM Matt Caswell  wrote:
> 
> There's been quite a number of PRs added to the 3.0 beta 1 milestone.
>
> Within the PRs there are a couple of bug fixes:
>
> https://github.com/openssl/openssl/pull/12884
> https://github.com/openssl/openssl/pull/12874
>
> IMO these would be really nice to get into beta 1, but they should not
> be considered blockers for it (i.e. if they didn't go in, it shouldn't
> stop us from releasing beta 1).
>
> There are also some nice-to-have items:
>
> https://github.com/openssl/openssl/pull/12777
> https://github.com/openssl/openssl/pull/12771
> https://github.com/openssl/openssl/pull/12726
> https://github.com/openssl/openssl/pull/12669
> https://github.com/openssl/openssl/pull/12072
>
> Again - these are nice-to-have, and if they happen to get merged in time
> for beta 1 then great. Otherwise, they should wait for 3.1 (possibly
> things which are just cleanup/minor refactoring could still be done
> within the beta period). So, IMO, these should not be considered
> blockers either.
>
> So - this leads me to the question - what is the milestone for? Does it
> means these things *must* go in before we can release beta 1? Or does it
> mean we would *like* to get these things in for beta 1?
>
> I actually don't mind either way - but if its the latter, then I need a
> way of identifying the "must haves". These are the top priority items,
> and at the moment I can't easily track their progress.
>
> Matt
> 
> --
> SY, Dmitry Belyavsky
> 
> 
-- 
Richard Levitte levi...@openssl.org
OpenSSL Project http://www.openssl.org/~levitte/


Re: 3.0 beta 1 milestone

2020-09-18 Thread Matt Caswell



On 18/09/2020 08:26, Richard Levitte wrote:
> On Thu, 17 Sep 2020 15:57:52 +0200,
> Tomas Mraz wrote:
>> I do not think the milestone should include nice-to-have items.
> 
> Another view is that beta 1 is feature freeze.  If those nice to have
> items are characterized as new features, then it makes sense to have
> them included in the beta 1 milestone if we want them for 3.0.0.
> Otherwise, we will have to put them on the waiting list for after
> 3.0.0.

Not every feature that someone dreams up and creates a PR for should
mean we have to hold 3.0 beta 1 until it goes in. There are features
that are required, and features that are nice-to-have. If nice-to-have
features don't reach approval in time, then they should be dropped from
3.0, and wait for 3.1 instead.

Matt



> 
> If they are not characterized as new features, that is a different
> matter, of course.  The conclusion is that we will have to take some
> time (I assume that'll be quick in most cases) thinking how we
> characterize certain PRs before beta 1 is released.
> 
> Cheers,
> Richard
> 


Re: 3.0 beta 1 milestone

2020-09-18 Thread Tomas Mraz
On Fri, 2020-09-18 at 09:26 +0200, Richard Levitte wrote:
> On Thu, 17 Sep 2020 15:57:52 +0200,
> Tomas Mraz wrote:
> > I do not think the milestone should include nice-to-have items.
> 
> Another view is that beta 1 is feature freeze.  If those nice to have
> items are characterized as new features, then it makes sense to have
> them included in the beta 1 milestone if we want them for 3.0.0.
> Otherwise, we will have to put them on the waiting list for after
> 3.0.0.

Yes, but that effectively makes them either "must have in beta1" if we
decide that we want them in 3.0.0 or "not at all in beta1" if we decide
otherwise. As we are so close to beta1 now we should not have any
"let's see if they can make it" features for 3.0.0 anymore.

> If they are not characterized as new features, that is a different
> matter, of course.  The conclusion is that we will have to take some
> time (I assume that'll be quick in most cases) thinking how we
> characterize certain PRs before beta 1 is released.

Yes!

-- 
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: 3.0 beta 1 milestone

2020-09-18 Thread Richard Levitte
On Thu, 17 Sep 2020 18:49:19 +0200,
Kurt Roeckx wrote:
> 
> On Thu, Sep 17, 2020 at 01:48:18PM +0100, Matt Caswell wrote:
> > So - this leads me to the question - what is the milestone for? Does it
> > means these things *must* go in before we can release beta 1? Or does it
> > mean we would *like* to get these things in for beta 1?
> 
> We need to have a decision about those before beta 1, which can
> include:
> - It should be in beta 1
> - It doesn't block beta 1, before the 3.0 release is fine too,
>   which just means that you change the milestone to 3.0
> - It doesn't go into 3.0. No idea what the best way to tag them
>   is.

Sorry, I realise I repeated what you said...

Regarding things not going into 3.0.0, one way is not to assign a
milestone to them.  If we decide to do it that way, it probably means
that we should set the 3.0.0 milestone on everything that we consider
a bug fix rather than a new feature.

Cheers,
Richard

-- 
Richard Levitte levi...@openssl.org
OpenSSL Project http://www.openssl.org/~levitte/