rusackas commented on PR #41010:
URL: https://github.com/apache/superset/pull/41010#issuecomment-4734759642

   Did some digging here, since `cryptography` majors have bitten us before. 
Worth noting this jumps 46 → 48 and skips 47 entirely, so *both* releases' 
breaking changes are in play. Walking through what we actually touch:
   
   - **Fernet** (encrypted DB passwords, SSH tunnel creds, OAuth tokens) is 
untouched across 47/48, so the historically scary part is fine.
   - `parse_ssl_cert` in `superset/utils/core.py` catches `ValueError` from 
`load_pem_x509_certificate`, and that still raises `ValueError` on bad input. 
The 47.0 exception-type change only affects `Certificate.public_key()` and CRL 
loading, neither of which we call there, so the handler stays correct.
   - Snowflake keypair auth (`load_pem_private_key` in 
`db_engine_specs/snowflake.py`) can now raise `UnsupportedAlgorithm` instead of 
`ValueError` for unsupported-algorithm keys. But we don't wrap that call in a 
`ValueError` handler (only the `json.loads` above it), so it propagates the 
same either way, and genuinely malformed keys still raise `ValueError`. 
`test_snowflake` exercises the keypair path (incl. a bad-key case) and it's 
green.
   - The OpenSSL 1.1 drop and Python 3.8 removal don't affect us: manylinux 
wheels bundle their own OpenSSL, our images are Debian (OpenSSL 3), and our 
floor is already py3.9. CI's build + test jobs pass, which backs that up.
   - SECT* binary curves / LibreSSL / TripleDES changes: not used anywhere I 
can find.
   
   So core-wise I think this is safe. The one thing I'd sanity-check before 
merging is **third-party DB connector extras that pin `cryptography` narrowly** 
(the usual historical pain). Base resolves clean and co-bumps `pyopenssl` to 
26.2.0, but extras resolve at the user's install, not here. If someone's 
confirmed the common ones (`snowflake-connector-python`, 
`databricks-sql-connector`) accept 48.x, I'm comfortable.
   
   No new tests strictly required given the existing coverage on these paths, 
though an explicit "parses-but-unsupported-algorithm" key case would be the 
only way to actually lock in the new `UnsupportedAlgorithm` behavior if we want 
belt-and-suspenders.
   


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]


---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to