New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Backport a version-agnostic form of crypto 1.5 compatibility #1292

Closed
bitprophet opened this Issue Sep 18, 2018 · 4 comments

Comments

Projects
None yet
1 participant
@bitprophet
Member

bitprophet commented Sep 18, 2018

Increasingly vexed by the enormous reams of warnings spat out by Paramiko <2.3 during test runs, caused by a lack of #979.

However, it's not nice to backport that ticket itself (because then dependencies will change in tertiary releases - I'm more flexible these days but that's beyond the pale) so I want to see if it's feasible to rewrite it for 2.0+ in a "if X else Y" fashion.

Ought to be straightforward? Famous last words...

Remember to make sure that the merge from 2.2 to 2.3 uses -s ours or similar, so that 2.3+ goes back to assuming what it's able.

@bitprophet bitprophet added the Support label Sep 18, 2018

@bitprophet

This comment has been minimized.

Show comment
Hide comment
@bitprophet

bitprophet Sep 18, 2018

Member

Belatedly realized a side effect of this is that 2.3+ could ostensibly relax its version requirement for Cryptography if we preserve the either-or code during the merge.

However that cat's out of the bag - users of Paramiko 2.3+ are already going to be on Cryptography 1.5+ - so it doesn't really seem worthwhile. And esp re: crypto libraries we want to be pushing users to get used to updating periodically instead of staying on old versions, when we have a choice...

Member

bitprophet commented Sep 18, 2018

Belatedly realized a side effect of this is that 2.3+ could ostensibly relax its version requirement for Cryptography if we preserve the either-or code during the merge.

However that cat's out of the bag - users of Paramiko 2.3+ are already going to be on Cryptography 1.5+ - so it doesn't really seem worthwhile. And esp re: crypto libraries we want to be pushing users to get used to updating periodically instead of staying on old versions, when we have a choice...

@bitprophet

This comment has been minimized.

Show comment
Hide comment
@bitprophet

bitprophet Sep 18, 2018

Member

Updating travis-ci at this point too so it tests some older cryptography versions (for 2.0-2.2, crypto 1.1 and 1.5 as well as implicit latest; then when I merge to 2.3, I should preserve some of this so that it tests 1.5 and latest only.)

Member

bitprophet commented Sep 18, 2018

Updating travis-ci at this point too so it tests some older cryptography versions (for 2.0-2.2, crypto 1.1 and 1.5 as well as implicit latest; then when I merge to 2.3, I should preserve some of this so that it tests 1.5 and latest only.)

@bitprophet

This comment has been minimized.

Show comment
Hide comment
@bitprophet

bitprophet Sep 18, 2018

Member

FWIW I am unable to even return to older cryptography versions on macOS 10.12, so I'm basically relying on Travis here (tho I can test on a container locally if I gotta).

Also of note, I'm very slightly modifying the logic in the code, pulling the setup of the signatures/etc inside the try/except/else. Otherwise, the test for whether the keys have the newer API is split up in two places and it just looks messy/is hard to follow. This should be safe because the try/except/else only catches InvalidSignature; so any exceptions within the verifier/signature/etc setup should still get raised as they were previously by being outside the block.

Member

bitprophet commented Sep 18, 2018

FWIW I am unable to even return to older cryptography versions on macOS 10.12, so I'm basically relying on Travis here (tho I can test on a container locally if I gotta).

Also of note, I'm very slightly modifying the logic in the code, pulling the setup of the signatures/etc inside the try/except/else. Otherwise, the test for whether the keys have the newer API is split up in two places and it just looks messy/is hard to follow. This should be safe because the try/except/else only catches InvalidSignature; so any exceptions within the verifier/signature/etc setup should still get raised as they were previously by being outside the block.

bitprophet added a commit that referenced this issue Sep 18, 2018

Pull in changelog re #1292
Rest of merge was resolved with '-s ours' to keep
those changes back on the old branches only.
@bitprophet

This comment has been minimized.

Show comment
Hide comment
@bitprophet

bitprophet Sep 18, 2018

Member

Should be all done, including making sure not to nuke the improved Travis "test some older Cryptos" additions (which...I almost nuked in the merge. heh.)

Member

bitprophet commented Sep 18, 2018

Should be all done, including making sure not to nuke the improved Travis "test some older Cryptos" additions (which...I almost nuked in the merge. heh.)

@bitprophet bitprophet closed this Sep 18, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment