[Haskell-cafe] SSL support for hackage and cabal

[Vincent Hanquez]

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