Yes, I think you've summarized the security aspects of this nicely. There's also the reliability and availability guarantees we get from a distributed system, but that's outside the realm of security (unless you're talking about denial of service).
On Wed, Apr 15, 2015 at 7:12 AM Greg Weber <[email protected]> wrote: > What security guarantees do we get from this proposal that are not present > from Chris's package signing work? > Part of the goal of the package signing is that we no longer need to trust > Hackage. If it is compromised and packages are compromised, then anyone > using signing tools should automatically reject the compromised packages. > > Right now I think the answer is: that this provides a security model for > revisions: it limits what can be done and formalizes the trust of this > process in a cryptographic way. Whereas with Chris's work there is no > concept of a (trusted) revision and a new package must be released? > > On Mon, Apr 13, 2015 at 3:02 AM, 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 >> > -- >> > You received this message because you are subscribed to the Google Groups >> "Commercial Haskell" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected]. >> To post to this group, send email to [email protected]. >> > To view this discussion on the web visit >> https://groups.google.com/d/msgid/commercialhaskell/CAKA2JgL4MviHic52_S3P8RqxyJndkj3oFA%2BPVG11AAgMhMJksw%40mail.gmail.com >> <https://groups.google.com/d/msgid/commercialhaskell/CAKA2JgL4MviHic52_S3P8RqxyJndkj3oFA%2BPVG11AAgMhMJksw%40mail.gmail.com?utm_medium=email&utm_source=footer> >> . > > >> For more options, visit https://groups.google.com/d/optout. >> > > -- > You received this message because you are subscribed to the Google Groups > "Commercial Haskell" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To post to this group, send email to [email protected]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/commercialhaskell/CAKRanNCnSV%3Ddds4ZDmacNO8WMxSgDmEh6acc0StMh%2Btgz%3D09hA%40mail.gmail.com > <https://groups.google.com/d/msgid/commercialhaskell/CAKRanNCnSV%3Ddds4ZDmacNO8WMxSgDmEh6acc0StMh%2Btgz%3D09hA%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > For more options, visit https://groups.google.com/d/optout. >
_______________________________________________ haskell-infrastructure mailing list [email protected] http://community.galois.com/mailman/listinfo/haskell-infrastructure
