Filtered providers: add useOriginalNames and additionalServices properties

[cconlon]

This PR adds two opt-in Security properties to the filtered Sun providers (FilteredSun/FilteredSunEC/FilteredSunRsaSign). Default behavior is unchanged.

wolfssl.filtered.useOriginalNames - when set to true in java.security, the providers register under the original provider names (SUN, SunEC, SunRsaSign), so legacy code and OpenJDK internals that hardcode provider names (ex: CertificateFactory.getInstance("X.509", "SUN")) keep working on hardened/FIPS images.

wolfssl.filtered.{sun,sunec,sunrsasign}.additionalServices - comma-separated Type.Algorithm list granting individual services through the filter without recompiling (ex: MessageDigest.MD5 keeps java.util.UUID.nameUUIDFromBytes() working when no registered provider offers MD5). Grants are exact: no wildcards, canonical names only, served by the JDK's pure-Java implementation outside the wolfCrypt FIPS module boundary.

• Security properties only, read once at provider construction. Same-named system properties are ignored.
• Only allow-listed plus explicitly granted services are exposed regardless of registered name. getInfo() still identifies the providers as filtered for auditing
• Misconfigurations print one-line stderr warnings at construction (unmatched/malformed grant entries, unrecognized useOriginalNames values, ignored -D system properties). A correct configuration prints nothing
• README documents usage, pros/cons, and common configuration mistakes, including that providers must be registered by class name (a security.provider.N=SUN name-form entry loads the stock Sun provider, bypassing the filter)

[Copilot]

Pull request overview

Adds an opt-in wolfssl.filtered.useOriginalNames Security property for the filtered Sun providers so they can register under the original provider names (SUN, SunEC, SunRsaSign) to preserve compatibility with code paths that hardcode provider names, while keeping service allow-listing and “filtered” identification via getInfo().

Changes:

• Add ProviderServiceCopier.resolveName() to select filtered vs original provider registration names based on a Security property.
• Update FilteredSun, FilteredSunEC, and FilteredSunRsaSign to use the resolved provider name and document the new behavior.
• Expand functional tests and README documentation to cover the new property and its operational tradeoffs.

Reviewed changes

Copilot reviewed 6 out of 6 changed files in this pull request and generated 5 comments.

Show a summary per file

File	Description
src/test/java/com/wolfssl/security/providers/test/FilteredProviderFunctionalTest.java	Adds functional tests for default/overridden provider names and hardcoded "SUN" lookups.
examples/filtered-providers/src/com/wolfssl/security/providers/ProviderServiceCopier.java	Introduces resolveName() helper that reads wolfssl.filtered.useOriginalNames from java.security/Security properties.
examples/filtered-providers/src/com/wolfssl/security/providers/FilteredSun.java	Uses resolveName() and documents how/why to register as "SUN".
examples/filtered-providers/src/com/wolfssl/security/providers/FilteredSunEC.java	Uses resolveName() and documents how/why to register as "SunEC".
examples/filtered-providers/src/com/wolfssl/security/providers/FilteredSunRsaSign.java	Uses resolveName() and documents how/why to register as "SunRsaSign".
examples/filtered-providers/README.md	Documents the new Security property, its pros/cons, and registration caveats.

---

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

[Copilot]

Pull request overview

Copilot reviewed 8 out of 8 changed files in this pull request and generated no new comments.

Suppressed comments (1)

src/test/java/com/wolfssl/security/providers/test/FilteredProviderFunctionalTest.java:556

• The provider reinsertion loop restores removed providers in ascending position order. Because Security.insertProviderAt() shifts later providers to the right, inserting low positions first changes the effective target indices of later insertions and can leave the provider order different from what it was before the test. This can leak state into subsequent tests that rely on provider precedence.

Reinsert in descending order (highest original position first) to preserve original ordering/positions.

            /* Reinsert removed providers at original positions, ascending */
            for (Map.Entry<Integer, Provider> e : removed.entrySet()) {
                if (Security.getProvider(e.getValue().getName()) == null) {
                    Security.insertProviderAt(e.getValue(), e.getKey());
                }

[wolfSSL-Fenrir-bot]

Fenrir Automated Review — PR #246

Scan targets checked: wolfcrypt-jni-bugs, wolfcrypt-jni-src

Findings: 1
1 finding(s) posted as inline comments (see file-level comments below)

This review was generated automatically by Fenrir. Findings are non-blocking.