Reordering new API's that have a libctx, propq

[Dr. Matthias St. Pierre]

Both suggestions make sense to me and they were discussed several times in the weekly calls.
So you have my support whether there will be the need for a formal vote or not.

> An otc_hold was put on this.. Do we need to have a formal vote?

Since Tim placed the hold, only he can remove it. If he doesn’t, an OTC vote is inevitable.

https://github.com/openssl/openssl/pull/12778#issuecomment-686348526

In that case, let’s just have the vote and finish it quickly.

Matthias


From: openssl-project <openssl-project-bounces at openssl.org> On Behalf Of SHANE LONTIS
Sent: Saturday, September 5, 2020 5:48 AM
To: openssl-project at openssl.org
Subject: Reordering new API's that have a libctx, propq

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


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mta.openssl.org/pipermail/openssl-project/attachments/20200905/10b7bd24/attachment-0001.html>