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

Handling panics in encrypt/decrypt #78

Open
wants to merge 2 commits into
base: main
Choose a base branch
from

Conversation

olegbespalov
Copy link
Contributor

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

@olegbespalov olegbespalov requested a review from a team as a code owner April 23, 2024 09:18
@olegbespalov olegbespalov requested review from mstoykov and joanlopez and removed request for a team April 23, 2024 09:18
Copy link
Contributor

@mstoykov mstoykov left a 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.

Comment on lines +97 to +106
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
}()
Copy link
Contributor

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.

Copy link
Contributor Author

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:

@olegbespalov olegbespalov self-assigned this Apr 24, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Gracefully handling panics
3 participants