Hi Elad, I'll reply inline.
On Thu, Apr 23, 2026 at 3:08 PM Elad Kalif <[email protected]> wrote: > ... > You referenced a PR in another repo > https://github.com/vespa-engine/pyvespa/pull/1229 that I am not sure how I > was supposed to find and also still doesn't explain the issue I asked > about. > You weren't supposed to find it, because it didn't occur to me that I should have mentioned that - it was just Jarek and me troubleshooting why the CI complained. In retrospect, that was a mistake - please accept my apologies. I'll try to be more transparent in the future. > > Here, we are bumping ssh/sftp due to a provider that is not > tightly coupled. You are asking all ssh/sftp users (who are a lot!) to bump > version to accommodate vespa users. > The root cause for bumping isn't tied to Vespa, though. pyvespa would happily work with a lower cryptography version; it's just that there are vulnerabilities marked as High, which are fixed in the new version. Namely: https://github.com/vespa-engine/pyvespa/security/dependabot/61 Hence, the cryptography bump in pyvespa which caused the conflict. Thomas (in CC - pyvespa maintainer and steward to the Vespa provider) could have lowered the lower bound on pyvespa, but we thought it's not a good idea (for those security reasons) and Jarek agreed. Again, in retrospect we should have been more transparent, IMO. Sorry again! > ssh/sftp are really sensitive providers - they are used by many who run > older versions and we should be mindful of that. > It's OK to do that but: > Bump paramiko lower bound to >=3.5.1 due to adding Vespa provider > > can **not** be the reason we give to the ssh/sftp users. > The reason needs to be something the community will appreciate. Agreed! I think that the vulnerability addressed by the newer cryptography version should be quoted, as it's the main reason anyway. > > For the moment, I can't really tell if the issue is just the release note > entry or if there is a way to avoid the change altogether. I still can't find any reference to the discussions you are referring to > about the versions and more specifically I did not find anywhere where an > answer to why vespa can't specify the paramiko and cryptography in its own > toml file. > The CI will pick the versions it specifies along with the ones we have in > ssh/sftp and will decide on the versions we have in constraints. > If there is an issue with the CI - I don't understand what it is and at > what PR it was discussed. Can you please point me to it? > pyvespa (which is what the vespa provider uses) depends on cryptography (not paramiko, afaik). Even if I specify the needed cryptography version in the vespa provider toml, wouldn't that make the CI pull that minimum cryptography version? In which case the old version of paramiko will break at runtime - that was the CI error we saw. Something like the snippet below. Is there a way around it? FAILED providers/ssh/tests/unit/ssh/hooks/test_ssh.py::TestSSHHook::test_tunnel_with_private_key_passphrase - airflow.sdk.exceptions.AirflowException: Private key provided cannot be read by paramiko.Ensure key provided is valid for one of the followingkey formats: RSA, DSS, ECDSA, or Ed25519 FAILED providers/ssh/tests/unit/ssh/hooks/test_ssh.py::TestSSHHook::test_ssh_connection_with_private_key_passphrase_extra - airflow.sdk.exceptions.AirflowException: Private key provided cannot be read by paramiko.Ensure key provided is valid for one of the followingkey formats: RSA, DSS, ECDSA, or Ed25519 Regarding the discussions you're asking about, I'm sorry they weren't more transparent. It just didn't occur to me to write it to the PR or on the dev list; there was no specific reason. All the best, Radu
