[Haskell-cafe] Improvements to package hosting and security

[Michael Snoyman]

Many of you saw the blog post Mathieu wrote[1] about having more composable
community infrastructure, which in particular focused on improvements to
Hackage. I've been discussing some of these ideas with both Mathieu and
others in the community working on some similar thoughts. I've also
separately spent some time speaking with Chris about package signing[2].
Through those discussions, it's become apparent to me that there are in
fact two core pieces of functionality we're relying on Hackage for today:

* A centralized location for accessing package metadata (i.e., the cabal
files) and the package contents themselves (i.e., the sdist tarballs)
* A central authority for deciding who is allowed to make releases of
packages, and make revisions to cabal files

In my opinion, fixing the first problem is in fact very straightforward to
do today using existing tools. FP Complete already hosts a full Hackage
mirror[3] backed by S3, for instance, and having the metadata mirrored to a
Git repository as well is not a difficult technical challenge. This is the
core of what Mathieu was proposing as far as composable infrastructure,
corresponding to next actions 1 and 3 at the end of his blog post (step 2,
modifying Hackage, is not a prerequesite). In my opinion, such a system
would far surpass in usability, reliability, and extensibility our current
infrastructure, and could be rolled out in a few days at most.

However, that second point- the central authority- is the more interesting
one. As it stands, our entire package ecosystem is placing a huge level of
trust in Hackage, without any serious way to vet what's going on there.
Attack vectors abound, e.g.:

* Man in the middle attacks: as we are all painfully aware, cabal-install
does not support HTTPS, so a MITM attack on downloads from Hackage is
trivial
* A breach of the Hackage Server codebase would allow anyone to upload
nefarious code[4]
* Any kind of system level vulnerability could allow an attacker to
compromise the server in the same way

Chris's package signing work addresses most of these vulnerabilities, by
adding a layer of cryptographic signatures on top of Hackage as the central
authority. I'd like to propose taking this a step further: removing Hackage
as the central authority, and instead relying entirely on cryptographic
signatures to release new packages.

I wrote up a strawman proposal last week[5] which clearly needs work to be
a realistic option. My question is: are people interested in moving forward
on this? If there's no interest, and everyone is satisfied with continuing
with the current Hackage-central-authority, then we can proceed with having
reliable and secure services built around Hackage. But if others- like me-
would like to see a more secure system built from the ground up, please say
so and let's continue that conversation.

[1]
https://www.fpcomplete.com/blog/2015/03/composable-community-infrastructure

[2]
https://github.com/commercialhaskell/commercialhaskell/wiki/Package-signing-detailed-propsal

[3] https://www.fpcomplete.com/blog/2015/03/hackage-mirror
[4] I don't think this is just a theoretical possibility for some point in
the future. I have reported an easily trigerrable DoS attack on the current
Hackage Server codebase, which has been unresolved for 1.5 months now
[5] https://gist.github.com/snoyberg/732aa47a5dd3864051b9
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20150413/aabfe852/attachment.html>