Exclude unused Cryptacular from phase4 runtime

[gregjotau]

What this changes

• Excludes org.cryptacular:cryptacular from phase4's WSS4J dependency.
• Adds an end-to-end regression test that signs and verifies a real SOAP message with RSA-SHA256 and the AS4/Peppol BST_DIRECT_REFERENCE key identifier while BC, ph-bc, and Cryptacular are all hidden from the isolated runtime.

Why this is safe for phase4

Cryptacular supports WSS4J's OpenSAML integration. phase4 does not use SAML and already excludes the OpenSAML implementation artifacts from this dependency. Keeping Cryptacular in the phase4 graph therefore pulls the BC provider jars into every AS4 application without serving a phase4 code path.

This does not change WSS4J itself or prevent an application from adding Cryptacular/OpenSAML explicitly for unrelated SAML use. It only stops phase4 from supplying an unused feature dependency transitively.

Verification

• mvn -pl phase4-test -am verify passed for the complete parent/lib/test reactor.
• phase4-lib: 149 tests passed.
• phase4-test: 205 tests passed, including the HTTP/Jetty signing, verification, encryption, retry, and message-processing suites (9 existing skips).
• The isolated no-BC test uses the complete Surefire runtime classpath but blocks org.bouncycastle.*, com.helger.bc.*, and org.cryptacular.*; it performs both signature creation and WSS4J verification and confirms the verified reference type is DIRECT_REF.
• A downstream reactor consumer (phase4-test) has an empty runtime dependency-tree filter for BC, ph-bc, and Cryptacular. phase4-lib still retains its already-optional ph-bc declaration solely for the deprecated BC-typed OID compatibility API, so it is not propagated to consumers.

Together with the already released provider-neutral OID work in phase4 4.6.1, phax/ph-commons#57, and the dependent phax/peppol-commons#81, this removes phase4's remaining unnecessary provider dependency from standard Peppol AS4 runtimes.

[phax]

Would it be even better to file a request to WSS4J to separate this better?

[phax]

And what is your intrinsic motivation to minimize the dependencies? Do you want to run it on a Raspy? Feel free to send me your email address so I can add you to my Slack

[gregjotau]

Thanks — no Raspberry Pi target here :) The intrinsic motivation is operational hygiene in a large production application. Dependency bloat tends to be death by a thousand cuts: each unused transitive dependency is another artifact to download, package, inventory in the SBOM, scan and triage, and keep patched. It also increases supply-chain and runtime surface even when its feature is never used.

This particular exclusion removes Cryptacular plus its three BC artifacts (about 10.5 MB at the versions in the current graph) from every downstream AS4 runtime. Bouncy Castle itself is actively maintained and useful; I am not arguing that it is defective or universally obsolete. The narrower point is that phase4 does not use WSS4J SAML, so a SAML-support dependency and its crypto-provider graph should ideally not be present transitively for phase4 users.

And yes, upstream separation is the cleaner solution. I checked before filing a duplicate: the exact OpenSAML/WSS4J module split is already being tracked in CXF-8913. The WSS4J maintainer reported separating SAML from the DOM code, revisited making OpenSAML optional in April 2026, and the issue is still In Progress. WSS4J currently compiles its SAML integration into ws-security-common, so this is an architectural module change rather than just changing one dependency flag.

I also documented that boundary in apache/ws-wss4j#653; that focused PR removes the remaining direct BC linkage from core X.509 key-identifier parsing without pretending to solve the SAML module boundary.

I see this phase4 change as the small consumer-side bridge while the upstream split is unfinished. phase4 already excludes the unused OpenSAML implementation artifacts; excluding Cryptacular completes that declaration. Applications can still add the SAML dependencies explicitly, and the new isolated test proves the actual phase4/Peppol BST_DIRECT_REFERENCE sign-and-verify path with BC and Cryptacular unavailable, in addition to the full reactor and Java 17/21/25 builds.