dotnet
Make doStrongNameCheck usable
SignTool contains an option for validating strong name signing. Today, in all the .NET Core produce repos, that flag doStrongNameCheck is "false". It's never true. If we set it to "true", then the verification will fail for some (not all) repos. Primarily, runtime repo has some assemblies that are "authenticode" signed, but not "strongname" signed.
A couple of things:
-
If the parameter can never be true, then we should just delete the code so that good intentioned devs don't turn it on.
-
why can't the parameter be true? Is there a valid reason that Runtime is not strongname signing some of their assemblies?
-
if there is a valid reason not to strongname sign some assemblies, we should enable turning this flag on. That likely means adding the assemblies to exclusions file
Some examples:
[Yesterday 5:56 PM] Matt Mitchell
2020-09-30T00:48:38.3427693Z fail: Microsoft.DotNet.Signing.Extensions.MsBuildEngine[0]
2020-09-30T00:48:38.3428534Z error : Assembly C:\A\1\_temp\ContainerSigning\3035\tools/ILCompiler.TypeSystem.ReadyToRun.dll is not strong-name signed correctly.
[Yesterday 5:57 PM] Matt Mitchell
2020-09-30T00:48:38.2717474Z fail: Microsoft.DotNet.Signing.Extensions.MsBuildEngine[0]
2020-09-30T00:48:38.2718336Z error : Assembly C:\A\1\_temp\ContainerSigning\3032\tools/crossgen2.dll is not strong-name signed correctly.
2020-09-30T00:48:38.2953151Z fail: Microsoft.DotNet.Signing.Extensions.MsBuildEngine[0]
2020-09-30T00:48:38.2955017Z error : Assembly C:\A\1\_temp\ContainerSigning\3033\tools/ILCompiler.DependencyAnalysisFramework.dll is not strong-name signed correctly.
2020-09-30T00:48:38.3190806Z fail: Microsoft.DotNet.Signing.Extensions.MsBuildEngine[0]
2020-09-30T00:48:38.3191585Z error : Assembly C:\A\1\_temp\ContainerSigning\3034\tools/ILCompiler.ReadyToRun.dll is not strong-name signed correctly.
2020-09-30T00:48:38.3427693Z fail: Microsoft.DotNet.Signing.Extensions.MsBuildEngine[0]
2020-09-30T00:48:38.3428534Z error : Assembly C:\A\1\_temp\ContainerSigning\3035\tools/ILCompiler.TypeSystem.ReadyToRun.dll is not strong-name signed correctly.
FYI @mmitche @missymessa @jcagme
Is there a valid reason that Runtime is not strongname signing some of their assemblies?
@hoyosjs Do you know why the crossgen2 tool and associated assemblies aren't strong named?
If the parameter can never be true, then we should just delete the code so that good intentioned devs don't turn it on.
It definitely can be true, but we need to enable the exclusion list.
The primary thing that happens in runtime is the following:
- The crossgen2 assemblies aren't delay signed, so they don't get a strong name key through ESRP or locally
- The check for the crossgen2 assemblies is not based on whether they should have gotten SN signed, but whether they could be. This is the ideal way to do the check, but we need to exclude some files.
I'd have to take a look. That package is created in a very... particular way. However in a post .net framework world where we don't have the GAC, I'm not sure how necessary SN is. Makes sense for netstandard assemblies. I'll take a look and let you know know in a bit.
@mmitche checked and we explicitly don't sign them. In a world of .NET Core we don't see any value to stron-name sign them, I've confirmed with JanK that there's no reason to.
