Reordering new API's that have a libctx, propq

[Richard Levitte]

On Wed, 09 Sep 2020 13:38:42 +0200,
Tomas Mraz wrote:
> > Regarding model 3, it must be said that there is potential for
> > confusion
> > on what it's supposed to do, replace the default property query
> > string
> > (settable with EVP_set_default_properties()), or merge with it.
> > Remember that a property query string given through any XXX_fetch()
> > function is temporarly merged with the default properties when
> > looking
> > for fitting algorithms.
> 
> Here I would actually argue, that there should be another property
> query in the libctx in addition to the default, that would have the
> exactly same semantics as the propq parameter has now and for the
> functions with the propq parameter it even would not be applied. How to
> name it so it won't be confused with the default property query, that's
> hard to say though.

"current" was mentioned several times during yesterday's videocall,
that could actually be used for a name.

I'm ok with putting such a property query string into the library
context, As Long As there is the understanding that it's not *tied*
to that library context, i.e. it can be used to pass a property query
string on to a provider implementation, to be used with whatever
library context the provider uses (the FIPS module has its own, for
example).

Side note: the function OPENSSL_CTX_set0_default() is a confusing
name, as there's an internal default ("default default", "ultimate
default"?) library context already, it's possible that we should
rename that to OPENSSL_CTX_set0_current().

Cheers,
Richard

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