| Summary: | =dev-java/bcprov-1.54: version bump | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | cyberbat <cyberbat83> |
| Component: | [OLD] Java | Assignee: | Java team <java> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | ||
| Priority: | Normal | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| URL: | http://www.bouncycastle.org/releasenotes.html | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
Renaming the latest 1.52 ebuild seems to work normally. commit 12add96 (HEAD, master) Author: Patrice Clement <monsieurp@gentoo.org> Date: Sun Feb 7 19:24:24 2016 +0000 dev-java/bcprov: Version bump. Fixes bug 573438. Package-Manager: portage-2.2.26 Signed-off-by: Patrice Clement <monsieurp@gentoo.org> create mode 100644 dev-java/bcprov/bcprov-1.54.ebuild Thank you for the heads up! |
2.1.1 Version Release: 1.54 Date: 2015, December 29 2.1.2 Defects Fixed Blake2b-160, Blake2b-256, Blake2b-384, and Blake2b-512 are now actually in the provider and an issue with cloning Blake2b digests has been fixed. PKCS#5 Scheme 2 using DESede CBC is now supported by the PKCS#12 implementation. The IES engine would sometimes throw a "too short" exception on small messages which were the right length. This has been fixed. Cipher.getOutputSize() for IES ciphers would throw a ClassCastException. This has been fixed. It turns out, after advice one way and another that the NESSIE test vectors for Serpent are now what should be followed and that the vectors in the AES submission are regarded as an algorithm called Tnepres. The Serpent version now follows the NESSIE vectors, and the Tnepres cipher has been added to the provider and the lightweight API for compatibility. Problems with DTLS record-layer version handling were resolved, making version negotiation work properly. 2.1.3 Additional Features and Functionality Camellia and SEED key wrapping are now supported for CMS key agreement The BC TLS/DTLS code now includes a non-blocking API. CTR/SIC mode now support an internal counter. The internal counter can be turned on by passing an IV smaller than the block size of the cipher's algorithm. The lightweight CMS API operators now support CAST5 and RC2 CBC encryption. The CMS API now supports Diffie-Hellman as specified in RFC 3370. Support has been added to the CMS API for PKCS#7 ANY type encapsulated content where the encapsulated content is not an OCTET STRING. PSSSigner in the lightweight API now supports fixed salts. 2.1.4 Security Advisory (D)TLS 1.2: Motivated by CVE-2015-7575, we have added validation that the signature algorithm received in DigitallySigned structures is actually one of those offered (in signature_algorithms extension or CertificateRequest). With our default TLS configuration, we do not believe there is an exploitable vulnerability in any earlier releases. Users that are customizing the signature_algorithms extension, or running a server supporting client authentication, are advised to double-check that they are not offering any signature algorithms involving MD5. 2.1.5 Notes If you have been using Serpent, you will need to either change to Tnepres, or take into account the fact that Serpent is now byte-swapped compared to what it was before. 2.2.1 Version Release: 1.53 Date: 2015, October 10 2.2.2 Defects Fixed The BC JCE cipher implementations could sometimes fail when used in conjunction with the JSSE and NIO. This has been fixed. PGPPublicKey.getBitStrength() always returned 0 for EC keys. This has been fixed. A PKCS12 key store containing a looping certificate chain could cause an OutOfMemoryException. This has been fixed. A change in JDK 1.8 meant that X509Certificate.verify(PublicKey, Provider) would cause a stack overflow. This has been fixed. Nested multiparts with irregular post-amble could cause verification issues for the SMIMESigned classes. This has been fixed. CMSSignedData now supports verification of signed attributes where the calculated digest uses a different algorithm from the digest used in the signature. TRUSTED CERTIFICATE parsing in PEM files was ignoring the attribute block. A new class X509TrustedCertificateBlock is now returned containing both the certificate and the trust information. Adding a password to a PGP key which did not previously have one would result in an improperly formatted key. This has been fixed. ECIES/IES was only using a 4 byte label length for the MAC tag when it should have been an 8 byte one. This has now been fixed and OldECIES/OldIES has been added for backwards compatibility. The JceCRMFEncryptorBuilder was not recognising key size specific object identifiers properly. This has been fixed. The OpenPGP ClearSignedFileProcessor would not handle verification of single line files properly. This has been fixed. The BC X509Certificate class was no longer in agreement with the standard class for hashCode(). The BC X509Certificate class will now track the changes made in the standard Java distribution. PGP signature hashed sub-packets with long length encodings would fail to validate on signature checking. This has been fixed. The S/MIME API would occasionally leak InputStreams which could cause issues with custom DataSource implementations. This has been fixed. The PKCS#12 KeyStore implementation would sometimes leave orphaned chain certificates in the key store after private key deletion. This has been fixed. A bug in the DirectKeySignature OpenPGP example which could lead to extra data appearing in the signature has been fixed. Explicit configuration of a BcAsymmetricKeyWrapper with a SecureRandom was not properly propagated internally. This has been fixed. A CRL with a null certificate issuer would sometimes result in a NullPointerException during CertPathProcessing. This has been fixed. The CertPath processor would occasionally fail to match a DistributionPoint name correctly. This has been fixed. In order to avoid confusion about thread safety, BCrypt now uses a new instance for hash calculation every time it is invoked. Some decidedly odd argument casting in the PKIXCertPathValidator has been fixed to throw an InvalidAlgorithmParameterException. Presenting an empty array of certificates to the PKIXCertPathValidator would cause an IndexOutOfRangeException instead of a CertPathValidatorException. This has been fixed. 2.2.3 Additional Features and Functionality It is now possible to specify that an unwrapped key must be usable by a software provider in the asymmetric unwrappers for CMS. A Blake2b implementation has been added to the provider and lightweight API. SHA3 has now been added to the provider and the lightweight API. SHAKE128 and SHAKE256 have also been added to the lightweight API. The original implementation of the draft standard has been renamed to Keccak. The CMS API now supports RFC 6211 for both SignedData and AuthenticatedData. The ASN.1 parser for ECGOST private keys will now parse keys encoded with a private value represented as an ASN.1 INTEGER. EAX mode and CMAC is now supported for ciphers such as SHACAL-2 and Threefish. The SM4 block cipher has been added to the provider and the lightweight API. X9.31, ISO9796/2, and PSS signature support has been added for SHA512/224, SHA512/256. SubjectPublicKeyInfoFactory now supports DSA parameters. A range of new algorithms are now support for EC key agreement. EC ContentSigners and EC ContentVerifiers have been added to the lightweight operator package in the PKIX APIs. The PKCS#12 key store will now garbage collect orphaned certificates on saving. Caching for ASN.1 ObjectIdentifiers has been rewritten to make use of an intern method. The "usual suspects" are now interned automatically, and the cache is used by the parser. Other OIDs can be added to the cache by calling ASN1ObjectIdentifier.intern(). 2.2.4 Notes It turns out there was a similar, but different, issue in Crypto++ to the BC issue with ECIES. Crypto++ 6.0 now offers a corrected version of ECIES which is compatible with that which is now in BC.