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 <[email protected]> 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 >
_______________________________________________ haskell-infrastructure mailing list [email protected] http://community.galois.com/mailman/listinfo/haskell-infrastructure
