[wasm] Ensure subtleCrypto is usable from Blazor app

[lewing]

There are potentially several things blocking it from working

• Blazor uses their own runtime initialization path and the crypto initialization call is not included in that path (or public)
  • [blazor][wasm] load .js and .wasm assets by runtime aspnetcore#43049
  • [wasm] asset loading for workers #73484
• Blazor's publish targets limit what files end up in the publish output history
  • [Blazor] Update SDK to account for the crypto worker file sdk#26966
  • [wasm] rewrite crypto-worker to typescript #73073
• For Blazor WebAssembly (hosted), consider enabling cross-origin isolation by default aspnetcore#42114
• Provide a way to disable using subtle crypto on WebAssembly for the .NET crypto APIs #73386
• [wasm] crypto deadlock fix #73537
• [wasm] fix error cases in assets loading #73702

[ghost]

Tagging subscribers to 'arch-wasm': @lewing
See info in area-owners.md if you want to be subscribed.

Issue Details

---

There are potentially several things blocking it from working

• Blazor uses their own runtime initialization path
• Blazor's publish targets limit what files end up in the publish output
• For Blazor WebAssembly (hosted), consider enabling cross-origin isolation by default aspnetcore#42114

Author:	lewing
Assignees:	-
Labels:	arch-wasm, untriaged, area-VM-meta-mono
Milestone:	7.0.0

[lewing]

also related to #69741

[pavelsavara]

After this arrives to Blazor via SDK, we will attempt to load the dotnet-crypto-worker.js

We need to add dotnet-crypto-worker.js into SDK and into list of files hosted by Blazor.

[pavelsavara]

The current runtime code is using new Worker("dotnet-crypto-worker.js") which means that the file is relative to baseURL is that what we want for Blazor? That is / in the sample app. Not /_framework/ where all the other files are.

[pavelsavara]

It seems we also need Cross-Origin-Embedder-Policy: require-corp for it.

[pavelsavara]

Also, the file as is doesn't have any hash or cache policy.

[javiercn]

@pavelsavara @radical and I talked about this.

It would be ideal if the runtime does not hardcode any path and receives this data as part of the initialization process. We likely want to add a version hash to the file in the same way we do for dotnet.js, and in general, we want control over anything that loads over a fetch request. (In other words, the runtime should not hardcode the logic related to how things work, as we might want to change it in the future or needs to be tweaked depending on the scenario.

[pavelsavara]

Yes, but your custom startup sequence is already nightmare for us. So it would be better if we don't make it worse by handling modules of the runtime in separate way as well.

My draft dotnet/aspnetcore#42770 doesn't deal with JS assets, but passing us the list of assets with hashes is the right way how to do it.

[javiercn]

@pavelsavara cool, that's very much inline with what @radical and myself discussed.

We mostly care about what @SteveSandersonMS commented on the relevant issue. As long as we maintain the current functionality, we should be good, for example, we wouldn't want to start imposing a concrete file layout on the deployed apps.

[pavelsavara]

[radical]

JFYI, this will need a test in Wasm.Build.Tests. It can use playwright to click on some button to trigger a crypto call. An existing blazor test - https://github.com/dotnet/runtime/blob/main/src/tests/BuildWasmApps/Wasm.Build.Tests/WasmTemplateTests.cs#L250-L278 :

runtime/src/tests/BuildWasmApps/Wasm.Build.Tests/WasmTemplateTests.cs

Lines 268 to 277 in bf56a7c

	await using var runner = new BrowserRunner();
	var page = await runner.RunAsync(runCommand, $"run -c {config} --no-build");
	await page.Locator("text=Counter").ClickAsync();
	var txt = await page.Locator("p[role='status']").InnerHTMLAsync();
	Assert.Equal("Current count: 0", txt);
	await page.Locator("text=\"Click me\"").ClickAsync();
	txt = await page.Locator("p[role='status']").InnerHTMLAsync();
	Assert.Equal("Current count: 1", txt);

[eerhardt]

cc @jeffhandley - FYI

[radical]

Closing in favor of #73858 . Please re-open if needed for some reason.