search

dotnet-foundation / projects

This repository is used for onboarding new projects
112 stars 30 forks source link

Code Signing Certificate Request: .NEXT #157

Closed sakno closed 3 years ago

sakno commented 3 years ago

Please fill in the information below

Certificate onboarding checklist:

ChrisSfanos commented 3 years ago

Trade name registration has been submitted

sakno commented 3 years ago

@ChrisSfanos , any updates on this?

ChrisSfanos commented 3 years ago

Hi @sakno - at this point it's out of my hands. Once I submit the Trade Name, @clairernovotny takes over and handles the rest. Looks like we are waiting on the certificate to come back. I know it can take a few weeks

clairernovotny commented 3 years ago

I'm following up with DigiCert on this -- it usually doesn't take this long.

sakno commented 3 years ago

@clairernovotny , any news from DigiCert?

clairernovotny commented 3 years ago

Yeah--hopefully soon. Looks like things got snagged by recent baseline updates where key lengths had to be 3072 or greater. Took a while to get to the bottom of that and now they need to issue/update our intermediate root with a cert to match the new baseline. I've been on them about it.

sakno commented 3 years ago

Any estimations about that? I'm stuck with release so I need to inform users about the delay.

clairernovotny commented 3 years ago

you should be able to release without it for now?

sakno commented 3 years ago

Yes, I can do that, but also I can predict questions from users like why the package is not signed?

clairernovotny commented 3 years ago

I'm hoping it'll be done by next week, but it's been slow going with them. That said, everyone knows what needs to be done now.

clairernovotny commented 3 years ago

Sorry for how long it has taken -- the certificate was finally provisioned and I've shared the lastpass folder with the credentials. There's a sample pipeline here: https://github.com/novotnyllc/CodeSigningDemo

clairernovotny commented 3 years ago

Once you have your Pipeline configured, please let me know and I can accept the NuGet co-owner requests. The certificate will be recognized by NuGet then.

sakno commented 3 years ago

Thanks @clairernovotny for good news! Unfortunately, automatic publishing to NuGet is not working in my case. The repo has several libraries with the dependencies between them. Azure Pipeline doesn't have a step that allows to wait for publication. When package gets published, it can be unavailable for download for some time (5-20 minutes). I think it happens because of CDN or caching on NuGet side. That's why I have to do this manually.

clairernovotny commented 3 years ago

Can you please be more specific? It's strongly recommended that all publishing to NuGet be automated. There is a few minutes after publish before it's indexed and available for download, but that's never really been an issue I've come across. For reference, I publish Humanizer, which has >50 packages that are tightly coupled (localization packages).

sakno commented 3 years ago

Sure, the project has the following structure:

For instance, if I want to build and publish DotNext.AspNetCore.Cluster library then the following following sequence must be respected:

  1. Publish DotNext
  2. Publish DotNext.Threading
  3. Publish DotNext.Net.Cluster
  4. Finally publish DotNext.AspNetCore.Cluster
clairernovotny commented 3 years ago

Not sure I see what the issue is?

Why wouldn't you build and publish them all at the same time?

For example, we pack the packages here: https://github.com/dotnet/reactive/blob/main/azure-pipelines.ix.yml#L68-L75

Publish them to a build artifact: https://github.com/dotnet/reactive/blob/main/azure-pipelines.ix.yml#L100-L106

For non-PR builds, we code sign and publish the artifacts to a SignedPackages artifact: https://github.com/dotnet/reactive/blob/main/azure-pipelines.ix.yml#L108

Then later, in a release management, we push the signedpackages to NuGet upon approval, when we want to publish a particular package.

sakno commented 3 years ago

The issue that library B references A using PackageReference in Release config. So B cannot be packed without having A in package registry.

sakno commented 3 years ago

Oh I see that build of related packages from the same repo is natively supported by NuGet according to this article: https://markheath.net/post/multiple-nuget-single-repo

However,

Of course, one challenge with this approach is that if you have an automated CI server that publishes the packages to a NuGet feed, how does it know which NuGet package has changed? Probably the simplest option is to always up-version all the NuGet packages in the repo and republish them.

That's very bad side effect of this approach.

sakno commented 3 years ago

@clairernovotny I've fixed YML file according to recommendations but unable to create Code Sign - Approvals environment in Azure DevOps. Also credentials moved to Variable Group as secrets.

clairernovotny commented 3 years ago

Using automated verisoning is recommended. don't version manually. I use Nerdbank.GitVersioning in all of my projects for that.

sakno commented 3 years ago

Agree, but it requires a lot of effort at the moment because each library has its own version history so I need to configure nbgv tool for 8 projects + separate pipelines for each library. Probably, it can be done in more effective way so I prefer to add this task in TODO list at the moment.

sakno commented 3 years ago

@clairernovotny , code signing done without custom environment. Release build is possible only from master branch so I removed approval step from code signing. The next step is to setup Release pipeline for publishing signed packages to NuGet. This is the better place to use approvals. The issue can be closed.

clairernovotny commented 3 years ago

The environment was there as an example as some people want to be able to approve the code signing stage. I don't tend to use approvals there, but do so with a release pipeline as you say.