arcade: Signing ARM/ARM64 crossgened images broken
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
https://github.com/dotnet/arcade/blob/d7e189c6182ec601a086e70ba5a88f1b837f12c3/src/Microsoft.DotNet.SignTool/src/ContentUtil.cs#L64
About this issue
- Original URL
- State: closed
- Created 6 years ago
- Comments: 40 (32 by maintainers)
Commits related to this issue
- Re-enable signing for System.Private.CoreLib Now that https://github.com/dotnet/arcade/issues/1582 is fixed. Addresses https://github.com/dotnet/coreclr/issues/21946. — committed to sbomer/coreclr by sbomer 5 years ago
- Re-enable signing of System.Private.CoreLib (#22068) * Re-enable signing for System.Private.CoreLib Now that https://github.com/dotnet/arcade/issues/1582 is fixed. Addresses https://github.com/do... — committed to dotnet/coreclr by sbomer 5 years ago
- Re-enable signing of System.Private.CoreLib (dotnet/coreclr#22068) * Re-enable signing for System.Private.CoreLib Now that https://github.com/dotnet/arcade/issues/1582 is fixed. Addresses https:/... — committed to picenka21/runtime by sbomer 5 years ago
We define default strong name and authenticode certicicates here: https://github.com/dotnet/arcade/blob/master/src/Microsoft.DotNet.Arcade.Sdk/tools/Sign.proj#L20-L25
So I assume one of them kicks in for System.Private.CoreLib.
I think it would be useful if the SignTool detected crossgen’d images and skipped strong name signing automatically.