Library contextify "everything" [master only]

[levitte]

I'm unsure if this should be regarded as a new feature or a bug fix... it rather seems it's a bit of both

While looking at configuration modules, it became clear that we have a disconnect between loading a configuration file (all values currently end up in the default library context) and the use of providers in a non-default library context. The EVP configuration module allows setting the default property query string, but that currently only ends up in the default library context, and if some application decides to use another library context (explicitly created with OPENSSL_CTX_new()) and then loads the config file, they will still see none of the configured property query string.

This would affect functions like CONF_modules_load, and OPENSSL_init_crypto will probably be affected as well (although it does take a settings parameter, so it's possible a library context can be passed that way... I haven't looked yet). This also means that all affected internal databases will have to move into the library context.

This will also affect the interactive mode of the openssl app, since it will become easy to just create a library context before executing each command, and clean it up on completion of each command, thereby fixing the issue #2795, #4679, #6292...

As part of this effort, we need to identify what databases should be affected by this, if not all.

[richsalz]

I believe that library contexts are not sufficiently thought through, and that for 3.0 you only have a global context. Keep the API's, but treat anything non-NULL as an error for this release.

[levitte]

I'm not sure what you mean with "not sufficient", care to elaborate?

[richsalz]

This issue, for example? Ordering? The "init" problem?

[levitte]

#8764 talks a bit about ordering problems. We have that regardless of library context.

[richsalz]

Shrug. I think this is premature but I know I'm in the minority here. Shrug.

[levitte]

This issue has aged