Remove unused C# and Java interop validators under test/validators

[cjbarth]

Summary

Remove test/validators/ — the C# (XmlCryptoUtilities) and Java (XmlCryptoJava) interop scratchpads. They are not run by CI, npm scripts, or any documented workflow, and parts of them no longer compile. The reference-implementation value they once provided is already frozen into the static fixtures under test/static/.

Current state

C# — test/validators/XmlCryptoUtilities/

• ValidateSignature.csproj targets TargetFrameworkVersion v4.0 (.NET Framework, Client profile, x86), in a Visual Studio 2010 format .sln. Not buildable with the modern toolchain on Linux/macOS.
• Program.cs signs or verifies an enveloped signature using a hardcoded WSE 2.0 sample cert and prints signature is valid. It makes no assertion and never compares against xml-crypto's output — it was run by hand and eyeballed.
• utilities.cs is entirely commented out. Namespace is ConsoleApplication31; it references C:\Program Files\Microsoft WSE\v2.0\Samples\....
• program-repro-misc-validation-and-canon.cs is not in the <Compile> item group, so it does not build. It also reflects into SignedXml's private m_signature field, a .NET Framework internal with no modern equivalent.
• Build outputs are committed: bin/Debug/*.exe, *.pdb, obj/, and a binary .suo.
• ClientPrivate.pfx is committed with its password (wse2qs) in adjacent source. It is a well-known public Microsoft WSE sample cert, not a real secret, but a committed .pfx plus password reliably trips secret scanners.

Java — test/validators/XmlCryptoJava/

• One test file (HMACTest.java), JUnit 4.13.1, maven-compiler-plugin source/target 1.7, log4j 1.2.17, slf4j 1.7.12. Also never run by CI.

Why removal rather than modernization

Cross-checking against a reference implementation is genuinely valuable for XML-DSig — canonicalization is exactly where implementations diverge. But:

1. The value is already captured. test/static/ holds 53 fixtures (wsu signatures, SAML responses, WS-Federation metadata, keyinfo - pretty-printed.xml) that are precisely the reference outputs this tooling produced. They were generated once and frozen, which is the right shape — tests assert against known-good bytes with no second toolchain in the loop.
2. Modernizing is a rewrite, not a port. Of three C# sources, one works and asserts nothing, one is dead, one does not compile.
3. A live harness only pays off if it runs in CI. That means a net8.0 rewrite, a dotnet job in ci.yml, generated test certs instead of a committed .pfx, and an actual diff against xml-crypto output. For a library with a stable surface, that is a permanent second (or third) toolchain in CI for a thin return.

Side benefit

The .sln/.csproj cause VS Code's C# extension to activate on this workspace, which then surfaces .NET SDK deprecation notices to contributors. Removing the solution resolves that.

Proposed change

• Delete test/validators/ (21 tracked files, ~232K).
• Add a short note to the test README or CONTRIBUTING recording that fixtures in test/static/ were originally generated against the Microsoft and Apache Santuario implementations, so the provenance is not lost.

Counterargument

If maintainers regard these as documentation of how the fixtures were produced, keeping them as inert reference has some archival logic. The position here is that a paragraph of prose does that job better than a non-compiling project — and the git history preserves them either way.

If full removal is contentious, the uncontroversial subset is dropping the build artifacts and the committed cert: bin/, obj/, .suo, ClientPrivate.pfx.