-
Notifications
You must be signed in to change notification settings - Fork 9.8k
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
The public key doesn't match if any field doesn't match #13382
Conversation
Could anyone provide feedback on this PR? Thanks. |
Can you add a test? |
Thanks for the comment. In theory, the current implementation isn't correct, because it regards the public keys as not matched when all fields do not match. It means that if some fields match, and others do not match, then it will regard them as matched. So I submitted this PR, it will only regard the public keys as matched when all fields match. Actually I thought about adding unit test to cover the corner case, but eventually I gave up. Reasons are below. Firstly, the existing unit tests in jwt_test.go already cover all the basic scenarios. Secondly, it's difficult to create a real private & public key to hit the corner case. Thirdly, I thought about adding some mock functions (see below), and add some fake public key & private key of json marshaled strings in jwt_test.go. When the values for "sign-method" in the –auth-token is "fake-rsa" or "fake-ecdsa", then etcd will use the mock functions. But it will have some impacts on the production environment as well and accordingly have security concern, so I gave up this approach.
What do you think? |
@serathius any comments please? |
Sorry, I don't think competent enough in Auth code to review this change. Was hoping that adding tests would show exact impact of this change. Best to ask original author or reviewer of PR that implemented JWT #9883 |
Talk bout a blast from the past... I'm no longer active with etcd, but I'll try to add some context here. When the code was written three years ago (2018), the There is actually a subtle bug in the current logic, as described in the last line of the referenced issue. Apparently I failed to properly distribute the negation. Current RSA stdlib implementation: return pub.N.Cmp(xx.N) == 0 && pub.E == xx.E vs. existing logic: if pub != nil && pub.E != priv.E && pub.N.Cmp(priv.N) != 0 { Since it's meant to be checking for an error, it should have been: if pub != nil && (pub.E != priv.E || pub.N.Cmp(priv.N) != 0) { Since Wrapping up:From a mechanical perspective, this code does fix some incorrect logic in the key comparison that I wrote years ago. I can't say much more beyond that. |
ef0b86a
to
68ae5c4
Compare
Just rebased the PR and squashed the commits. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks @joelegasse, your comment was very helpful.
+1 based on @joelegasse comment
68ae5c4
to
63ff6d4
Compare
Rebased again although there is no conflict with the base branch. |
Fix #13381