12
Vote

Signed Packages

description

One thing we haven't discussed yet is what plans we have for supporting certificate signing packages. As you might recall, OPC has support for signing packages: http://msdn.microsoft.com/en-us/library/aa905326.aspx

Keep in mind, I'm not suggesting we necessarily do this for v1, but we should start talking about it now to flesh out the details. Currently, we plan to follow the community driven moderation approach ala CodePlex and Ruby Gems. But we may want to provide the ability to have support for verifying signed packages for those who want to sign packages.

The question is, why bother? How would the end-user experience be different? One idea that comes to mind is that NuPack might have a "high security" mode, for lack of a better name, that would prompt to install unsigned packages and install signed packages without prompting.

Thoughts?

comments

skoon wrote Oct 7, 2010 at 4:44 AM

One of the big security issues for me is that the packages are based on PowerShell scripts, which means they offer a lot of power. The prospect of a malicious powershell script being included in a package is a red flag to me. It doesn't have to be as malicious as "format c:/", it could be as simple as "parse the web.config and send off any connection information you find" or "create a new SQL server user". Heck even something as simple as "send the IP/hostname/email address of the person who just loaded this package so I can find out who is using my package" has privacy implications.

skoon wrote Oct 7, 2010 at 4:45 AM

Also, think of somebody uploading an "updated" version of NHibernate that includes a backdoor that sends off hostname and connection information to an unknown destination? Sure, the community would catch it eventually but the damage would be done.

Haacked wrote Oct 7, 2010 at 7:27 AM

Well once we have the gallery implementation, onyl the person who uploads a package can update the package. Packages will be associated with accounts.

One concept we'll be looking at as a possibility that Nick Quaranto (project founder of RubyGems.org) pointed me to is the concept of a web of trust: http://en.wikipedia.org/wiki/Web_of_trust

This is the basis upon which Ruby Gems provides its multiple security models: http://docs.rubygems.org/read/chapter/21

We may want to consider a model similar to that. I still need to grok it and other options.

scubamuki wrote Oct 7, 2010 at 7:57 AM

I was thinking the same security issues - see http://nupack.codeplex.com/Thread/View.aspx?ThreadId=229930.

We should be adopting a security first (or at least have it at the forefront of our minds) approach

mr_miles wrote Mar 25, 2011 at 11:22 PM

The powershell elements worry me a lot too. Never mind the signing, I think some option to disable them or identify packages without scripts or prompt that they will be run would be good. 99% of the time.you do want to use them but occasionally not. Particulalry.if you are using the new feature to reconstitute your packages from packages.config : the script may already have been run.

justinc wrote May 23, 2011 at 6:53 PM

Code Signing, meh.

But the powershell issue, that is a good point. Maybe you should make it javascript instead. If we had a node.js like container to add modules you could still give access to the VS api's but in a sandboxed way. Or possibly Lua woudl be better since it is more robust on windows and handles these types of scenarios well. But proper sandboxing is an important thing.

justinc wrote Oct 4, 2011 at 12:48 PM

@clamont both of those issues you linked to seem to have reasonable answers to them. I'm not sure test signing is really going to get you much since most open source projects include the .snk file in their public repository anyway. They're a very minor risk, oh well. Don't install packages while elevated.

DWinx wrote Oct 27, 2011 at 1:03 PM

The question asked was "why bother". The purpose of signing is to identify the source and seal the package, not to establish trustworthiness. Packages with harmful (intentional or unintentional) content could be signed and distributed. It is up to the consumer to decide whether the source can be trusted. One of the ways to verify that the source identity is as it claims to be is by examining the signer's certificate. Signing at the point of origin is the source's only way of saying "I made this". IMO, once a package leaves the point of origin it is susceptible to tampering no matter how trustworthy the carrier (web of trust).

Sign in to add a comment or to set email notifications