arcade: 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.
About this issue
- Original URL
- State: closed
- Created 5 years ago
- Comments: 19 (19 by maintainers)
Commits related to this issue
- Disable code signing - dotnet/arcade#1911 — committed to natemcmaster/AspNetCore by deleted user 5 years ago
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.
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
StrongNameSignInfoname… still, the change that I was going to propose to meet @natemcmaster scenario was to letStrongNameSignInfo->StrongName (ItemSpec)accepts “None” which would mean don’t strong name this file. So essentiallyStrongNameSignInfowill be used to configure information for strong name & authenticode interchangeably.Yeah, this is confusing. When I was reading code, it appeared as if
StrongNameSignInfopurpose was to say “sign all PE files with a given PKT with this Authenticode cert”. FileSignInfo is close, but not exactly the same because it also requires specifying the file name.BTW, I understand there might be a confusion with StrongNameSignInfo having CertificateName attribute. I specifically proposed removing that but that hasn’t been done yet.