<div dir="ltr">Thanks for responding, I intend to go read up on TUF and your blog post now. One question:<br><br><span style="font-size:13.1999998092651px;line-height:19.7999992370605px">      * We're incorporating an existing design for incremental updates</span><br style="font-size:13.1999998092651px;line-height:19.7999992370605px"><span style="font-size:13.1999998092651px;line-height:19.7999992370605px">        of the package index to significantly improve "cabal update"</span><br style="font-size:13.1999998092651px;line-height:19.7999992370605px"><span style="font-size:13.1999998092651px;line-height:19.7999992370605px">        times.</span><br><div><span style="font-size:13.1999998092651px;line-height:19.7999992370605px"><br></span></div><div><span style="font-size:13.1999998092651px;line-height:19.7999992370605px">Can you give any details about what you're planning here? I put together a Git repo already that has all of the cabal files from Hackage and which updates every 30 minutes, and it seems that, instead of reinventing anything, simply using `git pull` would be the right solution here:</span></div><div><span style="font-size:13.1999998092651px;line-height:19.7999992370605px"><br></span></div><div><a href="https://github.com/commercialhaskell/all-cabal-files">https://github.com/commercialhaskell/all-cabal-files</a><br></div></div><br><div class="gmail_quote">On Thu, Apr 16, 2015 at 12:34 PM Duncan Coutts <<a href="mailto:duncan@well-typed.com">duncan@well-typed.com</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi folks,<br>
<br>
As I mentioned previously on the commercialhaskell list, we're working<br>
on Hackage security for the IHG at the moment.<br>
<br>
We've finally written up the design for that as a blog post:<br>
<br>
<a href="http://www.well-typed.com/blog/2015/04/improving-hackage-security" target="_blank">http://www.well-typed.com/blog/2015/04/improving-hackage-security</a><br>
<br>
It includes a section at the end comparing in general terms to this<br>
proposal (specifically Chris's part on package signing).<br>
<br>
The design is basically "The Update Framework" for Hackage. Our current<br>
implementation effort for the IHG covers the first part of that design.<br>
<br>
<a href="http://theupdateframework.com/" target="_blank">http://theupdateframework.com/</a><br>
<br>
I think TUF addresses many of the concerns that have been raised in this<br>
thread, e.g. about threat models, what signatures actually mean etc.<br>
<br>
It also covers the question of making the "who's allowed to upload what"<br>
information transparent, with proper cryptographic evidence (albeit<br>
that's in the second part of the design).<br>
<br>
So if collectively we can also implement the second part of TUF for<br>
Hackage then I think we can address these issues properly.<br>
<br>
Other things worth noting:<br>
      * This will finally allow us to have untrusted public mirrors,<br>
        which is the traditional approach to improving repository<br>
        reliability.<br>
      * We're incorporating an existing design for incremental updates<br>
        of the package index to significantly improve "cabal update"<br>
        times.<br>
<br>
I'll chip in elsewhere in this thread with more details about how TUF<br>
(or our adaptation of it for hackage) solves some of the problems raised<br>
here.<br>
<br>
Duncan<br>
<br>
On Mon, 2015-04-13 at 10:02 +0000, Michael Snoyman wrote:<br>
> Many of you saw the blog post Mathieu wrote[1] about having more composable<br>
> community infrastructure, which in particular focused on improvements to<br>
> Hackage. I've been discussing some of these ideas with both Mathieu and<br>
> others in the community working on some similar thoughts. I've also<br>
> separately spent some time speaking with Chris about package signing[2].<br>
> Through those discussions, it's become apparent to me that there are in<br>
> fact two core pieces of functionality we're relying on Hackage for today:<br>
><br>
> * A centralized location for accessing package metadata (i.e., the cabal<br>
> files) and the package contents themselves (i.e., the sdist tarballs)<br>
> * A central authority for deciding who is allowed to make releases of<br>
> packages, and make revisions to cabal files<br>
><br>
> In my opinion, fixing the first problem is in fact very straightforward to<br>
> do today using existing tools. FP Complete already hosts a full Hackage<br>
> mirror[3] backed by S3, for instance, and having the metadata mirrored to a<br>
> Git repository as well is not a difficult technical challenge. This is the<br>
> core of what Mathieu was proposing as far as composable infrastructure,<br>
> corresponding to next actions 1 and 3 at the end of his blog post (step 2,<br>
> modifying Hackage, is not a prerequesite). In my opinion, such a system<br>
> would far surpass in usability, reliability, and extensibility our current<br>
> infrastructure, and could be rolled out in a few days at most.<br>
><br>
> However, that second point- the central authority- is the more interesting<br>
> one. As it stands, our entire package ecosystem is placing a huge level of<br>
> trust in Hackage, without any serious way to vet what's going on there.<br>
> Attack vectors abound, e.g.:<br>
><br>
> * Man in the middle attacks: as we are all painfully aware, cabal-install<br>
> does not support HTTPS, so a MITM attack on downloads from Hackage is<br>
> trivial<br>
> * A breach of the Hackage Server codebase would allow anyone to upload<br>
> nefarious code[4]<br>
> * Any kind of system level vulnerability could allow an attacker to<br>
> compromise the server in the same way<br>
><br>
> Chris's package signing work addresses most of these vulnerabilities, by<br>
> adding a layer of cryptographic signatures on top of Hackage as the central<br>
> authority. I'd like to propose taking this a step further: removing Hackage<br>
> as the central authority, and instead relying entirely on cryptographic<br>
> signatures to release new packages.<br>
><br>
> I wrote up a strawman proposal last week[5] which clearly needs work to be<br>
> a realistic option. My question is: are people interested in moving forward<br>
> on this? If there's no interest, and everyone is satisfied with continuing<br>
> with the current Hackage-central-authority, then we can proceed with having<br>
> reliable and secure services built around Hackage. But if others- like me-<br>
> would like to see a more secure system built from the ground up, please say<br>
> so and let's continue that conversation.<br>
><br>
> [1]<br>
> <a href="https://www.fpcomplete.com/blog/2015/03/composable-community-infrastructure" target="_blank">https://www.fpcomplete.com/blog/2015/03/composable-community-infrastructure</a><br>
><br>
> [2]<br>
> <a href="https://github.com/commercialhaskell/commercialhaskell/wiki/Package-signing-detailed-propsal" target="_blank">https://github.com/commercialhaskell/commercialhaskell/wiki/Package-signing-detailed-propsal</a><br>
><br>
> [3] <a href="https://www.fpcomplete.com/blog/2015/03/hackage-mirror" target="_blank">https://www.fpcomplete.com/blog/2015/03/hackage-mirror</a><br>
> [4] I don't think this is just a theoretical possibility for some point in<br>
> the future. I have reported an easily trigerrable DoS attack on the current<br>
> Hackage Server codebase, which has been unresolved for 1.5 months now<br>
> [5] <a href="https://gist.github.com/snoyberg/732aa47a5dd3864051b9" target="_blank">https://gist.github.com/snoyberg/732aa47a5dd3864051b9</a><br>
><br>
<br>
<br>
--<br>
Duncan Coutts, Haskell Consultant<br>
Well-Typed LLP, <a href="http://www.well-typed.com/" target="_blank">http://www.well-typed.com/</a><br>
<br>
--<br>
You received this message because you are subscribed to the Google Groups "Commercial Haskell" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an email to <a href="mailto:commercialhaskell%2Bunsubscribe@googlegroups.com" target="_blank">commercialhaskell+unsubscribe@googlegroups.com</a>.<br>
To post to this group, send email to <a href="mailto:commercialhaskell@googlegroups.com" target="_blank">commercialhaskell@googlegroups.com</a>.<br>
To view this discussion on the web visit <a href="https://groups.google.com/d/msgid/commercialhaskell/1429176843.25663.31.camel%40dunky.localdomain" target="_blank">https://groups.google.com/d/msgid/commercialhaskell/1429176843.25663.31.camel%40dunky.localdomain</a>.<br>
For more options, visit <a href="https://groups.google.com/d/optout" target="_blank">https://groups.google.com/d/optout</a>.<br>
</blockquote></div>