Skip to content

chore(deps): Bump the "all-dependencies" group with 2 updates across multiple ecosystems - #45

Open
dependabot[bot] wants to merge 1 commit into
mainfrom
dependabot/all_dependencies-eb2dcd3212
Open

chore(deps): Bump the "all-dependencies" group with 2 updates across multiple ecosystems#45
dependabot[bot] wants to merge 1 commit into
mainfrom
dependabot/all_dependencies-eb2dcd3212

Conversation

@dependabot

@dependabot dependabot Bot commented on behalf of github Aug 31, 2026

Copy link
Copy Markdown

Bumps the all-dependencies group with 3 updates: actions/setup-java, github/codeql-action/init and github/codeql-action/analyze.

Updates actions/setup-java from 5.7.0 to 6.0.0

Release notes

Sourced from actions/setup-java's releases.

v6.0.0

What's Changed

... (truncated)

Commits

Updates github/codeql-action/init from 4.37.6 to 4.37.9

Release notes

Sourced from github/codeql-action/init's releases.

v4.37.9

  • Update default CodeQL bundle version to 2.26.4. #4106

v4.37.8

No user facing changes.

v4.37.7

  • Update default CodeQL bundle version to 2.26.3. #4085
Changelog

Sourced from github/codeql-action/init's changelog.

CodeQL Action Changelog

See the releases page for the relevant changes to the CodeQL CLI and language packs.

[UNRELEASED]

No user facing changes.

4.37.9 - 26 Aug 2026

  • Update default CodeQL bundle version to 2.26.4. #4106

4.37.8 - 21 Aug 2026

No user facing changes.

4.37.7 - 13 Aug 2026

  • Update default CodeQL bundle version to 2.26.3. #4085

4.37.6 - 04 Aug 2026

  • Changed the default filepath for the new remote file address format that was introduced in CodeQL Action 4.37.0 / 3.37.0 to .github/codeql-config.yml to align it with the suggested path that is used elsewhere. #4070

4.37.5 - 03 Aug 2026

  • Fixed a bug where a network error while streaming the download of the CodeQL bundle could terminate the init Action instead of falling back to downloading the bundle before extracting it. #4061

4.37.4 - 29 Jul 2026

  • This version of the CodeQL Action adds support for the tools input for the codeql-action/init step to be specified using a github-codeql-tools repository property. This feature will gradually be rolled out following the release of this version. Once rolled out, this allows for the CodeQL CLI version that is used in GitHub-managed workflows, such as Default Setup, to be set to a custom value. For example, customers who run into issues with rate limits when a new CodeQL CLI version is released can set the value to toolcache to always use the CodeQL CLI version that is available in the runner toolcache. For Advanced Setup workflows, the value provided for tools in the workflow definition always takes precedence unless the value of the repository property starts with !. #4037
  • Update default CodeQL bundle version to 2.26.2. #4051

4.37.3 - 22 Jul 2026

No user facing changes.

4.37.2 - 21 Jul 2026

  • The new address format for the config-file input that was introduced in CodeQL Action 4.37.0 is now enabled by default. In addition to the format described there, the remote= prefix can now be used to explicitly indicate that the input refers to a remote file. All previous input formats continue to be accepted as well. #4023
  • The CodeQL Action can now make use of configured private registries in Default Setup to retrieve CodeQL configuration files from remote repositories that require authentication. This will allow customers to store their CodeQL configuration in a single repository that can then be referenced by Default Setup workflows in other repositories. We expect to roll this and other, related changes out to everyone in July. #4007

4.37.1 - 16 Jul 2026

  • Upcoming breaking change: Add a deprecation warning for customers using CodeQL version 2.20.6 and earlier. These versions of CodeQL were discontinued on 1 July 2026 alongside GitHub Enterprise Server 3.16, and will be unsupported by the next minor release of the CodeQL Action. #3956
  • Update default CodeQL bundle version to 2.26.1. #4019

4.37.0 - 08 Jul 2026

  • Update default CodeQL bundle version to 2.26.0. #3995

... (truncated)

Commits
  • cdf488f Merge pull request #4107 from github/update-v4.37.9-920ba7cd1
  • 7243f38 Update changelog for v4.37.9
  • 920ba7c Merge pull request #4106 from github/update-bundle/codeql-bundle-v2.26.4
  • ecfa6e1 Add changelog note
  • adcdf4a Update default bundle to codeql-bundle-v2.26.4
  • 486fec2 Merge pull request #4099 from github/update-supported-enterprise-server-versions
  • 134624c Merge pull request #4101 from github/dependabot/npm_and_yarn/npm-minor-457d82...
  • ff43db8 Merge pull request #4103 from github/mergeback/v4.37.8-to-main-db488dde
  • 4605e03 Rebuild
  • 099c869 Update changelog and version after v4.37.8
  • Additional commits viewable in compare view

