[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 https://github.com/NuGet/Home/issues/1882#issuecomment-294603338, 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 https://github.com/NuGet/Home/issues/5260#issuecomment-305361367 (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:

• [x] Verifiable authenticity, not just "authentic because a possibly compromised CA says so".
• [x] PGP/GPG signature infrastructure and open source tools to simplify as well as automate the verification of signatures.
• [x] A simple, free and open source friendly process for creating X.509 certificates.
• [x] 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... :disappointed: 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 :smile: 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 https://github.com/NuGet/Home/issues/1882#issuecomment-294737881, 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.

[c0shea]

In theory, this sounds all well and good. But in practice, I am fearful that this will create a new barrier to entry in the .NET ecosystem. I think for this to work successfully, the proposal must:

• be free and accessible to the masses. Approaches that require the developer to pay for a certificate or similar will not work. Though I personally would cough up the money, not everyone is willing to do so. A "pay-to-play" environment will only alienate potential contributors.
• be easy and integrated into the development process. Microsoft and the NuGet team have made it incredibly easy to create a new package, even more so with .NET Standard, in a matter of a couple simple steps. The only time a developer might need to leave VS is if they are going to nuget.org to upload a package. If additional steps are required that break the developer out of the VS and nuget.org workflow, it's no longer as easy and will quickly become a nuisance. One must also consider that not every developer understands the ins-and-outs of code signing, nor should they need to when they could be focusing on the actual content of their package instead.
• be platform-independent and usable through automated build and CI processes. Those that have setup their project to build using tools like AppVeyor, Travis CI, or VSTS should be able to continue having an end-to-end build and publish solution without the need for manual signing intervention.
• be backwards compatible. If the proposal for signing moves forward, it should apply only to new and updated packages. Authors should not be forced to retroactively sign their published packages or risk having them unpublished. This would be a disservice to the .NET community for the great contributions they've already made.
• work with (or at least not break) other private feeds, such as MyGet and VSTS.

[StephenCleary]

Feature request: a GitHub-specific Certificate Authority.

As long as Authenticode certificates cost money, they will not be adopted by most open-source projects. I recommend developing a free public service that: 1) Has a root signing certificate recognized as an acceptable authority by Nuget.org. 2) Automatically grants private signing certificates to users based on their GitHub authorization.

Running a service like this would cost almost nothing to run on Azure, would allow any open-source project maintainer to sign their packages for free, and would provide Authenticode certificates that positively identify GitHub users.

It would be Let's Encrypt for GitHub.

I'm capable and willing to write the actual service, if Microsoft would sponsor the hosting and include the root cert in Nuget.org's official accepted list.

[clairernovotny]

@StephenCleary I proposed that already, it's against CA/B forum and Windows Root Authority rules. You have to validate legal entities, individuals/organizations only.

[StephenCleary]

But Nuget.org's verification != Windows Root Authority

[clairernovotny]

It chains up to the same thing and the trust comes from there.

[maartenba]

Afraid this may actually be the case now NuGet.org is in effect Microsoft -> https://blog.nuget.org/20170907/Changes-to-NuGet-dot-org-service-management-and-performance-improvements-in-China.html

Think many end users/enterprises will expect Windows Root Authority for all things Microsoft (and .NET).

[StephenCleary]

In that case, package signing is dead in the water. It'll never be widely adopted.

[clairernovotny]

The majority of packages don't have to be signed. This lets projects/organizations that want that extra level of identity do so.

[StephenCleary]

Yes. And library authors will be constantly pestered about it.

Microsoft will start warning consumers about unsigned packages by default, creating a division between those who have corporate sponsorship and those who write libraries out of love.

I see this as a net negative for the .NET community and innovation as a whole, but perhaps it is not.

[pedrolamas]

I'm frankly with @StephenCleary on this one... if this is to fix an issue, it needs to be broadly used, not something to be used just by the ones willing to pay for it.

[clairernovotny]

Here's a question -- why is NuGet any different than what people do today? How many people/orgs Authenticode sign their files? Corporations usually do. Some OSS. Most don't. Why would it be different for NuGet? Why would people suddenly start caring there when they clearly didn't care before?

[pedrolamas]

I guess that question should be put to NuGet and Microsoft, not the open-source community who are only interested in sharing code (packages) with others!

[clairernovotny]

How is this a NuGet/Microsoft question? In that respect, they are following what people are already doing today in this area. Those that care, sign their files, most don't. NuGet is just choosing to provide a mechanism to enable this.

[pedrolamas]

My point is I'm not sure the community actually asked for this! Seems to me - and as you correctly pointed out - this is mostly a feature requested by corporations (to only use signed packages), but in the end will be available publicly and does help to avoid fake packages being submitted to NuGet, so I do see advantages for wider adoption.

What I don't like is the fact that as is stands, it requires developers to spend money on a X.509 certificate.

[jozefizso]

@PedroLamas count me in as community member who wants packages to be signed.

[maartenba]

