Re: Status of the remaining beta1 PRs

2020-09-20 Thread Richard Levitte
On Fri, 18 Sep 2020 17:24:59 +0200,
Matt Caswell wrote:
> 
> 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()

There's a counter PR now: #12920

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


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