Updates github/codeql-action/analyze from 4.37.6 to 4.37.9

Release notes

Sourced from github/codeql-action/analyze's releases.

v4.37.9

  • Update default CodeQL bundle version to 2.26.4. #4106

v4.37.8

No user facing changes.

v4.37.7

  • Update default CodeQL bundle version to 2.26.3. #4085
Changelog

Sourced from github/codeql-action/analyze's changelog.

CodeQL Action Changelog

See the releases page for the relevant changes to the CodeQL CLI and language packs.

[UNRELEASED]

No user facing changes.

4.37.9 - 26 Aug 2026

  • Update default CodeQL bundle version to 2.26.4. #4106

4.37.8 - 21 Aug 2026

No user facing changes.

4.37.7 - 13 Aug 2026

  • Update default CodeQL bundle version to 2.26.3. #4085

4.37.6 - 04 Aug 2026

  • Changed the default filepath for the new remote file address format that was introduced in CodeQL Action 4.37.0 / 3.37.0 to .github/codeql-config.yml to align it with the suggested path that is used elsewhere. #4070

4.37.5 - 03 Aug 2026

  • Fixed a bug where a network error while streaming the download of the CodeQL bundle could terminate the init Action instead of falling back to downloading the bundle before extracting it. #4061

4.37.4 - 29 Jul 2026

  • This version of the CodeQL Action adds support for the tools input for the codeql-action/init step to be specified using a github-codeql-tools repository property. This feature will gradually be rolled out following the release of this version. Once rolled out, this allows for the CodeQL CLI version that is used in GitHub-managed workflows, such as Default Setup, to be set to a custom value. For example, customers who run into issues with rate limits when a new CodeQL CLI version is released can set the value to toolcache to always use the CodeQL CLI version that is available in the runner toolcache. For Advanced Setup workflows, the value provided for tools in the workflow definition always takes precedence unless the value of the repository property starts with !. #4037
  • Update default CodeQL bundle version to 2.26.2. #4051

4.37.3 - 22 Jul 2026

No user facing changes.

4.37.2 - 21 Jul 2026

  • The new address format for the config-file input that was introduced in CodeQL Action 4.37.0 is now enabled by default. In addition to the format described there, the remote= prefix can now be used to explicitly indicate that the input refers to a remote file. All previous input formats continue to be accepted as well. #4023
  • The CodeQL Action can now make use of configured private registries in Default Setup to retrieve CodeQL configuration files from remote repositories that require authentication. This will allow customers to store their CodeQL configuration in a single repository that can then be referenced by Default Setup workflows in other repositories. We expect to roll this and other, related changes out to everyone in July. #4007

4.37.1 - 16 Jul 2026

  • Upcoming breaking change: Add a deprecation warning for customers using CodeQL version 2.20.6 and earlier. These versions of CodeQL were discontinued on 1 July 2026 alongside GitHub Enterprise Server 3.16, and will be unsupported by the next minor release of the CodeQL Action. #3956
  • Update default CodeQL bundle version to 2.26.1. #4019

4.37.0 - 08 Jul 2026

  • Update default CodeQL bundle version to 2.26.0. #3995

... (truncated)

Commits
  • cdf488f Merge pull request #4107 from github/update-v4.37.9-920ba7cd1
  • 7243f38 Update changelog for v4.37.9
  • 920ba7c Merge pull request #4106 from github/update-bundle/codeql-bundle-v2.26.4
  • ecfa6e1 Add changelog note
  • adcdf4a Update default bundle to codeql-bundle-v2.26.4
  • 486fec2 Merge pull request #4099 from github/update-supported-enterprise-server-versions
  • 134624c Merge pull request #4101 from github/dependabot/npm_and_yarn/npm-minor-457d82...
  • ff43db8 Merge pull request #4103 from github/mergeback/v4.37.8-to-main-db488dde
  • 4605e03 Rebuild
  • 099c869 Update changelog and version after v4.37.8
  • Additional commits viewable in compare view

Bumps the all-dependencies group with 8 updates:

Package From To
org.jetbrains.kotlin:kotlin-gradle-plugin 2.4.20-Beta1 2.4.20-RC2
com.android.application 9.3.1 9.3.2
com.android.library 9.3.1 9.3.2
org.bouncycastle:bcprov-jdk18on 1.85 1.85.2
org.bouncycastle:bcpkix-jdk18on 1.85 1.85.2
org.bouncycastle:bcutil-jdk18on 1.85 1.85.2
androidx.core:core 1.17.0 1.19.0
gradle-wrapper 9.7.0 9.7.1

Updates org.jetbrains.kotlin:kotlin-gradle-plugin from 2.4.20-Beta1 to 2.4.20-RC2

Release notes

