- Signature.setParameter(...) on the composite ML-DSA services threw NullPointerException when called before initSign / initVerify, the composite counterpart of the base-engine defect fixed for issue #2396. The composite SignatureSpi has its own engineSetParameter, which applies a context by re-initialising the component signatures with the key the Signature holds, and it went straight to that re-initialisation without checking there was a key to re-initialise with - with no key the intent is unknowable, so the null key fell into the signing branch and all thirty-six composite services, plus the generic COMPOSITE service, failed identically. The context may now be set either side of initialisation, as it may be for the base ML-DSA and SLH-DSA services: setting it on a signature that already has a key re-initialises the component signatures at once as before, and setting it beforehand records it to be applied when the key arrives. Three further problems in the same method are fixed with it. A parameter spec that is not one of the provider's own but carries a context - the shape another provider's ML-DSA spec has, which the base engines accept - had the context applied and was then reported as rejected by the same call, so a caller that took the exception at its word went on to produce signatures bound to a context it believed had not been set; such a spec is now simply accepted, and one carrying no context at all is still refused. getParameters() cached the AlgorithmParameters it built and setting a new context did not clear that cache, so getParameters() went on reporting the previous context. And on the generic COMPOSITE service, whose algorithm is not known until the key arrives, a CompositeSignatureSpec set beforehand threw NullPointerException from the absent digest; its choice of pre-hash mode is now recorded and applied at initialisation. Setting a context after initialisation, which is what the existing tests and examples do, produces exactly the signatures it did before (github #2412).
0 commit comments