test the returned type in oer getInstance identity guards - #2373
Open
rootvector2 wants to merge 4231 commits into
Open
test the returned type in oer getInstance identity guards#2373rootvector2 wants to merge 4231 commits into
rootvector2 wants to merge 4231 commits into
Conversation
# Conflicts: # docs/releasenotes.html
…usion, byte-identical and constant-time-neutral
Speed up ARIA (ARIAEngine) ~1.3–1.4× via SWAR multiply-broadcast diffusion, byte-identical and constant-time-neutral See merge request root/bc-java!191
# Conflicts: # docs/releasenotes.html # prov/src/main/java/org/bouncycastle/pqc/jcajce/spec/HQCParameterSpec.java # prov/src/test/java/org/bouncycastle/pqc/jcajce/provider/test/AllTests.java
…ycloneDX 1.6 CBOM/SBOM documents for the release artifacts, with matching .pom and Gradle module metadata for the BOM coordinates
# Conflicts: # docs/releasenotes.html
…KeyFactorySpi subclasses, pkix AlgorithmIdentifier finder entries, and legacy-tree PublicKeyFactory converters
PKIXNameConstraintValidator extracts a tested mailbox's host at the first '@', but RFC 5321 allows a quoted local part containing '@', so the domain is after the LAST '@'. A tested rfc822Name such as "user@evil.com"@excluded.example.com (a genuine excluded.example.com mailbox) was split to host evil.com"@excluded.example.com, matching neither excluded.example.com nor .excluded.example.com, and so evaded an excluded subtree (fail-open). Reject a tested rfc822Name with more than one '@' - it cannot be split into local/domain unambiguously - fail-closed, and only when email constraints are present (strict-when-constrained). The check is on the tested-name path (checkPermittedEmail/checkExcludedEmail); constraints are unaffected, since a mailbox constraint matches by whole-string equality. Added X509_ALLOW_LENIENT_RFC822_NAME safety valve for rfc822Name strictness. The multi-'@' rejection is strictly an over-reach vs RFC 5321 sec. 4.1.2: a quoted local part may contain '@', so "a@b"@example.com is a valid Mailbox that the strict check rejects. Gate it behind a property so an affected user can restore the legacy lenient parsing.
…ctions up to date (JDK 25 requirement, BC_JDK25, test task gating)
…rge of main: keep new base code on the Java 4 source floor, add jdk1.4 compile overlays, refresh ant excludes and make the affected tests 1.4-safe
…ioural fixes: name-constraint bypasses, RSA/ElGamal decrypt hardening, policy-tree and keystore iteration DoS guards, CRL signer recursion guard with AKI narrowing, CRL cache TTL, armor-header CRLF rejection, destroyable races, plus provider KDF/XChaCha registrations
X.509 name-parse robustness (COV-4 / COV-6) See merge request root/bc-java!254
…lay so the build1-4 build keeps compiling the updated PKIXNameConstraintValidator
…urce preprocessing limits, real-1.4-javac floor, overlay delete-vs-sync discipline and the build/sign/test flow
…, relates to github bcgit#2176. Private keys for all standard (RFC 8391 + SP 800-208) XMSS/XMSS^MT parameter sets now encode in the RFC 9802 id-alg-xmss-hashsig / id-alg-xmssmt-hashsig form the public key already uses - the 4-octet parameter-set OID is carried ahead of the raw key so the private and public halves of a keypair share one algorithm OID and a private key round-trips losslessly to its exact parameter set (including n). Previously private keys always used the legacy PQCObjectIdentifiers.xmss(_mt) + XMSSKeyParams form, which cannot represent the SP 800-208 sets: SHAKE256/256 and SHAKE256/192 threw on encode, and SHA-256/192 silently round-tripped to the n=32 set. The legacy form is still read. The SP 800-208 sets are now also reachable through the JCA: XMSSParameterSpec / XMSSMTParameterSpec gain SHA256_192 / SHAKE256_256 / SHAKE256_192 selectors and named constants, both KeyPairGenerator SPIs build them (via the now-public explicit-n XMSSParameters / XMSSMTParameters constructors), an unknown tree digest now throws InvalidAlgorithmParameterException instead of a later NPE, and getTreeDigest() is n-aware so the /192 and /256 variants sharing a tree-digest OID are distinguished. org.bouncycastle.asn1.iana.IANAObjectIdentifiers is consolidated into the core source tree (published in bcprov, exported by the org.bouncycastle.provider module) and the internal.asn1.iana copy is removed, so there is a single definition; iana is dropped from the bcutil bnd Export-Package and the util module-info. The public class name is unchanged.
…ytesFully() rather than allocating the full declared length up front, so a short crafted header over a raw stream cannot drive a heap-sized allocation before any data is read (CWE-789); DefiniteLengthInputStream.toByteArray() reads through the stream itself so the "DEF length ... object truncated by ..." truncation message is preserved.
…datorUtilities, jce/provider/RFC3280CertPathUtilities, x509/CertPathValidatorUtilities) with base, folding in the ReasonsMask API rename, the PKIXCRLValidator/PKIXPolicyNode extraction, and the ExtException-to-java.security.cert migration those overlays had missed since each landed - build1-4 has been broken since the first of these changes regardless of anything else. Also fix jdk1.4 test-tree compile breaks left by unrelated recent commits (SM9 Destroyable, a PKIXRevocationChecker test, an EST import pulled into ParseTest, String.contains in PBETest, a stale PKIXCertPathReviewer test reference, and two getDeclaredMethod varargs call sites) so build-test compiles and the full jdk1.4 suite runs again.
…g the FixedLengthContentSigner/ExtendedContentSigner wrapping it had predated entirely - CMS SignerInfoGenerator.getPredictedEncodedLength could never return a length prediction on the jdk1.4 build for any algorithm as a result, surfacing as NewSignedDataTest.testEd448PredictedEncodedLength. Genuine 1.4 adaptations kept: PSS digest names are derived from the signature algorithm string rather than PSSParameterSpec.getDigestAlgorithm()/getMGFParameters()/getTrailerField() or MGF1ParameterSpec, none of which exist on JRE 1.4; the LMS-only constructor and the real-CompositePrivateKey/buildComposite() path are dropped, since org.bouncycastle.pqc.crypto.lms and composite JCE support are both excluded from the jdk1.4 distribution.
…f deprecated methods
…alidateRemove, since a signed comparison let an out-of-range sender pass the membership check and drive NodeIndex.parent() into an unbounded cycle - a remotely triggerable DoS against any group member.
…fix the resulting build-lw/build-pkix/build-pg/build-test rot: regenerate PKIXCertPathValidatorSpi/CertPathValidatorUtilities/RFC3280CertPathUtilities/x509 CertPathValidatorUtilities against current base (ReasonsMask rename, PKIXPolicyNode/PKIXPolicyTreeUtil extraction, dropping the unused Ext*Exception classes), regenerate stale core/pg test overlays from base (CipherTest, RomulusTest, RSABlindSignatureTest, ArmoredOutputStream's String.split call sites, StreamUtil's missing writeSeconds/readSeconds), fix jdk1.3 field-hiding compile errors (explicit this. qualifiers in JceCMSContentEncryptorBuilder and BcPGPKeyPairGeneratorProvider), and add/sync jdk1.3-overlay AllTests.java suite files (cms, pkcs, pkix, i18n, jce/provider, mail/smime) so they stop referencing test classes ant/jdk13.xml now excludes for post-1.3 JDK APIs. Also mirror the build-jdk13-docker skill's ORO_JAR pattern to mount an ant TrAX Xalan (real JDK 1.3.1 predates JAXP, so ant's own <junitreport> XSLT step and the forked <junit> XML formatter both need an external Xerces/Xalan) and to mount bc-test-data into the container, since build-test now compiles 100% cleanly across the whole jdk1.3 distribution.
…n-count cap (commit 0ab15c2), which shipped without one - the RFC 9579 PBMAC1 verifier was the one PBE/PBMAC1 path in the tree left uncapped, letting a small PKCS#12 file pin a CPU core pre-authentication.
…for a structurally malformed signature and a cryptographically wrong one, unlike the JDK's own SUN provider which throws SignatureException for the former - class-level javadoc on the JCA SignatureSpi/HashSignatureSpi and lightweight MLDSASigner/HashMLDSASigner, plus a release note, relates to github bcgit#2367.
…nded-key-length with IllegalArgumentException, mirroring the ML-DSA public key length check, instead of building a silently-corrupt key or leaking an IndexOutOfBoundsException
…ded-key-length with IllegalArgumentException, mirroring the ML-KEM public key length check, instead of silently accepting a key with a truncated implicit-rejection secret
…A signer is used before initialisation, matching the Ed25519/HashMLDSA signer convention
…RecipientInfo, PasswordRecipientInfo, CertRequest, RevAnnContent) with a lower-bound size check, throwing IllegalArgumentException instead of leaking ArrayIndexOutOfBoundsException for a truncated SEQUENCE
…ption("forget something!") when a BKS/UBER key entry stored as byte data cannot be recovered as a key
…ng extract-then-expand and extract-only derived AES SecretKeys against deriveData and the RFC 8619 CMS vector
… the TLS API, reporting connection secrets to a TlsKeyLog named by the org.bouncycastle.tls.keylog.class security property, with the standard bctls jar carrying only an inert seam
…ey exchange test and example - the master-key user-derivation method was renamed on main, leaving the two hid = 0x02 call sites in SM9KeyExchangeTest and SM9KeyExchangeExample on the old name
…un to completion: X509CertSelector.getNameConstraints()/setNameConstraints() no longer throw (they were unimplemented stubs breaking every PKIX candidate-certificate lookup), RFC3280CertPathUtilities avoids a SimpleDateFormat pattern character real JDK 1.3.1 rejects, OwlCurveTest/ECJPAKECurveTest/PrimesTest are guarded against a real JDK 1.3.1 BigInteger.isProbablePrime() false negative, NewAuthenticatedDataTest drops its KMAC-with-SHAKE tests (they hung the JVM), CMSTimeStampedData's jdk1.3 overlay is resynced with an already-landed NPE fix it had missed, and the build-jdk13-docker skill script now wires up JAXP tooling and bc-test-data so the test harness works at all. All 34 AllTests suites now run with 0 errors; three carry known, unrelated residual failures left for a future pass.
# Conflicts: # docs/releasenotes.html
…) and CVE-2024-29857 (F2m field size), cross-reference every 1.78 advisory CVE from its defects-fixed entry, and credit the Robusta team's constant-time analysis.
… their ASCII equivalents: U+2010 and U+2011 hyphens, an en dash, and smart quotes and apostrophes.
…ferenced between its defects-fixed entry and the security advisory block, with 1.78 as the worked example.
…f2m_field_size F2m field size bound (CVE-2024-29857) and use it in ECCurve rather than the inlined literal, mirroring the constant into the jdk1.4 overlay.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
5 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
the identity fast path in
UINT32.getInstance,etsi102941.basetypes.Version.getInstanceandEtsiTs103097DataEncryptedUnicast.getInstancetests a sibling type instead of the one it casts to (andOEROptional.getObjecthas theisInstancearguments transposed), so the first two reject their own type withIllegalArgumentExceptionfromASN1Integer.getInstance, the third throwsClassCastExceptionon anEtsiTs103097DataEncrypted, and the fourth never takes the cast path at all - found by turning on theIsInstanceIncompatibleTypeandInstanceOfAndCastMatchWrongTypeerror-prone checks thatbuild.gradlecurrently switches off.