Sourced from org.jetbrains.kotlin:kotlin-gradle-plugin's releases.

Kotlin 2.4.20-RC2

Changelog

Compiler

  • KT-88316 K/N: StackOverflowError in CastsOptimization when two nullable local variables are assigned to each other across nested loops

Compose compiler

  • b/549552317 Fixed a bug that, in certain cases, prevented execution of non-local return statements inside lambdas called from when expressions.

JavaScript

  • KT-88571 K/JS: "llegalStateException: Internal error: cannot find external signature" caused by @Serializable enum in 2.4.20-RC

Tools. CLI

  • KT-88475 IncrementalCompilationComponents instances are not being called anymore

Tools. Gradle. Wasm

  • KT-88566 K/Wasm: Webpack configuration generated after user defined chunks from the webpack.config.d directory

Kotlin 2.4.20-RC

Changelog

Backend. J2KLIB

  • KT-88165 Add Support for -XheaderModeType=compilation to improve header compilation performance
  • KT-86239 [JKLIB] Investigate which type system context is needed in JklibIrLinker
  • KT-88306 [JKLIB] Unbound symbols for kotlin.coroutines.SuspendFunctionN
  • KT-88120 [JKLIB] Add -jvm-target to K2JKlibCompilerArguments
  • KT-88176 [JKLIB] DeserializationStrategy.WITH_INLINE_BODIES when deserializaing dependencies
  • KT-88163 Allow to disable firAggressivePrunner for Jklib

Compiler

  • KT-87499 ClassCastException "Float cannot be cast to Unit" when a suspend function's result is discarded in a when-branch
  • KT-87983 CCE on member extension property delegated to bound property reference
  • KT-85403 kotlin.NoWhenBranchMatchedException on Kotlin Native with sealed interface
  • KT-87922 K1FakeDescriptorsForReferencesKt classes duplicated between kotlin-scripting-compiler-embeddable and kotlin-build-tools-impl
  • KT-86657 Native: turn on incremental compilation by default

Compose compiler

  • b/543684938 Fix composable singleton in function with type parameters
  • b/537617330 Fixed a bug that caused miscompilation of cross-module calls       to getters and setters, causing spurious runtime errors.

JVM. Reflection

... (truncated)

Changelog

Sourced from org.jetbrains.kotlin:kotlin-gradle-plugin's changelog.

2.4.20-RC2

Compiler

  • KT-88316 K/N: StackOverflowError in CastsOptimization when two nullable local variables are assigned to each other across nested loops

Compose compiler

  • b/549552317 Fixed a bug that, in certain cases, prevented execution of non-local return statements inside lambdas called from when expressions.

JavaScript

  • KT-88571 K/JS: "llegalStateException: Internal error: cannot find external signature" caused by @Serializable enum in 2.4.20-RC

Tools. CLI

  • KT-88475 IncrementalCompilationComponents instances are not being called anymore

Tools. Gradle. Wasm

  • KT-88566 K/Wasm: Webpack configuration generated after user defined chunks from the webpack.config.d directory

2.4.20-RC

Backend. J2KLIB

  • KT-88165 Add Support for -XheaderModeType=compilation to improve header compilation performance
  • KT-86239 [JKLIB] Investigate which type system context is needed in JklibIrLinker
  • KT-88306 [JKLIB] Unbound symbols for kotlin.coroutines.SuspendFunctionN
  • KT-88120 [JKLIB] Add -jvm-target to K2JKlibCompilerArguments
  • KT-88176 [JKLIB] DeserializationStrategy.WITH_INLINE_BODIES when deserializaing dependencies
  • KT-88163 Allow to disable firAggressivePrunner for Jklib

Compiler

  • KT-87499 ClassCastException "Float cannot be cast to Unit" when a suspend function's result is discarded in a when-branch
  • KT-87983 CCE on member extension property delegated to bound property reference
  • KT-85403 kotlin.NoWhenBranchMatchedException on Kotlin Native with sealed interface
  • KT-87922 K1FakeDescriptorsForReferencesKt classes duplicated between kotlin-scripting-compiler-embeddable and kotlin-build-tools-impl
  • KT-86657 Native: turn on incremental compilation by default

Compose compiler

  • b/543684938 Fix composable singleton in function with type parameters
  • b/537617330 Fixed a bug that caused miscompilation of cross-module calls       to getters and setters, causing spurious runtime errors.

JVM. Reflection

... (truncated)