I think the big issue is in creating "classes" of OSS:

Many would not go with NUnit if they see this. And if I authenticode-sign Newtonsoft.Jsno I'd be happy with a green "TAKE ME, TAKE ME!" mark next to it.

All else about signing is awesome. Those who need it can go all-in and reject/approve certain chains etc. What's not to like there!

[clairernovotny]

The UI isn't the only thing.... corporations may prohibit unsigned packages too, so there is reason for those projects to get signed.

[tomkerkhove]

I'm with @maartenba on this one - Let people sign them, but don't discriminate people that don't.

@onovotny It's a reason but you can't expect them to do that.

[clairernovotny]

An unsigned package can put anything in the package authors section they wanted. I could create a package and list "Microsoft Corporation" as the author and upload it unsigned. The dialog above would show that.

How would someone tell the difference from the package Microsoft created where the package author information came from the certificate instead?

[maartenba]

By only allowing the Microsoft cert chain?

[clairernovotny]

That's drastic. Most people will not be doing only whitelisted certificates (though some corps may). When you're looking at the UI, how do you know which author field value is more trusted and accurate?

[tomkerkhove]

Signing a package doesn't avoid your scenario as well to be honest? Or am I missing something? Verified != Signed.

[clairernovotny]

In a signed package, the UI will use the information in the certificate subject as the author for display instead of the metadata in the package. Verification is for package ID's, signing is for identity of the author.

[StephenCleary]

Signing does identify authorship. It definitely adds value.

I'd just like to see "authorship" also include "this GitHub user", not just "some person who convinced a CA that they are who they say they are". But it's Nuget.org's call whether to allow that or not.

[clairernovotny]

It's really not NuGet's call, it's CA/B forum and the Microsoft Root Authority programs call. I did suggest this back in Feb and @blowdart shot it down hard.

[StephenCleary]

Well, I would expect that to be a fight. Simply put, CAs have a ton of clout, even though they have tons of problems (constantly issuing certs without sufficient validation, disproportionate price for service).

Until Let's Encrypt came along and shook it all up. I'm just still wishing we can do the same for code signing.

[clairernovotny]

@StephenCleary I agree 💯%, and I tried to figure out a way to do this this past winter. Would love it if something like this was possible.

[StephenCleary]

I don't know how Let's Encrypt got past the CA guardians into the root list, but I suspect they've learned from that and will fight to the death to prevent free code-signing certificates.

That said, we could start our own SimpleCA project using scalable tech (Auth0, Key Vault, Blobs/Tables, and Functions should do it). And then once we have a proven, open-source solution, we might be able to talk to Nuget.org.

[blowdart]

Even if nuget suddenly had a CA (which would involve me being hit by a bus first) it would not issue code signing certs, it would issue package signing certs, because there's no way in heck we'd want to grant the ability to get a pass from smartscreen simply because you created a nuget.org account.

[StephenCleary]

That's not what I'm suggesting at all.

What I'm suggesting is that Nuget.org allows package signing using certificates issued by our custom GitHub-CA in addition to regular CAs.

Nuget.org would not manage the custom GitHub-CA. There are people in the community who could do that. It would be best to keep Nuget separate from the CA even if you were willing to do it.

The certificates issued by the custom GitHub-CA could only be used to verify packages. Of course they wouldn't pass SmartScreen; they would only be accepted by Nuget.org.

[clairernovotny]

@StephenCleary the problem there is if they have the right EKU on the cert, not 5 minutes after such a thing existed, would there be a guide and people telling people how to put that "GitHub-CA" root CA cert into their machine's trusted root store, and then smart screen would be impacted.

[StephenCleary]

Ah. Yes, that would be a problem. Not unlike Fiddler. The root cert could have a similar DO_NOT_TRUST disclaimer. :)

[ektrah]

How important is it that this uses X.509 certificates? I mean, what do you really need to know?

• That the package was signed by "CN=Scott Hanselman, O=Microsoft Corporation, L=Redmond, S=Washington, C=US",
• that the package was signed by GitHub user "shanselman",
• that the package was signed by NuGet.org user "shanselman",
• that the package was signed with the key listed in the package's GitHub README, or
• that the package was signed with the same key as the previous version?

The first one is really expensive. The second and third one should be doable. The fourth (manual key pinning) and fifth one (trust on first use) are easy and might be a good starting point ("the simplest thing that could possibly work").

[clairernovotny]

@ektrah The first one is the only one that many large organizations care about. It's really the only independently trustable thing we have today.

Key pinning needs to take renewal into account as certificates expire.

[mavnn]

@onovotny I dispute the fact that the first one is the only one large organizations care about. For example, many large organization trust Debian packages based on PGP/GPG signing.

This is a solved problem in many open source communities: as an open source contributor I cannot see anyway of tying this into the CA system which will not result in a "two class" trust system that excludes the vast majority of open source. Apart from the cost, many OSS authors will be reluctant to use CA based tokens on principle - for example, it effectively cuts out any anonymous contribution of open source.