dotnetjunky wrote:
And I significantly disagree with some of Phil's assertions.
http://coapp.org/news/2013-04-04-Trust-And-Identity.html
And, you'd damn well read Kim Cameron's Laws of Identity: http://www.identityblog.com/?p=352
Having worked in the Digital Identity ecosystem (and authored a book on the subject) I can tell you that this isn't a trivial problem.
To Address specific issues:
Relying on a third-party authentication system significantly weakens trust. What happens when someone's Twitter or SO account is hacked? Worse, what if they go offline? What if they disappear?
This is a direct violation of Law 3 :
JUSTIFIABLE PARTIES -- Digital identity systems must be designed so the disclosure of identifying information is limited to parties having a necessary and justifiable place in a given identity relationship.
Involving an unrelated third party is not acceptable.
And I want to repost the link to Phil's blog about trust in NuGet. This is the NuGet team's stance on the topic of package signing.
http://haacked.com/archive/2013/02/19/trust-and-nuget.aspx
And I significantly disagree with some of Phil's assertions.
http://coapp.org/news/2013-04-04-Trust-And-Identity.html
And, you'd damn well read Kim Cameron's Laws of Identity: http://www.identityblog.com/?p=352
Having worked in the Digital Identity ecosystem (and authored a book on the subject) I can tell you that this isn't a trivial problem.
To Address specific issues:
That said, I see private NuGet servers popping up in enterprises too (mine included), so don't ignore these scenarios where package source identity is probably easier to manage at the server level, and strong naming (spit) doing the grunt work at the package level.Enterprises should be encouraged to issue individual certificates off of a common CA, with which each developer can sign binaries for use inside the organization with. This actually gives a greater degree of trust, since you can track down the individual who actually compiled the binary, and have an effective audit trail.
I want to point out that NuGet today does validate the package file hash before installation to make sure it hasn't been tampered with. Coupled with the fact that we use HTTPS by default, I think we have that concern covered.No. You don't. Who generated the hash? This doesn't provide any ability to ensure that a poisoned package hasn't been inserted at all. Nor does it provide the ability to know specifically who created a package .
What process?One of the fears that keeps getting brought up is that for some reason people view signing as "hard" or "difficult" or "complicated" ... the tools can be built so that this is implicit, and requires zero additional work on the part of the developer, and shouldn't require any significant functionality at the server (since, NuGet packages are very useful even without a server).
Today, nuget.org automatically replaces the Owners field in the nuspec file with the account username of the user who uploads the package. So one way to address this concern is to establish a trust system on the nuget.org website itselfAnd this is a perfect example of tampering with the package. Not Cool.
David Ebbo and Phil Haack suggested relaying on Twitter or StackOverflow. Once we have that system in place, we don't need to sign packages at all.OMFG. NO.
Relying on a third-party authentication system significantly weakens trust. What happens when someone's Twitter or SO account is hacked? Worse, what if they go offline? What if they disappear?
This is a direct violation of Law 3 :
JUSTIFIABLE PARTIES -- Digital identity systems must be designed so the disclosure of identifying information is limited to parties having a necessary and justifiable place in a given identity relationship.
Involving an unrelated third party is not acceptable.
