PKey._write_private_key uses old identifier from cryptography #741
Comments
Thanks, not sure how this got overlooked unless it's related to 1e7849b (but the commit you linked is apparently present in crypto 0.8 and up, so even our old requirement should have been API consistent...) |
Also I'm assuming this is evidence of a hole in the test suite, perhaps there aren't enough (any?) tests for the writing of keys, only reading. Old code is old |
Writing and reading password protected private keys fails with cryptography >= 0.8. Closes bug paramiko#741
Writing and reading password protected private keys fails with cryptography >= 0.8. This patch fixes the issue by updating changed class names and adding support for AES-256-CBC. Closes bug paramiko#741
Decryption fails as well due to missing support for AES-256-CBC. |
Writing and reading password protected private keys fails with cryptography >= 0.8. This patch fixes the issue by updating changed class names and adding support for AES-256-CBC. Closes bug paramiko#741
There's about 3 different tickets that deal with this now. Search, people! Search! sobbing noises Also, 2 of them muddy the waters by adding Thus, none of them are one-click merge-able; I am hand-picking the necessary bits and then attempting to credit everybody involved. Workflow:
|
Regardless of the "why do we need to tell ourselves about how to run these ciphers" question, I think I am now mostly ok with considering the entirety of #912 a 2.0-level bugfix. Being unable to read the very files we write is quite bugfix-y and it's not like this truly constitutes "new functionality" and/or much of a stability risk. |
Cryptography changed BestEncryption to BestAvailableEncryption in pyca/cryptography@199dc27#diff-f567fb1e66bd7ded34d4717d684339b7R188.
This results in a failure to write the key to a file with paramiko 2.0.0:
The text was updated successfully, but these errors were encountered: