|brent s. 29dea9ae1f|
A Golang library variant of ChaCha20-Poly1305 that OpenSSH uses (
|Note that this module only supports the OpenSSH variant, and should only be used for key generation/parsing/modification/manipulation, not actual connection/stream encryption.|
The usage of this library is very limited in scope; it’s only intended for low-level OpenSSH key operations.
Primarily, for use with go_sshkeys.
I really, really hope this library is no longer necessary by the time I’m done writing it but based on my past experiences with core Golang devs, my expectations are extremely low.
Narrator: It was still necessary .
They have no decent support for OpenSSH keys or lower-level operations. And guess what — sometimes you need lower-level functionality. Who knew?
So now because I’m just a single individual, bug fixes will probably lag behind upstream if I have to re-vendor because I’m not maintaining an entire fork of golang.org/x/crypto. All because Golang devs decided the OpenSSH variant was "too weird".
But, of course, not "weird" enough to not support the wire protocol for SSH. Just the key encryption. Because of course. And not publicly exposed either. Because of course.
I couldn’t think of a better one and I wanted something notably distinct from the stdlib-x naming.
And module names can’t include the
To keep code changes from upstream light (and thus easier to debug, audit, etc.)
Because otherwise the module name is inaccurate
Because OpenSSH has their own specific variant
Which means we can handle SSH-specific functionality if needed
Because golang.org/x/crypto has made it painfully clear that if you want something that deviates from what they think is "best practice", you need to do it yourself
Which ironically is something they also brand an "anti-pattern" which is just *chef’s kiss*