Issue 19704 get default search path

[pm-cfs]

Checklist

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

Description of change

Update core provider to add:

• OSSL_PROVIDER_get1_default_search_path
• Unit test to verify that set/get work as expected in library contexts

Fixes #19704

[paulidale]

Just a random thought but would OSSL_PROVIDER_get0_default_search_path be more sensible? The caller gets to decide to strdup or not -- the path exists for the life of the libctx, so not duping it is reasonable.

const char *OSSL_PROVIDER_get0_default_search_path(OSSL_LIB_CTX *libctx)
{
    char *path = NULL;

    if ((store = get_provider_store(libctx)) != NULL
            && CRYPTO_THREAD_read_lock(store->default_path_lock)) {
        path = OPENSSL_strdup(store->default_path ? store->default_path : "");
        CRYPTO_THREAD_unlock(store->default_path_lock);
    }
    return path;
}

[pm-cfs]

That is always an option; in that case, I would just do:

path = store->default_path;

You do get less error info that way; if the lock failed for some reason or the library context was invalid which is why I went the other route.

[paulidale]

Sorry, didn't look at the code properly :(

An invalid library context is likely to crash. The lock failing is a legitimate concern I guess.

[pm-cfs]

I think an invalid library context should return NULL on get_provider_store (it calls ossl_lib_ctx_get_data which will also fail gracefully).

[paulidale]

or it will crash or return rubbish. C has no way to distinguish a good pointer from a bad one.

[pm-cfs]

ok, switched to OSSL_PROVIDER_get0_default_search_path

[t8m]

I'd also prefer implementing get0 accessor instead. I would definitely be ok with adding it to 3.1. In that case the libcrypto.num and documentation HISTORY entry has to change.

Not sure about 3.0. I do not see it as bug fix.

[t8m]

Instead of adding merge commits please rebase the whole PR against fresh master branch.

[pm-cfs]

Ok, rebased to master and squashed to simplify commit history.

[t8m]

pyca-cryptography

The pyca-cryptography submodule change has to be reverted.

[pm-cfs]

For the pyra-cryptography, do I just ignore those / Discard? Git keeps adding it in as a change from master.

[t8m]

The original commit message was lost. Could you please amend the first commit message and possibly squash the two commits into one? You can use git rebase -i for that.

[tmshort]

LGTM

[openssl-machine]

This pull request is ready to merge

[t8m]

As is this can be merged only to master branch. So I did that.

@pm-cfs if you want this in 3.1 would you please submit a PR against master branch that changes the version in the manpage and libcrypto.num and separate PR against openssl-3.1 branch that cherry-picks this merged commit?