ensure ed25519 password is bytes

[ploxiln]

fixes #1039

Side Note: I just noticed that this file imports "six", even though that's not explicitly a requirement in setup.py (but it's a requirement of cryptography)

[bitprophet]

That snuck past me too (the six import). Since it's now in our dependency tree it might be nice to nuke a bunch of py3compat.py in favor of Just Using Six™, sometime. Side thought.

Actual change discussion / notes to future self: seems ok, I verified your statement from #1039 re: other key types implicitly performing b(); it happens in util.generate_key_bytes, which is called in PKey._read_private_key, which is called by all subclasses.

The reason that generate_key_bytes is not utilized by Ed25519Key seems to be that its newer key format always omits the 'headers' used by the older formats, including the 'is encrypted' header which is what triggers seeking/using of password. Ed25519Key thus always runs _read_private_key as if the key is unencrypted, then performs its own decryption in a subsequent step - the one @ploxiln is modifying here.

[ploxiln]

ping.
should I rebase?

[bitprophet]

No idea why I did all that sleuthing and then didn't merge. Doing it now. Includes adding...dun dun dun...a TEST! Which I have proven yields the error from #1039 when unpatched, under Python 3.

[bsholdice]

sorry to dig up an old issue, but i've arrived here after too many hours of troubleshooting my failing ansible play. this fix solved my paramiko ("Unicode-objects must be encoded before hashing") issue. Im not good at git but it looks like this fix was in v2.2, yet I dont see the fixes in the version 2.4 that I am using. what am I missing?

[ploxiln]

This was merged into the branches for v2.2 v2.3 v2.4, but there have been no releases made since then (v2.4.0 was released before this was merged).

[bitprophet]

Yea that's my bad, was expecting to shovel some more bugfixes and then never did. Gonna pop something out this week/weekend hopefully though.