Message12974

This is not to do with shading, since I get the same effect when classes are bundled as org.bouncycastle... .. The Bouncy Castle JAR is signed and our jython.jar is rejected as a security provider, somewhere in the depths of javax.crypto,. The exception then emerges as a "not available".

BC is perhaps following this guidance: https://docs.oracle.com/javase/8/docs/technotes/guides/security/crypto/HowToImplAProvider.html#integritycheck

The checks only apply to certain operations, which are used in the failing test. Options now appear to be:
1. Do not bundle Bouncy Castle at all, and recommend installing it on the class path.
2. Bundle Bouncy Castle (un)shaded, and recommend installing it on the class path if an application needs the checked services.
3. Get our JARs acknowledged as a security provider.

I favour 2, shaded. Most of SSL then still works, judging by the test. When the checked services are required, _sslcerts.py will pick up the unshaded version in preference to the one we bundle. Option 3 sounds difficult: it's a claim of quality I doubt we could get the CA to back.