Backport a version-agnostic form of crypto 1.5 compatibility

[bitprophet]

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]

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]

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]

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]

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]

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]

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]

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]

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.)