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.
On Mon, Apr 13, 2015 at 6:04 PM Arnaud Bailly | Capital Match < [email protected]> wrote: > 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. > > Then packages themselves could be completely and rather safely distributed > through standard p2p file sharing. > > I am not a specialist of crypto money, though. > > My 50 cts > Arnaud > > Le lundi 13 avril 2015, Dennis J. McWherter, Jr. <[email protected]> > a écrit : > >> 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. >> >> 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). >> >> In any case, as I said before, the proposal looks great! I am looking >> forward to this. >> >> On Monday, April 13, 2015 at 5:02:46 AM UTC-5, Michael Snoyman 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/4487776e-b862-429c-adae-477813e560f3%40googlegroups.com >> <https://groups.google.com/d/msgid/commercialhaskell/4487776e-b862-429c-adae-477813e560f3%40googlegroups.com?utm_medium=email&utm_source=footer> >> . > > >> For more options, visit https://groups.google.com/d/optout. >> > > > -- > *Arnaud Bailly* > > CTO | Capital Match > > CapitalMatch > > 71 Ayer Rajah Crescent | #06-16 | Singapore 139951 > > (FR) +33 617 121 978 / (SG) +65 8408 7973 | [email protected] | > www.capital-match.com > > Disclaimer: > > *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.* > >
_______________________________________________ haskell-infrastructure mailing list [email protected] http://community.galois.com/mailman/listinfo/haskell-infrastructure
