<div dir="ltr">That could work in theory. My concern with such an approach is that- AFAIK- the tooling around that kind of stuff is not very well developed, as opposed to an approach using Git, SHA512, and GPG, which should be easy to combine. But I could be completely mistaken on this point; if existing, well vetted technology exists for this, I'm not opposed to using it.<br><br><div class="gmail_quote">On Mon, Apr 13, 2015 at 6:04 PM Arnaud Bailly | Capital Match <<a href="mailto:arnaud@capital-match.com" target="_blank">arnaud@capital-match.com</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Just thinking aloud but wouldn't it be possible to take advantage of cryptographic ledgers a la Bitcoin for authenticating packages and tracking the history of change ? This would provide redundancy as the transactions log is distributed and "naturally" create a web of trust or at least authenticate transactions. People uploading or modifying a package would have to sign a transactions with someone having enough karma to allow this.<div><br></div><div>Then packages themselves could be completely and rather safely distributed through standard p2p file sharing.</div><div><br></div><div>I am not a specialist of crypto money, though. </div><div><br></div><div>My 50 cts</div><div>Arnaud </div><div><div><br><div><div></div></div></div></div><div><div><div><div>Le lundi 13 avril 2015, Dennis J. McWherter, Jr. <<a href="mailto:dennis@deathbytape.com" target="_blank">dennis@deathbytape.com</a>> a écrit :<br></div></div></div></div><div><div><div><div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">This proposal looks great. The one thing I am failing to understand (and I recognize the proposal is in early stages) is how to ensure redundancy in the system. As far as I can tell, much of this proposal discusses the centralized authority of the system (i.e. ensuring secure distribution) and only references (with little detail) the distributed store. For instance, say I host a package on a personal server and one day I decide to shut that server down; is this package now lost forever? I do see this line: "backup download links to S3" but this implies that the someone is willing to pay for S3 storage for all of the packages.<div><br></div><div>Are there plans to adopt a P2P-like model or something similar to support any sort of replication? Public resources like this seem to come and go, so it would be nice to avoid some of the problems associated with high churn in the network. That said, there is an obvious cost to replication. Likewise, the central authority would have to be updated with new, relevant locations to find the file (as it is currently proposed).</div><div><br></div><div>In any case, as I said before, the proposal looks great! I am looking forward to this.<br><div><br>On Monday, April 13, 2015 at 5:02:46 AM UTC-5, Michael Snoyman wrote:<blockquote class="gmail_quote" style="margin:0;margin-left: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" rel="nofollow" target="_blank">https://www.fpcomplete.com/<u></u>blog/2015/03/composable-<u></u>community-infrastructure</a> </div><div>[2] <a href="https://github.com/commercialhaskell/commercialhaskell/wiki/Package-signing-detailed-propsal" rel="nofollow" target="_blank">https://github.com/<u></u>commercialhaskell/<u></u>commercialhaskell/wiki/<u></u>Package-signing-detailed-<u></u>propsal</a> </div><div>[3] <a href="https://www.fpcomplete.com/blog/2015/03/hackage-mirror" rel="nofollow" target="_blank">https://www.fpcomplete.com/<u></u>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" rel="nofollow" target="_blank">https://gist.github.com/<u></u>snoyberg/732aa47a5dd3864051b9</a> </div></div>
</blockquote></div></div></div>
<p></p></blockquote></div></div></div></div><div><div><div><div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
-- <br></blockquote></div></div></div></div><div><div><div><div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
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>commercialhaskell+unsubscribe@googlegroups.com</a>.<br>
To post to this group, send email to <a>commercialhaskell@googlegroups.com</a>.<br></blockquote></div></div></div></div><div><div><div><div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
To view this discussion on the web visit <a href="https://groups.google.com/d/msgid/commercialhaskell/4487776e-b862-429c-adae-477813e560f3%40googlegroups.com?utm_medium=email&utm_source=footer" target="_blank">https://groups.google.com/d/msgid/commercialhaskell/4487776e-b862-429c-adae-477813e560f3%40googlegroups.com</a>.</blockquote></div></div></div></div><div><div><div><div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><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></div></div></div><div><div><div><div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"></blockquote></div></div></div></div><br><br>-- <br><div dir="ltr"><div><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div><font color="#000000"><b>Arnaud Bailly</b></font></div><div><p><span style="color:black">CTO | Capital Match</span><u></u><u></u></p></div><div><p><span lang="EN-US" style="font-size:36pt;font-family:'Fontin Sans Rg',serif;color:rgb(139,0,0)">Capital</span><span lang="EN-US" style="font-size:36pt;font-family:'Fontin Sans Rg',serif;color:gray">Match</span><u></u><u></u></p></div><div><p><a value="+6594299471" style="color:rgb(17,85,204)"></a><span style="color:rgb(0,0,0)">71 Ayer Rajah Crescent | #06-16 | Singapore 139951</span></p><p>(FR) +33 617 121 978<span style="color:black"> / </span><span style="color:black">(SG) +65 8408 7973 | </span><a href="mailto:arnaud@capital-match.com" style="color:rgb(17,85,204)" target="_blank">arnaud@capital-match.com</a><span style="color:black"> | </span><a href="http://www.capital-match.com/" style="font-size:12.8000001907349px;color:rgb(17,85,204)" target="_blank">www.capital-match.com</a></p></div><div><div><p><span style="font-family:Arial,sans-serif;color:rgb(153,153,153)">Disclaimer:</span><span style="font-family:Arial,sans-serif"><u></u><u></u></span></p></div><div><p><span style="font-size:12.8000001907349px;background-color:rgb(255,255,255)"><i><font color="#999999">Capital Match Platform Pte. Ltd. (the "Company") registered in Singapore (Co. Reg. No. 201501788H), a subsidiary of Capital Match Holdings Pte. Ltd. (Co. Reg. No. 201418682W), provides services that involve arranging for multiple parties to enter into loan and invoice discounting agreements. The Company does not provide any form of investment advice or recommendations regarding any listings on its platform. In providing its services, the Company's role is limited to an administrative function and the Company does not and will not assume any advisory, fiduciary or other duties to clients of its services.</font></i></span><br></p></div></div></div></div></div></div></div></div></div><br>
</blockquote></div></div>