Updated docs.

On a per-command basis, I'm not sure I like the whole library context fiddling, at all. It seems... unnecessary.

Note, though, that I don't think that a library context per se is unnecessary, but it should be made on a global level. Think of the interactive mode, where we currently have each command affecting the rest regarding libcrypto global data. If each command was executed within its own library context, the problem of one command affecting the next should ultimately go away.

Remains electively loading the null provider into the default provider... I assume that's an interim thing, to purposefully make things break if they rely on the default library context when they shouldn't. I'm not sure I'd make that subject of a per-command option, but rather of an environment variable (mostly because we don't have global options). OPENSSL_NO_DEFAULT_CONTEXT maybe?

I've had a global app library context in the back of my mind for a while, so I have ideas (but for once, not a branch yet). Do you want to tackle that or shall I?

I would like to see less environment variables, not more of them :)
Putting the null provider into the default context and using the fips provider in a created library context is a fundamental requirement. The library context was introduced to solve a particular problem. Using the fips provider in the default library context is avoiding the issue that the library context was added for.

As I just discovered with pkeyutl a library context is going to break certain operations that are not currently compatible (such as SM2). Which is why I went with the per command -use_libctx option.

I would like to see less environment variables, not more of them :)

Yes, me too, but I would like even less to see interim / unnecessary options

Putting the null provider into the default context and using the fips provider in a created library context is a fundamental requirement.

Er, what??? Why?

The library context was introduced to solve a particular problem. Using the fips provider in the default library context is avoiding the issue that the library context was added for.

Yes, almost everything that's currently global in libcrypto should move to be stored in a library context, and we're currently not there. That's the reason I'm calling all these new options "interim", because as soon as we've finished that move, they will not be necessary any more. That's also why I seriously question the "fundamental requirement" that the FIPS provider must be loaded in a non-default provider... it sounds much more like a band-aid than a "fundamental requirement".

@levitte. I have updated the code.
I need the 'use_libctx' option to test this as well as any other fips tests (see CMS). So even though it is 'just for testing'. It needs to always be there in order to do the tests. So this is not really a temporary config option.

I have reused -config instead of using provider_config (but this also now loads any modules).

The size of PR #11884 is getting quite large - so I have tried to separate out some bits into smaller PR's to make it easier to review.

ping @levitte

I have multiple PR's that rely on testing using a extra libctx from the apps.

ping @levitte

Changed apps to use an environment variable 'OPENSSL_TEST_LIBCTX'
instead of the -use_libctx option.

@levitte or @mattcaswell - can someone review please.

Needed to rebase and remove the default options for tests call to fipsinstall.

you could have left the redundant default flags, as a test. When I added the defaults, I deliberately did that in one test.

Either way.. having hexkey:00 was not good though :)

Wow the tests ran without a timeout...

24 hours has passed since 'approval: done' was set, but as this PR has been updated in that time the label 'approval: ready to merge' is not being automatically set. Please review the updates and set the label manually.

Thanks.. Merged to master.