Signing ARM/ARM64 crossgened images broken

[morganbr]

Signing ARM or ARM64 crossgened images fails because the images are incorrectly identified as regular managed assemblies and the SignTool task tries (and fails) to StrongName sign them.

This is most likely due to the ContentUtil.GetAssemblyName method, which uses AssemblyName.GetAssemblyName to detect whether an assembly is managed. AssemblyName.GetAssemblyName throws for x86 and x64 crossgened images, but returns a value for ARM images

arcade/src/Microsoft.DotNet.SignTool/src/ContentUtil.cs

Line 64 in d7e189c

return AssemblyName.GetAssemblyName(fullFilePath);

[JohnTortugo]

Can you post a link to a build or where we can get some logs?

[morganbr]

https://dnceng.visualstudio.com/internal/_build/results?buildId=58190 is a test signed build that hit this (real signing has a similar problem). You can test it with System.Private.CoreLib from any ARM or ARM64 build.

[JohnTortugo]

@morganbr is this blocking your work?

[morganbr]

I've worked around it by not signing the binary where we hit this, but we'll need to sign it eventually.

[JohnTortugo]

Thanks for confirming. I'll put this on my list of soon to do things.

[JohnTortugo]

Weird enough what we have is the recommended way to implement this .. https://docs.microsoft.com/en-us/dotnet/csharp/programming-guide/concepts/assemblies-gac/how-to-determine-if-a-file-is-an-assembly I'm looking into adding a stronger check.

[JohnTortugo]

So, my understanding right now is that crossgen seems to keep information on the output file that mislead all checks that I've tried so far. The only way I could successfully distinguish between managed / native code was by trying to load the file.

Right now my idea is to try to load the file using AssemblyLoadContext.LoadFromAssemblyPath and treat BadImageFormat as native code condition.

Any suggestion here @tmat ?

[JohnTortugo]

I tried to move forward with the idea of AssemblyLoadContext.LoadFromAssemblyPath but got some problems since AFAIU it's not possible to unload the file so I couldn't subsequently open the file for writing.

I ended up implementing a check by inspecting the PE structure of the file. AFAIU we should be able to tell whether the file is managed or not if it has an entry at position 14 of the Data directory (for instance, see comment here) and also checking that the content/size of that entry matches expected values.

[sbomer]

After taking an arcade update, we're now seeing signing of SPC fail on x64 and x86 in addition to ARM/ARM64, with the following (from https://dnceng.visualstudio.com/internal/_build/results?buildId=74359):

2019-01-16T22:24:49.3841998Z   3> 16.22.24.48 F:\vsagent\20\s\bin\Product\Windows_NT.x64.Release\System.Private.CoreLib.dll does not represent a strongly named assembly
2019-01-16T22:24:49.3842203Z   21> 16.22.24.48 Wait 2 minutes before retry

[JohnTortugo]

I'm taking a look

[JohnTortugo]

The problem is that you're using the default version of sign tool that comes with the SDK - It's a known issue - unfortunately that version doesn't have the fix for this issue. I'll update the default version on the SDK and once you get a new maestro update everything should work fine.