This update includes a few backwards-incompatible changes. Aside from a
few simple renames, the other incompatibilities are correctness-related.
* **BACKWARDS INCOMPATIBLE:** Removed the deprecated
``PUBLIC_KEY_TYPES``, ``PRIVATE_KEY_TYPES``,
``CERTIFICATE_PRIVATE_KEY_TYPES``, ``CERTIFICATE_ISSUER_PUBLIC_KEY_TYPES``,
and ``CERTIFICATE_PUBLIC_KEY_TYPES`` type aliases. Use
``PublicKeyTypes``, ``PrivateKeyTypes``, ``CertificateIssuerPrivateKeyTypes``,
``CertificateIssuerPublicKeyTypes``, and ``CertificatePublicKeyTypes``
instead. These were deprecated in version 40.0.
* **BACKWARDS INCOMPATIBLE:** :class:`~cryptography.hazmat.primitives.ciphers.algorithms.ChaCha20`
now treats the first 4 bytes of the ``nonce`` as a 32-bit little-endian block
counter (as defined in :rfc:`7539`) and tracks the number of bytes processed.
Attempting to encrypt or decrypt more data than the counter allows before it
would overflow now raises a :class:`ValueError` rather than silently diverging
from RFC 7539. Setting the counter portion of the ``nonce`` to zero allows
encrypting up to 256 GiB with a given nonce.
* **BACKWARDS INCOMPATIBLE:** Loading an X.509 certificate whose ECDSA or DSA
signature ``AlgorithmIdentifier`` contains encoded NULL parameters now raises
a :class:`ValueError`. Such certificates are invalid, but older versions of
Java emitted them; previously they loaded with a deprecation warning.
Complete changelog: https://github.com/pyca/cryptography/blob/49.0.0/CHANGELOG.rst
Full changelog: https://cryptography.io/en/latest/changelog/#v48-0-0
This contains one backwards-incompatible change, but which is in a
failure path where the previous behavior was unexpected.
- BACKWARDS INCOMPATIBLE: Loading an X.509 CRL whose inner
TBSCertList.signature algorithm does not match the outer
signatureAlgorithm now raises ValueError. Previously, such CRLs were
parsed successfully and only rejected during signature validation.
- Added support for ML-KEM key encapsulation and ML-DSA signing when
using OpenSSL 3.5.0 or later
Signed-off-by: Jeremy Cline <jeremycline@microsoft.com>
