[Feature] Package signing

[harikmenon]

Status: Reviewing

The specification is available here:
Package signing

Discussions should happen on this issue. Please link other issues with similar asks to this one.

[jariq]

Are there any details available on this subject? I would be happy to review/comment the design or even take a part in implementation if possible.

[asbjornu]

I'm also very interested in this. What I want it for is to ensure as far as possible that between source code is committed to source control (with a signed Git tag or signed commit) and until it ends up on a production server (with Octopus Deploy), the code can be verified against a signature so it's certain that it hasn't been tampered with.

Using the same key infrastructure to sign both the source control commit as well as the package itself would make tooling and use of the whole thing easiest.

Sidenote: If anything related to this involves the clusterfuck (sorry for being honest here) that is makecert.exe, the whole ordeal, no matter how well architected and designed, is going to fail.

[asbjornu]

Also, as @diverdan92 writes in #1882 (comment), I do not think code or package signatures need to be vetted by a CA. As long as the signature can be verified towards a public key and the key is associated with an entity that the package consumer trusts, a CA does not have to be involved.

A CA should at least not be required, since the value of package signing is still great if the consumer trusts the publisher by other means, such as Keybase for instance.

[ferventcoder]

And by this if you mean PGP/GPG signing, you are likely on the right track here. Asking someone to purchase an authenticode certificate to sign a package is going to be a non-starter.

Update:

GPG and Authenticode both do the same thing. What's great about GPG/PGP is that it is achieved with no cost and it builds on what other package managers have been using for many years. Authenticode is more built-in to Windows and well-known, but it suffers from not being free for real use (you need a central validation place that is trusted to verify identities). We can't underestimate the value of no cost. If you want an approachable ecosystem, folks will need to be able to sign packages for free (forever free). If Microsoft wants to host a CA and provides these Authenticode certificates for no cost, I applaud the idea. To be honest, the cost is really the only thing holding back a recommendation of authenticode over GPG as GPG likely needs more support on Windows than it currently has.

I wrote more at #5260 (comment) (notedly the difference between free and even a tiny cost).

[clairernovotny]

@ferventcoder I very much disagree here. It should not be NuGet's job to validate identity. Authenticode does two things: verify a publisher's identity and ensure integrity of the package. Both are important. A package may be used outside of NuGet.org (think private feeds, MyGet, etc) and there has to be a standard way of attaching an identity to a package. CA's already have that trust path and have the infrastructure to validate documentation. It's not something that should be re-invented IMO.

There are cheap CA's for OSS projects like Certum. Foundation's can help too. Projects that are members of the .NET Foundation get access to code signing certificates.

[ferventcoder]

Hi @onovotny - I updated my response above. I don't think we disagree at all, in fact I think we agree with each other. PGP/GPG and Authenticode do very much the same thing in this situation.

[asbjornu]

@onovotny: Perhaps Authenticode is a solution. I've never heard about it before and the first relevant hit I found on Google was this archived article about Authenticode and DirectX in Internet Explorer which makes me want to tear my eyes out. Anyway, I do think we all agree on the overall architecture, although we might disagree on the exact implementation. One thing to keep in mind is that this needs to work on all platforms; Authenticode seems to be very Windows specific.

@ferventcoder has mentioned PGP/GPG and I've mentioned Keybase, which is basically an extension of PGP/GPG. I agree with @ferventcoder that signing should be free and I want to add that there's no true value in having a CA issued certificate. At least not to me. I actually trust that this is indeed Scott Hanselman more than I would trust a CA issued certificate claiming to represent him.

[pedrolamas]

@onovotny

Authenticode does two things: verify a publisher's identity and ensure integrity of the package. Both are important. A package may be used outside of NuGet.org (think private feeds, MyGet, etc) and there has to be a standard way of attaching an identity to a package.

Nothing stops NuGet of allowing users to just go to the website, logging in to their account, and then specifying their public PGP/GPG key(s).

This is something that GitHub already does with great success!

CA's already have that trust path and have the infrastructure to validate documentation. It's not something that should be re-invented IMO.

PGP/GPG has been around long enough to be a solid and credible alternative, no one is "re-inventing" anything here!

Ubuntu package manager (apt-get stuff) uses GPG signing, so I guess we can assume this is quite safe to use here also!

There are cheap CA's for OSS projects like Certum. Foundation's can help too. Projects that are members of the .NET Foundation get access to code signing certificates.

Cheap != Free

On a side note: I'm not a mac/unix user, but how well does Authenticode actually work there? Just a thought...

[clairernovotny]

