[Blazor WASM] PWA Wrong Hash for win-x64

[zr00130]

Describe the bug

I generated a project from the latest preview2 template (Microsoft.AspNetCore.Components.WebAssembly.Templates::3.2.0-preview2.20160.5) project using the PWA setting. After publishing using a FileSystem publish, the SHA-256 hashes generated for the DLLs in the service-worker-assets.js file do not match when running against the file itself. This produces errors in the browser when it calls the following line in service-worker.published.js

.map(asset => new Request(asset.url, { integrity: asset.hash }));

produced lots of these errors:

example error: Failed to find a valid digest in the ‘integrity’ attribute for resource ‘https://foo.bar/_framework/_bin/Microsoft.AspNetCore.Components.Web.dll’ with computed SHA-256 integrity ‘vCEa3gqoQS5aAN0wq+fGIjUUcKKPTh068Y8QMy0/Y1g=’. The resource has been blocked.

After further testing, it seems to only happen when I used the win-x64 runtime -- though I only tested with this runtime. When I removed <RuntimeIdentifier>win-x64</RuntimeIdentifier> (Runtime: Portable in the publish gui) from the pubxml and manually compared the generated hash vs running the following command in WSL openssl dgst -sha256 -binary _framework\_bin\Microsoft.AspNetCore.WebUtilities.dll | openssl base64 -A as an example, the hashes matched. It seems to happen for all DLLs in _framework\_bin

To Reproduce

• Generate blazor wasm project using latest preview2 template and check PWA.
• Publish with the below pubxml settings
• Copy published files to an IIS server and create as a website in IIS Manager (https bindings, proper cert, etc)... in my case Windows Server 2016 with dotnet core 3.1.2 hosting bundle
• when navigating to the application, you will see integrity check errors for the DLLs in the browsers console
• remove <RuntimeIdentifier>win-x64</RuntimeIdentifier>
• clean/rebuild/publish
• manually check using openssl like above and the hash matches the service-worker-assets.js
• redeploy to IIS and cache-bust reload browser and the DLLs load this time with proper integrity check passes

publish profile pubxml

<Project ToolsVersion="4.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
  <PropertyGroup>
    <WebPublishMethod>FileSystem</WebPublishMethod>
    <PublishProvider>FileSystem</PublishProvider>
    <LastUsedBuildConfiguration>Release</LastUsedBuildConfiguration>
    <LastUsedPlatform>Any CPU</LastUsedPlatform>
    <SiteUrlToLaunchAfterPublish />
    <LaunchSiteAfterPublish>True</LaunchSiteAfterPublish>
    <ExcludeApp_Data>False</ExcludeApp_Data>
    <ProjectGuid>69b17a14-55fc-4090-8596-1c9d5c379429</ProjectGuid>
    <publishUrl>bin\Release\netcoreapp3.1\publish\</publishUrl>
    <DeleteExistingFiles>True</DeleteExistingFiles>
    <TargetFramework>netcoreapp3.1</TargetFramework>
    <SelfContained>false</SelfContained>
    
    <!-- service-worker-assets.js SHA-256 hash incorrect; remove to make Portable and hash matches -->
    <RuntimeIdentifier>win-x64</RuntimeIdentifier>
    
  </PropertyGroup>
</Project>

Further technical details

• ASP.NET Core runtime version 3.1.2, SDK 3.1.102
• using information from https://devblogs.microsoft.com/aspnet/blazor-webassembly-3-2-0-preview-2-release-now-available/
• Include the output of dotnet --info

.NET Core SDK (reflecting any global.json):
 Version:   3.1.102
 Commit:    573d158fea

Runtime Environment:
 OS Name:     Windows
 OS Version:  10.0.18363
 OS Platform: Windows
 RID:         win10-x64
 Base Path:   C:\Program Files\dotnet\sdk\3.1.102\

Host (useful for support):
  Version: 3.1.2
  Commit:  916b5cba26

.NET Core SDKs installed:
  1.0.4 [C:\Program Files\dotnet\sdk]
  2.1.104 [C:\Program Files\dotnet\sdk]
  3.1.101 [C:\Program Files\dotnet\sdk]
  3.1.102 [C:\Program Files\dotnet\sdk]

.NET Core runtimes installed:
  Microsoft.AspNetCore.All 2.1.15 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.All]
  Microsoft.AspNetCore.App 2.1.15 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 3.1.1 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 3.1.2 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.NETCore.App 1.0.5 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 1.1.2 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 2.0.6 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 2.1.15 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 3.1.1 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 3.1.2 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.WindowsDesktop.App 3.1.1 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
  Microsoft.WindowsDesktop.App 3.1.2 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]

• The IDE (VS / VS Code/ VS4Mac) you're running on, and it's version
• VS Prof 2019 (16.4.6)

[javiercn]

@zr00130 thanks for contacting us.

@SteveSandersonMS can you look into this?

[SteveSandersonMS]

@javiercn I have been having a look, and it appears that publishing with win-x64 modifies the resulting assemblies after we computed their hashes. This doesn't make sense for a Blazor WebAssembly application, since the client-side assemblies are not really going to run on win-x64 - they are going to run on dotnet.wasm.

As such this seems to be a defect in how we do the publishing. We need to take whatever steps are necessary to make the build/publish process not make platform-specific modifications to the client-side assemblies. The hash checking makes the problem more obvious, but the problem exists independently of hash checking, since we're publishing assemblies built for an unexpected platform.

This needs to go into the usual triage process to determine when we'll have capacity to investigate this in more detail.

@zr00130 In the meantime, I recommend not selecting the "win-x64" option and continuing to use "portable". Is that possible in your scenario?

[javiercn]

@SteveSandersonMS that sounds weird, in what way are the assemblies modified? Is this due to a hosted server using win-x64 and translating that to the client project?

[SteveSandersonMS]

@javiercn It is weird, yes.

Try publishing to "filesystem" once with portable and once with win-x64. Then check the .dll files on disk in the two resulting wwwroot\_framework\_bin directories. You'll find that the hashes of corresponding files don't match each other. As for why, I don't know.

[mihaimyh]

I am having the same issue with a wasm project hosted on aspnet.core running in a linux docker container:

(index):1 Failed to find a valid digest in the 'integrity' attribute for resource 'https://exacmple.com/_framework/wasm/dotnet.3.2.0-preview2.20159.2.js' with computed SHA-256 integrity 'G0POD2J1R26XEDtnl2OT/PoZVgMsdYwohijiCDj36YQ='. The resource has been blocked.

[SteveSandersonMS]

@mihaimyh Please post a new issue with your own repro steps, as your issue may have a totally different cause.

[zr00130]

@SteveSandersonMS yep, I can continue to run as portable for now, thanks!

Some more details that may be useful:

I'm using the client/server template setup to get access to the web api. I'm publishing on the netcoreapp3.1 server project with the win-x64 RID.

Visual Studio has been weird and might point to some of my odd behavior. Cleaning/rebuilding the server project didn't seem to completely clean the client project so when publishing within visual studio it was doing odd things like generating the different hash in the service-worker-assets.js file vs the actual file.

If I run dot net publish -c Release -o "C:\test\portable" and dot net publish -c Release -r win-x64 -o "C:\test\win-x64" it does seem to correctly produce matching hashes to the dll and the assets file (though the binaries do differ as @SteveSandersonMS alluded to and are not staying portable for the client)