search

NuGet / Home

Repo for NuGet Client issues
Other
1.5k stars 252 forks source link

[Feature] Package signing #2577

Closed harikmenon closed 6 years ago

harikmenon commented 8 years ago

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.

Lakritzator commented 7 years ago

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 commented 7 years ago

@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 commented 7 years ago

@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 commented 7 years ago

@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 commented 7 years ago

@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 commented 7 years ago

@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 commented 7 years ago

@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 commented 7 years ago

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 commented 7 years ago

@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 commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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

clairernovotny commented 7 years ago

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 commented 7 years ago

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:

image

Let me share my personal subjective feeling about the icons:

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:

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

c0shea commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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

From the OSS side:

From the "consumer" side:

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

mavnn commented 7 years ago

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 commented 7 years ago

@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 commented 7 years ago

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 commented 7 years ago

@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 commented 7 years ago

@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 commented 7 years ago

@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 commented 7 years ago

@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 commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

@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 commented 6 years ago

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 commented 6 years ago

@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 commented 6 years ago

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 commented 6 years ago

@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 commented 6 years ago

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 commented 6 years ago

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

rido-min commented 6 years ago

@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 commented 6 years ago

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

jainaashish commented 6 years ago

@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 commented 6 years ago

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