Re: New GitHub label for release blockers

2020-09-14 Thread Richard Levitte
On Sun, 13 Sep 2020 22:41:23 +0200,
Dr. Matthias St. Pierre wrote:
> 
> Conversely, there were also pull requests associated with the '3.0.0' or 
> '3.0.0 beta1' milestone,
> without  being associated to the  '3.0 New Core + FIPS' project. This has 
> been fixed now.

I fail to see why the milestones '3.0.0' / '3.0.0 beta1' must be 1:1
with the '3.0 New Core + FIPS' project.  If we make them the same,
what's the reason to have both?

I just looked in the project, and these are issues and PRs the
presence of which I think is questionable:

#10612
#4930
#12860
#11311

Maybe there's a misunderstand of what "3.0 New Core" means.  Please
note the lack of comma.  But if that doesn't help, how about the
project description?

I've seen a bit too much of wanting to pile *everything* into that
project.  That was never the intention.

Cheers,
Richard

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


Re: OTC vote on PR11188

2020-09-14 Thread Matt Caswell
This vote is now closed (actually it closed last week but I forgot to
report it). The vote was not accepted:

for: 0, against: 8, abstained: 3, not voted: 0

On 27/08/2020 11:06, Matt Caswell wrote:
> FYI, I have initiated the following vote on PR11188. Please see the
> comments in that PR for the background. I will report back with the
> result of the vote once known.
> 
> topic: The performance improvements provided in PR11188 should be
>considered a bug fix and therefore acceptable for backport to
>1.1.1
> Proposed by Matt Caswell
> Public: yes
> opened: 2020-08-27
> closed: 2020-mm-dd
> 
> 
> Matt
> 


Re: Reordering new API's that have a libctx, propq

2020-09-14 Thread Richard Levitte
On Mon, 14 Sep 2020 13:46:01 +0200,
Tim Hudson wrote:
> 
> [1  ]
> [2  ]
> On Mon, Sep 14, 2020 at 9:19 PM Matt Caswell  wrote:
> 
> I must be misunderstanding your point because I don't follow your logic
> at all.
>
> So this is the correct form according to my proposed policy:
>
> TYPE *TYPE_make_from_ctx(char *name,TYPE_CTX *ctx)
> 
> And that is the point - this is not how the existing CTX functions
> work (ignoring the OPENSSL_CTX stuff).

I'd say that the example here is flawed, at least for libcrypto.

(libssl has some very different patterns that are quite confusing when
relating them to what's been said here, so I'm choosing to ignore them
for the moment, for the sake of clarity)

The prime example I have for that sort of constructor constructor is this:

EVP_PKEY_CTX *EVP_PKEY_CTX_new_from_name(OPENSSL_CTX *libctx,
 const char *name,
 const char *propquery);

Function name wise, it's obvious that the name is of primary interest.
The library context is located as first argument, because "library
global state" or factory pool, which is fine.

However, other than SSL contra SSL_CTX, I can't recall that we have
much functions that contruct a TYPE from a TYPE_CTX.

( mind you, our TYPE naming is all over the place and quite inconsistent.
  In many EVP APIs, we have a TYPE / TYPE_CTX pair where TYPE is the
  structure with method pointers and TYPE_CTX is the structure with
  instance data...  except with EVP_PKEY, where we had (roughly and in
  legacy terms) the EVP_PKEY_ASN1_METHOD / EVP_PKEY pair and the
  EVP_PKEY_METHOD / EVP_PKEY_CTX pairs...  and with non EVP APIs (such
  as BIO), we often have the TYPE_METHOD / TYPE pair

  I haven't even begun to analyse the SSL types in similar terms, if
  that's doable )

> > The PR should cover that context of how we name the variations of
> > functions which add the OPENSSL_CTX reference.
>
> IMO, it does. They should be called "*_ex" as stated in chapter 6.2. I
> don't see why we need to special case OPENSSL_CTX in the policy. Its
> written in a generic way an can be applied to the OPENSSL_CTX case.
> 
> And that means renaming all the with_libctx to _ex which frankly I
> don't think makes a lot of sense to do.

I don't see a lot of sense in _with_libctx (and I scold myself for
starting that pattern).  Imagine the next time we have something
important that we want to add as argument to the same essential
function, what then?  TYPE_blah_with_libctx_with_whatever()?
That doesn't set a sensible pattern...

