Home » Oreps » Frost Server » All Pull Requests » #2431
fraunhoferiosb/frost-server
A Complete Server implementation of the OGC SensorThings API
Watch
1
Commit Activity
Pull Requests
Directory Browser
Velocity History
Releases

Bump the dependencies group across 1 directory with 13 updates #2431

Compare code on GitHub
Open
dependabot[bot] opened 11:35am on September 14, 2026 wants to merge 1 commit into fraunhoferiosb/frost-server v2.7.x from
dependabot/maven/v2.7.x/dependencies-e47852e36d

Pull Request Overview

  • Opened on September 14, 2026
  • Status Open
  • Commit count 1 with first commit September 14, 2026

Total Delta

0 Total Diff Delta

Open Days

Open 6 weekdays

Test Delta

0 Diff Delta in Test Files
Breakdown by Phase

How long has this pull request spent in each phase of its lifecycle?

Data pending calculation for pull request

Author avatar

Bump the dependencies group across 1 directory with 13 updates

Bumps the dependencies group with 13 updates in the / directory:

| Package | From | To |
| --- | --- | --- |
| org.eclipse.jetty.ee10:jetty-ee10-servlet | 12.1.12 | 12.1.13 |
| org.jooq:jooq | 3.21.7 | 3.21.8 |
| org.jooq:jooq-codegen | 3.21.7 | 3.21.8 |
| org.jooq:jooq-meta | 3.21.7 | 3.21.8 |
| org.slf4j:jul-to-slf4j | 2.0.18 | 2.0.19 |
| org.slf4j:slf4j-api | 2.0.18 | 2.0.19 |
| io.github.git-commit-id:git-commit-id-maven-plugin | 10.0.0 | 10.0.1 |
| org.apache.maven.plugins:maven-compiler-plugin | 3.15.0 | 3.16.0 |
| com.diffplug.spotless:spotless-maven-plugin | 3.10.1 | 3.10.2 |
| org.apache.maven.plugins:maven-surefire-plugin | 3.5.6 | 3.6.0 |
| org.bouncycastle:bcpkix-jdk18on | 1.85 | 1.86 |
| org.bouncycastle:bcprov-jdk18on | 1.85 | 1.86 |
| org.bouncycastle:bcutil-jdk18on | 1.85 | 1.86 |

Updates org.eclipse.jetty.ee10:jetty-ee10-servlet from 12.1.12 to 12.1.13

Updates org.jooq:jooq from 3.21.7 to 3.21.8

Updates org.jooq:jooq-codegen from 3.21.7 to 3.21.8

Updates org.jooq:jooq-meta from 3.21.7 to 3.21.8

Updates org.jooq:jooq-codegen from 3.21.7 to 3.21.8

Updates org.jooq:jooq-meta from 3.21.7 to 3.21.8

Updates org.slf4j:jul-to-slf4j from 2.0.18 to 2.0.19

Updates org.slf4j:slf4j-api from 2.0.18 to 2.0.19

Updates org.slf4j:slf4j-api from 2.0.18 to 2.0.19

Updates io.github.git-commit-id:git-commit-id-maven-plugin from 10.0.0 to 10.0.1

Release notes

Sourced from io.github.git-commit-id:git-commit-id-maven-plugin's releases.



Version 10.0.1 is finally there and includes various bug-fixes and improvements :-)


What's Changed


Dependencies used by the plugin



Github Action



Maven Plugins used by the plugin



Getting the latest release


The plugin is available from Maven Central (see here), so you don't have to configure any additional repositories to use this plugin. All you need to do is to configure it inside your project as dependency:


<dependency>

    <groupId>io.github.git-commit-id</groupId>

    <artifactId>git-commit-id-maven-plugin</artifactId>

    <version>10.0.1</version>

</dependency>

Getting the latest snapshot (build automatically)


If you can't wait for the next release, you can also get the latest snapshot version from sonatype, that is being deployed automatically by github actions:


<pluginRepositories>

    <pluginRepository>

        <id>sonatype-snapshots</id>

        <name>Sonatype Snapshots</name>

         <url>https://s01.oss.sonatype.org/content/repositories/snapshots/&lt;/url>

    </pluginRepository>

</pluginRepositories>

Even though the github actions will only deploy a new snapshot once all tests have finished, it is recommended to rely on the released and more stable version.


