dotnet / arcade

Tools that provide common build infrastructure for multiple .NET Foundation projects.
MIT License
673 stars 347 forks source link

[Signing] Update Signing documentation #387

Closed maririos closed 6 years ago

natemcmaster commented 6 years ago

Do you have any kind of doc describing what you're planning to implement? At the very least, it would be really helpful to have a short document like https://github.com/dotnet/roslyn-tools/tree/master/src/SignTool. I'm primarily interested in:

If I know those details, I can start making plans around changes we need to make in aspnet to adopt the new tool.

JohnTortugo commented 6 years ago

The documentation is actually in progress. I'm waiting to merge PR #410 before I create another PR with it.

You can see what I already have for documentation here: https://github.com/JohnTortugo/arcade/tree/SignToolDocumentation/src/Microsoft.DotNet.SignTool

Roughly speaking it's like this. Arcade SDK will make a list of all files (see this issue #464) that need to be signed and pass them to the SignTool. Once this PR (#410) is merged this list of files might contain .dll, .nupkg, .vsix and the SignTool will be able to open container files and look for which files need to be signed.

natemcmaster commented 6 years ago

Awesome, this is exactly what I've been looking for.

A couple questions about this draft.

The tool operates as a post-build step...For example, in Roslyn it took build + sign times down from 1-2 hours to 8 minutes.

This is a really interesting comment. I'm assuming the signtool shells out to MicroBuild. Any idea what MicroBuild does after that? In aspnet, we've been running into issues with the ESRPClient timing out. The ESRP team tolds us its because we submit too many files at once. They recommended 1 file per 1 sign request. @joeloff has been doing some work on his team to validate this, and he reported that signing dropped from 30-40 minutes to 6 using this approach.

TargetFramework field are: .NETStandard,Version=v2.0, .NETFramework,Version=v4.6.1, .NET Core,Version=v2.0

Everywhere else in our build, we use the short form of TFMs. Will the tool also handle netstandard2.0, net461, and netcoreapp20?

Post signing checks: Takes extra steps to ensure a file is properly signed after the signing process completes.

Which kinds of validation due you run? @joeloff wrote an awesome SignCheck tool that we were planning to add to aspnet's build.

maririos commented 6 years ago

The tool operates as a post-build step...For example, in Roslyn it took build + sign times down from 1-2 hours to 8 minutes.

@tmat might have more context here

JohnTortugo commented 6 years ago

This is a really interesting comment. I'm assuming the signtool shells out to MicroBuild. Any idea what MicroBuild does after that ...

I don't know what MicroBuild does after it receives the request. Currently, the way it works is creating creating a list of all files that can be signed at that momment (see here: https://github.com/dotnet/arcade/blob/cd8498a9a47afe6cfa1122406b979a1f3a7a91c9/src/Microsoft.DotNet.SignTool/src/SignTool.cs#L45), put that list into a xml, and them invokes a process to forward the information to MicroBuild. For instance, to sign Arcade binaries with that approach we just send two request to MicroBuild, each containing a couple of files to be signed.

Will the tool also handle netstandard2.0, net461, and netcoreapp20?

Yeap, it works for .Net framework, native dlls and .net core.

Which kinds of validation due you run?

Take a look here; Basically, the binary is open a we check for the signed flag.

AFAIU @jaredpar was the one that wrote the original version which provided the substantial performance gains.

natemcmaster commented 6 years ago

I see. We're currently invoking ESRPClient.exe directly. Maybe MicroBuild handles the parallelization. I guess we'll see.

Ok, thanks for clarifying about verification. I think we'll still use @joeloff's signcheck tool to supplement this check. source code. It does strong name verification, too, and also verifices nupkg, OPC (vsix) and Authenticode signatures. @joeloff also did some work to avoid false positives on crossgen-ed assemblies, which has been a problem for strong name verification in .NET Core.

maririos commented 6 years ago

Interesting. Do you see a possibility on porting the SignCheck tool to Arcade so we can consume it too?

joeloff commented 6 years ago

I'd definitely like to port it. It's a win x86 app (it can't be compiled against x64 because there are some native 32-bit DLLS that it needs to link against to deal with WiX bundles). It also supports XML sign checks, though that's disabled by default as most of our XML files are intellisense and we don't sign those.

tmat commented 6 years ago

I believe MicroBuild has a plugin that validates signing.