[Haskell-cafe] SSL support for hackage and cabal

[Gershom Bazerman]

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.

On a related topic:

On 11/3/13 1:19 PM, Niklas Hambüchen wrote:
> There seem to be a lot of volunteers around who would like to help 
> (for example, I have asked for this multiple times over the last years 
> and this thread shows that there are many more people interested in it).

What we need is not a 'drive by' volunteer just for one-time certificate 
deployment (which is easy). Volunteers for hackage and cabal to tackle 
the bigger technical issues described above would be much more 
important. Join the cabal-devel mailinglist, or hang out in #hackage on 
irc, or both.

On reducing the load on the core infra team, what would be best is 
people able to devote a consistent (even if small) amount of time on a 
prolonged basis. Someone familiar with various virtualization 
technologies and deployment on linux would be ideal. Join the 
#haskell-infrastructure channel on irc, the haskell-infrastructure list 
hosted by galois, email admin at haskell.org, or email me directly, and 
we'll see where you might fit in best. It's great if people want to jump 
in -- there's plenty of work to be done. Let's centralize what people 
have to offer, so that we can work most efficiently!

Cheers,
Gershom