> Having a naming indicating OPENSSL_CTX added isn't a bad thing to do
> in my view.

Can you guarantee that this is the one and only time we add something
like '_with_libctx' to a function name, or do we risk ending up
feeling "inspired" some time in the future?

> Collecting a whole pile of _ex functions and having to look at each
> one to figure out what the "extension" is does add additional burden
> for the user.

A sensible thing to do is to deprecate the old and clunky.  That'll
tell the user which if variants A, B, and C they should use going
forward.

I'm with you insofar that I thoroughly dislike _ex, but I've made
peace with it when someone pointed out that _ex{n} is possible.
And quite frankly, I dislike more or less every scheme on giving new
names to functions that are just extended but otherwise have the same
essential functionality as the previous one.  They're all ugly.  So in
my mind mind, it comes down to choosing a scheme that one can live
with and that holds for a long time going forward.  And just so we're
clear, if you take a function and make a replacement that takes some
slightly different arguments but that essentially (i.e. perhaps not
exactly in the details, but in broader terms) gives the same result,
then I'd say that the new function is an extension of the old, not an
entirely new function.

I'll also point out that when we make functions that are "concurrent"
variants of the same, then it does make sense to have specific naming,
like these:

EVP_PKEY_CTX *EVP_PKEY_CTX_new_from_name(OPENSSL_CTX *libctx,
 const char *name,
 const char *propquery);
EVP_PKEY_CTX *EVP_PKEY_CTX_new_from_pkey(OPENSSL_CTX *libctx,
 EVP_PKEY *pkey, const char *propquery);

These are not replacements of each other, so it makes sense here to
put the distinguishing feature of each as part of the function name.

> There is a reason that _with_libctx was added rather than picking
> _ex as the function names - it clearly communicates then intent
> rather than be a generic extension-of-API naming.

Considering I came up with that, I can easily declare that the intent
wasn't originally as grand as you make it out to be.  It was a name I
came up with spur of the moment.  Today, I wish I never had, at 

Re: Reordering new API's that have a libctx, propq

2020-09-14 Thread Matt Caswell



On 14/09/2020 13:14, Tim Hudson wrote:
> On Mon, Sep 14, 2020 at 9:52 PM Matt Caswell  > wrote:
> 
> > And that is the point - this is not how the existing CTX functions
> work
> > (ignoring the OPENSSL_CTX stuff).
> 
> Do you have some concrete examples of existing functions that don't work
> this way?
> 
> 
> SSL_new()
> BIO_new_ssl()
> BIO_new_ssl_connect()

All of these three are consistent with my proposed policy.

The policy says:

"the key argument that identifies the thing be constructed should be
placed first (if such an argument exists)"

The parenthetical comes into play here "if such an argument exists". It
doesn't exist in any of these three cases and therefore this part
doesn't apply. In all cases the arguments are a single argument and so
trivially agree with the ordering rules.


> BIO_new_bio_pair()

This one is a slight oddity in that it doesn't create just one object
but two. I'm not aware of anywhere else where we do this, but even if we
do I don't think it is a common pattern, so I don't feel the need to
base our future policy on this precedent.


> etc
> 
> And all the existing method using functions which are also factories.
> 
> But I get the point - if there is only one argument is it logically
> coming first or last - obviously it can be seen both ways.
> 
> IMO, we absolutely MUST have the ability to delete parameters (for
> example ENGINEs). If we can do that, then I don't see why we can't add
> parameters.
> 
> 
> No - that doesn't follow. It is perfectly reasonable to have an ENGINE
> typedef that remains and is passed as NULL as usual - and in fact most
> of the top-level ENGINE stuff handles NULL as meaning no engine usage so
> that would remain consistent. There is no absolute requirement to
> delete a parameter for this or other purposes. If you want to reorder
> parameters I would argue it should be a new function name and not an _ex
> version.

