search

NuGet / NuGetGallery

NuGet Gallery is a package repository that powers https://www.nuget.org. Use this repo for reporting NuGet.org issues.
https://www.nuget.org/
Apache License 2.0
1.54k stars 643 forks source link

Support Azure Trusted Signing certificate on NuGet.org account settings #10027

Open jozefizso opened 3 months ago

jozefizso commented 3 months ago

NuGet Product(s) Involved

Other/NA

The Elevator Pitch

The Azure Trusted Signing service rotates the managed authenticode certificates each three days.

As the NuGet Gallery requires to specify a single, long lived certificate, it is not feasible to sign nuget packages with the ATS.

Additional Context and Details

@dlemstra has authored a proposal design to fix this problem: https://github.com/NuGet/Home/pull/13791

jebriede commented 3 months ago

@jozefizso thanks for reaching out. Could you please include details of what feature or change you are proposing? Thanks!

jozefizso commented 3 months ago

The Gallery should support the code signatures made by Azure Trusted Signing. It is unfeasible to upload new signature to Gallery each three days to get the verified badge.

joelverhagen commented 3 months ago

Thanks for opening the issue @jozefizso. I agree using Trusted Signing with NuGet.org is a painful process today. You need to extract the .cer file from your signed artifact (or get it from Trusted Signing directly, perhaps) and then manually upload it to your account profile on NuGet.org.

For my own experiments I created a CLI tool to extract the .cer file and include it as a GitHub Actions artifact. Tool: https://www.nuget.org/packages/Knapcode.CertificateExtractor Workflow: https://github.com/joelverhagen/PackageLifeCycle/blob/7930b64f7e72518faf6b646187b47b46e2d64d22/.github/workflows/build.yml#L76-L87

This is better than nothing, but not much better!

dlemstra commented 3 months ago

I would nice if we could get a new option to specify the Enhanced key usage that is shown on the page of our Certificate Profile inside our Trusted Signing Account. That is the same one as the bottom one that is shown here:

Enhanced key usage

And then when we upload the NuGet package the server checks if this matches and also checks if the signing of the package is done by the right authority.

ianjmcm commented 3 months ago

Supporting the Subscriber identity validation EKU as @dlemstra points out would be durable over all certificate rotations/renewals. Here is the public docs on these values: https://learn.microsoft.com/en-us/azure/trusted-signing/concept-trusted-signing-cert-management#subscriber-identity-validation-eku.

mjcheetham commented 3 months ago

This problem is currently impacting Git Credential Manager that ships a NuGet package that's signed by Azure Trusted Signing – would love to see some support for these sorts of certificates/signed packages, and a solution that is durable over all of the short-lived certs.

jmecosta commented 3 months ago

Thanks for opening the issue @jozefizso. I agree using Trusted Signing with NuGet.org is a painful process today. You need to extract the .cer file from your signed artifact (or get it from Trusted Signing directly, perhaps) and then manually upload it to your account profile on NuGet.org.

For my own experiments I created a CLI tool to extract the .cer file and include it as a GitHub Actions artifact. Tool: https://www.nuget.org/packages/Knapcode.CertificateExtractor Workflow: https://github.com/joelverhagen/PackageLifeCycle/blob/7930b64f7e72518faf6b646187b47b46e2d64d22/.github/workflows/build.yml#L76-L87

This is better than nothing, but not much better!

@joelverhagen is the & "bin\Sign.Cli\sign.exe" something that you have created? can you share it? or do you have any pointers how to get nuget sign with trusted service? or are you using https://github.com/dotnet/sign/pull/716

dlemstra commented 3 months ago

The "bin\Sign.Cli\sign.exe" executable is the output of the dotnet/sign project. The branch of my PR is still work in progress so it's subject to change. I have been using it locally but not yet in a pipeline.

jmecosta commented 3 months ago

yep, just getting to that conclusion also, there are a few cli options changed but pretty much what im looking for... thank you

dlemstra commented 3 months ago

And those options might still change because the PR is still being reviewed by the team.

jmecosta commented 3 months ago

Yep important is the sign functionality itself if that works we can start integrating it already

joelverhagen commented 3 months ago

@dlemstra is spot on. I have a private build of sign CLI used in the pipeline links above.

But to be clear this GitHub issue tracks better support of Trusted Signing on NuGet.org (verification of signing at push time in NuGet.org) and not the sign flow which is tracked by https://github.com/dotnet/sign/issues/683.

glennawatson commented 4 weeks ago

Has anyone seen issues where the validation fails with sign cli and trusted signing.

I'm extracting out the certificate using @joelverhagen tool

I can see the valid certificate in the nuget package explorer tool

seeing

The package was signed, but the signing certificate (SHA-1 thumbprint <thumbprint>) is not associated with your account. You must register this certificate to publish signed packages.

I have got the SHA1/256 hash and confirmed its there, and in the cert area it's showing microsoft signing there like its picked up and processed the cert.

I have tried the sign cli experimental version, jsign client, signtool as recommended in the docs and all producing the same results.

jmecosta commented 4 weeks ago

no problems so far, you could try this (assuming u have done az login and your account has permissions)

dotnet tool install --global AzureTrustedSignTool dotnet tool install Knapcode.CertificateExtractor --global dotnet tool install --global sign --prerelease AzureTrustedSignTool sign --folder ./pkgs --searchpattern *.nupkg --accountname YourAccount --profilename YourSignProfile

that signs the packages and generates a .cer next to each nuget. so you can upload both at same time. So far no problems with this approach.

glennawatson commented 4 weeks ago

@jmecosta I think its some sort of special rules for my package rather than a trusted signing process issue.

Eg having some packages get published (with the same single owner) and some not.

Splat had the DotNetFoundation as a owner and I know there are special rules for DNF owned packages, also its in a reserved space.

I suspect it's more rules around that rather than a legitimate certificate failure given the intermitient results about which ones pass (nupkg that never were owned by the DotNetFoundation user get published)

I have used the same steps you have used above effectively.

jmecosta commented 4 weeks ago

Interesting I've never notice certificate bounded to package names. If so the error message is not really accurate

jmecosta commented 3 weeks ago

@glennawatson i can confirm this also, ive just experience the same. the account is shared, and ive uploaded the CER file with my account and the other user was not able to publish the nuget...

he then re-upload the CER to his account and was able to do so. so conclusion is that the ones uploading the nugets need to have the CER files uploaded also

joelverhagen commented 1 week ago

@jmecosta, @glennawatson, @mjcheetham - folks, thank you for your input so far in this issue.

@dlemstra has opened a proposal design to address this NuGet.org limitation. Any input you have for Dirk and our team would be most appreciated over on the proposal PR: https://github.com/NuGet/Home/pull/13791!