[Haskell-cafe] Improvements to package hosting and security

[Michael Snoyman]

Also, since it's relevant, here's a Github repo with all of the cabal files
from Hackage which (thanks to a cron job and Travis CI) automatically
updates every 30 minutes:

https://github.com/commercialhaskell/all-cabal-files

On Mon, Apr 13, 2015 at 1:02 PM Michael Snoyman <michael at snoyman.com> wrote:

> 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/be1b5fd5/attachment.html>