-
Notifications
You must be signed in to change notification settings - Fork 3
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
Handling panics in encrypt/decrypt #78
base: main
Are you sure you want to change the base?
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.
LGTM, but I do prefer if we do not depend on panics and recovers in general.
result, err := func() (result []byte, err error) { | ||
defer func() { | ||
if r := recover(); r != nil { | ||
err = NewError(OperationError, fmt.Sprintf("an unexpected error during encrypting happened: %s", r)) | ||
} | ||
}() | ||
|
||
result, err = encrypter.Encrypt(plaintext, ck) | ||
return | ||
}() |
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.
Given that the issue in the concrete case is about the input not being what is expected, I do wonder if it is not better to check the input instead of using recover
.
I guess we can still have this code, but I am not a fan of "exceptional workflow".
AFAIK the reason this is a panic in the crypto
module is because there is no reason for someone to provide it incorrect data.
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.
In general, I totally agree with you, and we should catch this on input/validation. My issue is that if we don't catch such input rule, e.g. that algorithm was part of the web API test suite and still, k6 ended up with hard interruption which isn't great :sad:
What?
As #66 showcased, there could be cases where using some specific methods (even from Golang's standard library) could lead to panic.
This PR introduces a way to handle such panics and "convert" them into regular errors. If the approach makes sense, we could use all of the main webcrypto methods. Later on, some generic abstraction could be considered to make all web crypto methods bootstrap free.
Why?
Panics terminate k6 whenever. For such cases, it's just an application-level error.
Closes #66