Known Issues / Limitations:



  • This plugin is unfortunately not working with Heroku which is due to the fact how Heroku works. In summary Heroku does not copy over the .git-repository but in order to determine the git properties this plugin relies on the fact that it has access to the git-repository. A somewhat workaround to get some information is outlined in ktoso/maven-git-commit-id-plugin#279

  • Using maven's plugin prefix resolution (e.g. mvn com.test.plugins:myPlugin:myMojo) might result in unresolved properties even with <injectAllReactorProjects>true</injectAllReactorProjects>. Please refer to git-commit-id/maven-git-commit-id-plugin#287 or git-commit-id/maven-git-commit-id-plugin#413 for details and potential workarounds


<!-- raw HTML omitted -->

... (truncated)

Commits



  • 73542f2 Bump version: 10.0.0 → 10.0.1


  • 7e95a7e Revert "add tests for java 27"


  • dae217c add tests for java 27


  • dc5b90b run tests with the latest maven versions 3.9.9 -> 3.9.16; 4.0.0-rc-5 -> 4.0.0...


  • 28f14aa bump git-commit-id-plugin-core from 6.2.0 to 6.2.1 (refs https://github.com/g...


  • dcf31ab Merge pull request #934 from git-commit-id/dependabot/maven/org.apache.maven....


  • e4e48ba Merge pull request #933 from git-commit-id/dependabot/maven/org.jspecify-jspe...


  • ef3c336 Merge pull request #935 from git-commit-id/dependabot/github_actions/actions/...


  • eacd498 Merge pull request #930 from git-commit-id/dependabot/maven/org.sonatype.cent...


  • d892203 build(deps): bump actions/setup-java from 5 to 6

  • Additional commits viewable in compare view


Updates org.apache.maven.plugins:maven-compiler-plugin from 3.15.0 to 3.16.0

Release notes

Sourced from org.apache.maven.plugins:maven-compiler-plugin's releases.



3.16.0


<!-- raw HTML omitted -->

🚀 New features and improvements



🐛 Bug Fixes



📝 Documentation updates



👻 Maintenance



📦 Dependency updates



Commits



  • e7bba6e [maven-release-plugin] prepare release maven-compiler-plugin-3.16.0


  • c906809 Avoid using deprecated method CompilerConfiguration.setCompilerVersion


  • ad74fee Replace adopt-openj9 by semeru JDK distribution on GH


  • beb0eda Recompile when dependencies change (#1102)


  • a0b689e [MCOMPILER-578] Track outputs across compiler executions (#1091)


  • 2e81228 Fix incremental detection of empty sources, 3.x (#1075)


  • 2132f5b configure ATR project


  • 5992b77 Build fails when annotation processor list is empty (but present) (#1077)


  • acccef7 Bump plexusCompilerVersion from 2.16.2 to 2.17.0


  • 72bc445 Bump org.codehaus.plexus:plexus-java from 1.5.2 to 1.6.0

  • Additional commits viewable in compare view


Updates com.diffplug.spotless:spotless-maven-plugin from 3.10.1 to 3.10.2

Release notes

Sourced from com.diffplug.spotless:spotless-maven-plugin's releases.



Maven Plugin v3.10.2


Fixed




  • <shortenFullyQualifiedTypes> now shortens fully-qualified types used in expression contexts (such as static method calls, static fields, and enum constants) while avoiding imports that would change how existing unqualified type references resolve. (#3039)

  • Eclipse JDT formatter step no longer fails with NoClassDefFoundError when lombok is active as a JVM agent (e.g. -javaagent:lombok.jar in Eclipse/VS Code/Cursor). (#2795)


Commits



  • dc2a4cb Published maven/3.10.2


  • 876c8c4 Published gradle/8.10.2


  • ff28375 Published lib/4.10.2


  • e260aa7 shortenFullyQualifiedTypes: preserve unqualified type resolution (#3037)


  • 5a2cdca Update changelogs.


  • 98ca50e Merge remote-tracking branch 'origin/main' into 3033-unqualified-type-collision


  • 9591d7e Resolve interopability with spotless, lombok and VSCode (#3038)


  • 5842e1b shortenFullyQualifiedTypes: shorten FQTs in expression context (#3039)


  • e7f5b60 Add changelog entries


  • 79ff6c7 Resolve interopability with spotless, lombok and VSCode

  • Additional commits viewable in compare view


Updates org.apache.maven.plugins:maven-surefire-plugin from 3.5.6 to 3.6.0

Release notes

Sourced from org.apache.maven.plugins:maven-surefire-plugin's releases.



3.6.0


<!-- raw HTML omitted -->

Please refer to the main page for what's new https://maven.apache.org/surefire/
And the migration page https://maven.apache.org/surefire/maven-surefire-plugin/whats-new-3-6-0.html


🚀 New features and improvements



🐛 Bug Fixes



📝 Documentation updates



👻 Maintenance



<!-- raw HTML omitted -->

... (truncated)

Commits



  • 0ff622b [maven-release-plugin] prepare release surefire-3.6.0


  • bb3932a Let's go for 3.6.0 release


  • 3002a16 Bump mavenVersion from 3.9.14 to 3.9.16


  • 61a531d Bump Maven parent version from 47 to 49 (#3449)


  • e52ead4 [SUREFIRE-523] Link all reported tests to source XRef (#3445)


  • 45102fa [SUREFIRE-3446] Fix direct selection of JUnit Jupiter @​Nested classes (#3447)


  • b2e1f70 Fix #3303: distinguish JUnit 6 ParameterizedClass invocations (#3432)


  • c051938 Discover tests in a fork when a toolchain JDK is used (#3444)


  • db75df8 Bump org.codehaus.plexus:plexus-java from 1.5.2 to 1.6.0 (#3441)


  • 77f2759 Bump org.codehaus.plexus:plexus-interpolation from 1.29 to 1.30.0

  • Additional commits viewable in compare view


Updates org.bouncycastle:bcpkix-jdk18on from 1.85 to 1.86

Changelog

Sourced from org.bouncycastle:bcpkix-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


<!-- raw HTML omitted --><!-- raw HTML omitted -->


2.1.1 Version


Release: 1.87

Date: 2026, TBD


2.1.2 Defects Fixed




  • A KeyAgreement asked for its shared secret before doPhase returned data rather than refusing. javax.crypto.KeyAgreement specifies IllegalStateException for that state, but nothing in the provider tracked it, so each SPI handed back whatever its result field held: for Diffie-Hellman that was the private value itself - engineInit seeded result with x, so generateSecret() returned the private exponent padded to the prime's length and generateSecret("AES") an all-zero key taken from that padding - while ECDH returned null and its named-algorithm overload raised NullPointerException. BaseAgreementSpi now records whether a doPhase has completed the agreement since the last init and refuses the request with an IllegalStateException naming the algorithm, so every family in the provider - DH, ECDH and ECMQV, the SM2 exchange, both ECGOST families, XDH, SM9 and NewHope - answers the same way, and the DH SPI no longer holds the private value in that field at all.




  • Mac.getInstance and KeyGenerator.getInstance by the HMAC SHA-512/224 and SHA-512/256 object identifiers (1.2.840.113549.2.12 and .13) failed, although the same algorithms resolved by name and the matching SecretKeyFactory aliases were registered: the SHA512 mappings called addHMACAlgorithm for the two truncated variants without the addHMACAlias that registers their OIDs against Mac and KeyGenerator. Both are now aliased, as every other HMAC in that class already was.




  • A KTSParameterSpec naming an HKDF key-derivation function with a parameters field - a form the provider does not service - was accepted at Cipher init and then failed out of wrap or unwrap with an unchecked IllegalStateException neither method declares. The KTS key-wrapping Ciphers (ML-KEM, Classic McEliece, FrodoKEM, the composite KEM and RSA-KEM) now validate the spec's KDF when they take it, reporting an unserviceable one as the InvalidAlgorithmParameterException engineInit declares, which is what the javax.crypto.KEM services already did through KdfUtil.resolveKemSpec.




  • A DTLS handshake deadlocked when a handshake message ahead of the peer's ChangeCipherSpec (a client's CertificateVerify, say) was lost while the ChangeCipherSpec and Finished behind it arrived: the record layer moved its read epoch on at the ChangeCipherSpec and then discarded every retransmission of the lost message as belonging to the old epoch, whose records are only accepted once the handshake has completed. Each side then waited on the other until a handshake timeout, if one was configured, ended it. Every client-authenticated handshake, and every handshake in which the server issues a NewSessionTicket, was exposed. Until the handshake completes, handshake records from the current epoch are now still accepted after the read epoch has moved on, and each message is checked against the epoch of the record that carried it. The DTLS loopback tests now run their handshakes at 10% datagram loss in each direction, with a client-authenticated handshake at 25%.




  • The lightweight SubjectPublicKeyInfoFactory and PrivateKeyInfoFactory encoded a GOST R 34.10-2012 key on one of the legacy CryptoPro curves under id-GostR3410-2001, although RFC 9215 sec. 4.2 permits those curves for 2012 keys. The digestParamSet now decides: a GOST R 34.11-94 parameter set means 2001 (RFC 4491 sec. 2.3.2), a GOST R 34.11-2012 digest or none means 2012 with 256/512 taken from the curve field size, and any other value is rejected. GOST3410PublicKeyAlgParameters treats digestParamSet as OPTIONAL on both read and write per RFC 9215, and PrivateKeyInfoFactory now passes attributes through for ECGOST3410 keys (bc-csharp github #707).




  • The name-constraint host canonicalisation removed a single RFC 1034 root-label dot, the only empty label a name may legally carry, but nothing refused the ones that are not legal: a dNSName, rfc822Name host or uniformResourceIdentifier host such as "example.com.." kept a phantom empty label after the strip and so matched no constraint at all, escaping an excluded subtree naming the host it appears to carry. A tested name whose host carries an empty label - a second trailing dot, a doubled dot or a leading dot - is now refused outright wherever a constraint of that type is in force, rather than canonicalised into a name it is not: removing the extra dots would decide on the caller's behalf that "example.com.." names example.com, which is not how a consumer resolving or comparing the name reads it, and refusing fails closed in both directions where canonicalising would newly admit such a name under a permitted subtree. The single trailing dot is canonicalised as before, a bare "." remains the root label rather than an empty one, and the guard is scoped to the host, so the doubled dot a quoted local part may legally carry is unaffected. Constraints are untouched - one may still begin with a dot, which is how this implementation spells "subdomains only" (github PR #2436).




2.1.3 Additional Features and Functionality


2.1.4 Additional Notes



  • The sources and javadoc jars of the Ant-built distributions (jdk14, jdk15to18 and jdk13) no longer carry test material. Each module's javadoc target copies the package documentation it needs - org/bouncycastle/<!-- raw HTML omitted -->//.html - back into the module source directory that has already been compiled from, and zip-src zips that directory afterwards, so every test package's package.html arrived in the sources jar by that route; javadoc-util additionally copied org/bouncycastle/asn1/isismtt//.java, which put test classes into the bcutil javadoc as generated pages, and javadoc-pg deliberately copied the gpg and bcpg test sources in order to document them. Separately the source copies excluded test material only one directory deep and only for .java, because Ant reads * as an any-depth wildcard just where it is a whole path segment, so anything nested further or with another extension - the PEM certificate fixtures under org/bouncycastle/est/test/san corrected in 1.86, and an ICAO master list under org/bouncycastle/asn1/icao/test - went through. The source and javadoc copies of every module now exclude test directories at any depth, and javadoc-pg no longer documents the test packages. org.bouncycastle.util.test is unaffected and still ships in the bcprov binary, sources and javadoc jars, as it does from the Gradle build: it is the SimpleTest framework the light-weight API's own test classes are written against, not test material of the distribution. No binary changes - the classes and resources of every Ant-built jar are identical to those of the 1.86 release - and the Gradle-built jdk18on artifacts never carried any of this.


<!-- raw HTML omitted --><!-- raw HTML omitted -->


2.2.1 Version


Release: 1.86

Date: 2026, 11th September.


2.2.2 Defects Fixed



  • The high-level OpenPGP API let a subkey inherit the primary key's Key Flags when its own Subkey Binding signature carried none, so a subkey bound with no flags counted as signing-capable for one check while the cross-certification check RFC 9580 sec. 5.2.1.8 requires of a signing subkey saw none and was skipped - letting a third party's public signing subkey be bound to an attacker's primary key and that party's genuine signatures verify under the attacker's identity. Flags are no longer inherited (CVE-2026-71887).

  • The high-level OpenPGP API used a version 6 key carrying no valid Direct Key signature, falling back to the primary user ID binding as it correctly does for version 4. RFC 9580 sec. 5.2.3.10 requires the opposite, and since a v6 certificate carries its expiration and preferences there, stripping that one packet silently dropped them - the certificate went on offering subkeys of a key set to expire. isBoundBy now requires a valid Direct Key self-signature before any v6 component is treated as bound; version 4 is unaffected.

  • The high-level OpenPGP API ignored the OpenPGPPolicy a caller had configured when verifying signatures on an inline message: OpenPGPMessageInputStream took the policy from the implementation's own default rather than from the processor doing the verification, so a hardened policy had no bearing on acceptance and getSignatures() reported isTestedCorrect() true for a signature that policy rejects. Both the one-pass and prefixed-signature paths now read the configured policy.

  • The high-level OpenPGP API went on offering the subkeys of a certificate whose primary key had expired, the binding check evaluating only a subkey's own Subkey Binding signature - so the certificate contradicted itself, reporting the primary unbound while still handing out its subkeys. The primary key's expiration now applies to the whole certificate, as GnuPG and Sequoia treat it, and a subkey no longer inherits the primary's validity period, which RFC 9580 sec. 5.2.3.13 counts from the creation time of the key the carrying signature is made on.

  • OpenPGPDocumentSignature.isValidAt(Date) reported a data signature as valid past the signature's own Signature Expiration Time (RFC 9580 sec. 5.2.3.18): it checked that the signature was correct and the issuing key bound and signing-capable at that date, but never the signature's own expiration, so it disagreed with isEffectiveAt() on the same object and with its own javadoc. isValid() and isValid(policy), which evaluate at creation time, are unchanged.

  • The lightweight LMSSigner and HSSSigner refused a key wrapped in ParametersWithRandom, which is how BcContentSignerBuilder passes one once setSecureRandom() has been called, so BcHssLmsContentSignerBuilder failed with "Incorrect Key Parameters" and the two signers raised ClassCastException. All three now unwrap it, as the ML-DSA and SLH-DSA signers already did; the random is accepted and ignored, LMS deriving its message randomiser deterministically from the seed and one-time index.

  • LMS signature verification did not apply two checks RFC 8554 sec. 5.4.2 requires before a signature is processed: step 2g, refusing a signature whose LMS typecode is not the public key's - without it a signature claiming a height-25 parameter set drove a 25-level computation against a height-5 key - and step 2i, refusing a leaf number outside the tree. Neither was a forgery, but both are attacker-chosen work the specification says to refuse up front. Both are now checked.

  • The LMS and HSS key parameter classes now apply at construction the checks their decoders apply, so a key built directly cannot be one the decoder would refuse: LMSPrivateKeyParameters accepted an identifier of any length where the decoder reads exactly 16 bytes, and left q, maxQ and the seed length unchecked, while HSSPrivateKeyParameters checked neither its level count nor that it had a component key and chaining signature per level. The decoders now report a bad version or seed length as IOException rather than IllegalStateException.

  • In the LMS JCE layer, LMSKeyGenParameterSpec.fromNames knew all twenty LMS parameter-set names but only four of the sixteen LM-OTS ones, so none of the SP 800-208 n24 or SHAKE sets could be named; all sixteen are now present. initialize(int, SecureRandom) now reports InvalidParameterException as the JCA specifies, and BCLMSPrivateKey.getIndex takes the exhaustion check and the index read under one monitor.

  • KeyPairGenerator.initialize(int, SecureRandom) is documented to raise InvalidParameterException when the key size is not one the generator supports, and thirty of them raised a bare IllegalArgumentException instead. Every generator in BCPQC, and the ML-DSA, ML-KEM, SLH-DSA, Classic McEliece, FrodoKEM, NTRU and composite ones in the BC provider, now raise the documented type - which extends IllegalArgumentException, so existing catches still match. The two RSA generators translate the lightweight refusal through a new SecurityExceptions.invalidParameterException factory.


<!-- raw HTML omitted -->

... (truncated)

Commits


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

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


<!-- raw HTML omitted --><!-- raw HTML omitted -->


2.1.1 Version


Release: 1.87

Date: 2026, TBD


2.1.2 Defects Fixed




  • A KeyAgreement asked for its shared secret before doPhase returned data rather than refusing. javax.crypto.KeyAgreement specifies IllegalStateException for that state, but nothing in the provider tracked it, so each SPI handed back whatever its result field held: for Diffie-Hellman that was the private value itself - engineInit seeded result with x, so generateSecret() returned the private exponent padded to the prime's length and generateSecret("AES") an all-zero key taken from that padding - while ECDH returned null and its named-algorithm overload raised NullPointerException. BaseAgreementSpi now records whether a doPhase has completed the agreement since the last init and refuses the request with an IllegalStateException naming the algorithm, so every family in the provider - DH, ECDH and ECMQV, the SM2 exchange, both ECGOST families, XDH, SM9 and NewHope - answers the same way, and the DH SPI no longer holds the private value in that field at all.




  • Mac.getInstance and KeyGenerator.getInstance by the HMAC SHA-512/224 and SHA-512/256 object identifiers (1.2.840.113549.2.12 and .13) failed, although the same algorithms resolved by name and the matching SecretKeyFactory aliases were registered: the SHA512 mappings called addHMACAlgorithm for the two truncated variants without the addHMACAlias that registers their OIDs against Mac and KeyGenerator. Both are now aliased, as every other HMAC in that class already was.




  • A KTSParameterSpec naming an HKDF key-derivation function with a parameters field - a form the provider does not service - was accepted at Cipher init and then failed out of wrap or unwrap with an unchecked IllegalStateException neither method declares. The KTS key-wrapping Ciphers (ML-KEM, Classic McEliece, FrodoKEM, the composite KEM and RSA-KEM) now validate the spec's KDF when they take it, reporting an unserviceable one as the InvalidAlgorithmParameterException engineInit declares, which is what the javax.crypto.KEM services already did through KdfUtil.resolveKemSpec.




  • A DTLS handshake deadlocked when a handshake message ahead of the peer's ChangeCipherSpec (a client's CertificateVerify, say) was lost while the ChangeCipherSpec and Finished behind it arrived: the record layer moved its read epoch on at the ChangeCipherSpec and then discarded every retransmission of the lost message as belonging to the old epoch, whose records are only accepted once the handshake has completed. Each side then waited on the other until a handshake timeout, if one was configured, ended it. Every client-authenticated handshake, and every handshake in which the server issues a NewSessionTicket, was exposed. Until the handshake completes, handshake records from the current epoch are now still accepted after the read epoch has moved on, and each message is checked against the epoch of the record that carried it. The DTLS loopback tests now run their handshakes at 10% datagram loss in each direction, with a client-authenticated handshake at 25%.




  • The lightweight SubjectPublicKeyInfoFactory and PrivateKeyInfoFactory encoded a GOST R 34.10-2012 key on one of the legacy CryptoPro curves under id-GostR3410-2001, although RFC 9215 sec. 4.2 permits those curves for 2012 keys. The digestParamSet now decides: a GOST R 34.11-94 parameter set means 2001 (RFC 4491 sec. 2.3.2), a GOST R 34.11-2012 digest or none means 2012 with 256/512 taken from the curve field size, and any other value is rejected. GOST3410PublicKeyAlgParameters treats digestParamSet as OPTIONAL on both read and write per RFC 9215, and PrivateKeyInfoFactory now passes attributes through for ECGOST3410 keys (bc-csharp github #707).




  • The name-constraint host canonicalisation removed a single RFC 1034 root-label dot, the only empty label a name may legally carry, but nothing refused the ones that are not legal: a dNSName, rfc822Name host or uniformResourceIdentifier host such as "example.com.." kept a phantom empty label after the strip and so matched no constraint at all, escaping an excluded subtree naming the host it appears to carry. A tested name whose host carries an empty label - a second trailing dot, a doubled dot or a leading dot - is now refused outright wherever a constraint of that type is in force, rather than canonicalised into a name it is not: removing the extra dots would decide on the caller's behalf that "example.com.." names example.com, which is not how a consumer resolving or comparing the name reads it, and refusing fails closed in both directions where canonicalising would newly admit such a name under a permitted subtree. The single trailing dot is canonicalised as before, a bare "." remains the root label rather than an empty one, and the guard is scoped to the host, so the doubled dot a quoted local part may legally carry is unaffected. Constraints are untouched - one may still begin with a dot, which is how this implementation spells "subdomains only" (github PR #2436).




2.1.3 Additional Features and Functionality


2.1.4 Additional Notes



  • The sources and javadoc jars of the Ant-built distributions (jdk14, jdk15to18 and jdk13) no longer carry test material. Each module's javadoc target copies the package documentation it needs - org/bouncycastle/<!-- raw HTML omitted -->//.html - back into the module source directory that has already been compiled from, and zip-src zips that directory afterwards, so every test package's package.html arrived in the sources jar by that route; javadoc-util additionally copied org/bouncycastle/asn1/isismtt//.java, which put test classes into the bcutil javadoc as generated pages, and javadoc-pg deliberately copied the gpg and bcpg test sources in order to document them. Separately the source copies excluded test material only one directory deep and only for .java, because Ant reads * as an any-depth wildcard just where it is a whole path segment, so anything nested further or with another extension - the PEM certificate fixtures under org/bouncycastle/est/test/san corrected in 1.86, and an ICAO master list under org/bouncycastle/asn1/icao/test - went through. The source and javadoc copies of every module now exclude test directories at any depth, and javadoc-pg no longer documents the test packages. org.bouncycastle.util.test is unaffected and still ships in the bcprov binary, sources and javadoc jars, as it does from the Gradle build: it is the SimpleTest framework the light-weight API's own test classes are written against, not test material of the distribution. No binary changes - the classes and resources of every Ant-built jar are identical to those of the 1.86 release - and the Gradle-built jdk18on artifacts never carried any of this.


<!-- raw HTML omitted --><!-- raw HTML omitted -->


2.2.1 Version


Release: 1.86

Date: 2026, 11th September.


2.2.2 Defects Fixed



  • The high-level OpenPGP API let a subkey inherit the primary key's Key Flags when its own Subkey Binding signature carried none, so a subkey bound with no flags counted as signing-capable for one check while the cross-certification check RFC 9580 sec. 5.2.1.8 requires of a signing subkey saw none and was skipped - letting a third party's public signing subkey be bound to an attacker's primary key and that party's genuine signatures verify under the attacker's identity. Flags are no longer inherited (CVE-2026-71887).

  • The high-level OpenPGP API used a version 6 key carrying no valid Direct Key signature, falling back to the primary user ID binding as it correctly does for version 4. RFC 9580 sec. 5.2.3.10 requires the opposite, and since a v6 certificate carries its expiration and preferences there, stripping that one packet silently dropped them - the certificate went on offering subkeys of a key set to expire. isBoundBy now requires a valid Direct Key self-signature before any v6 component is treated as bound; version 4 is unaffected.

  • The high-level OpenPGP API ignored the OpenPGPPolicy a caller had configured when verifying signatures on an inline message: OpenPGPMessageInputStream took the policy from the implementation's own default rather than from the processor doing the verification, so a hardened policy had no bearing on acceptance and getSignatures() reported isTestedCorrect() true for a signature that policy rejects. Both the one-pass and prefixed-signature paths now read the configured policy.

  • The high-level OpenPGP API went on offering the subkeys of a certificate whose primary key had expired, the binding check evaluating only a subkey's own Subkey Binding signature - so the certificate contradicted itself, reporting the primary unbound while still handing out its subkeys. The primary key's expiration now applies to the whole certificate, as GnuPG and Sequoia treat it, and a subkey no longer inherits the primary's validity period, which RFC 9580 sec. 5.2.3.13 counts from the creation time of the key the carrying signature is made on.

  • OpenPGPDocumentSignature.isValidAt(Date) reported a data signature as valid past the signature's own Signature Expiration Time (RFC 9580 sec. 5.2.3.18): it checked that the signature was correct and the issuing key bound and signing-capable at that date, but never the signature's own expiration, so it disagreed with isEffectiveAt() on the same object and with its own javadoc. isValid() and isValid(policy), which evaluate at creation time, are unchanged.

  • The lightweight LMSSigner and HSSSigner refused a key wrapped in ParametersWithRandom, which is how BcContentSignerBuilder passes one once setSecureRandom() has been called, so BcHssLmsContentSignerBuilder failed with "Incorrect Key Parameters" and the two signers raised ClassCastException. All three now unwrap it, as the ML-DSA and SLH-DSA signers already did; the random is accepted and ignored, LMS deriving its message randomiser deterministically from the seed and one-time index.

  • LMS signature verification did not apply two checks RFC 8554 sec. 5.4.2 requires before a signature is processed: step 2g, refusing a signature whose LMS typecode is not the public key's - without it a signature claiming a height-25 parameter set drove a 25-level computation against a height-5 key - and step 2i, refusing a leaf number outside the tree. Neither was a forgery, but both are attacker-chosen work the specification says to refuse up front. Both are now checked.

  • The LMS and HSS key parameter classes now apply at construction the checks their decoders apply, so a key built directly cannot be one the decoder would refuse: LMSPrivateKeyParameters accepted an identifier of any length where the decoder reads exactly 16 bytes, and left q, maxQ and the seed length unchecked, while HSSPrivateKeyParameters checked neither its level count nor that it had a component key and chaining signature per level. The decoders now report a bad version or seed length as IOException rather than IllegalStateException.

  • In the LMS JCE layer, LMSKeyGenParameterSpec.fromNames knew all twenty LMS parameter-set names but only four of the sixteen LM-OTS ones, so none of the SP 800-208 n24 or SHAKE sets could be named; all sixteen are now present. initialize(int, SecureRandom) now reports InvalidParameterException as the JCA specifies, and BCLMSPrivateKey.getIndex takes the exhaustion check and the index read under one monitor.

  • KeyPairGenerator.initialize(int, SecureRandom) is documented to raise InvalidParameterException when the key size is not one the generator supports, and thirty of them raised a bare IllegalArgumentException instead. Every generator in BCPQC, and the ML-DSA, ML-KEM, SLH-DSA, Classic McEliece, FrodoKEM, NTRU and composite ones in the BC provider, now raise the documented type - which extends IllegalArgumentException, so existing catches still match. The two RSA generators translate the lightweight refusal through a new SecurityExceptions.invalidParameterException factory.


<!-- raw HTML omitted -->

... (truncated)

Commits


Updates org.bouncycastle:bcutil-jdk18on from 1.85 to 1.86

Changelog

Sourced from org.bouncycastle:bcutil-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


<!-- raw HTML omitted --><!-- raw HTML omitted -->


2.1.1 Version


Release: 1.87

Date: 2026, TBD


2.1.2 Defects Fixed




  • A KeyAgreement asked for its shared secret before doPhase returned data rather than refusing. javax.crypto.KeyAgreement specifies IllegalStateException for that state, but nothing in the provider tracked it, so each SPI handed back whatever its result field held: for Diffie-Hellman that was the private value itself - engineInit seeded result with x, so generateSecret() returned the private exponent padded to the prime's length and generateSecret("AES") an all-zero key taken from that padding - while ECDH returned null and its named-algorithm overload raised NullPointerException. BaseAgreementSpi now records whether a doPhase has completed the agreement since the last init and refuses the request with an IllegalStateException naming the algorithm, so every family in the provider - DH, ECDH and ECMQV, the SM2 exchange, both ECGOST families, XDH, SM9 and NewHope - answers the same way, and the DH SPI no longer holds the private value in that field at all.




  • Mac.getInstance and KeyGenerator.getInstance by the HMAC SHA-512/224 and SHA-512/256 object identifiers (1.2.840.113549.2.12 and .13) failed, although the same algorithms resolved by name and the matching SecretKeyFactory aliases were registered: the SHA512 mappings called addHMACAlgorithm for the two truncated variants without the addHMACAlias that registers their OIDs against Mac and KeyGenerator. Both are now aliased, as every other HMAC in that class already was.




  • A KTSParameterSpec naming an HKDF key-derivation function with a parameters field - a form the provider does not service - was accepted at Cipher init and then failed out of wrap or unwrap with an unchecked IllegalStateException neither method declares. The KTS key-wrapping Ciphers (ML-KEM, Classic McEliece, FrodoKEM, the composite KEM and RSA-KEM) now validate the spec's KDF when they take it, reporting an unserviceable one as the InvalidAlgorithmParameterException engineInit declares, which is what the javax.crypto.KEM services already did through KdfUtil.resolv...

    Description has been truncated




No comments have been left on this PR.

GitClear uses cookies to ensure you get the best experience on our website. Learn more about our cookie policy