gradle - bouncycastle classversion conflict on `NISTObjectIdentifiers`

[nora-h-papercut]

I'm encountering an issue that seems to be related to the bouncycastle providers on the classpath - jsign uses LTS-2.73.7, but gradle (8.14.3) appears to be trying to interact with the builtin version (or another on my classpath), which is different and lacks certain fields.

Caused by: java.lang.NoClassDefFoundError: Could not initialize class org.bouncycastle.cms.CMSSignedData
	at net.jsign.cat.CatalogFile.<init>(CatalogFile.java:94)
	at net.jsign.cat.CatalogFile.<init>(CatalogFile.java:79)
	at net.jsign.cat.CatalogFile.isCatalogFile(CatalogFile.java:64)
	at net.jsign.spi.CatalogSignableProvider.isSupported(CatalogSignableProvider.java:38)
	at net.jsign.Signable.of(Signable.java:182)
	at net.jsign.SignerHelper.sign(SignerHelper.java:438)
	at net.jsign.SignerHelper.execute(SignerHelper.java:305)
	at net.jsign.SignerHelper.execute(SignerHelper.java:299)
	at net.jsign.JsignGradlePlugin$1.doCall$original(JsignGradlePlugin.java:51)
	at net.jsign.JsignGradlePlugin$1.doCall(JsignGradlePlugin.java)
	at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103)
...
Caused by: java.lang.ExceptionInInitializerError: Exception java.lang.NoSuchFieldError: Class org.bouncycastle.asn1.nist.NISTObjectIdentifiers does not have member field 'org.bouncycastle.asn1.ASN1ObjectIdentifier id_slh_dsa_sha2_128s' [in thread "Daemon worker Thread 8"]
	at org.bouncycastle.operator.DefaultDigestAlgorithmIdentifierFinder.<clinit>(Unknown Source)
	at org.bouncycastle.cms.CMSSignedData.<clinit>(Unknown Source)
	... 214 more

I'm not 100% on what would cause this behaviour and whether there's a reasonable workaround where I can manually depend on the LTS to get it to be used - and/or whether there's an issue with the way the gradle plugin has its dependencies declared in the published version.

[nora-h-papercut]

tried to validate this one with an empty gradle project and it's not happening, so i'm guessing this is an issue specific to my project (which uses several other plugins, and has a dependency on bouncycastle for the actual project itself).

Not an issue with jsign itself, I'll see if I can find a workaround for future troubleshooters

[nora-h-papercut]

on inspection, it seems like org.bouncycastle:bcpkix is referencing a field in org.bouncycastle:bcprov that doesn't exist, i.e the problem isn't that one is the wrong version, but rather that they're the wrong versions relative to eachother somehow. buildEnvironment looks pretty happy so i'm not actually sure how that's possible.

[ebourg]

How did you integrate the plugin in the build file? With the new syntax:

plugins {
    id("net.jsign") version "7.1"
}

or the old one ?

buildscript {
    dependencies {
        classpath 'net.jsign:jsign-gradle-plugin:7.1'
    }
}

apply plugin: 'net.jsign'

[nora-h-papercut]

New syntax, but i've now tried old for posterity and got the same result.

[nora-h-papercut]

Question, why isn't it referencing net.jsign.bouncycastle? I thought there was relocation as part of the build process there. is that something that could be done for the core jar (or the gradle jar by shadowing the core jar?)

[nora-h-papercut]

Through local publishing, i gave it a shot:

plugins {
    id 'java'
    id 'com.gradle.plugin-publish' version '1.2.0'
    id 'com.gradleup.shadow' version '9.0.0-rc3'
}

group = 'net.jsign'
version = '7.2-shadowtest'

repositories {
    mavenLocal()
}

dependencies {
    implementation gradleApi()
    shadow "net.jsign:jsign-core:7.1"
}

jar {
    archiveClassifier = 'slim'
}

shadowJar {
    archiveClassifier = ''
    configurations = [project.configurations.shadow]
    relocate 'org.bouncycastle', 'net.jsign.bouncycastle'
}

This did end up working for me. As much as i'd prefer gradle to just not explode plugin dependencies with no clues (I tried a lot of weird workarounds but nothing that seemed to budge it), this is definitely an effective option.

[ebourg]

Question, why isn't it referencing net.jsign.bouncycastle? I thought there was relocation as part of the build process there. is that something that could be done for the core jar (or the gradle jar by shadowing the core jar?)

The relocation is only applied on the all-in-one jar used for the CLI and the Ant task. The Maven and Gradle plugins use normal dependencies.

I wonder why Gradle fails to isolate the classpath of the plugin in this case. Something you could try is to exclude the dependency on BouncyCastle, something like this:

buildscript {
    dependencies {
        classpath 'net.jsign:jsign-gradle-plugin:7.1' {
            exclude group: "org.bouncycastle", module: "bcutil"
            exclude group: "org.bouncycastle", module: "bcprov"
            exclude group: "org.bouncycastle", module: "bcpkix"
        }
    }
}

apply plugin: 'net.jsign'

[nora-h-papercut]

I've tried a whole host of manual dependency setting and module substitution, but here's what i get from the above idea:

    dependencies {
        classpath('net.jsign:jsign-gradle-plugin:7.1') {
            exclude group: "org.bouncycastle"
        }
        classpath('org.owasp.dependencycheck:org.owasp.dependencycheck.gradle.plugin:12.+') {
            exclude group: "org.bouncycastle"
        }
    }

with this configuration, ./gradlew buildEnvironment has zero instances of org.bouncycastle in its output.

Then, running the task, as you'd expect i get

Caused by: java.lang.ClassNotFoundException: org.bouncycastle.cms.CMSException

commenting just the first exclude, i get the usual again

Caused by: java.lang.NoSuchFieldError: Class org.bouncycastle.asn1.nist.NISTObjectIdentifiers does not have member field 'org.bouncycastle.asn1.ASN1ObjectIdentifier id_slh_dsa_sha2_128s'

re-adding the exclude manually re-adding via 'org.bouncycastle:bcpkix-lts8on:2.73.7' gives me the same thing. swapping to bcpkix-jdk18on gives me the same thing. even shadowing WITHOUT relocation doesn't work - which is so beyond me given the output of buildEnvironment

I'd be genuinely convinced that it's a bug in bcpkix itself if not for the fact that it works on a clean project and that it works if jsign gradle uses relocation.

[ebourg]

I got a look at DependencyCheck, the version 12.1.3 depends transitively on Bouncy Castle 1.78 through org.eclipse.packager:packager-rpm 0.21.0.

I don't understand why Gradle doesn't isolate the plugins, and the fact that Bouncy Castle LTS isn't relocated and shares the same namespace as the non-LTS version doesn't help either.

So this means Jsign has to embed and relocate the dependencies for the Gradle plugin. That's annoying because some features don't work in this mode, Jsign becomes unable to open some encrypted keystores (those relying on an encryption mechanism supported by Bouncy Castle but not by the JDK. The relocation breaks the signature of the Bouncy Castle jar and makes the decryption algorithms unusable through JCA). Fortunately file based keystores are now obsolete so the impact is limited, but still...

[nora-h-papercut]

realistically for file-based keystores gradle users can still manually execute the jar as a task, so that seems like a reasonable compromise?

[ebourg]

Another idea would be to publish two plugins, with and without dependencies.

[nora-h-papercut]

not a bad idea! would certainly solve my issue