Add params argument to _init calls

[paulidale]

• documentation is added or updated
• tests are added or updated

[levitte]

The discussion in #14383 (comment) has me wonder, for whose benefit do we make this change? For EVP_MAC and EVP_KDF, it's quite clear, we had an intention to give the user (the callers of the EVP_MAC and EVP_KDF functions) some comfort, so they wouldn't need to call a separate set_params function. That's pretty clear cut.

This change doesn't do anything similar, as it's kept quite internal in libcrypto... I'm not sure that I can see how this benefits the author of a KEYMGMT implementation, and considering that this is only being passed NULL from the libcrypto code, it seems strangely futile.

EDIT: and @paulidale, I'm quite aware that I nudged you in this direction.

[paulidale]

The OTC wanted the params argument on all _init() calls: #11007 (comment) plus the comments after.

I'm having second thoughts -- the same ones you are. The rest is kept quite internal and it would mean a slurry of new APIs to access. Some things can't even be accessed directly currently and it seems silly to add calls just so they can be.

Hence the suggestion to add the argument to the core_dispatch APIs but to not expose it at the libcrypto level. This I could support as a future proofing exercise.

[levitte]

The OTC wanted the params argument on all _init() calls: #11007 (comment) plus the comments after.

Yes, and that's primarily about our public API, i.e. user callable functions like EVP_MAC_init(), ... I didn't necessarily hear that as meaning the libcrypto<->provider interface (although I do see the practicality for OSSL_FUNC_mac_init(), but that's more because of the added key + keylen, so it didn't hurt to throw in the params as well)

[t-j-h]

It would be a very strange choice to elect that init's in the provider interface don't have OSSL_PARAMs when we have collectively decided that init's have OSSL_PARAMs - I did not see that OTC decision as limited to only public APIs or that anyone would think that we should have a different approach in terms of capabilities in the public and provider APIs - frankly that didn't occur to me that someone would want to split hairs at that level on an OTC decision.

[levitte]

frankly that didn't occur to me that someone would want to split hairs at that level on an OTC decision.

Hmm, I'm pretty sure I have mentioned, more than once, that the public API and the libcrypto<->provider interface aren't necessarily the same thing. For one thing, different crowds are affected; whatever we decide for the libcrypto<->provider interface primarily concern provider authors, while the public API primarily concern application authors.

That being said, I have nothing per se against adding an OSSL_PARAM argument to the provider side init functions, not at all. However, if the only user of those functions (our libcrypto code) does nothing bu pass NULL, it seems like an exercise in futility.

[paulidale]

That being said, I have nothing per se against adding an OSSL_PARAM argument to the provider side init functions, not at all. However, if the only user of those functions (our libcrypto code) does nothing bu pass NULL, it seems like an exercise in futility.

My rationale is that we can't change the provider API so including the params now prevents problems in the future.
That we can't change the libcrypto API means we need to introduce a new function if we add the argument -- this is something we can do later in a dot release.

[levitte]

That we can't change the libcrypto API means we need to introduce a new function if we add the argument -- this is something we can do later in a dot release.

Okie, that translates into at least an idea of a future intention. That's what I didn't hear before. That's good enough for me.

[paulidale]

I've exposed the new functionality to the public API, that was easy. The provider API is horrible now and I've broken a lot of things. Moreover, I'm even less sure of the benefits -- we don't seem to push parameters into PKEY_CTXs much, rather we just do an operation with one. Almost all digests get zero benefit from the changes. For ciphers, it seems like major overkill for little upside.

Apart from MAC and KDF which are parameter heavy, there seems to be little need for this.

It seemed like such a good idea when we discussed it with the OTC....

[/venting]

[paulidale]

EVP_CIPHER_init() ?

[paulidale]

Time for some reviewing :)

[levitte]

Now that we have seen the effect, I think we need to review the OTC decision.

[paulidale]

OTC decision: updating the provider side API to include the params is okay.

[paulidale]

Merged to master. Thanks for the reviews.