I disagree with you on this.

Matt





Re: Reordering new API's that have a libctx, propq

2020-09-14 Thread Tim Hudson
On Mon, Sep 14, 2020 at 9:52 PM Matt Caswell  wrote:

> > And that is the point - this is not how the existing CTX functions work
> > (ignoring the OPENSSL_CTX stuff).
>
> Do you have some concrete examples of existing functions that don't work
> this way?
>

SSL_new()
BIO_new_ssl()
BIO_new_ssl_connect()
BIO_new_bio_pair()
etc

And all the existing method using functions which are also factories.

But I get the point - if there is only one argument is it logically coming
first or last - obviously it can be seen both ways.

IMO, we absolutely MUST have the ability to delete parameters (for
> example ENGINEs). If we can do that, then I don't see why we can't add
> parameters.
>

No - that doesn't follow. It is perfectly reasonable to have an ENGINE
typedef that remains and is passed as NULL as usual - and in fact most of
the top-level ENGINE stuff handles NULL as meaning no engine usage so that
would remain consistent. There is no absolute requirement to delete a
parameter for this or other purposes. If you want to reorder parameters I
would argue it should be a new function name and not an _ex version.

Tim.


Re: Reordering new API's that have a libctx, propq

2020-09-14 Thread Matt Caswell



On 14/09/2020 12:46, Tim Hudson wrote:
> On Mon, Sep 14, 2020 at 9:19 PM Matt Caswell  > wrote:
> 
> I must be misunderstanding your point because I don't follow your logic
> at all.
> 
> So this is the correct form according to my proposed policy:
> 
> TYPE *TYPE_make_from_ctx(char *name,TYPE_CTX *ctx)
> 
> 
> And that is the point - this is not how the existing CTX functions work
> (ignoring the OPENSSL_CTX stuff).

Do you have some concrete examples of existing functions that don't work
this way?


>  
> 
> > The PR should cover that context of how we name the variations of
> > functions which add the OPENSSL_CTX reference.
> 
> IMO, it does. They should be called "*_ex" as stated in chapter 6.2. I
> don't see why we need to special case OPENSSL_CTX in the policy. Its
> written in a generic way an can be applied to the OPENSSL_CTX case.
> 
> 
> And that means renaming all the with_libctx to _ex which frankly I don't
> think makes a lot of sense to do. 

My understanding of the current consensus from previous discussions is
that most people feel differently to you on this. Maybe I'm wrong.


> Having a naming indicating OPENSSL_CTX added isn't a bad thing to do in
> my view.
> Collecting a whole pile of _ex functions and having to look at each one
> to figure out what the "extension" is does add additional burden for the
> user.
> There is a reason that _with_libctx was added rather than picking _ex as
> the function names - it clearly communicates then intent rather than be
> a generic extension-of-API naming.
> 
> 
> IMO *the* most confusing thing would be to *change* an existing ordering
> 
> (for example swap two existing parameters around). I see no problem with
> adding new ones anywhere that's appropriate.
> 
> 
> Clearly we disagree on that - if you are making an extended version of a
> function and you aren't keeping the same existing parameter order (which
> you are not if you add or remove parameters which is the point I was
> making - the order isn't the same as the existing function because
> you've removed items - what you have is the order of whatever parameters
> remain in the extended function are the same - and that's a pretty
> pointless distinction to make - if you aren't simply adding additional
> items on the end you make for a change over mess and this I think we
> should be trying to avoid). My context there is for the users of the
> existing API.
> It becomes especially problematic if you have type equivalence when the
> order is changed around so there are no compiler warnings if the user
> hasn't picked up on reordering of parameters.

IMO, we absolutely MUST have the ability to delete parameters (for
example ENGINEs). If we can do that, then I don't see why we can't add
parameters.

Matt
 


Re: Reordering new API's that have a libctx, propq

2020-09-14 Thread Matt Caswell



On 14/09/2020 11:30, Matt Caswell wrote:
> In order to try and move this discussion forward I have made a concrete
> proposal for how we should formulate the various ideas in this thread
> into an actual style. Please see here:
> 
> https://github.com/openssl/web/pull/194
> 
> Since we're not yet fully in agreement some compromises will have to be
> made. I hope I've come up with something which isn't too abhorrent to
> anyone.
> 
> Please take a look.

I'm planning to gather feedback on this PR today - so if you have any
thoughts then please comment. I will post an updated version tomorrow
incorporating any feedback. I plan to start a vote on this later this
week (perhaps Wednesday).

Possibly I might do two votes: one for the proposed chapter 6.1, and one
for the proposed chapter 6.2.

Given the disagreements on this, I don't believe unanimous agreement is
going to be achievable. I hope to get it into a state where it is
acceptable to as many people as possible.

Matt


> 
> Matt
> 
> 
> On 05/09/2020 04:48, SHANE LONTIS wrote:
>>
>>   PR #12778 reorders all the API’s of the form:
>>
>>
>>   EVP_XX_fetch(libctx, algname, propq) 
>>
>>
>>   So that the algorithm name appears first.. 
>>
>>
>>   e.g: EVP_MD_fetch(digestname, libctx, propq);
>>
>> This now logically reads as 'search for this algorithm using these
>> parameters’.
>>
>> The libctx, propq should always appear together as a pair of parameters.
>> There are only a few places where only the libctx is needed, which means
>> that if there is no propq it is likely to cause a bug in a fetch at some
>> point. 
>>
>> This keeps the API’s more consistent with other existing XXX_with_libctx
>> API’s that put the libctx, propq at the end of the parameter list..
>> The exception to this rule is that callback(s) and their arguments occur
>> after the libctx, propq..
>>
>> e.g:
>> typedef OSSL_STORE_LOADER_CTX *(*OSSL_STORE_open_with_libctx_fn)
>>     (const OSSL_STORE_LOADER *loader,
>>      const char *uri, OPENSSL_CTX *libctx, const char *propq,
>>      const UI_METHOD *ui_method, void *ui_data);
>>
>> An otc_hold was put on this.. Do we need to have a formal vote?
>> This really needs to be sorted out soon so the API’s can be locked down
>> for beta.
>>
>> 
>> Also discussed in a weekly meeting and numerous PR discussions was the
>> removal of the long winded API’s ending with ‘with_libctx’
>> e.g CMS_data_create_with_libctx
>> The proposed renaming for this was to continue with the _ex notation..
>> If there is an existing _ex name then it becomes _ex2, etc.
>> There will most likely be additional parameters in the future for some
>> API’s, so this notation would be more consistent with current API’s.
>> Does this also need a vote?
>>
>> Regards,
>> Shane
>>
>>
> 


Re: Reordering new API's that have a libctx, propq

2020-09-14 Thread Tim Hudson
On Mon, Sep 14, 2020 at 9:19 PM Matt Caswell  wrote:

> I must be misunderstanding your point because I don't follow your logic
> at all.
>
> So this is the correct form according to my proposed policy:
>
> TYPE *TYPE_make_from_ctx(char *name,TYPE_CTX *ctx)
>

And that is the point - this is not how the existing CTX functions work
(ignoring the OPENSSL_CTX stuff).


> > The PR should cover that context of how we name the variations of
> > functions which add the OPENSSL_CTX reference.
>
> IMO, it does. They should be called "*_ex" as stated in chapter 6.2. I
> don't see why we need to special case OPENSSL_CTX in the policy. Its
> written in a generic way an can be applied to the OPENSSL_CTX case.
>

And that means renaming all the with_libctx to _ex which frankly I don't
think makes a lot of sense to do.
Having a naming indicating OPENSSL_CTX added isn't a bad thing to do in my
view.
Collecting a whole pile of _ex functions and having to look at each one to
figure out what the "extension" is does add additional burden for the user.
There is a reason that _with_libctx was added rather than picking _ex as
the function names - it clearly communicates then intent rather than be a
generic extension-of-API naming.


IMO *the* most confusing thing would be to *change* an existing ordering
>
(for example swap two existing parameters around). I see no problem with
> adding new ones anywhere that's appropriate.
>

Clearly we disagree on that - if you are making an extended version of a
function and you aren't keeping the same existing parameter order (which
you are not if you add or remove parameters which is the point I was making
- the order isn't the same as the existing function because you've removed
items - what you have is the order of whatever parameters remain in the
extended function are the same - and that's a pretty pointless distinction
to make - if you aren't simply adding additional items on the end you make
for a change over mess and this I think we should be trying to avoid). My
context there is for the users of the existing API.
It becomes especially problematic if you have type equivalence when the
order is changed around so there are no compiler warnings if the user
hasn't picked up on reordering of parameters.

Tim.


Re: Reordering new API's that have a libctx, propq

2020-09-14 Thread Matt Caswell



On 14/09/2020 11:52, Tim Hudson wrote:
> Any proposal needs to deal with the constructors consistently - whether
> they come from an OPENSSL_CTX or they come from an existing TYPE_CTX.
> That is absent in your PR.
> 
> Basically this leads to the ability to provide inconsistent argument
> order in functions.
> 
> TYPE *TYPE_make_from_ctx(TYPE_CTX *ctx, char *name)
> or
> TYPE *TYPE_make_from_ctx(char *name,TYPE_CTX *ctx)
> 
> It simply isn't consistent to basically allow both forms of this approach.
> 
> Seeing the OPENSSL_CTX as something different to the other APIs in terms
> of its usage when it is providing the context from which something is
> constructed is the underlying issue here.
> Your PR basically makes rules for "context" arguments which lead to
> allowing both the above forms - and making the current usage of CTX
> values a different logical order than the OPENSSL_CTX.

I must be misunderstanding your point because I don't follow your logic
at all.

In your example above the proposal seems clear (to me):

"Where present the TYPE argument should always be first. In constructors
or object factory type functions (such as a "fetch" function), the key
argument that identifies the thing be constructed should be placed first
(if such an argument exists)."

Your example is a "factory type" or constructor. Therefore the argument
that identifies the thing being constructued should be first, i.e. the name.

The section of the policy says:

"The remaining argument list should be put into order of importance."

Only then does it go on to list where the ctx sits in that order of
importance. The phrase "the remaining argument list" indicates that that
ordering is subordinate to the preceding paragraph.

So this is the correct form according to my proposed policy:

TYPE *TYPE_make_from_ctx(char *name,TYPE_CTX *ctx)


> 
> Separately, we should have consistency in the naming of the functions
> which take an OPENSSL_CTX - the _with_libctx makes no sense now that we
> settled on OPENSSL_CTX rather than OPENSSL_LIBCTX or OPENSSL_LIB_CTX as
> the naming. We also have a pile of _ex functions that were introduced
> just to add an OPENSSL_CTX - those should be consistently named. 

The policy is clear. We are adding extended forms of existing functions.
Therefore "_with_libctx" is not consistent with the policy. "_ex" (or
"_ex2" if necessary), is.


> 
> The PR should cover that context of how we name the variations of
> functions which add the OPENSSL_CTX reference.

IMO, it does. They should be called "*_ex" as stated in chapter 6.2. I
don't see why we need to special case OPENSSL_CTX in the policy. Its
written in a generic way an can be applied to the OPENSSL_CTX case.

> 
> The suggested rules for extended functions is inconsistent in stating
> the order "should be retained" and then allowing for inserting "at any
> point".

This is not inconsistent. The *order* must be retained. Inserting
additional arguments does *not* change the order. So according to the
policy, if you have a function:

FOO_do_something(bar, wibble, blah);

Then this is ok:

FOO_do_something(new, bar, wibble, blah);

