Skip to content
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

TestInvalidFuzzed is flaky #284

Closed
KyleMaas opened this issue Dec 31, 2022 · 10 comments · Fixed by #286
Closed

TestInvalidFuzzed is flaky #284

KyleMaas opened this issue Dec 31, 2022 · 10 comments · Fixed by #286
Labels

Comments

@KyleMaas
Copy link
Contributor

This has apparently been happening enough that it's part of the code for the test:

https://github.com/ssbc/go-ssb/blob/master/message/legacy/verify_invalid_test.go#L20

Where it's crashing is here:

https://github.com/ssbc/go-ssb/blob/master/message/legacy/verify_invalid_test.go#L82

So...I think we've got some data in testdata-fuzzed.json which is invalid.

See #237

@KyleMaas
Copy link
Contributor Author

Specifically, it's this message:

@KyleMaas
Copy link
Contributor Author

Ah, it has a signature that's too long and is overflowing the decoding buffer.

@KyleMaas
Copy link
Contributor Author

Yeah, I think this is actually a bug in the test data. ed25519 signatures should always be the same length, AFAIK. In the data, they're not.

@KyleMaas
Copy link
Contributor Author

KyleMaas commented Jan 1, 2023

@decentral1se

Mind sanity checking my assumptions on this? From what I understand, an ed25519 signature should always result in an output of 64 bytes (SignatureSize from crypto/ed25519 ), correct?

@decentral1se
Copy link
Member

decentral1se commented Jan 1, 2023

@KyleMaas I think you're on to something suspecting the test data!

For the length, yep, it's also tested also further down:

"signature": "RjXbPdILiOAUZHvhCz+/aZz4gHxG9w1IB/KipZXvjt93vLpadnvZhwLUNgm7hZlc9TLt0HhBPjAiVFPIbfjMAwLUNgm7hZlc9TLt0HhBPjAiVFPIbfjMAw==.sig.ed25519"
},
"error": "Signature must decode to a value with 64 bytes",
"valid": false,
"id": "%dxYBn6ufvrC1URGE9oWh+YQxBnZT2gUNdl5LW5HpzH4=.sha256"

Removing that entry does start to make the test pass again. So perhaps we just need to set some guard deeper down in the stack to avoid the explosion and bubble up an error? I guess the code was changed at some point and stopped bubbling errors up... (has valid: false in the test data...)

Somewhere here?

func ExtractSignature(b []byte) ([]byte, Signature, error) {

@KyleMaas
Copy link
Contributor Author

KyleMaas commented Jan 2, 2023

@decentral1se

I tried adding a check here in my experimental branch:

532060c

But it's still broken.

However, knowing that it's always supposed to decode as 64 bytes definitely gives me something to go on.

@KyleMaas
Copy link
Contributor Author

KyleMaas commented Jan 2, 2023

I think I figured it out. It's due to a bug related to data being padded and the length measurements not taking that into account.

@KyleMaas
Copy link
Contributor Author

KyleMaas commented Jan 2, 2023

So...not a problem with the test data. It was actually a bug in the signature check due to problems with how the data decoded with padding. So this was actually quite useful for catching that.

@decentral1se
Copy link
Member

Brilliant @KyleMaas! Great to get a fix out for something so core as sig validation 👏 👏 👏

@KyleMaas
Copy link
Contributor Author

KyleMaas commented Jan 2, 2023

Thanks! Glad we could get this one picked off the list.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
Development

Successfully merging a pull request may close this issue.

2 participants