<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Apr 14, 2015 at 9:50 PM, Michael Snoyman <span dir="ltr"><<a href="mailto:michael@snoyman.com" target="_blank">michael@snoyman.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">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).<br></div></blockquote><div><br></div><div>Is it possible to separate out the concept of trusted revisions from a distributed hackage (into 2 separate proposals) then?</div><div>If Hackage wanted to it could implement trusted revisions. Or some other (distributed or non-distributed) package service could implement it (as long as the installer tool knows to check for revisions there, perhaps this would be added to Chris's signing tooling).</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><br><div class="gmail_quote"><div><div class="h5">On Wed, Apr 15, 2015 at 7:12 AM Greg Weber <<a href="mailto:greg@gregweber.info" target="_blank">greg@gregweber.info</a>> wrote:<br></div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="h5"><div dir="ltr">What security guarantees do we get from this proposal that are not present from Chris's package signing work?<div>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.</div><div><br></div><div>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?</div>
</div><div class="gmail_extra"><br><div class="gmail_quote"></div></div><div class="gmail_extra"><div class="gmail_quote">On Mon, Apr 13, 2015 at 3:02 AM, Michael Snoyman <span dir="ltr"><<a href="mailto:michael@snoyman.com" target="_blank">michael@snoyman.com</a>></span> wrote:<br></div></div><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>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:</div><div><br></div><div>* A centralized location for accessing package metadata (i.e., the cabal files) and the package contents themselves (i.e., the sdist tarballs)</div><div>* A central authority for deciding who is allowed to make releases of packages, and make revisions to cabal files</div><div><br></div><div>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.</div><div><br></div><div>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.:</div><div><br></div><div>* 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</div><div>* A breach of the Hackage Server codebase would allow anyone to upload nefarious code[4]</div><div>* Any kind of system level vulnerability could allow an attacker to compromise the server in the same way</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>[1] <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> </div><div>[2] <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> </div><div>[3] <a href="https://www.fpcomplete.com/blog/2015/03/hackage-mirror" target="_blank">https://www.fpcomplete.com/blog/2015/03/hackage-mirror</a> </div><div>[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 </div><div>[5] <a href="https://gist.github.com/snoyberg/732aa47a5dd3864051b9" target="_blank">https://gist.github.com/snoyberg/732aa47a5dd3864051b9</a> </div></div></blockquote></div></div><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span><font color="#888888">
<p></p>
-- <br></font></span></blockquote></div></div><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span><font color="#888888">
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+unsubscribe@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></font></span></blockquote></div></div><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span><font color="#888888">
To view this discussion on the web visit <a href="https://groups.google.com/d/msgid/commercialhaskell/CAKA2JgL4MviHic52_S3P8RqxyJndkj3oFA%2BPVG11AAgMhMJksw%40mail.gmail.com?utm_medium=email&utm_source=footer" target="_blank">https://groups.google.com/d/msgid/commercialhaskell/CAKA2JgL4MviHic52_S3P8RqxyJndkj3oFA%2BPVG11AAgMhMJksw%40mail.gmail.com</a>.</font></span></blockquote></div></div><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span><font color="#888888"><br>
For more options, visit <a href="https://groups.google.com/d/optout" target="_blank">https://groups.google.com/d/optout</a>.<br>
</font></span></blockquote></div></div><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span><font color="#888888"></font></span></blockquote></div><br></div>
<p></p>
-- <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+unsubscribe@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></div></div>
To view this discussion on the web visit <a href="https://groups.google.com/d/msgid/commercialhaskell/CAKRanNCnSV%3Ddds4ZDmacNO8WMxSgDmEh6acc0StMh%2Btgz%3D09hA%40mail.gmail.com?utm_medium=email&utm_source=footer" target="_blank">https://groups.google.com/d/msgid/commercialhaskell/CAKRanNCnSV%3Ddds4ZDmacNO8WMxSgDmEh6acc0StMh%2Btgz%3D09hA%40mail.gmail.com</a>.<span class=""><br>
For more options, visit <a href="https://groups.google.com/d/optout" target="_blank">https://groups.google.com/d/optout</a>.<br>
</span></blockquote></div></div>
</blockquote></div><br></div></div>