Constrain file store decoders to the caller's provider boundary

[yosuke-wolfssl]

Constrain file store decoders to the caller's provider boundary

Summary

The wolfProvider file store fetched its terminal decoders using only the
structure property and ignored the caller's property query, so a store load
routed to wolfProvider could add and use a decoder from another provider. This
PR propagates the caller's property query into those explicit fetches so a
provider=wolfprov boundary is honored consistently. Fixes finding f_5534.

Problem

wp_file_set_decoder() fetched each decoder like this:

decoder = OSSL_DECODER_fetch(ctx->provCtx->libCtx, wp_decoders[i].name,
    wp_decoders[i].propQuery);   /* e.g. "structure=PrivateKeyInfo" */

The caller-supplied ctx->propQuery (where an application expresses a
provider=wolfprov compliance boundary via OSSL_STORE_PARAM_PROPERTIES) was
applied only to OSSL_DECODER_CTX_add_extra, not to these explicit fetches.
As a result the store's own terminal decoders were fetched without any provider
constraint and could resolve to another provider's implementation.

Fix

Add a file-local helper that combines each decoder's structure query with the
caller's property query, and use it for every explicit fetch:

static int wp_file_decoder_prop_query(const char* base, const char* caller,
    char** query);   /* 1 = ok, 0 = alloc failure; *query freed by caller */

• No caller query (NULL) → behavior unchanged ("structure=...").
• provider=wolfprov → combined query ("structure=...,provider=wolfprov"),
  so the boundary applies to the explicit fetches as well as to
  OSSL_DECODER_CTX_add_extra.

Behavior / compatibility

• Default behavior (no property query) is unchanged.
• When the caller sets provider=wolfprov, the boundary is now enforced on all
  of the store's decoder fetches. A load that previously resolved silently
  through another provider will now stay within wolfProvider — or fail if
  wolfProvider cannot satisfy it, which is the intended boundary semantics.

Testing

• Builds clean under the project's strict warning set
  (-Werror -Wextra -Wshadow -Wshorten-64-to-32 ...).
• Full unit suite passes (OPENSSL_CONF=provider.conf), including the
  store-load paths: test_rsa_load_key, test_rsa_load_cert,
  test_ec_load_key, test_ec_load_cert.

[Copilot]

Pull request overview

This PR fixes a provider-boundary enforcement gap in the wolfProvider file store decoder selection: the store’s explicitly-fetched “terminal” decoders now respect the caller’s OSSL_STORE_PARAM_PROPERTIES query (e.g., provider=wolfprov) instead of only applying it to OSSL_DECODER_CTX_add_extra.

Changes:

• Added a file-local helper to combine each decoder’s structure property query with the caller’s property query.
• Updated explicit OSSL_DECODER_fetch() calls in the file store to use the combined query, ensuring provider boundary constraints are consistently enforced.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[wolfSSL-Fenrir-bot]

Fenrir Automated Review — PR #430

Scan targets checked: wolfprovider-bugs, wolfprovider-src

No new issues found in the changed files. ✅

[aidangarske]

🐺 Skoll Code Review

Overall recommendation: COMMENT
Findings: 1 total — 1 posted, 0 skipped

Posted findings

• [Medium] New property-bound decoder fetch path lacks regression coverage — src/wp_file_store.c:425-431

Review generated by Skoll.

[aidangarske]

🟡 [Medium] New property-bound decoder fetch path lacks regression coverage
💡 SUGGEST test

The PR's core behavior is that explicit OSSL_DECODER_fetch() calls now include ctx->propQuery, but the existing store-load tests do not pass OSSL_STORE_PARAM_PROPERTIES; repository search found that parameter only in src/wp_file_store.c. That leaves the fixed provider-boundary path untested, so a future change could drop the caller query again while the current RSA/EC load tests still pass.

Recommendation: Add a store-load regression test that passes OSSL_STORE_PARAM_PROPERTIES with provider=wolfprov and verifies the key/cert load succeeds within wolfProvider. A negative case using a property query that excludes wolfProvider (e.g. provider=default) would also exercise the failure boundary. Add these focused tests for OSSL_STORE_PARAM_PROPERTIES on the file store path before or soon after merge.

[yosuke-wolfssl]

Agreed, and added the regression tests

[yosuke-wolfssl]

Hello @aidangarske ,
Could you check this please ?