On a side note: I'm not a mac/unix user, but how well does Authenticode actually work there? Just a thought...

I was just describing what Authenticode does and how it uses x509 certificates. I'm not suggesting that Authenticode necessarily be used as it's just one implementation of code signing. There are others too, including XmlDSig that Open Packaging uses (Office docs, VSIX). One of those may be better suited.

[Lakritzator]

@onovotny
From a technical perspective I also agree that code signing with certificates also the "best" solution, as it doesn't add another technology.. some people already must use this for their assemblies, why not use it for the nuget packages too.

I agree that in the mean time, the price for a certificate is quite low and I myself don't see a direct problem with paying that price. The main problem is not the price itself, it's the process.

It used to be "easy":
https://blog.aluxian.com/free-code-signing-certificate-for-open-source-software-d836270823a7
Except for the fact that you need to be a company, as you need a VAT ID, which is not possible or easy for some open source developers.

I have used a Certum certificate to sign Greenshot for the last year, and now I need to renew my certificate. There are currently two problems:

• Certum doesn't seem to understand my english emails, the support is therefor extremely hard.
• The signing process (in general, this is not related directly to Certum) was changed, one now needs hardware to sign (which adds another ~100$ to the price). Here is a blog on the change which should be active since Feb. 2017:
  https://casecurity.org/2016/12/08/leading-certificate-authorities-and-microsoft-introduce-new-standards-to-protect-consumers-online/

I currently don't understand how I can make automated builds, for instance on AppVeyor, which sign my product (greenshot installer or nuget packages) with using a Cryptographic card.

This in all makes it quite hard, and having such a requirement might make it impossible for some projects to publish to nuget.org.

Maybe the .NET foundation can somehow help here?

P.S.
I still don't have a working certificate, as I don't have supported hardware and the support of Certum can't / doesn't answer my questions. I considered moving to Comodo but the process there is also quite hard (which is in fact also a good thing...)

[jozefizso]

I wanted to get authenticode from Certum for my open source projects. Unfortunately their shopping cart did not work at the time and they increased the price and require hardware to sign applications. And Certum support is useless.

Money is not a concern for the authenticode certificate. It's the process to get one which makes it hard. No other CA provides certificates for open source entities.

[asbjornu]

If package signing is going to require X.509 certificates, it still feels like no CA can fulfil the requirements of the NuGet community, since CA issued certificates serve a completely different – although overlapping – utility than signing software packages.

If keybase/keybase-issues#387 is implemented, I'd say that Keybase is the undeniably best solution for all of the problems package signing is attempting to solve, including the issuance of X.509 certificates. Keybase would then cover:

• Verifiable authenticity, not just "authentic because a possibly compromised CA says so".
• PGP/GPG signature infrastructure and open source tools to simplify as well as automate the verification of signatures.
• A simple, free and open source friendly process for creating X.509 certificates.
• X.509 certificate hosting.

Should NuGet choose to use Keybase for this purpose, I would be pretty sure that would affect Keybase's priority of the linked issue.

[clairernovotny]

In general, an OSS project that does not have a legal entity/foundation behind it would need to get a certificate in the name of one of the individuals involved. Many/most? CA's issue CS certs to both individuals and legal organizations. An OSS project is either one of those...if it's not an incorporated entity, then it has to be an individual.

That said, and I don't know about Certum, if they let you submit a CSR, but you can use an Azure Key Vault HSM to hold a code signing key and sign stuff. I've been working hard to get this all working and it does now. There's a code signing service you can set up for yourself that can be used in a CI build (https://github.com/onovotny/SignService). It orchestrates several tools and adds Key Vault support.

With DigiCert, as an example, you can provide a CSR for a CS cert request. That CSR can come from a Key Vault HSM certificate. DigiCert can then validate and issue the cert from that. I'm trying to make that part more automated.

[Lakritzator]

@onovotny
I don't know about all CA's, but fortunately Certum can issue certs for individuals, if you are willing to jump through all the hoops. The process costed me multiple hours, that was last year!

Very cool that you are trying to help others with such a solution as your SignService, I already found it last week, but honestly I didn't understand all of it... 😞 at least not currently! I need to wrap my head around some concepts, crypto isn't my primary (by far) knowledge and Azure Key Fault is also new to me.

Currently I am blocked from renewing my certificate, as Certum wants to have a cryptographic card while generating the private keys which are needed to create the certificate. This only works, as far as the documentation says, in Internet Explorer.
I finally got a response on my question which cards are supported, and got this list of working cryptograpic cards:

