Home: [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.

[Lakritzator]

This discussion is very interesting, and although I currently don't have an good ideas to solve it I just wanted to add some information.

Currently an Open-Source Code Signing Certificate costs 28€ per year (last year it was ~17€):
https://en.sklep.certum.pl/data-safety/code-signing-certificates/open-source-code-signing-929.html
From my point of view, this is an acceptable price especially as it's not needed by everyone (but there are people who have less...) Additionally one needs a specific Smart-Card (USB stick), this costs a lot more...

Another issue is the amount of work one has to invest, to get things working. Especially with the new rules which where introduced this year. I don't really know how I can sign something on my CI-Server (which might be a container) when I need to have the certificate on an USB stick? (is Azure AD Managed Service Identity an accepted solution?)

Here are some related discussions:
https://stackoverflow.com/questions/45971536/generating-code-signing-certificate-without-smart-card
https://blog.thecybershadow.net/2013/08/22/code-signing/
https://blog.aluxian.com/free-code-signing-certificate-for-open-source-software-d836270823a7

But the biggest problem I had, is that (as far as I understood) there was no way to buy an Open Source Certificate from Certum without having an VAT number, which is only available to companies... this means even if individuals want to pay the price, they can't.

What I wanted to say, whatever direction you want to go, it needs to be something which can be implemented by the masses and especially individuals.

P.S.
Another thing, what bothers me slightly, GitHub is mentioned as CA... was this just an example, or what about other git providers like BitBucket, Gitlab etc...?

[clairernovotny]

@Lakritzator For the specific issue of CI builds, I have a code signing service that you can deploy for that: https://github.com/onovotny/SignService. It supports certificates in Azure Key Vault's HSM, and that's a FIPS compliant device suitable for EV code signing certificates (I have mine in there).

[Lakritzator]

@onovotny Yes, you are right, I almost forgot 👍 I will really need to put some time in that as it looks very promising! But I didn't get my certificate renewed yet, as Certum still forces you to have one in the activation / renew process.. and the one I bought wasn't supported 😢

P.S.
Cake support, or maybe an example, will save me some time 😈

[clairernovotny]

@Lakritzator Cake itself is using it:
https://github.com/cake-build/cake/blob/develop/build.cake#L304-L351

I'm not sure if it's possible for Certum to issue a certificate to Key Vault. You have two options for that:

For a non EV cert, without an HSM requirement, if you can get a PFX you can import it into Key Vault. For an EV cert, or ones that will only be issued to an HSM, you can generate the certificate signing request (CSR) with a keyType of RSA-HSM and then submit that to your CA. I don't know if Certum supports that method, but others do.

[StephenCleary]

@Lakritzator I'm just using GitHub as an example for what I call the GitHub-CA. It would be a general-purpose OSS-CA that could support multiple forms of authentication. I just mentioned GitHub because I've done GH authentication before and they're one of the most popular OSS sources. So they'd probably be the first credentials supported; but yes, it is intended to be a general-purpose OSS-CA.

[asbjornu]

@StephenCleary:

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".

That's exactly what Keybase does. Keybase is the "GitHub-specific Certificate Authority" you ask for. I've attempted to explain what it is and would provide NuGet with in this thread, specifically this comment: https://github.com/NuGet/Home/issues/2577#issuecomment-323184243

Please read what I've written, but more importantly; try the service out. Everything behind the scenes is afaik open source and I believe Microsoft's involvement in the project would be highly appreciated.

Yes, a LetsEncrypt-ish service would be good, but not better than what is already provided by Keybase. Their verification process is much better than any CA's, imho.

[pedrolamas]

@asbjornu I use Keybase, seems to me it does a pretty good job!

Plus, its free for everyone and supports GnuPG, which is available cross-platform today and not just on "stage 3" as per this post...

[ektrah]

I think it should be possible to link NuGet packages to GitHub accounts (or BitBucket, Gitlab, ...) without needing to get a third party involved. I've put a very rough proposal here.

[asbjornu]

@ektrah: Keybase already does this. Please have a look at my profile. The GitHub icon there points to this gist, which proves to Keybase that I'm the owner of the GitHub account. That verification method can be repeated on every online system in existence to increase the authority of a user and confidence to consumers of that user's published artifacts (such as a NuGet package, if it had Keybase support).

[ektrah]

I just wanted to point out that it could be done without Keybase if desired, not that Keybase is a bad idea. What would be needed to get Keybase support into NuGet?

Interesting problem: How do we prevent someone from revoking/expiring their key and break the Internet?

[clairernovotny]

Interesting problem: How do we prevent someone from revoking/expiring their key and break the Internet?

That's what time stamping is for. Revocations are for a certain time and after. Code signed before the revocation are usually considered valid.*

*There are exceptions to this.

[ektrah]

But where do get the certificate from if the package owner decides to rage quit?

[clairernovotny]

Huh? How would that matter? You wouldn't have access to upload the NuGet package or commit to the repo either? You'd probably fork and rename...?

[jariq]

I am very happy that package signing is finally getting some attention and so far everything looks good to me except the UI presented in the wiki. I agree with @maartenba that current UI draft is creating the feeling there are "classes" of packages:

---

---

Let me share my personal subjective feeling about the icons:

• EntityFramework is the "wooow-this-must-be-the-best" package.
• jQuery and bootstrap are both "I-am-not-sure-what-that-means-but-it-must-be-good-because-it-is-green-or-blue" packages
• HtmlAgilityPack is the "second-class-citizen" package
• Wait! Are there any other icons? "spends-another-hour-browsing-nuget-gallery-searching-for-other-icon-combinations"

I usually approach similar problems by "simply-stating-the-facts"^TM. Instead of using fancy icons I present all "boolean variables" to the user in a plain text form:

---

EntityFramework
Author is verified: yes
Package is signed: yes

HtmlAgilityPack
Author is verified: no
Package is signed: no

jQuery
Author is verified: yes
Package is signed: no

bootstrap
Author is verified: no
Package is signed: yes

---

I am not saying it is the best solution to the presented problem but IMO this kind of representation:

• does not penalize package authors who are not verified or does not use package signing
• does not encourage package users to judge the quality of package by the number or color of the icons displayed next to the package name
• shows full list of "boolean variables" so users don't need to guess if there are any other combinations
• allows NuGet team to introduce any number of additional "boolean variables" in the future

Please reconsider the decision to use those icons in NuGet user interfaces.

[c0shea]

I might be remembering wrong but I thought the blue checkmark icon currently represents that the package is installed.

I do agree that having icons like that would divide the community. I'm not a fan.

[StephenCleary]

I have a question re the package signing proposal that I couldn't find an answer to in the Wiki:

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.

Also, we'll need to keep in mind the (probably too common) scenario of OSS devs checking in their private key for 1.1.0, and then having to revoke it and reissue a 1.1.1 release with a different certificate. In this case, 1.1.0 and 1.1.1 would be signed by different certs.

[StephenCleary]

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 think a lot of people will confuse this will strong-name signing (just look at how much strong-name signing is confused with Authenticode signing today - and the only reason that isn't a huge problem is because the .NET community pretty much ignores Authenticode).

E.g., there's already lots of articles out there recommending OSS devs to check their signing keys into source control. If we call this new feature "package signing", then checking their package signing keys into source control will be a common mistake. I expect it'll be a lot of work for the .NET community tech leaders to explain "yes, you should check in your strong-name signing keys into source control, but not your package signing keys". Over and over and over again. Whereas, if we call it "package verification", then the distinction becomes clearer: "you should check in your strong-naming keys into source control, but not your package verification keys".

Also, there's already a package naming convention for "X.Signed" - that refers to strong-name signing, Using a different term for package signing makes it clear that consumers do not need "X.Signed" to get a "verified package".

[Lakritzator]

Is the signing certificate linked to an individual, or is it also possible to get a certificate (or whatever) for a team? Can I as an individual get multiple certificates, for different projects I work on?

[mavnn]

So, I've been thinking thoughts about this all weekend (thanks guys!), and I'll try and condense them here.

From the OSS side:

• most OSS projects are not organizations in the formal sense of the word; they have no legal existence, no shared budget, possibly not even a website
• many OSS authors do not particularly trust the CA system
• there are many OSS projects which could not acquire a CA signed X.509 cert anyway (see first point)
• there are existing patterns for signing packages out there which are trusted in the OSS community (gpg, for example)

From the "consumer" side:

• many consumers (including large enterprises) trust a variety of key signing strategies already - anyone who uses Debian/Ubuntu is trusting gpg, for example
• I actively want to be able to use the best OSS projects, not the ones with the most money / an established legal presence
• I want as many packages as possible to be signed, because in many situations it only matters if all of my dependencies as signed; some being signed and others not doesn't really give me much

The intersection of the two lists leads me to these conclusions:

• Using CA signed certs for "trust" in nuget would be a disastrous move that would void much of the point of this exercise, as very few OSS projects will end up being signed
• Package signing is a valid goal, and I agree that this work being done is important
• Not using GPG/PGP seems like NIH syndrome, to be totally honest
• It would be nice to either provide (via nuget.org) or recommend (via things like keybase) some tooling around the "web of trust" to make trusting packages easier

[mavnn]

Also: good point from @StephenCleary - signing is already a very overloaded term in the .net build space. I don't know what a better name is, but his concerns are very valid.

[rido-min]

@maartenba, @StephenCleary and @PedroLamas:
NuGet.org will not require signed packages, and by default NuGet client will not warn or block users when installing unsigned packages from NuGet.org.

We have prioritized X.509 certificates over other PKI systems because it's widely used across platforms, and has excellent support in Windows and .NET.  We are evaluating other PKI approaches (like PGP), and how these will fit in our scenarios.

This is a security feature, and the visual indicators are the easiest way to communicate to package consumers which packages are digitally signed, so that they can make better decisions about which packages to install. Think about it as the green lock in the browser for SSL requests. At the end, it’s a user decision.

[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)