On 2013-11-04 03:00, Gershom Bazerman wrote:
On various topics:
Security is a multifaceted beast with many related issues, depending on which attack vectors we're concerned about, with what degree of assurance.
Ultimately, we rely on trusted parties, and so of course don't have a defense (other than 'many eyes') if someone were to hand e.g. SPJ or Austin or the maintainer of a key package in the Platform a swiss bank account with some quantity of gold sufficient to induce them to put in a backdoor, or perhaps just steal their computers, passwords, and keys to put in a backdoor themselves.
That said, even if we consider that we 'trust' key individuals involved, as well as the security of their keys and identity, we still have other vectors to prevent. Here's my summary of what I understand (thanks to Duncan for helping me sort this out on IRC. Most insights his, all omissions mine).
1) Only those individuals who own packages should be able to upload their packages. A) This is solvable soon and directly by adding SSL to hackage, so that they can upload (via the web interface) in a secure manner. B) To upload securely via "cabal upload" we'll need cabal to have access to the right secure protocols. C) The "easy" answer here is to shell out to curl or the like, and place the obligation on the end user to have the right security-enabled binaries on their system. D) Other than that, we need to use e.g. "tls" and "tls-extras" E) To trust those, we should encourage outreach to the security community as a whole to examine, harden, etc. the code. It is in the interests of many, not just in the haskell world, to have more, different, and reliable open-source implementations of our open protocols for secure communication. F) Even if we don't 'trust' tls sufficiently to bless it for the platform, we can still bake it into platform-distributed cabal-install binaries, as better than nothing.
2) When I download a package, I should be able to trust that the package I download is one uploaded by a verified uploader. A) This is about signing and verification, not a secure protocol as such. B) It requires a different design. The library support is easier than that for SSL. However, there are more options for "how verified" we want the chain of trust to be -- is it sufficient for hackage to sign the tarballs, or do we want to let users sign their own tarballs and allow verification of that, etc.
This is a very good list. 1) c) I think "shelling out" is probably the best idea: * it doesn't cost much on cabal infrastructure and its maintenance * it doesn't add any dependencies * it allow user to replace their binaries by custom solutions if needed. With this in place, even tls doesn't necessary have to be favorited. 2) b) similar to the uploading/downloading, if you have a special binary somewhere, it would use it to automatically insert signatures (at sdist time), and verify packages when needed. -- Vincent