Commits
  • ab5bcd9 Edit ChangeLog for 2.4.20-RC2
  • 9464edc Add ChangeLog for 2.4.20-RC2
  • 0261e43 Cherry-pick "Fix asBodyAndResultVar call in `visitInlinedLambdaInComposable...
  • 0763513 [box-tests] Workaround for klib compatibility tests (#7626)
  • 045aec6 [Wasm] Append scripts from webpack.config.d in the end of the file (#7615)
  • cd7173b 🍒 [2.4.20] [K/JS] Keep associated obj annotation only if getInstance survives...
  • d36a2ff CastsOptimizationPass: break aliases cycles (#7578)
  • 8664983 [CLI] Restore custom IC search scope creation
  • 2b6fec7 Add Changelog for 2.4.20-RC
  • ab55759 [Gradle] Fix JS in-process compilation fails with random reasons on Gradle 9.7
  • Additional commits viewable in compare view

Updates com.android.application from 9.3.1 to 9.3.2

Updates com.android.library from 9.3.1 to 9.3.2

Updates org.bouncycastle:bcprov-jdk18on from 1.85 to 1.85.2

Changelog

Sourced from org.bouncycastle:bcprov-jdk18on's changelog.

Bouncy Castle Crypto Package - Release Notes

1.0 Introduction

The Bouncy Castle Crypto package is a Java implementation of cryptographic algorithms. The package is organised so that it contains a light-weight API suitable for use in any environment (including the J2ME) with the additional infrastructure to conform the algorithms to the JCE framework.

2.0 Release History

2.1.1 Version

Release: 1.86
Date: 2026, TBD

2.1.2 Defects Fixed

  • The high-level OpenPGP API (org.bouncycastle.openpgp.api) let a subkey inherit the primary key's Key Flags when its own Subkey Binding signature carried no Key Flags subpacket, which made the two capability decisions taken for one subkey disagree. OpenPGPCertificate.OpenPGPComponentKey.isSigningKey() reads the effective flags, which fell back to the primary key's direct-key or primary user ID self-signature, so a subkey bound with no flags of its own counted as signing-capable; verifyEmbeddedPrimaryKeyBinding reads the binding signature's own flags, found no signing capability there, and so skipped the embedded Primary Key Binding (cross-certification) signature that RFC 9580 sec. 5.2.1.8 and sec. 10.1.3 require of a subkey that can issue signatures. A data signature made by such a subkey was therefore attributed to the certificate and reported valid by OpenPGPSignature.OpenPGPDocumentSignature.isValid() with the cross-certification requirement never applied, where GnuPG refuses the same certificate and message as not cross-certified. An attacker holding a third party's public signing subkey - which is public material - could bind it to their own primary key with a Subkey Binding signature they are able to make, carrying no Key Flags and no embedded Primary Key Binding signature, which they cannot make without the subkey's private key, and have that party's genuine signatures verify as valid under the attacker's own identity: misattribution of a real signature rather than a forgery of a new one, since the signature still has to be one the subkey actually made. Key Flags are a statement about the key the carrying signature refers to (RFC 9580 sec. 5.2.3.29), so a subkey no longer inherits them from the certificate-wide signatures of the primary key: a Subkey Binding signature that omits the subpacket now leaves the subkey with no capabilities rather than the primary's, which makes the flags the cross-certification check consults the same flags every other decision consults. Preferences and the other subpackets a direct-key signature carries are inherited as before, and the primary key itself - whose flags legitimately come from its direct-key or user ID self-signature - is unaffected. The low-level PGPSignature / PGPPublicKeyRing API performs no binding checks by design and is unchanged.
  • Neither the HSS nor the XMSS^MT private key decoder checked its declared index against the traversal state stored beside it, although the two are independent records of the same position in the key and so can be compared. For HSS the records are the top-level index and the component keys' one-time indices q; for XMSS^MT they are the global index and the per-layer BDS states. A stored key whose index had been rolled back while its state stayed advanced - a partial write, a restore from backup, a buggy storage layer - was therefore accepted, and it then signed a second message under a one-time key the key had already used, producing a signature that verified, so nothing anywhere surfaced the reuse. RFC 8554 sec. 1 and RFC 8391 sec. 1.1 both require each one-time key to be used exactly once, and this is the failure those requirements exist to prevent; the single-tree XMSS decoder has tied its BDS state to its index since that state was first validated, and this brings the two multi-tree schemes into line. HSS decode now requires the declared index to equal the position the component q values imply - a level above the last contributes (q - 1) leaves of the levels beneath it, since its q has already advanced past the subtree it signed - and XMSS^MT decode now requires each present layer's BDS index to equal the leaf index that layer derives from the global index, allowing the one position where a layer has moved into a new subtree and its state legitimately still carries the previous subtree's final index. A layer with no state yet is unaffected, since those are built lazily at signing time. Related, and the same shape of omission: an XMSS or XMSS^MT private key encoding carries the tree root twice - the key's own root field and the root node of the BDS state stored beside it, which for XMSS^MT is the top layer's - and the two were never compared either. A corrupted root was accepted and then poisoned every signature the key made, because the root is hashed into the message digest: the signature did not verify and nothing indicated why. Decode now requires the two copies to agree. The BDS node values themselves are not checkable the way the LMS tree cache above is - a BDS authentication path, stack, retain or keep node does not have its children stored alongside it, so recomputing one means building a subtree, which is the work the state exists to avoid. Both checks are integer comparisons over the levels of the key, too small to measure against the surrounding decode, and both were verified not to reject any legitimate key by walking every index a key can reach: the full key space of the two-level HSS and the h=4/d=2, h=6/d=2, h=6/d=3, h=9/d=3 and h=8/d=4 XMSS^MT parameter sets, plus a three-level HSS key across a subtree boundary and an HSS shard. Since those node values cannot be recomputed, the encoded state now carries a checksum over itself instead, with the owning key's public seed hashed in front of it. Any corruption of the stored state is refused at decode rather than being loaded and then producing signatures that silently do not verify, and because the public seed is bound in, a state transplanted between two keys of the same parameter set is refused too, even though it is internally consistent and arrives with its own matching root. The public seed is bound rather than the secret seed or the PRF key deliberately: the state's own root and index are inside the encoding and so are already covered, hashing secret material would make the stored checksum a commitment to it for no gain in detection, and the PRF key does not influence the state at all. This is an error-detecting code and not integrity protection - anyone able to rewrite the stored key recomputes it, so it establishes that the state is unchanged since it was written, never that it was correct when written, and the allocation bounds on the encoding remain the guard against a crafted one. It costs one SHA-256 over the state, measured at 5 to 8 microseconds each way for the h=10 and h=16 parameter sets, and 32 bytes of encoding. The state encoding was added earlier in this same cycle and has not been released, so the checksum is simply part of it rather than a new version: a state written by a 1.86 beta is rejected, which is recovered from by re-exporting the key. The deprecated org.bouncycastle.pqc.crypto.lms copy carries the HSS check as well (github #2414).
  • The S/MIME example smoke test in the misc module (org.bouncycastle.mail.smime.examples.test.AllTests) drove SendSignedAndEncryptedMail against smtp.gmail.com, and that example finishes with Transport.send() under JavaMail's default settings, which have no connect timeout. Where outbound port 25 is refused the failure was swallowed and the test passed; where it is silently dropped, as on many home networks, the connect blocked and ./gradlew build hung in :misc:test indefinitely with "0 tests completed". The test now delivers to an SMTP stub on a loopback port, with connect / read / write timeouts as a backstop, and asserts the message arrived (github #2407).
  • Composite ML-KEM encapsulation took the traditional component public key bytes it feeds the KEM combiner from the recipient key's own encoding, while decapsulation recomputes the point from the private key and so always produced an uncompressed one. Section 4 of draft-ietf-lamps-pq-composite-kem requires an EC component to be carried as an uncompressed point, but a component key that encodes itself compressed - a BC EC key whose point format has been set through org.bouncycastle.jce.interfaces.ECPointEncoder, or a key from a provider that preserves a compressed encoding - was passed through as it came. Both sides then combined a different tradPK and derived different shared secrets, with no error reported on either: encapsulation and decapsulation both succeeded and the recipient simply could not decrypt. The EC component is now normalised to an uncompressed point wherever the engine serialises one, which covers the ephemeral key that forms the ciphertext as well. X25519 and X448 components have a single encoding and were unaffected, as were EC keys left in their default (uncompressed) format, whose shared secrets are unchanged. CompositePublicKey.getEncoded() took its component bytes the same way, so such a key also encoded to a composite key other implementations reject and whose bytes changed across an encode / decode / encode round trip - 1238 bytes rather than 1270 for MLKEM768-ECDH-P256, and for the composite ML-DSA keys sharing that method, 2006 rather than 2038 for MLDSA65-ECDSA-P256. It now normalises the component the same way. This is a write-side change only: a composite key carrying a compressed EC component is still decoded, since the component key factories accept either form, and continues to verify signatures as before - it simply re-encodes in the normalised form. The shared normalisation is org.bouncycastle.jcajce.provider.asymmetric.util.ECUtil.getUncompressedSubjectPublicKeyBytes.
  • Composite ML-KEM encapsulation threw a NullPointerException, wrapped in an IllegalStateException out of KeyGenerator.generateKey(), when the SecureRandom it was given was null - which javax.crypto.KEM.newEncapsulator() documents as a request for the provider's default, and which KeyGenerator.init(spec, null) passes straight through. The three RSA-OAEP composites draw the traditional shared secret from that random directly, so they were the ones affected; the ECDH and X25519 / X448 composites escaped only because their component KeyPairGenerators default a random of their own. CompositeMLKEMEngine now defaults one through CryptoServicesRegistrar.getSecureRandom() on first use, as the composite KEM Cipher's wrap path already did, and as the KEM generators corrected earlier in this cycle now do. Related, the engine now also clears the ML-KEM component's shared secret alongside the traditional one on both the encapsulate and decapsulate paths - the copy handed back by getEncoded() was left in the heap - as section 3.5 of draft-ietf-lamps-pq-composite-kem requires.
  • CompositePublicKey.getAlgorithm() and CompositePrivateKey.getAlgorithm() returned null for all twelve Composite ML-KEM (draft-ietf-lamps-pq-composite-kem) parameter sets. Both classes resolved the name through the composite signature index only, which holds the composite ML-DSA OIDs, so a composite KEM key pair - generated, parsed from a certificate, or read from PKCS#8 - reported no algorithm at all, and the standard JCA idiom of reconstructing a key with KeyFactory.getInstance(key.getAlgorithm()) raised a NullPointerException. The lookup now falls back to the composite KEM index, so the name returned is the one the provider registers the algorithm under (e.g. MLKEM768-X25519-SHA3-256), matching the composite ML-DSA behaviour. The same single-index assumption made the CompositePublicKey(SubjectPublicKeyInfo) and CompositePrivateKey(PrivateKeyInfo) constructors reject a composite KEM key with "unable to create CompositePublicKey from SubjectPublicKeyInfo"; they now dispatch to the composite KEM key factory for those OIDs. Keys obtained through KeyFactory or through BouncyCastleProvider.getPublicKey / getPrivateKey were unaffected and are unchanged (github #2404).
  • The org.bouncycastle.jcajce.spec.KEMKDFSpec constructor stored a null otherInfo as given, so getOtherInfo() returned null, and three of the KDF branches KdfUtil.makeKeyBytes dispatches to - KMAC-128, KMAC-256 and SHAKE-256 - read the otherInfo length without a guard and threw NullPointerException out of the KEM operation, where the KDF2, KDF3 and HKDF branches tolerate a null through KDFParameters / HKDFParameters. The Builder of every spec in the package already mapped null to empty, so no provider path reached it, but the constructor is protected on a public class and KdfUtil is documented for callers building their own KEM integration; the deprecated KEMParameterSpec passes a null itself and escaped only because it also pins the KDF to null. The constructor now stores empty for a null, so getOtherInfo() never returns null, and a null and an explicitly empty otherInfo derive the same key.
  • QR-UOV signature verification accepted a signature encoding that was not canonical, so the encoding of a signature was not unique even after the trailing-byte fix of github #2403. Each F_q element of the signature is stored in ceil(log2 q) bits, one more bit pattern than the field has elements: q itself is representable and is arithmetically congruent to zero, so an element written as q verified exactly as the same element written as zero would, and the bits padding the last element out to the byte boundary were never read at all. Every zero element of a signature therefore carried a second encoding, and for the q = 7 parameter sets roughly one element in seven is zero - a single qruov_5_q7_L10 signature measured 256 spare bits, so on the order of 2^256 distinct byte strings verified for the one message and key. Verification now rejects any element outside [0, q) and any set padding bit; a signature produced by this or by the reference implementation is unaffected, as the KAT vectors of every parameter set confirm. (github #2403)
  • SNOVA signature verification ignored four bits inside the signature for any parameter set whose solution is an odd number of GF(16) nibbles - the SNOVA_24_5_5, SNOVA_25_8_3, SNOVA_29_6_5 and SNOVA_66_15_3 families, sixteen of the forty-four parameter sets. The last byte of the encoded solution carries a single nibble and the signer leaves the top four bits zero, but the decoder did not read them, so sixteen distinct byte strings verified for one signature. This is the same non-unique encoding github #2403 closed for bytes following the signature, applied inside it; the verifier now requires those bits to be zero. (github #2403)
  • SnovaPrivateKeyParameters did not validate the length of the private key encoding handed to it - the only one of the five schemes of github #2403 that did not - and SnovaParameters.getPrivateKeyLength() reported the expanded ("ESK") length even for a parameter set whose private key is the seed pair. A private key encoding reaches this constructor straight from a PKCS#8 blob, so a wrong length went undetected: a seed-form key with extra bytes appended was accepted and signed under a different derived key, and a short expanded-form key sized the signer's decode buffer negatively, throwing NegativeArraySizeException out of generateSignature() rather than being reported at construction. Related, the signing retry loop could not terminate: the vinegar values are derived from a single-byte counter, so only 256 distinct linear systems can be tried, and an expanded-form private key that is not a real central map is singular for all of them - generateSignature() then span forever rather than failing. The length is now checked at construction, getPrivateKeyLength() reports the length that parameter set's private key actually has, and the retry loop gives up after its 256 attempts as MAYO's does.
  • MayoSigner and MayoKeyPairGenerator did not clear several buffers holding secret key material that the MAYO reference implementation explicitly clears. Signing left the secret oil space O, the expanded L = (P1 + P1^t) * O + P2, and the M / VPV / Ox intermediates of the central map in place, having gone to the trouble of clearing eleven other buffers; key generation left the expanded seed, whose tail is the encoded oil space, and the P1 * O + P2 half of P; and the row-echelon step left the packed echelon form of the secret linear system and its pivot rows. Separately, if all 256 attempts at solving for the signature had given a rank-deficient system, signing emitted a signature built from the failed attempt's state instead of reporting the failure the reference returns, and AIMerSigner.generateSignature returned an empty array on failure, which a caller would hand on as though it were a signature. Both now throw.
  • Five PQC signature schemes - MAYO, SNOVA, QR-UOV, SQIsign and AIMer - returned the NIST crypto_sign "sm" signed-message envelope from generateSignature() rather than the signature. That envelope is an artefact of the reference KAT harness, which records the message alongside the signature so a vector file can be self-contained; it is not part of any of the five specifications, and no other BC signer emits it (Falcon's KAT test rebuilds the equivalent envelope in the test, which is where it belongs). Two consequences followed, both reaching the JCA Signature services of every parameter set of the five schemes in BouncyCastlePQCProvider. First, since the message was appended to the signature, verification had to skip whatever followed the signature proper, and it did so by checking only that the buffer was long enough - so any number of trailing bytes could be added to a valid signature, or the appended message replaced with unrelated data, and it still verified. A signature encoding was therefore not unique: anyone holding one valid signature could produce unlimited distinct byte strings that all verified for the same message and key, which breaks any use that treats the signature bytes as an identifier, deduplicates on them, or records them as evidence. Second, the envelope propagated into everything built on the operator layer: because ContentSigner hands the signature straight into the structure being signed, every X.509 certificate, CRL, CMS SignedData and TLS CertificateVerify BC produced with one of these algorithms carried a verbatim copy of the signed data inside its own signature field - a self-signed MAYO-1 certificate came to 3567 bytes where the same certificate is now 2020 - which no other implementation can parse as a signature, and which in a detached CMS signature meant the "detached" signature carried the content. generateSignature() now returns the bare signature, and verifySignature() requires exactly the parameter set's signature length, so appended or truncated data is rejected rather than ignored. This is a behavioural change for signatures produced by an earlier release - MAYO and SNOVA from 1.84, QR-UOV, SQIsign and AIMer from 1.85 - which are no longer accepted in the envelope form they were emitted in; the signature bytes themselves are unchanged, so a stored value can be recovered by taking the leading signature-length bytes, or for AIMer, whose envelope was message || signature rather than signature || message, the trailing ones. The KAT tests now rebuild the envelope before comparing against the vector files, which continue to record it. Note that AIMer's verification had already been made length-exact during this cycle (see the entry below relating to github #2401), so of the five only its envelope remained (github #2403).
  • The MLS implementation did not bind an X.509 credential to the LeafNode's signature_key. LeafNode.verify() checked a leaf's signature against the signature_key declared in the leaf itself, while the X.509 credential's certificate chain was stored but never parsed or checked, so the certificate's public key was never required to match signature_key (RFC 9420 sec. 5.3). A leaf could therefore carry one party's certificate while being signed by an unrelated key and still be accepted under that party's identity through KeyPackage.verify() and the Group leaf-validation path. LeafNode.verify() now requires the end-entity certificate's subject public key, in the cipher suite's signature encoding, to equal signature_key for an X.509 credential, and rejects the leaf otherwise - including an empty chain or a certificate whose key type does not match the cipher suite; certificate-chain and identity validation to a trust anchor remain the application's responsibility per RFC 9420 sec. 5.3.1. A public org.bou...

    Description has been truncated

@dependabot
chore(deps): bump the all-dependencies group with 3 updates
a7222ea 
Bumps the all-dependencies group with 3 updates: [actions/setup-java](https://github.com/actions/setup-java), [github/codeql-action/init](https://github.com/github/codeql-action) and [github/codeql-action/analyze](https://github.com/github/codeql-action).


Updates `actions/setup-java` from 5.7.0 to 6.0.0
- [Release notes](https://github.com/actions/setup-java/releases)
- [Commits](actions/setup-java@b6effb0...dd06d9c)

Updates `github/codeql-action/init` from 4.37.6 to 4.37.9
- [Release notes](https://github.com/github/codeql-action/releases)
- [Changelog](https://github.com/github/codeql-action/blob/main/CHANGELOG.md)
- [Commits](github/codeql-action@5595cca...cdf488f)

Updates `github/codeql-action/analyze` from 4.37.6 to 4.37.9
- [Release notes](https://github.com/github/codeql-action/releases)
- [Changelog](https://github.com/github/codeql-action/blob/main/CHANGELOG.md)
- [Commits](github/codeql-action@5595cca...cdf488f)
chore(deps): bump the all-dependencies group with 8 updates

Bumps the all-dependencies group with 8 updates:

| Package | From | To |
| --- | --- | --- |
| [org.jetbrains.kotlin:kotlin-gradle-plugin](https://github.com/JetBrains/kotlin) | `2.4.20-Beta1` | `2.4.20-RC2` |
| com.android.application | `9.3.1` | `9.3.2` |
| com.android.library | `9.3.1` | `9.3.2` |
| [org.bouncycastle:bcprov-jdk18on](https://github.com/bcgit/bc-java) | `1.85` | `1.85.2` |
| org.bouncycastle:bcpkix-jdk18on | `1.85` | `1.85.2` |
| org.bouncycastle:bcutil-jdk18on | `1.85` | `1.85.2` |
| androidx.core:core | `1.17.0` | `1.19.0` |
| [gradle-wrapper](https://github.com/gradle/gradle) | `9.7.0` | `9.7.1` |


Updates `org.jetbrains.kotlin:kotlin-gradle-plugin` from 2.4.20-Beta1 to 2.4.20-RC2
- [Release notes](https://github.com/JetBrains/kotlin/releases)
- [Changelog](https://github.com/JetBrains/kotlin/blob/v2.4.20-RC2/ChangeLog.md)
- [Commits](JetBrains/kotlin@v2.4.20-Beta1...v2.4.20-RC2)

Updates `com.android.application` from 9.3.1 to 9.3.2

Updates `com.android.library` from 9.3.1 to 9.3.2

Updates `org.bouncycastle:bcprov-jdk18on` from 1.85 to 1.85.2
- [Changelog](https://github.com/bcgit/bc-java/blob/main/docs/releasenotes.md)
- [Commits](https://github.com/bcgit/bc-java/commits)

Updates `org.bouncycastle:bcpkix-jdk18on` from 1.85 to 1.85.2

Updates `org.bouncycastle:bcutil-jdk18on` from 1.85 to 1.85.2

Updates `androidx.core:core` from 1.17.0 to 1.19.0

Updates `gradle-wrapper` from 9.7.0 to 9.7.1
- [Release notes](https://github.com/gradle/gradle/releases)
- [Commits](gradle/gradle@v9.7.0...v9.7.1)

---
updated-dependencies:
- dependency-name: actions/setup-java
  dependency-version: 6.0.0
  dependency-type: direct:production
  update-type: version-update:semver-major
  dependency-group: all-dependencies
- dependency-name: github/codeql-action/init
  dependency-version: 4.37.9
  dependency-type: direct:production
  update-type: version-update:semver-patch
  dependency-group: all-dependencies
- dependency-name: github/codeql-action/analyze
  dependency-version: 4.37.9
  dependency-type: direct:production
  update-type: version-update:semver-patch
  dependency-group: all-dependencies
- dependency-name: org.jetbrains.kotlin:kotlin-gradle-plugin
  dependency-version: 2.4.20-RC2
  dependency-type: direct:production
  update-type: version-update:semver-patch
  dependency-group: all-dependencies
- dependency-name: com.android.application
  dependency-version: 9.3.2
  dependency-type: direct:production
  update-type: version-update:semver-patch
  dependency-group: all-dependencies
- dependency-name: com.android.library
  dependency-version: 9.3.2
  dependency-type: direct:production
  update-type: version-update:semver-patch
  dependency-group: all-dependencies
- dependency-name: org.bouncycastle:bcprov-jdk18on
  dependency-version: 1.85.2
  dependency-type: direct:production
  update-type: version-update:semver-patch
  dependency-group: all-dependencies
- dependency-name: org.bouncycastle:bcpkix-jdk18on
  dependency-version: 1.85.2
  dependency-type: direct:production
  update-type: version-update:semver-patch
  dependency-group: all-dependencies
- dependency-name: org.bouncycastle:bcutil-jdk18on
  dependency-version: 1.85.2
  dependency-type: direct:production
  update-type: version-update:semver-patch
  dependency-group: all-dependencies
- dependency-name: androidx.core:core
  dependency-version: 1.19.0
  dependency-type: direct:production
  update-type: version-update:semver-minor
  dependency-group: all-dependencies
- dependency-name: gradle-wrapper
  dependency-version: 9.7.1
  dependency-type: direct:production
  update-type: version-update:semver-patch
  dependency-group: all-dependencies
...

Signed-off-by: dependabot[bot] <support@github.com>
@dependabot dependabot Bot added dependencies Pull requests that update a dependency file github_actions Pull requests that update GitHub Actions code labels Aug 31, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

No reviews

Assignees

No one assigned

Labels

dependencies Pull requests that update a dependency file github_actions Pull requests that update GitHub Actions code

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

0 participants