SimpleBrowserDotNet/SimpleBrowser

Move Nuget packaging and release process to Azure Pipelines

kevingy opened this issue · 21 comments

The CI/CD build is implemented in Azure DevOps Pipelines. The ability to take a build and release to Nuget is present in Azure DevOps Pipelines. Since TeamCity can no longer build SimpleBrowser and Azure DevOps Pipelines can, the work to move Nuget packaging should be moved to Azure.

This should be done sooner than later. The most current Nuget package that is not pre-release is from 2016. It would be nice to have something modern on Nuget.

@Teun When the SimpleBrowserDotNet organization was created, I was made an admin on the TeamCity project to modify CI/CD and kick off a Nuget publush. It looks like I don't have access to the SimpleBrowser Nuget project/orgnization itself, outside of TeamCity. Do you have access to that? If so, can you make me an admin there as well? My username is kevingy.

@Teun Ping!

@jbuedel Can you get me into the SimpleBrowser Nuget account?

@Teun @jbuedel Still hoping to get in to the SimpleBrowser Nuget account to be able to push a new Nuget package. Thanks!

Sorry man, I missed your earlier mention. Checking into it now...

@jbuedel Yep. That's me. I updated my Gravatar for that email address to match my photo here.

@kevingy Cool. I added you to the nuget package.

@jbuedel I'm all set. Thank you!

Teun commented

@jbuedel @Teun The current NuGet package has a .signature.p7s file in it, meaning that it is signed. My new NuGet package doesn't have one because it's not signed. Do we have the PFX certificate to sign the NuGet package? (I'm new to this whole NuGet thing. Does it need a specific PFX? Can I just create a new one?)

If I ever had it, I don't anymore. (Actually, I'll check when I get back to my home pc but I doubt I do).

Anyway, I occasionally create nuget packages for work and we don't sign any of them. I do not think it is required. (That said, we don't publish them on nuget.org either. Perhaps it is required there, I don't know).

Any plan on releasing a new version of the nuget package to nuget.org?

@mikaelliljedahl Yes. We are close.

In previous Nuget releases, the package was signed. Either the previous packages were signed by Nuget automatically (unlikely) or we lost the certificate used to sign the package (most likely). As a result, we are only able to release an unsigned package.

Deployment got stalled on whether we wanted to continue with an unsigned package or try to sign the package. That's where we currently stand.

In order to sign release packages, we would need a code signing certificate, which costs approximately USD$100 per year. I don't know how we were able to sign packages previously, but without funding, we're not going to be able to sign packages going forward.

I’m sure I didn’t pay for a cert when I created those packages. Maybe I signed them using the key I use for Github auth. Anybody know how to inspect that p7s file to get some details about the key used?

@jbuedel Here's the information from the cert:

image
image
image
image
image

It looks a lot like the certificate belongs to Nuget, as though Nuget signed the package. Perhaps they don't to that any longer?

It's interesting that the creation date is April 2018. We didn't release a package around that time. Additionally, the cert is good until April 2021, if we had the corresponding pfx file.

Reading this: https://haacked.com/archive/2019/04/03/nuget-package-signing/
as I understand signing a Nuget package is not mandatory (is it a setting in the project?).
And one option mentioned in the comments to get a free certificate is to join the .Net Foundation https://dotnetfoundation.org/ and another option is to let an Microsoft MVP member sign the package (since they have a way to create free certificates).

It actually seems that the certificate used is NuGet's own. The package is automatically signed (?) when it is submitted to nuget to tamper proof it, I got the info here:
https://devblogs.microsoft.com/nuget/introducing-repository-signatures/

Ok, I'm proceeding with creating an unsigned package and pushing it to Nuget. If we need or want to be signed, a new ticket can be created when that determination is made.

Done! The release pipeline throws an error, but it completed successfully, with a package uploaded to Nuget. I created a new .Net Core console app project, added the new Nuget package to the project as a test. It worked.

It would appear as though Nuget does inject a p7s certificate into the package as well. All of the turbulence around the certificate appears to have been needless.

I'm going to disable Team City. It's still building and failing.

I'd say this is done. Closing the issue!