Code Signing Certificate Request: .NEXT

[sakno]

Please fill in the information below

• Project Name: .NEXT
• LastPass Email (or send offline): roman dot sakno at gmail dot com

Certificate onboarding checklist:

• Register trade name @ChrisSfanos
• Create configuration in Code Signing Service
• Create organization with DigiCert
• Request certificate from DigiCert
• Received certificate and finalize sign service configuration
• Provide credentials in shared folder in LastPass

[ChrisSfanos]

Trade name registration has been submitted

[sakno]

@ChrisSfanos , any updates on this?

[ChrisSfanos]

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]

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

[sakno]

@clairernovotny , any news from DigiCert?

[clairernovotny]

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]

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

[clairernovotny]

you should be able to release without it for now?

[sakno]

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

[clairernovotny]

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]

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]

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]

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]

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]

Sure, the project has the following structure:

• DotNext
• DotNext.Threading depends on DotNext
• DotNext.Metaprogramming depends on DotNext
• DotNext.Unsafe depends on DotNext
• DotNext.Reflection depends on DotNext
• DotNext.IO depends on DotNext
• DotNext.Net.Cluster depends on DotNext.Threading
• DotNext.AspNetCore.Cluster depends on DotNext.Net.Cluster

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]

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]

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

[sakno]

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]

@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]

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

[sakno]

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]

@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]

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.