• Szafir card
• CenCert card
• EiroCert card
• Sigillum card

If I, with limited knowledge of CA/CSR and Certificates, understand it correctly this means that I cannot use Azure Key Vault during the Certum certificate activation process (maybe later?).

Anyway I just wanted to stress out the fact that it's very hard for people who don't really know these things to satisfy such a complex process like getting a code-signing certificate.
In the mean time, I already spent a larger part of a day in a period of 2 weeks, to get my certificate! (and still don't have it). If I finally manage to get it, I need to figure out how to satisfy the new standards for CS which are in effect since February 1, 2017.

And although I really really really think the subject here, signing packages, is extremely important and needed, it has to be a solution which is feasible for most developers. NuGet packages, are from my point of view, largely created by a community of people who probably don't have the technical knowledge or possibilities (or plainly don't have the time) to handle the process which I am currently going through. (it really used to be easier). Unfortunately, I don't have a solution to that either...

@asbjornu I tried to look at https://keybase.io/ to understand what this is, and how this can help us here... but I mostly found "Keybase is a free, open source security app. It's also a public directory of people.". They might help themselves if they add some use-cases to understand 😄 I do see that keybase might be a solution, but for companies who already use code-signing it could be overhead. Maybe the solution would be to support multiple possibilities, side by side? Have solution 1 (keybase?) for OSS (or small companies), and solution 2 (Code-Signing) for increased authentication/security... (if that is the difference)

[asbjornu]

@Lakritzator, I wrote a bit about it in #1882 (comment), but I'll repeat it here for brevity:

To the uninformed, Keybase is a website on which you upload your public keys and verify your account by posting strings of privately signed stuff on social media. Keybase then reads your tweets etc. containing these strings and verifies them against the hosted signatures.

It avoids using a CA and with what we've seen from Symantec and the likes lately, I trust Keybase's verification more than many CA's.

Please let me know if you still have questions about Keybase.

[anangaur]

Is the signing certificate linked to an individual, or is it also possible to get a certificate (or whatever) for a team?

@Lakritzator The term team can be interpreted in multiple ways:

If you are talking about a team in a company, then companies can get a certificate and that can be used.

If team means a group of NuGet.org users co-owning a package, then either of the co-owners' certificate can be used.

However, I am not sure if a group of people identifying as an entity (team) without being a public company can get a cert. This may depend on CA companies' policies.

[clairernovotny]

@vcsjones just posted a blog explaining his analysis on why x509 currently works better than PGP for the stated goals of NuGet: https://vcsjones.com/2017/09/18/nuget-package-signing/

[rido-min]

@mavnn, @StephenCleary about the feature name.

I also have a strong recommendation: let's not use the "signed"/"signing" terminology for package signing. E.g., use "package verification" or something like that exclusively.

I agree package singing can be confusing as signing itself is an overloaded word. However there some historical context where everyone refers to this feature as Package Signing and I continued with the same name.

I think a lot of people will confuse this will strong-name signing

This feature is about protecting the package as a whole, without setting any requirements on its content, for example strong named assemblies or Authenticode. We will make sure to use the right terms to avoid this confusion.

package naming convention for "X.Signed"

We are not suggesting any package name or file name changes for signed or unsigned packages.

[rido-min]

@StephenCleary about updating

Does this affect backwards compatibility at all? I.e., will the client tooling ever assume that since 1.1.0 is signed, that 1.1.1 must be signed as well? I'm thinking of a scenario where an OSS project loses corporate funding and thus its certificate, so 1.1.1 would be unsigned.

Client policies comes into play in Stage 3. Even at that point, the default behavior will not block the unsigned package version as stated in the above scenario. Only in the Secure Mode the client will always require signed packages.

[asbjornu]

@onovotny:

@vcsjones just posted a blog explaining his analysis on why x509 currently works better than PGP for the stated goals of NuGet: https://vcsjones.com/2017/09/18/nuget-package-signing/

Much of @vcjones' premise for debunking GPG/PGP is that the tooling is bad. As he doesn't mention Keybase, I assume he's never tried it. Keybase's tooling is good. With Microsoft's support, the tooling could become awesome.

I also find it a bit ironic to bash GPG/PGP tooling on Windows when the X.509 tooling Windows has is makecert.exe. Windows might have good tooling, but not for the command line. At least not for X.509 certificates. And arguments like these:

This is harder for individuals. Do I put my public key on my website? Does anyone know if vcsjones.com is really operated by someone named Kevin Jones? What if I don’t have HTTPS on my site - would you trust the key that you found there?

