-
Notifications
You must be signed in to change notification settings - Fork 4.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Prevent recursive hex encoding of keys #6080
Conversation
Great job and thanks for the PR @tradel. Do we know which code paths are double encoding? I don't think we store fields in any other format so it seems like a simple bug if we are accidentally encoding twice somewhere that should be fixed at root (no pun intended) rather than making the function use heuristics to prevent double application. If there is some really complex corner case where we aren't sure if input from the user is encoded yet or not I could see the argument for this kind of change but IIRC we do all of this internally and only in a handful of places so can we just write tests to make sure they don't double encode? |
Good point @banks. I didn't spend a lot of time trying to track it down how it was happening, when the fix took me half a minute to write. I can dig deeper if you like. |
If you have time to look then feel free seems like we need a fix. If not maybe we can get this into the backlog for someone else to look at. |
I modified the
One of the above trips because
Another seems to trip because |
Also if you fire up
|
I've tried various upgrade scenarios using @tradel's original patch to make sure we aren't actually relying on the double colon-hex-encoded strings being present in certs:
also
|
Current digging has yielded that the
Which process out to:
|
So I thought this was a double-encoding issue with the In the The |
Closing in favor of #6492 |
When comparing the signing keys on CA certs, Consul converts the bytes to a hex string. Unfortunately it appears that in some circumstances the string is double encoded.
For example, the following output was observed from the
/v1/connect/ca/roots
endpoint:Decoding this string reveals:
So the key was encoded more than once. This PR stops that by checking to see if the input is already a hex string before encoding it again.