Missing not_valid_after_utc property.

[vog]

It seems that Cryptography 44.0.0 introduced a regression by replacing not_valid_after_utc/not_valid_before_utc properties with their non-"utc" suffixed counterparts.

Background:

Not long ago the Cryptography library deprecated the not_valid_after property and encouraged everyone to switch to not_valid_after_utc:

• [RFC] Proposal for tz-aware datetime usage in cryptography.x509 #9186
• Deprecate naive datetime x509 APIs #9667

This is what we in requests_pkcs12, as downstream library, also did:

• cryptography.x509.Certificate.not_valid_after is deprecated m-click/requests_pkcs12#51
• remove deprecated cryptography not_valid_after m-click/requests_pkcs12#52

Now with Cryptography 44.0.0, the not_valid_after_utc suddenly vanished and only not_valid_after remained:

• FIX error AttributeError: '_Certificate' object has no attribute 'not… m-click/requests_pkcs12#58

Questions:

• Is this change back to a deprecated properties intentional?
  • If so, how are downstream libraries like requests_pkcs12 supposed to deal with that in a backwards compatible way?

[alex]

It's very difficult to understand the nature of this report -- the not_valid_after_utc attribute absolutely continues to exist:

~ ❯❯❯ vf tmp
Creating tempenv-3d533268639f via /opt/homebrew/Cellar/virtualfish/2.5.9_1/libexec/bin/python …
(tempenv-3d533268639f) ~ ❯❯❯ uv pip install cryptography
Using Python 3.13.1 environment at: .virtualenvs/tempenv-3d533268639f
Resolved 3 packages in 115ms
Installed 3 packages in 8ms
 + cffi==1.17.1
 + cryptography==44.0.0
 + pycparser==2.22
(tempenv-3d533268639f) ~ ❯❯❯ python3
Python 3.13.1 (main, Dec  3 2024, 17:59:52) [Clang 16.0.0 (clang-1600.0.26.4)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> from cryptography import x509
>>> x509.Certificate
<class 'cryptography.hazmat.bindings._rust.x509.Certificate'>
>>> x509.Certificate.not_valid_after_utc
<attribute 'not_valid_after_utc' of 'cryptography.hazmat.bindings._rust.x509.Certificate' objects>

Can you provide steps to reproduce the non-existence behavior?

[vog]

You are correct. Sorry for the noise. I was confused that the not_valid_after_utc property no longer existed in x509/base.py.