Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
proposal: concrete interfaces for crypto.PublicKey and crypto.PrivateKey #30140
This has bitten me a number of times because errors that could easily be caught by tooling or at compile time become runtime errors (sometimes very confusing ones).
It appears that all Private Keys in the crypto package include
There's also a well-known and intuitive standard way to compute a key Thumbprint that would work on any existing asymmetric keys and any future asymmetric keys. I believe there are also one or more well-known ways to compute a Fingerprint (SSH, among others), but perhaps Thumbprint is more distinct in that there is only one such specification (as far as I know).
I propose that
Thanks for the quick reply.
Before you tag this as Go2 only:
It makes them
Although you could technically say that changing the interface breaks compatibility, it's actually just moving run time errors to compile time errors.
However, I'm willing to concede that some weirdo, somewhere, has used
That being said, the bigger issue is the first point. It's trivial to add an interface.
I'm ok with making
I had never heard of a thumbprint, and I don't want to touch JWT specs if at all possible. I'm not opposed to adding a common method to all public keys, but I can't think of a good one.