As is this:

FOO_do_something(bar, new, wibble, blah);

And this:

FOO_do_something(bar, wibble, blah, new);

But *not* this (because the order of existing arguments is different):

FOO_do_something(blah, wibble, bar, new);



> IHMO either the new function must preserve the existing order and just
> add to the end (to easy migration) or it should conform to the naming
> scheme and parameter argument order for new functions - one of those
> should be the driver rather than basically creating something that is
> neither - not easy to migrate to and also not following the documented
> order. We should be trying to achieve one of those two objectives.

I disagree that that should be an objective.

IMO *the* most confusing thing would be to *change* an existing ordering
(for example swap two existing parameters around). I see no problem with
adding new ones anywhere that's appropriate.

Matt


Re: Reordering new API's that have a libctx, propq

2020-09-14 Thread Tim Hudson
Any proposal needs to deal with the constructors consistently - whether
they come from an OPENSSL_CTX or they come from an existing TYPE_CTX.
That is absent in your PR.

Basically this leads to the ability to provide inconsistent argument order
in functions.

TYPE *TYPE_make_from_ctx(TYPE_CTX *ctx, char *name)
or
TYPE *TYPE_make_from_ctx(char *name,TYPE_CTX *ctx)

It simply isn't consistent to basically allow both forms of this approach.

Seeing the OPENSSL_CTX as something different to the other APIs in terms of
its usage when it is providing the context from which something is
constructed is the underlying issue here.
Your PR basically makes rules for "context" arguments which lead to
allowing both the above forms - and making the current usage of CTX values
a different logical order than the OPENSSL_CTX.

Separately, we should have consistency in the naming of the functions which
take an OPENSSL_CTX - the _with_libctx makes no sense now that we settled
on OPENSSL_CTX rather than OPENSSL_LIBCTX or OPENSSL_LIB_CTX as the naming.
We also have a pile of _ex functions that were introduced just to add an
OPENSSL_CTX - those should be consistently named.

The PR should cover that context of how we name the variations of functions
which add the OPENSSL_CTX reference.

The suggested rules for extended functions is inconsistent in stating the
order "should be retained" and then allowing for inserting "at any point".
IHMO either the new function must preserve the existing order and just add
to the end (to easy migration) or it should conform to the naming scheme
and parameter argument order for new functions - one of those should be the
driver rather than basically creating something that is neither - not easy
to migrate to and also not following the documented order. We should be
trying to achieve one of those two objectives.

Tim.


On Mon, Sep 14, 2020 at 8:30 PM Matt Caswell  wrote:

> In order to try and move this discussion forward I have made a concrete
> proposal for how we should formulate the various ideas in this thread
> into an actual style. Please see here:
>
> https://github.com/openssl/web/pull/194
>
> Since we're not yet fully in agreement some compromises will have to be
> made. I hope I've come up with something which isn't too abhorrent to
> anyone.
>
> Please take a look.
>
> Matt
>
>
> On 05/09/2020 04:48, SHANE LONTIS wrote:
> >
> >   PR #12778 reorders all the API’s of the form:
> >
> >
> >   EVP_XX_fetch(libctx, algname, propq)
> >
> >
> >   So that the algorithm name appears first..
> >
> >
> >   e.g: EVP_MD_fetch(digestname, libctx, propq);
> >
> > This now logically reads as 'search for this algorithm using these
> > parameters’.
> >
> > The libctx, propq should always appear together as a pair of parameters.
> > There are only a few places where only the libctx is needed, which means
> > that if there is no propq it is likely to cause a bug in a fetch at some
> > point.
> >
> > This keeps the API’s more consistent with other existing XXX_with_libctx
> > API’s that put the libctx, propq at the end of the parameter list..
> > The exception to this rule is that callback(s) and their arguments occur
> > after the libctx, propq..
> >
> > e.g:
> > typedef OSSL_STORE_LOADER_CTX *(*OSSL_STORE_open_with_libctx_fn)
> > (const OSSL_STORE_LOADER *loader,
> >  const char *uri, OPENSSL_CTX *libctx, const char *propq,
> >  const UI_METHOD *ui_method, void *ui_data);
> >
> > An otc_hold was put on this.. Do we need to have a formal vote?
> > This really needs to be sorted out soon so the API’s can be locked down
> > for beta.
> >
> > 
> > Also discussed in a weekly meeting and numerous PR discussions was the
> > removal of the long winded API’s ending with ‘with_libctx’
> > e.g CMS_data_create_with_libctx
> > The proposed renaming for this was to continue with the _ex notation..
> > If there is an existing _ex name then it becomes _ex2, etc.
> > There will most likely be additional parameters in the future for some
> > API’s, so this notation would be more consistent with current API’s.
> > Does this also need a vote?
> >
> > Regards,
> > Shane
> >
> >
>


