Null provider

Active contributors: Matt Caswell, Pauli

Purpose

The null provider publishes no algorithms. Loading it into a library context is the way to positively forbid implicit loading of the default provider in that context.

Entry point: providers/nullprov.c (~2.6 KB). It is built into libcrypto.

Use case

Suppose your application maintains a custom OSSL_LIB_CTX (libctx) and you want to guarantee that any code path that forgets to specify a provider explicitly fails loudly rather than silently falling back to the global default context. By default, libcrypto will auto-load the default provider into the default libctx the first time anyone fetches an algorithm there. Loading null prevents that.

OSSL_LIB_CTX *child = OSSL_LIB_CTX_new();

/* Forbid implicit default-provider loading in the *default* libctx, so that
   bugs that forget to pass `child` will be caught immediately. */
if (!OSSL_PROVIDER_load(NULL, "null"))
    abort();

/* Now do all crypto via `child` only. */
EVP_MD *md = EVP_MD_fetch(child, "SHA2-256", NULL);

This is the pattern recommended by doc/man7/OSSL_PROVIDER-null.pod for applications that want strict isolation between contexts (e.g. a TLS terminator that uses one libctx for FIPS-validated cryptography and a different libctx for non-FIPS-validated transport-layer compression).

Implementation

nullprov.c is essentially a stub: its OSSL_provider_init returns dispatch tables that report no operations. The interesting bit is that it still has to be a valid provider (with a name, a teardown function, and so on) so that OSSL_PROVIDER_load(NULL, "null") succeeds and occupies the libctx's "must auto-load default provider" slot.

There is no documentation on the implementation beyond the file itself; the man page OSSL_PROVIDER-null covers the use cases.

Property

The null provider's algorithms (none) would carry the property provider=null. Since it publishes nothing, this never matters in practice.

Entry points for modification

The null provider is one of the smallest non-trivial files in the tree and is unlikely to require changes. If the provider ABI changes (a new mandatory OSSL_FUNC_provider_*), then nullprov.c is updated alongside defltprov.c, legacyprov.c, baseprov.c, and fipsprov.c.