CMS signature without explicit provider seem to have recently broken

[lapo-luchini]

I had used this code for years to produce a CMS signature:

JcaContentSignerBuilder cb = new JcaContentSignerBuilder(Algorithms.getSignature(cert.getPublicKey(), algoid));
if (provider != null)
    cb.setProvider(provider);
gen.addSignerInfoGenerator(bld.build(cb.build(key), cert));

in a specific instance I was using a PrivateKey from my own provider (which the key correctly contains), but recently upgrading to BC 1.85 broke this signature:

Caused by: org.bouncycastle.operator.RuntimeOperatorException: exception obtaining signature: java.lang.NullPointerException
	at myproj.war//org.bouncycastle.operator.jcajce.JcaContentSignerBuilder$1.getSignature(Unknown Source)
	at myproj.war//org.bouncycastle.operator.jcajce.JcaContentSignerBuilder$3.getSignature(Unknown Source)
	at myproj.war//org.bouncycastle.cms.SignerInfoGenerator.generate(Unknown Source)
	at myproj.war//org.bouncycastle.cms.CMSSignedDataGenerator.generateSignerInfo(Unknown Source)
	at myproj.war//org.bouncycastle.cms.CMSSignedDataGenerator.generate(Unknown Source)
Caused by: java.security.SignatureException: java.lang.NullPointerException
	at myproj.war//org.bouncycastle.jcajce.provider.asymmetric.rsa.DigestSignatureSpi.engineSign(Unknown Source)
	at java.base/java.security.Signature$Delegate.engineSign(Signature.java:1404)
	at java.base/java.security.Signature.sign(Signature.java:713)

As you can see the signature gets attempted using BC as a provider, not the provider of the key.
I'm not sure it was ever okay, but it was working fine up until recently.
Now it only works if I correctly specify the specific provider.
This might either be a bug/regression, or something to write in the release notes (when #2355 gets closed) as a HEADSUP for users.

[dghgit]

This is not a release notes thing... the issue is provider precedence, and there's a couple of ways this can manifest now - the JCA has been changed to try and recognise private keys for particular providers and then a provider with higher precedence advertising an algorithm name after an update that was not previously advertised can also upset things - this might be what is happening here, but at any rate I'm not sure which particular bit of the JCA provider auto-resolution chaos has been awakened.

Specify your provider if you're using particular keys (I'd assume from the stack trace it's a hardware key), it's the only way you can be certain the code will always do the right thing.

[lapo-luchini]

The provider was implemented by me, and it implements a KeyStore, a custom RSAPrivateKey (which has nothing locally, just a reference to a remote hardware key) and custom signature methods. Also, BC 1.85 requires the RSAPrivateKey.getModulus() to be implemented, which wasn't used before.
Yeah I do agree forgetting to set the provider explicitly was an error, and after long hours of debug I solved both problems, but still a change of behavior from the past which might lead other users to frustration.

[dghgit]

Provider selection is not determined by the Bouncy Castle provider. With hardware keys it is usually better to avoid the use of the standard interfaces as it can result in the kind of confusion as well.