Repository navigation
Commit eca60e7
![dependabot[bot]](https://avatars.githubusercontent.com/in/29110?v=4&size=40){kind=avatar}
chore(deps): bump org.bouncycastle:bcprov-jdk18on from 1.80 to 1.85 in /sdk-platform-java/java-shared-dependencies/third-party-dependencies (#14436)
Bumps
[org.bouncycastle:bcprov-jdk18on](https://github.com/bcgit/bc-java) from
1.80 to 1.85.
<details>
<summary>Changelog</summary>
<p><em>Sourced from <a
href="https://github.com/bcgit/bc-java/blob/main/docs/releasenotes.md">org.bouncycastle:bcprov-jdk18on's
changelog</a>.</em></p>
<blockquote>
<h1>Bouncy Castle Crypto Package - Release Notes</h1>
<h2>1.0 Introduction</h2>
<p>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.</p>
<h2>2.0 Release History</h2>
<p><!-- raw HTML omitted --><!-- raw HTML omitted --></p>
<h3>2.1.1 Version</h3>
<p>Release: 1.87<br />
Date: 2026, TBD</p>
<h3>2.1.2 Defects Fixed</h3>
<ul>
<li>
<p>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.</p>
</li>
<li>
<p>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.</p>
</li>
<li>
<p>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.</p>
</li>
<li>
<p>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%.</p>
</li>
<li>
<p>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 <a
href="https://redirect.github.com/bcgit/bc-java/issues/707">#707</a>).</p>
</li>
<li>
<p>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 <a
href="https://redirect.github.com/bcgit/bc-java/issues/2436">#2436</a>).</p>
</li>
</ul>
<h3>2.1.3 Additional Features and Functionality</h3>
<h3>2.1.4 Additional Notes</h3>
<ul>
<li>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 -->/<strong>/*.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/</strong>/*.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.</li>
</ul>
<p><!-- raw HTML omitted --><!-- raw HTML omitted --></p>
<h3>2.2.1 Version</h3>
<p>Release: 1.86<br />
Date: 2026, 11th September.</p>
<h3>2.2.2 Defects Fixed</h3>
<ul>
<li>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).</li>
<li>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.</li>
<li>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.</li>
<li>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.</li>
<li>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.</li>
<li>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.</li>
<li>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.</li>
<li>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.</li>
<li>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.</li>
<li>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.</li>
</ul>
<!-- raw HTML omitted -->
</blockquote>
<p>... (truncated)</p>
</details>
<details>
<summary>Commits</summary>
<ul>
<li>See full diff in <a
href="https://github.com/bcgit/bc-java/commits">compare view</a></li>
</ul>
</details>
<br />
[](https://docs.github.com/en/github/managing-security-vulnerabilities/about-dependabot-security-updates#about-compatibility-scores)
Dependabot will resolve any conflicts with this PR as long as you don't
alter it yourself. You can also trigger a rebase manually by commenting
`@dependabot rebase`.
[//]: # (dependabot-automerge-start)
[//]: # (dependabot-automerge-end)
---
<details>
<summary>Dependabot commands and options</summary>
<br />
You can trigger Dependabot actions by commenting on this PR:
- `@dependabot rebase` will rebase this PR
- `@dependabot recreate` will recreate this PR, overwriting any edits
that have been made to it
- `@dependabot show <dependency name> ignore conditions` will show all
of the ignore conditions of the specified dependency
- `@dependabot ignore this major version` will close this PR and stop
Dependabot creating any more for this major version (unless you reopen
the PR or upgrade to it yourself)
- `@dependabot ignore this minor version` will close this PR and stop
Dependabot creating any more for this minor version (unless you reopen
the PR or upgrade to it yourself)
- `@dependabot ignore this dependency` will close this PR and stop
Dependabot creating any more for this dependency (unless you reopen the
PR or upgrade to it yourself)
You can disable automated security fix PRs for this repo from the
[Security Alerts
page](https://github.com/googleapis/google-cloud-java/network/alerts).
</details>
Signed-off-by: dependabot[bot] <support@github.com>
Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
Co-authored-by: Sakthivel Subramanian <179120858+sakthivelmanii@users.noreply.github.com>1 parent 9424181 commit eca60e7
1 file changed
Lines changed: 1 addition & 1 deletion
File tree
| Original file line number | Diff line number | Diff line change | |
|---|---|---|---|
| |||
42 | 42 | | |
43 | 43 | | |
44 | 44 | | |
45 | | - | |
| 45 | + | |
46 | 46 | | |
47 | 47 | | |
48 | 48 | | |
| |||
0 commit comments