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

Merge webcrypto into k6 #4188

Merged
merged 190 commits into from
Jan 17, 2025
Merged

Merge webcrypto into k6 #4188

merged 190 commits into from
Jan 17, 2025

Conversation

olegbespalov
Copy link
Contributor

@olegbespalov olegbespalov commented Jan 16, 2025

What?

Move xk6-webcrypto inside the k6 codebase

Why?

k6's WebCrypto soon will be promoted out of experimental, and as the team we decided that the codebase should be located in the k6

Checklist

  • I have performed a self-review of my code.
  • I have added tests for my changes.
  • I have run linter locally (make lint) and all checks pass.
  • I have run tests locally (make tests) and all tests pass.
  • I have commented on my code, particularly in hard-to-understand areas.

Related PR(s)/Issue(s)

https://github.com/grafana/xk6-webcrypto/

Part of #3154

oleiade and others added 30 commits October 7, 2022 12:12
Define module API to match WebCrypto's
The Web Crypto API specification has a pretty loose set of expectations
towards errors. However, making our implementation pass the Web
Platform Tests outlined that they're expected to be in a quite specific
format.

In order to provide a good support for errors in the Web Crypto API,
we define its expected errors as custom errors.
Implement support for the crypto.getRandomValues operation
Implement support for the crypto.randomUUID operation
Implement support for the `crypto.subtle.digest` operation
The previous implementation of the normalization function was really
thorough, complex, and close to the specification. Up to a level where
the complexity was not necessarily worth it compared to the sought end
result.

This commit reduces the algorithm normalization to its bare minimum
requirements.
The pre-existing CryptoKey type was intended as a contract-type
declaration of type matching the specification's. It was not bound to
any specific implementation, and as a result, not battle tested.

This commit realigns its definition with the real-world use-case
brought by the `subtle.crypto.generateKey` operation's implementation.

The two main changes are the switch from a generic type to a `any` type
for the `CryptoKey.handle` and `Cryptoattribute. This attribute is not exposed to
the user, and is heavily contextual. We will in practice know from the
context what type it is supposed to be castable to. The second change
is to define a dedicated generic type for the algorithm field. There
are a variety of Algorithm object types defined by the specs, and we
need to be able to distinguish and export them to dedicated objects
easily for them to be convinient to use.
@olegbespalov olegbespalov self-assigned this Jan 16, 2025
@olegbespalov olegbespalov added dependencies Pull requests that update a dependency file area: webcrypto labels Jan 16, 2025
@olegbespalov olegbespalov marked this pull request as ready for review January 16, 2025 16:12
@olegbespalov olegbespalov requested a review from a team as a code owner January 16, 2025 16:12
@olegbespalov olegbespalov requested review from inancgumus and joanlopez and removed request for a team January 16, 2025 16:12
@olegbespalov olegbespalov changed the title WebCrypto promotion to k6 Merge webcrypto into k6 Jan 16, 2025
@olegbespalov olegbespalov added this to the v0.57.0 milestone Jan 16, 2025
@olegbespalov olegbespalov requested a review from mstoykov January 16, 2025 16:28
Copy link
Member

@inancgumus inancgumus left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I've reviewed as much as I could, but the PR is pretty large, so it wasn't a thorough review. I also found it a little unclear what was moved or added newly in this PR.

.github/workflows/wpt.yml Outdated Show resolved Hide resolved
> [!IMPORTANT]
> We do run the tests based on these examples, that's why we have a simple convention for each example:
>
> * It should do any `console.log`. Since we try to detect that output (log) contain `INFO` keyword.
Copy link
Member

@inancgumus inancgumus Jan 16, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What does "do" mean in this sentence: "It should do any console.log." I'm curious if it means "do" or "do not."

Suggested change
> * It should do any `console.log`. Since we try to detect that output (log) contain `INFO` keyword.
> * It should do any `console.log`. Since we try to detect that output (log) contains the `INFO` keyword.

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 that contains that mean perform, like it's expected to have at least one console.log

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I could fix this after merge if needed

Comment on lines +20 to +27
+ // promise_test(function(test) {
+ // return subtle.deriveBits({name: "ECDH", public: publicKeys[namedCurve]}, privateKeys[namedCurve], 8 * sizes[namedCurve] - 11)
+ // .then(function(derivation) {
+ // assert_true(equalBuffers(derivation, derivations[namedCurve], 8 * sizes[namedCurve] - 11), "Derived correct bits");
+ // }, function(err) {
+ // assert_unreached("deriveBits failed with error " + err.name + ": " + err.message);
+ // });
+ // }, namedCurve + " non-multiple of 8 bits");
Copy link
Member

@inancgumus inancgumus Jan 16, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should we consider removing that if it's not needed? I noticed there are some other parts like this commented out, but I didn't highlight all of them before understanding our reasons for keeping the code in the comments.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's needed, it's commented because comments easier to uncomment once support will be there

@olegbespalov
Copy link
Contributor Author

@inancgumus yeah, it's big, but don't worry from many aspects it's the code that has been already reviewed and this PR same as the PR of moving browser code

Copy link
Member

@inancgumus inancgumus left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🚀

Comment on lines +5 to +9
> [!IMPORTANT]
> We do run the tests based on these examples, that's why we have a simple convention for each example:
>
> * It should do any `console.log`. Since we try to detect that output (log) contain `INFO` keyword.
> * It should NOT `try/catch` exceptions. Since we try to detect if keywords like `"Uncaught"` and `"ERRO"` should not appear in the output (logs).
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Based on your comment, I'd suggest the following for clarity, but I have no strong opinion. The current text is also fine, except for the typo.

Suggested change
> [!IMPORTANT]
> We do run the tests based on these examples, that's why we have a simple convention for each example:
>
> * It should do any `console.log`. Since we try to detect that output (log) contain `INFO` keyword.
> * It should NOT `try/catch` exceptions. Since we try to detect if keywords like `"Uncaught"` and `"ERRO"` should not appear in the output (logs).
> [!IMPORTANT]
> We do run the tests based on these examples; that's why we have a simple convention for each example:
>
> * Success condition: Example SHOULD output an `INFO` keyword using `console.log` at least once.
> * Failure condition: Example SHOULD NOT `try/catch` exceptions so that we can detect failures. The log output SHOULD NOT contain any keywords like `"Uncaught"` and `"ERRO"`.

@@ -18,9 +18,16 @@ jobs:
with:
go-version: 1.23.x
check-latest: true
- name: Run tests
# TODO: combine WebPlatform tests checkout & patch into the singe step
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
# TODO: combine WebPlatform tests checkout & patch into the singe step
# TODO: combine WebPlatform tests checkout & patch into the single step

@@ -34,3 +34,6 @@ script.js

/packaging/.env
/packaging/*.gpg

# web platform tests
js/modules/k6/webcrypto/tests/wpt/
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nit; I'd move this line next to the other one related with the WPT tests.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area: webcrypto dependencies Pull requests that update a dependency file
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants