[wasm][tests] Use a polyfill library to provide Web Crypto API

[kjpou1]

Use Microsoft's provided Web Cryptography polyfill API in the test CI.

• Add a new parameter to the runtime.js to load extra scripts such as this one: --extra-scripts=
• The --extra-scripts= parameter takes comma separated list of scripts to load.
• An actual implementation of using the Web Crypto API getRandomValues can be found in the PR [wasm][crypto] RandomNumberGenerator mapped to Web Crypto getRandomValues #42728

close #42730

part of #40074

[ghost]

Tagging subscribers to this area: @dotnet/ncl
See info in area-owners.md if you want to be subscribed.

[steveisok]

Ah, cool. We'll have something more legit when running against v8.

[marek-safar]

Why do we need this? This looks like the scenario we don't need to support and the one we need to support cannot be tested this way

[kjpou1]

It provides the same interface as the browser web cryptography api that can be run in the CI test harness without the need for browser frontend to provide them.

Edit: Also to follow up on the back of Steve's comment it does provide a pretty much real-ish implementation of the getRandomValues instead of workaround.

buffer[0] = (Math.random()*256)|0;

[steveisok]

Why do we need this? This looks like the scenario we don't need to support and the one we need to support cannot be tested this way

@marek-safar While not absolutely necessary, I think it's more 'complete' to have the polyfill.

[marek-safar]

@steveisok the idea was to cut any custom implementation for crypto by calling into browser's APIs. Replacing one external implementation with another proxy implementation does not help us as we'll responsible for all the deployment and security problems.

[kjpou1]

This will not be deployed with our implementations. It is only to facilitate the testing of the API via the CI. The test code will be written to the browser spec and the polyfill will only facilitate the test api without the need for browser test harness at all. Actually what the polyfill implementation that is linked was written for.

[GrabYourPitchforks]

This adds ~400KB to the source repos. Since we'll probably need to keep these new dependencies up-to-date, I imagine this cost will grow over time.

Is there any other way to pull this in? For example, via a runtime-assets package?

[GrabYourPitchforks]

Also, if we're going to take a dependency on the MSR polyfill, what commit hash are we basing these files from? I can send an update for Component Governance once you're finished.

[steveisok]

I don’t think it’s worth taking this dependency. I would recommend we close the PR.

follow up comments

[ghost]

Tagging subscribers to this area: @bartonjs, @vcsjones, @krwq, @jeffhandley
See info in area-owners.md if you want to be subscribed.

[kjpou1]

Closing the PR as it brings in an unwanted dependency as per the comments above. Thanks everyone for providing feedback.