Per discussion here https://github.com/dotnet/corefx/pull/36022#discussion_r265347843
we should not sign symbol and .Private. packages as it adds some observable amount of time to the overall signing time (few minutes?) - we currently do it in parallel with testing so overall time might be similar.
Related code:
https://github.com/dotnet/corefx/blob/master/eng/Signing.props#L13
cc: @mmitche
Thanks
Are these files distributed? Or are they thrown away at some point?
Also @GrabYourPitchforks
@blowdart Those aren't, they are pulled apart and their internals are repackaged. They never make it to nuget.org, So the binaries inside should be signed, but we don't need to sign the packages themselves.
Ah so the innards remain signed? This is just something to shuttle things arounds?
Are these files distributed? Or are they thrown away at some point?
They are consumed by core-setup... also, most of the contents in those packages, are crossgen'd by core-setup before re-packaging and are signed again in core-setup, so we're double signing some pieces. (I believe the runtime assemblies are the one crossgen'd, but not the ref assemblies).
cc: @dagood @ericstj
Ok I shall wind down then :)
Right. The goal is just to get a minimal set of signed files, because signing is a big part of the build right now (adds about an hour to the build time, taking more time than it takes to actually build the code)
Well of course signing is slow, that's how you know it's secure ;)
Well of course signing is slow, that's how you know it's secure ;)
@blowdart Oh, that makes so much sense. Now I know how to implement certificate verification.
bool IsValidCert(X509Certificate2 cert) {
Thread.Sleep(5000);
return true;
}
We can close this as we no longer produce transport packages.
We still produce at least the Microsoft.Private.CoreFx.OOB transport package.
Looking at a recent build, don't we still produce quite a few? Here's a list from a recent build of 122 packages that look like transport packages to me: https://gist.github.com/dagood/171bda76e272a2897a4fdbfdcfe858ee
Then should this issue be repurposed to remove those packages?
Sorry, clicked the wrong button now 馃う鈥嶁檪
The title says
Transport packages should not be signed
which we still do for at least Microsoft.Private.CoreFx.OOB. That packages is used by dotnet/performance, cc @adamsitnik, why would we want to remove it? We should consider renaming it as some point but this issue is about not signing such packages. @mmitche is changing how we sign going forward so he might has additional context here.
I think we can close this. The signing will be moving out of the build altogether so it's probably not worth the risk (e.g. downstream repos forget to sign the transport contents) and effort to go and keep these from being signed under the current infra.
Sounds good. Closing.
Most helpful comment