Arcade: SignTool not strong name signing or erroring for non-strong name signed binaries

[weshaggard]

I'm in the process of switching corefx to using the signtool and I got it all plumbed and the signing succeeded but while verifying the signing I noticed that the binaries in the packages are authenticode signed but they are not strong name signed.

While I might have some configuration incorrectly setup I would have expected the signtool to error for any binary that isn't correctly strong name signed but it didn't.

For reference here is the build log for our private corefx packages:
https://devdiv.visualstudio.com/DefaultCollection/DevDiv/_build/results?buildId=2158848&view=logs

The published package can be found at https://dotnet.myget.org/F/dotnet-core/api/v2/package/runtime.win-x86.Microsoft.Private.CoreFx.NETCoreApp/4.6.0-preview1.18527.2

FYI @JohnTortugo @tmat

I have an idea of what might be wrong with my configuration but we need to fix the tool to correctly fail when things aren't strong name signed.

[JohnTortugo]

Thanks @weshaggard . I'll take a look on that asap.

[markwilkie]

@JohnTortugo / @jcagme - looks like this may have fallen through the cracks. Could you guys take a peek and make sure the right things happen please?

[JohnTortugo]

Sure. I'll take a look today. Thanks for bringing it up.

[weshaggard]

As soon as you support this corefx will start failing after uptake as there are a number of binaries that aren't fully strong-name signed currently because of https://github.com/dotnet/arcade/issues/1204 so you might want to tackle that one first.

[JohnTortugo]

@weshaggard now that I merged this PR #1317 I'm starting to work on this issue.

Is there a branch of CoreFX that I can test this issue on? My idea is to use this [new] branch to work on this issue and also validate the work from #1317 so that at the end hopefully nothing gets broken.

[weshaggard]

Just create a branch of master to test your changes. You can push that branch to our internal corefx repo and spin official builds pointing at that branch to test your changes.

[JohnTortugo]

My plan/status for this work:

• [x] Get a new SignTool package that can check if all packages are SN signed. Build complete here.
  
  
  
  • [x] Put that package in a new Arcade SDK.
  
  
• [x] Plug the Arcade SDK package above on a new branch of CoreFX.
• [x] Configure the new branch of CoreFX to use SignTool to locally sign the files that aren't SN signed.
• [x] Test / Iterate until the new CoreFX branch has all files strong name signed.
• [x] PR for updating SignTool to validate strong name signing.
  
  
  
  • [x] E-mail on Arcade group asking for concerns about this, since it's a breaking change.
  
  

I estimate 2 or max 3 work days on this.

[JohnTortugo]

@weshaggard I was running some check with the Arcade repo and noticed that some 3rd party libraries aren't strong name signed. How should we handle those files? E.g., Octokit.dll, Mono.options.dll , SevenZip.dll (I assume)

@tmat

[weshaggard]

We probably need to add them to a list to ignore these.

[weshaggard]

@JohnTortugo did you ever enable the strong name validation in corefx? I'm asking because I enabled it for the project I'm working on and I hit a null reference exception for a case when there are no items to skip and I'd expect most users of this to hit that bug. I'm going to submit a pull request to fix that issue but it made me wonder if anyone is actually using it yet.

[JohnTortugo]

Yeah, I think that one slipped through. No one is using that right now, CoreFX was the only one that manifested interest.