Age | Commit message (Collapse) | Author |
|
This work is based off the work done in https://github.com/paramiko/paramiko/pull/618
|
|
|
|
|
|
|
|
|
|
|
|
Foregoes a handful of unblackened bits to make the merge easier; will
blacken next anyways
|
|
|
|
|
|
Wouldn't matter as much under pytest-relaxed discovery, but, eh
|
|
|
|
|
|
|
|
Was limited to the 2.4 branch, master either never got it or fixed it
without a backport.
|
|
|
|
|
|
|
|
|
|
Wouldn't matter as much under pytest-relaxed discovery, but, eh
|
|
|
|
This prevents non-cert-related tests from incidentally loading
the certs, which was masking issues (re #1071)
|
|
|
|
|
|
This allows server-side Paramiko code to correctly create
cert-bearing RSAKey objects and thus verify client signatures,
and now the test suite passes again, barring the stub tests.
Re #1042
|
|
Roll agnostic certificate support into PKey, and tweak publickey
authentication to use it only if set. Requires explicit call to
PKey.load_certificate() in order to alter the authentication behavior.
|
|
|
|
|
|
|
|
makes Ed25519Key objs comparable, needed for host keys
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Previously only 256-bit was handled and in certain cases (private key
reading) 384- and 521-bit keys were treated as 256-bit keys causing
silent errors.
Tests have been added to specifically test the 384 and 521 keysizes. As
RFC 5656 defines 256, 384, and 521 as the required keysizes this seems a
good set to test. Also, this will cover the branches at ecdsakey.py:55.
Test keys were renamed and test_client.py was modified as a result.
This also fixes two bugs in ecdsakey.py. First, when calculating bytes
needed to store a key, the assumption was made that the key size (in
bits) was divisible by 8 (see line 137). This has been fixed by rounding
up (wasn't an issue as only 256-bit keys were used before). Another bug
was that the key padding in asbytes was being done backwards (was
padding on current_length - needed_length bytes).
|
|
The expected output keys for these tests needed to be rewritten because previously they were generated with a BER encoder, which is basically slopper. Now they're exported as DER, which means they're always as compact as possible. A comparison of the two strings with openssl asn1parse will show that they represent the same data, they the new value is just shorter
|
|
|
|
|
|
Conflicts:
paramiko/dsskey.py
paramiko/ecdsakey.py
paramiko/hostkeys.py
paramiko/kex_gex.py
paramiko/kex_group1.py
paramiko/pkey.py
paramiko/primes.py
paramiko/rsakey.py
tests/test_pkey.py
|
|
There's several reasons for this change:
1) It's faster for reads up to 1024 bytes (nearly 10x faster for 16 byte reads)
2) It receives considerably more security review since it's in the kernel.
3) It's yet another step towards running on PyPy.
4) Using userspace CSPRNGs is considered something of an anti-pattern. See:
http://sockpuppet.org/blog/2014/02/25/safely-generate-random-numbers/
http://webcache.googleusercontent.com/search?q=cache:2nTvpCgKZXIJ:www.2uo.de/myths-about-urandom/+&cd=3&hl=en&ct=clnk&gl=us
|
|
There's a few advantages to this:
1) It's probably fast, OpenSSL, which typically backs hashlib, receives far
more attention for optimizaitons than PyCrypto.
2) It's the first step to supporting PyPy, where PyCrypto doesn't run.
|
|
|
|
support and use the `b` byte string marker instead
|
|
|
|
|
|
|
|
|