-
Notifications
You must be signed in to change notification settings - Fork 250
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Feature] Package signing #2577
Comments
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. |
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 |
Also, as @diverdan92 writes in #1882 (comment), I do not think code or package signatures need to be vetted by a CA. As long as the signature can be verified towards a public key and the key is associated with an entity that the package consumer trusts, a CA does not have to be involved. A CA should at least not be required, since the value of package signing is still great if the consumer trusts the publisher by other means, such as Keybase for instance. |
And by this if you mean PGP/GPG signing, you are likely on the right track here. Asking someone to purchase an authenticode certificate to sign a package is going to be a non-starter. Update: GPG and Authenticode both do the same thing. What's great about GPG/PGP is that it is achieved with no cost and it builds on what other package managers have been using for many years. Authenticode is more built-in to Windows and well-known, but it suffers from not being free for real use (you need a central validation place that is trusted to verify identities). We can't underestimate the value of no cost. If you want an approachable ecosystem, folks will need to be able to sign packages for free (forever free). If Microsoft wants to host a CA and provides these Authenticode certificates for no cost, I applaud the idea. To be honest, the cost is really the only thing holding back a recommendation of authenticode over GPG as GPG likely needs more support on Windows than it currently has. I wrote more at #5260 (comment) (notedly the difference between free and even a tiny cost). |
@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. |
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. |
@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. |
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!
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!
Cheap != Free 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. |
@onovotny 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": 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:
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 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. |
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:
Should NuGet choose to use Keybase for this purpose, I would be pretty sure that would affect Keybase's priority of the linked issue. |
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. |
@onovotny Very cool that you are trying to help others with such a solution as your SignService, I already found it last week, but honestly I didn't understand all of it... 😞 at least not currently! I need to wrap my head around some concepts, crypto isn't my primary (by far) knowledge and Azure Key Fault is also new to me. Currently I am blocked from renewing my certificate, as Certum wants to have a cryptographic card while generating the private keys which are needed to create the certificate. This only works, as far as the documentation says, in Internet Explorer.
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. And although I really really really think the subject here, signing packages, is extremely important and needed, it has to be a solution which is feasible for most developers. NuGet packages, are from my point of view, largely created by a community of people who probably don't have the technical knowledge or possibilities (or plainly don't have the time) to handle the process which I am currently going through. (it really used to be easier). Unfortunately, I don't have a solution to that either... @asbjornu I tried to look at https://keybase.io/ to understand what this is, and how this can help us here... but I mostly found "Keybase is a free, open source security app. It's also a public directory of people.". They might help themselves if they add some use-cases to understand 😄 I do see that keybase might be a solution, but for companies who already use code-signing it could be overhead. Maybe the solution would be to support multiple possibilities, side by side? Have solution 1 (keybase?) for OSS (or small companies), and solution 2 (Code-Signing) for increased authentication/security... (if that is the difference) |
@Lakritzator, I wrote a bit about it in #1882 (comment), but I'll repeat it here for brevity:
Please let me know if you still have questions about Keybase. |
@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. |
@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/ |
@mavnn, @StephenCleary about the feature name.
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.
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.
We are not suggesting any package name or file name changes for signed or unsigned packages. |
@StephenCleary about updating
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. |
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
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. |
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.
Windows has
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.
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. |
That's a valid concern, but you even propose a very sensible solution to that problem:
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:
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. |
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) |
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)? |
@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. |
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 |
@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. |
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. |
@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. |
Package signing update: The Package Signing Technical Details spec has been published. First NuGet.exe previews with sign and verification support are available here. |
@rido-min so if we use those signing previews, can we submit packages with them? 😈 |
@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. |
Repository Signatures spec has been published. Use issue #6378 to discuss. |
@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. |
this is done in 4.6 (author signing) & 4.7 (repo signing) |
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.
The text was updated successfully, but these errors were encountered: