[Feature] Package signing #2577

Closed
harikmenon opened this Issue Apr 16, 2016 · 91 comments

Comments

@harikmenon

harikmenon commented Apr 16, 2016

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.

@harikmenon harikmenon self-assigned this Apr 16, 2016

@harikmenon harikmenon added this to the 3.6 Beta milestone Apr 16, 2016

@harikmenon harikmenon removed this from the 3.6 Beta milestone Apr 19, 2016

@jariq

This comment has been minimized.

Show comment
Hide comment
@jariq

jariq Apr 17, 2017

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.

jariq commented Apr 17, 2017

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

This comment has been minimized.

Show comment
Hide comment
@asbjornu

asbjornu Apr 18, 2017

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.

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

This comment has been minimized.

Show comment
Hide comment
@asbjornu

asbjornu Apr 18, 2017

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.

asbjornu commented Apr 18, 2017

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

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

@ferventcoder

This comment has been minimized.

Show comment
Hide comment
@ferventcoder

ferventcoder Jun 1, 2017

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 commented Jun 1, 2017

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

@onovotny

This comment has been minimized.

Show comment
Hide comment
@onovotny

onovotny Jun 1, 2017

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

onovotny commented Jun 1, 2017

@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

This comment has been minimized.

Show comment
Hide comment
@ferventcoder

ferventcoder Jun 1, 2017

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.

ferventcoder commented Jun 1, 2017

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

This comment has been minimized.

Show comment
Hide comment
@asbjornu

asbjornu Jun 8, 2017

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

asbjornu commented Jun 8, 2017

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

@karann-msft karann-msft assigned anangaur and unassigned harikmenon Aug 9, 2017

@karann-msft karann-msft changed the title from Package signing to [Feature] Package signing Aug 9, 2017

@PedroLamas

This comment has been minimized.

Show comment
Hide comment
@PedroLamas

PedroLamas Aug 11, 2017

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

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

@onovotny

This comment has been minimized.

Show comment
Hide comment
@onovotny

onovotny Aug 11, 2017

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.

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

This comment has been minimized.

Show comment
Hide comment
@Lakritzator

Lakritzator Aug 16, 2017

@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:

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

Lakritzator commented Aug 16, 2017

@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:

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

This comment has been minimized.

Show comment
Hide comment
@jozefizso

jozefizso Aug 16, 2017

Contributor

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.

Contributor

jozefizso commented Aug 16, 2017

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

This comment has been minimized.

Show comment
Hide comment
@asbjornu

asbjornu Aug 16, 2017

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.

asbjornu commented Aug 16, 2017

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.

@onovotny

This comment has been minimized.

Show comment
Hide comment
@onovotny

onovotny Aug 16, 2017

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.

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

This comment has been minimized.

Show comment
Hide comment
@Lakritzator

Lakritzator Aug 17, 2017

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

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

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

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

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

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

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

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

Lakritzator commented Aug 17, 2017

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

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

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

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

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

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

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

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

@asbjornu

This comment has been minimized.

Show comment
Hide comment
@asbjornu

asbjornu Aug 17, 2017

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

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

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

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

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

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

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

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

@c0shea

This comment has been minimized.

Show comment
Hide comment
@c0shea

c0shea Aug 27, 2017

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.

c0shea commented Aug 27, 2017

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.

@rido-min rido-min self-assigned this Sep 14, 2017

@StephenCleary

This comment has been minimized.

Show comment
Hide comment
@StephenCleary

StephenCleary Sep 15, 2017

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.

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.

@onovotny

This comment has been minimized.

Show comment
Hide comment
@onovotny

onovotny Sep 15, 2017

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

onovotny commented Sep 15, 2017

@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

This comment has been minimized.

Show comment
Hide comment
@StephenCleary

StephenCleary Sep 15, 2017

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

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

@onovotny

This comment has been minimized.

Show comment
Hide comment
@onovotny

onovotny Sep 15, 2017

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

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

@maartenba

This comment has been minimized.

Show comment
Hide comment
@maartenba

maartenba Sep 15, 2017

Contributor

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

Contributor

maartenba commented Sep 15, 2017

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

This comment has been minimized.

Show comment
Hide comment
@StephenCleary

StephenCleary Sep 15, 2017

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

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

@onovotny

This comment has been minimized.

Show comment
Hide comment
@onovotny

onovotny Sep 15, 2017

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

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

@StephenCleary

This comment has been minimized.

Show comment
Hide comment
@StephenCleary

StephenCleary Sep 15, 2017

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.

StephenCleary commented Sep 15, 2017

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.

@ektrah

This comment has been minimized.

Show comment
Hide comment
@ektrah

ektrah Sep 15, 2017

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?

ektrah commented Sep 15, 2017

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?

@onovotny

This comment has been minimized.

Show comment
Hide comment
@onovotny

onovotny Sep 15, 2017

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.

onovotny commented Sep 15, 2017

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

This comment has been minimized.

Show comment
Hide comment
@ektrah

ektrah Sep 15, 2017

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

ektrah commented Sep 15, 2017

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

@onovotny

This comment has been minimized.

Show comment
Hide comment
@onovotny

onovotny Sep 15, 2017

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

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

This comment has been minimized.

Show comment
Hide comment
@jariq

jariq Sep 16, 2017

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:

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

jariq commented Sep 16, 2017

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:

  • 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

This comment has been minimized.

Show comment
Hide comment
@c0shea

c0shea Sep 17, 2017

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.

c0shea commented Sep 17, 2017

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

This comment has been minimized.

Show comment
Hide comment
@StephenCleary

StephenCleary Sep 17, 2017

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.

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

This comment has been minimized.

Show comment
Hide comment
@StephenCleary

StephenCleary Sep 17, 2017

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

StephenCleary commented Sep 17, 2017

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

This comment has been minimized.

Show comment
Hide comment
@Lakritzator

Lakritzator Sep 17, 2017

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?

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

This comment has been minimized.

Show comment
Hide comment
@mavnn

mavnn Sep 18, 2017

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 commented Sep 18, 2017

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

This comment has been minimized.

Show comment
Hide comment
@mavnn

mavnn Sep 18, 2017

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.

mavnn commented Sep 18, 2017

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

This comment has been minimized.

Show comment
Hide comment
@rido-min

rido-min Sep 18, 2017

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

@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

This comment has been minimized.

Show comment
Hide comment
@anangaur

anangaur Sep 18, 2017

Member

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.

Member

anangaur commented Sep 18, 2017

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.

@onovotny

This comment has been minimized.

Show comment
Hide comment
@onovotny

onovotny Sep 18, 2017

@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/

@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

This comment has been minimized.

Show comment
Hide comment
@rido-min

rido-min Sep 18, 2017

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

@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

This comment has been minimized.

Show comment
Hide comment
@rido-min

rido-min Sep 18, 2017

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

@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

This comment has been minimized.

Show comment
Hide comment
@asbjornu

asbjornu Sep 18, 2017

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

@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

This comment has been minimized.

Show comment
Hide comment
@vcsjones

vcsjones Sep 18, 2017

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.

vcsjones commented Sep 18, 2017

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

This comment has been minimized.

Show comment
Hide comment
@asbjornu

asbjornu Sep 19, 2017

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.

asbjornu commented Sep 19, 2017

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.

@karann-msft karann-msft referenced this issue in NuGet/Announcements Sep 22, 2017

Open

Author Package Signing #6

@rido-min

This comment has been minimized.

Show comment
Hide comment
@rido-min

rido-min Oct 9, 2017

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)

rido-min commented Oct 9, 2017

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

This comment has been minimized.

Show comment
Hide comment
@hach-que

hach-que Oct 12, 2017

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

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

This comment has been minimized.

Show comment
Hide comment
@rido-min

rido-min Oct 12, 2017

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

@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

This comment has been minimized.

Show comment
Hide comment
@maartenba

maartenba Nov 14, 2017

Contributor

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)

Contributor

maartenba commented Nov 14, 2017

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

This comment has been minimized.

Show comment
Hide comment
@rido-min

rido-min Nov 14, 2017

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

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

@ridomin ridomin referenced this issue in NuGetPackageExplorer/NuGetPackageExplorer Nov 22, 2017

Closed

Support Package Signing #248

@rdreher

This comment has been minimized.

Show comment
Hide comment
@rdreher

rdreher Dec 1, 2017

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.

rdreher commented Dec 1, 2017

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

This comment has been minimized.

Show comment
Hide comment
@rido-min

rido-min Dec 1, 2017

@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 Dec 1, 2017

@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

This comment has been minimized.

Show comment
Hide comment
@rido-min

rido-min Dec 8, 2017

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 commented Dec 8, 2017

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

@onovotny

This comment has been minimized.

Show comment
Hide comment
@onovotny

onovotny Dec 8, 2017

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

onovotny commented Dec 8, 2017

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

@rido-min

This comment has been minimized.

Show comment
Hide comment
@rido-min

rido-min Dec 8, 2017

@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 Dec 8, 2017

@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

This comment has been minimized.

Show comment
Hide comment
@rido-min

rido-min Jan 3, 2018

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

rido-min commented Jan 3, 2018

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

@zhili1208 zhili1208 added this to the Backlog milestone Jan 10, 2018

@jainaashish jainaashish modified the milestones: Backlog, 4.7 Feb 1, 2018

@jainaashish

This comment has been minimized.

Show comment
Hide comment
@jainaashish

jainaashish Feb 1, 2018

Contributor

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

Contributor

jainaashish commented Feb 1, 2018

@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 comment has been minimized.

Show comment
Hide comment
@rohit21agrawal

rohit21agrawal Apr 4, 2018

Contributor

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

Contributor

rohit21agrawal commented Apr 4, 2018

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment