centml/sdk/utils/client_certs.py (93 lines) generates a CA/client certificate
triplet for private endpoints. It has had no callers anywhere in this repository
since October 2024, and it is the only reason cryptography is a dependency.
How it got here
|
|
| Added |
abdeb60 (2024-06-17, #48), called from centml/sdk/api.py |
| Caller removed |
d01e054 (2024-10-13, #79, "Upgrade to new platform APIs") |
| References since |
none |
$ git grep -n "client_certs\|generate_ca_client_triplet\|save_pem_file\|CAClientCertTriplet" -- . \
| grep -v "^centml/sdk/utils/client_certs.py:"
(no output)
Not mentioned in the README, not exported from centml/sdk/__init__.py (which
is from platform_api_python_client import * plus from . import api, auth), no
CLI command reaches it, and the 119-test suite never touches it.
Why it matters
It is the sole importer of cryptography in the package:
$ git grep -rn "^from cryptography\|^import cryptography" -- centml/
centml/sdk/utils/client_certs.py:6:from cryptography import x509
centml/sdk/utils/client_certs.py:7:from cryptography.hazmat.primitives import hashes, serialization
centml/sdk/utils/client_certs.py:8:from cryptography.hazmat.primitives.asymmetric import ec
centml/sdk/utils/client_certs.py:9:from cryptography.x509.oid import NameOID
auth.py calls jwt.decode(..., options={"verify_signature": False}), which
does not need it.
So the hard pin cryptography==50.0.0 in requirements.txt exists entirely for
this module, and the maintenance it generates lands on everyone:
Because the pin is ==, a user whose scanner flags the advisory cannot upgrade
cryptography in their own environment without a resolver conflict with us.
Dropping the module would drop the dependency — and cryptography is this
package's heaviest install, carrying compiled artefacts.
What needs deciding
Is private-endpoint certificate generation coming back? The caller was removed
as part of the platform API upgrade, so this is a product question rather than a
cleanup one.
If it is not coming back, removing the module and the cryptography requirement
ends a recurring maintenance stream. One caveat: the module ships in the wheel,
so anyone importing centml.sdk.utils.client_certs directly would break. It is
not a documented surface, but it is an importable one.
centml/sdk/utils/client_certs.py(93 lines) generates a CA/client certificatetriplet for private endpoints. It has had no callers anywhere in this repository
since October 2024, and it is the only reason
cryptographyis a dependency.How it got here
abdeb60(2024-06-17, #48), called fromcentml/sdk/api.pyd01e054(2024-10-13, #79, "Upgrade to new platform APIs")Not mentioned in the README, not exported from
centml/sdk/__init__.py(whichis
from platform_api_python_client import *plusfrom . import api, auth), noCLI command reaches it, and the 119-test suite never touches it.
Why it matters
It is the sole importer of
cryptographyin the package:auth.pycallsjwt.decode(..., options={"verify_signature": False}), whichdoes not need it.
So the hard pin
cryptography==50.0.0inrequirements.txtexists entirely forthis module, and the maintenance it generates lands on everyone:
manifest) were about a PKCS#7 API this package never calls
datetime.utcnow()callsBecause the pin is
==, a user whose scanner flags the advisory cannot upgradecryptographyin their own environment without a resolver conflict with us.Dropping the module would drop the dependency — and
cryptographyis thispackage's heaviest install, carrying compiled artefacts.
What needs deciding
Is private-endpoint certificate generation coming back? The caller was removed
as part of the platform API upgrade, so this is a product question rather than a
cleanup one.
If it is not coming back, removing the module and the
cryptographyrequirementends a recurring maintenance stream. One caveat: the module ships in the wheel,
so anyone importing
centml.sdk.utils.client_certsdirectly would break. It isnot a documented surface, but it is an importable one.