Are pretty much void given the existence of Keybase. With Keybase, you verify your account with just about any online service in existence. Facebook, Twitter, Reddit, HackerNews, Github, your own web site — you name it.

[vcsjones]

Much of @vcjones' premise for debunking GPG/PGP is that the tooling is bad. As he doesn't mention Keybase, I assume he's never tried it. Keybase's tooling is good.

I have. I do not agree. Tooling aside I don't think PGP is well understood by organizations, which frankly in my mind is the primary audience for consuming signed packages.

I also find it a bit ironic to bash GPG/PGP tooling on Windows when the X.509 tooling Windows has is makecert.exe.

Windows has certreq for enterprise enrollments or self-signed certificates, or PowerShell New-SelfSignedCertificate. But sure. I'll assume since you did not mention them that you have tried them.

With Keybase, you verify your account with just about any online service in existence. Facebook, Twitter, Reddit, HackerNews, Github, your own web site — you name it.

Which is my point, and I'm sorry if that didn't come across in the post. It validates an account holder (which I tried to explain with GitHub). There is nothing stopping me from making a Facebook account with someone else's name. There is a much better, but not infallible, chance that the name on the certificate is correct with x509 PKI.

bash GPG/PGP

That wasn't my intent. I tried not to come across as a snob in the post, but I do use PGP on MacOS every day for signing git commit messages. Perhaps I put too much effort in discussing the tooling when much of my concern around PGP is that there it is decentralized.

[asbjornu]

Perhaps I put too much effort in discussing the tooling when much of my concern around PGP is that there it is decentralized.

That's a valid concern, but you even propose a very sensible solution to that problem:

We do get some value from PGP if we are willing to accept that signatures are not tied to a human being, but rather a NuGet.org account.

A generic solution that ties into an account with the origin server of the package is very sensible and does not exclude private NuGet servers, MyGet, or similar as you state:

That means signing is tied to NuGet.org and couldn’t easily be used with a private NuGet server or alternative non-Microsoft server.

It just requires the solution to be generic; to connect the origin server and accounts within it. Is that a problem? If it is, I don't see it.

[rido-min]

Spec Update: After additional feedback, we have decided to do not show any visual indicator for signed packages in the Package Manager UI. (To discuss this specific feature please use #5889 issue)

[hach-que]

What impact does this have for alternative implementations of NuGet packaging such as Protobuild? Is the signing code going to require pulling a whole bunch of dependencies (we need to ship a single executable)?

[rido-min]

@hach-que We will publish the signature format specification for 3rd party nuget providers, and you can choose to implement the sign and verify features.

We will start using .NET framework and Windows API's to implement the feature. The distribution model for Windows will be similar to what we have today based on a singe .EXE file.

Later we will provide a cross platform implementation based on dotnet core.

[maartenba]

Seeing so many PR's right now in both the client and the gallery that involve signing, yet the spec still says "reviewing". What is the real status of the spec? Is there anything known about what is going to be implemented? (given all of the PR's I see also throw new NotImplementedException(); all around)

[rido-min]

@maartenba . Package signing is a complex feature that require multiple specs. The master spec Package signing contains links to related specs, and each of them is being reviewed (I've just changed the status of the CLI Sign and Verify specs), but the master spec will be "in review" for a while until we complete specs for Stage 2 and Stage 3.

The signature technical details spec will be published soon. In the meanwhile we are making good progress in other areas with fake or dummy implementations until we got the final Sign API available.

[rdreher]

I'm relatively new to NuGet and it's concept of signing, but I wondering if the design proposed by The Update Framework (TUF) [https://github.com/theupdateframework/tuf] was taken into consideration.
Both Python and Ruby package managers implement TUF for content verification. The same approach is used by Docker for content trust on images.

[rido-min]

@rdreher yes, we considered TUF. This approach is focused mainly on verifying package integrity on different mirrors but do not address how to perform offline verification.

[rido-min]

Package signing update: The Package Signing Technical Details spec has been published. First NuGet.exe previews with sign and verification support are available here.

[clairernovotny]

@rido-min so if we use those signing previews, can we submit packages with them? 😈

[rido-min]

@onovotny NuGet.org is not accepting signed packages (yet). If you submit a signed package you will see a validation failure. We will announce when NuGet.org starts accepting signed packages.

[rido-min]

Repository Signatures spec has been published. Use issue #6378 to discuss.

[jainaashish]

@rido-min please take care of this issue, if this is already done or being tracked as part of other specific issue then close this.

[rohit21agrawal]

this is done in 4.6 (author signing) & 4.7 (repo signing)