Deprecate/remove all non-SSL APIs in pyOpenSSL

[alex]

Motivation

pyOpenSSL has many APIs with poor designs that are entirely reliant on OpenSSL implementation details. For nearly all of these, pyca/cryptography has much better implementations with more thought out APIs.

Therefore, we would like to deprecate/remove anything besides SSL in pyOpenSSL (SSL has no equivalent in pyca/cryptography, nor is there is a path to adding one).

We've been doing this for a while already, but now we're filing an issue to actually track this in a systematic way.

Strategy

Most APIs can simply be deprecated and removed. In some cases, where SSL relies on these (e.g., PKey objects for private keys or X509 for certificates), we'll need to expand the SSL API to accept the pyca/cryptography versions of these objects (there are mostly already from_cryptography APIs we can keep around).

This also means we will not be adding any new API surface in these areas.

Status

Deprecations and Removals

• [ ] rand
  • [ ] add, status
    • [x] Deprecated
    • [ ] Removed
• [ ] crypto
  • [ ] PKey, dump_publickey, dump_privatekey, load_publickey, load_privatekey
    • [x] Replacement APIs
    • [ ] Deprecated
    • [ ] Removed
  • [ ] get_elliptic_curves, get_elliptic_curve
    • [x] Replacement APIs
    • [x] Deprecated
    • [ ] Removed
  • [ ] X509Name
    • [ ] Replacement APIs
    • [ ] Deprecated
    • [ ] Removed
  • [ ] X509Extension
    • [x] Deprecated
    • [ ] Removed
  • [ ] X509Req, dump_certificate_request, load_certificate_request
    • [x] Deprecated
    • [ ] Removed
  • [ ] X509, load_certificate, dump_certificate
    • [x] Replacement APIs
    • [ ] Deprecated
    • [ ] Removed
  • [ ] X509Store, X509StoreContext
    • [ ] Decision about how to handle SSL integration
    • [ ] Deprecated
    • [ ] Removed
  • [x] CRL, Revoked, dump_crl, load_crl
    • [x] Deprecated
    • [x] Removed
  • [x] sign, verify
    • [x] Deprecated
    • [x] Removed

APIs needing to accept/return pyca/cryptography types

• [ ] Context
  • [x] use_certificate
  • [x] add_extra_chain_cert
  • [x] use_privatekey
  • [x] set_tmp_ecdh
  • [ ] set_client_ca_list
  • [x] add_client_ca
• [ ] Connection
  • [x] use_certificate
  • [x] use_privatekey
  • [ ] get_client_ca_list
  • [x] get_certificate
  • [x] get_peer_certificate
  • [x] get_peer_cert_chain
  • [x] get_verified_chain

[phlax]

removing crypto has just broke gsutil - i suspect it will break a lot of other downstreams too

surely removing things like this would be better suited to a major (or at least minor) release rather than a patch release

[phlax]

my bad - it was at least a minor release

[alex]

@phlax If there's some action to be taken here, please file a separate bug. My read of the gsutil source is that it should work fine with these APIs removed in pyOpenSSL, because all the behavior has a 2nd implementation using pyca/cryptography.

[phlax]

probs there is no action here - but posted as i suspect others will arrive here with same issue (i also opened a pr in gsutil to pin the dep)

ftr - since last release doing ...

pip install gsutil
gsutil ...

... is broke - pinning pyopenssl==24.2.1 fixes

[colbyboles]

Further research shows that pyca/cryptography uses the OpenSSL random engines, so I will try to get my bytes() from there... Ignore below.

---

I'd like to cast my vote against the deprecation of some of these APIs, particularly rand. I understand the intent, but OpenSSL can be modified in useful ways to produce high-quality random numbers, for example. I use a TRNG along with this project:

https://github.com/tinskip/infnoise-openssl

Which can be configured as the engine which supplies randome numbers to OpenSSL. From there I use OpenSSL as a random number source and for key generation. In my case OpenSSL rand() is much better than os.random() and the deprecation in rand.py doesn't make sense. You can't assume that OpenSSL is using a worse engine than os.random().