SignTool: StrongNameInfo should not imply delay signing by default

Found as a result of trying to onboard ASP.NET Core to Azure Pipelines.

SignTool currently assumes that when a strong name key is specified via StrongNameInfo, that this means assemblies where delay-signed. As a result, it adds the <StrongName> metadata to the generated project it runs via MicroBuild.

Not all strong name keys we use are available in ESRP. For example, the MicrosoftAspNetCore key. This key is fully available in open source, so it should be unnecessary to have ESRP re-apply a strong name since C# will fully-sign assemblies locally.

Talking with @JohnTortugo about this, he proposed one workaround, which is take advantage of the ‘resign’ capability by changing StrongNameInfo to the path to a .snk file. This is not desirable either because this is unnecessary in most cases. The ‘resign’ capability is only necessary for .dll’s that need to modify the IL after the C# compiler is done, which IMO is the exception not the rule to strong-name signing. Re-signing every aspnet .dll would be inefficient.

[natemcmaster]

I thought ASP.NET is listing all files explicitly via FileSignInfo, isn’t that the case?

We were doing that and decided to try using the PKT/StrongNameSignInfo approach. If that’s not going to work, we’ll go back to listing files explicitly by name.

[JohnTortugo]

Yeah, AFAIU FileSignInfo will require the file name to be specified. What I understand nate wants is PKT -> AuthenticodeCertificate; independent of name, etc.

I also don’t like the StrongNameSignInfo name… still, the change that I was going to propose to meet @natemcmaster scenario was to let StrongNameSignInfo->StrongName (ItemSpec) accepts “None” which would mean don’t strong name this file. So essentially StrongNameSignInfo will be used to configure information for strong name & authenticode interchangeably.