-
Notifications
You must be signed in to change notification settings - Fork 8
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
[Bug] Ring address ordering makes valid subsets beings rejected #536
Conversation
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.
left some comments with suggested namings since it was a little confusing for me so long after looking at this quote. PTAL
pkg/crypto/rings/client.go
Outdated
|
||
ringPoints := make(map[string]ringtypes.Point, len(points)) | ||
for _, point := range points { | ||
ringPoints[string(point.Encode())] = point |
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.
It's not super clear to me what string(point.Encode())
. Is it like a hash or something else?
Trying to think if there's a better name to make this clear.
The CI will now also run the e2e tests on devnet, which increases the time it takes to complete all CI checks. If you just created a pull request, you might need to push another commit to produce a container image DevNet can utilize to spin up infrastructure. You can use |
Summary
This PR fixes the
RelayRequest
signature verification process that fails whendelegateeGatewayAddresses
ordering differs at on-chain verification time.Issue
The
RelayRequest
verification step checks that the ring addresses used to sign the request are contained within the expected ring at proof verification time. For this we useringSig.Ring().Equal(expectedRing)
.The actual implementation of
Equal
[1] imposes that the request ring pubkeys must be in the same order as the expected one.Using
Equal
in the following(requestRingAddrs, expectedRingAddrs)
examples would yield undesired results in some cases:Given our delegation and undelegation use cases with their dynamic aspect, we want the
(BC, ABC)
and(AC, ABC)
cases to yieldtrue
.[1] https://github.com/noot/ring-go/blob/master/ring.go#L23
Type of change
Select one or more:
Testing
Local Testing (only if making code changes)
make go_develop_and_test
make test_e2e
PR Testing (only if making code changes)
devnet-test-e2e
label to the PR.make trigger_ci
if you want to re-trigger tests without any code changesSanity Checklist