Re: Reordering new API's that have a libctx, propq

2020-09-14 Thread Matt Caswell
In order to try and move this discussion forward I have made a concrete
proposal for how we should formulate the various ideas in this thread
into an actual style. Please see here:

https://github.com/openssl/web/pull/194

Since we're not yet fully in agreement some compromises will have to be
made. I hope I've come up with something which isn't too abhorrent to
anyone.

Please take a look.

Matt


On 05/09/2020 04:48, SHANE LONTIS wrote:
> 
>   PR #12778 reorders all the API’s of the form:
> 
> 
>   EVP_XX_fetch(libctx, algname, propq) 
> 
> 
>   So that the algorithm name appears first.. 
> 
> 
>   e.g: EVP_MD_fetch(digestname, libctx, propq);
> 
> This now logically reads as 'search for this algorithm using these
> parameters’.
> 
> The libctx, propq should always appear together as a pair of parameters.
> There are only a few places where only the libctx is needed, which means
> that if there is no propq it is likely to cause a bug in a fetch at some
> point. 
> 
> This keeps the API’s more consistent with other existing XXX_with_libctx
> API’s that put the libctx, propq at the end of the parameter list..
> The exception to this rule is that callback(s) and their arguments occur
> after the libctx, propq..
> 
> e.g:
> typedef OSSL_STORE_LOADER_CTX *(*OSSL_STORE_open_with_libctx_fn)
>     (const OSSL_STORE_LOADER *loader,
>      const char *uri, OPENSSL_CTX *libctx, const char *propq,
>      const UI_METHOD *ui_method, void *ui_data);
> 
> An otc_hold was put on this.. Do we need to have a formal vote?
> This really needs to be sorted out soon so the API’s can be locked down
> for beta.
> 
> 
> Also discussed in a weekly meeting and numerous PR discussions was the
> removal of the long winded API’s ending with ‘with_libctx’
> e.g CMS_data_create_with_libctx
> The proposed renaming for this was to continue with the _ex notation..
> If there is an existing _ex name then it becomes _ex2, etc.
> There will most likely be additional parameters in the future for some
> API’s, so this notation would be more consistent with current API’s.
> Does this also need a vote?
> 
> Regards,
> Shane
> 
> 


SM2 asymmetric encryption

2020-09-14 Thread Matt Caswell
Currently, 1.1.1  supports SM2 asymmetric encryption. Real world use of
this is currently believed to be low (IIUC it is mainly useful for SM2
in TLS, which we don't current support). A discussion in PR #12536 is
proposing to drop this feature from 3.0 (possibly to re-introduce it in
some later release). This was mentioned on this list by me in this post:

https://mta.openssl.org/pipermail/openssl-project/2020-August/002138.html

No feedback has been received on that point. It was also discussed at
the recent OMC f2f (although no vote was held on the issue). Since
dropping this support is a breaking change it requires an OMC vote to
approve it. I'm proposing this vote wording:

"Support for SM2 asymmetric encryption should be dropped from OpenSSL 3.0"

Please let me know any thoughts on the vote wording (or any other
thoughts on the topic). Otherwise I plan to start this vote soon.

Matt