* ENT-11728: Force use of LTS version of BC everywhere.
* ENT-11728: Removed extra task left in.
* ENT-11728: Revert to the now released 2.73.6 version of BC.
* ENT-11728: Switched to LTS version of BC. Also removed PQC algos as not supported in LTS.
* ENT-11728: Removed the SPHINCS PQC algorithm.
* ENT-11728: Added dependency on bcutil to fix missing class error.
The various crypto tests that were previously ignored have been re-enabled.
The abandoned i2p EdDSA library has been replaced with native support that was added in Java 15.
Java 17 (via the `SunEC` provider) does not support the secp256k1 curve (one of the two ECDSA curves supported in Corda). This would not normally have been an issue as secp256k1 is already taken care of by Bouncy Castle. However, this only works if the `Crypto` API is used or if `”BC”` is explicitly specified as the provider (e.g. `Signature.getInstance(“SHA256withECDSA”, “BC”)`). If no provider is specified, which is what is more common, and actually what the Java docs recommend, then this doesn’t work as the `SunEC` provider is selected. To resolve this, a custom provider was created, installed just in front of `SunEC`, which “augments” `SunEC` by delegating to Bouncy Castle if keys or parameters for secp256k1 are encountered.
`X509Utilities.createCertificate` now calls `X509Certificate.verify()` to verify the created certificate, rather than using the Bouncy Castle API. This is more representative of how certificates will be verified (e.g. during SSL handshake) and weeds out other issues (such as unsupported curve error for secp256k1).
`BCCryptoService` has been renamed to `DefaultCryptoService` as it no longer explicitly uses Bouncy Castle but rather uses the installed security providers. This was done to fix a failing test. Further, `BCCryptoService` was already relying on the installed providers in some places.
The hack to get Corda `SecureRandom` working was also resolved. Also, as an added bonus, tests which ignored `SPHINCS256_SHA256` have been reinstated.
Note, there is a slightly inconsistency between how EdDSA and ECDSA keys are handled (and also RSA). For the later, Bouncy Castle is preferred, and methods such as `toSupportedKey*` will convert any JDK class to Bouncy Castle. For EdDSA the preference is the JDK (`SunEC`). However, this is simply a continuation of the previous preference of the i2p library over Bouncy Castle.
"WARNING: sun.reflect.Reflection.getCallerClass is not supported. This will impact performance." warning was being caused by log4j. Latest version fixes this issue.
This requires Kotlin 1.2 versions of core and serialization (core-1.2 and serialization-1.2 respectively), which are just "shell" modules and which compile the existing source code with Kotlin 1.2. The 1.2 plugin does not work with the current version of Gradle and so the 1.2 compiler has to be called directly.
Now with two versions of Kotlin in the code base, each module needs to have its version manually specified to ensure a clean separation. Otherwise, the default Kotlin version can override 1.2 when needed.
Some of the code was tidied-up or improved to enable it to be cross-compiled. For post-1.2 APIs being used, they have been copied into core-1.2 with the same method signatures. OpenTelemetryComponent was moved to node-api, along with the dependency, to avoid also having a 1.2 version for the opentelemetry module.
* Updated mockito version and removed ignored annotation to relevant test cases
* Updated mockito version and removed ignored annotation to relevant test cases
Major changes due to JDK 17:
1. JDK17 JCE Provider now has built-in support for eddsas, corda uses
the bouncycastle (i2p) implementation. This PR removes the conflicting
algorithms from the built-in JCE provider.
2. JavaScript scripting has been removed from the JDK, the corda log4j config was using
scripting to conditionally output additional diagnostic info if the MDC
was populated. This PR has removed the scripting.
3. The artifactory plug-ins used are now deprecated, this PR has removed them
and uses the same code as Corda 5 for publishing to artifactory.
4. Javadoc generation has been modified to use the latest dokka plug-ins.
5. Gradle 7.6 has implemented an incredibly annoying change where transitive
dependencies are not put on the compile classpath, so that they have to be
explicitly added as dependencies to projects.
6. Mockito has been updated, which sadly meant that quite a few source files
have to changes to use the new (org.mockito.kotlin) package name. This makes
this PR appear much larger than it is.
7. A number of tests have been marked as ignored to get a green, broadly they fall
into 3 classes.
The first is related to crypto keypair tests, it appears some logic
in the JDK prefers to use the SunJCE implementation and we prefer to use
bouncycastle. I believe this issue can be fixed with better test setup.
The second group is related to our use of a method called "uncheckedCast(..)",
the purpose of this method was to get rid of the annoying unchecked cast compiler
warning that would otherwise exist. It looks like the Kotlin 1.9 compiler type
inference differs and at runtime sometimes the type it infers is "Void" which causes
an exception at runtime. The simplest solution is to use an explicit cast instead of
unchecked cast, Corda 5 have removed unchecked cast from their codebase.
The third class are a number of ActiveMQ tests which appear to have a memory leak somewhere.
* ENT-10273: Upgrade BC to 1.75.
* Use BC 1.70 for core-deterministic avoid issue with primality checking done in 1.70+ which uses random numbers
---------
Co-authored-by: Shams Asari <shams.asari@r3.com>
First cut of telemetry integration.
Open telemetry can be enabled in two ways, first is via an opentelemetry java agent specified on the command line. With this way you get the advantage of spans created from other libraries, like hibernate. The java agent does byte code rewriting to insert spans.
The second way is with the open telemetry driver (that links with the opentelemetry sdk). This is a fat jar provided with this project and needs to go into the node drivers directory.
