[Haskell-cafe] Improvements to package hosting and security

Michael Snoyman michael at snoyman.com
Tue Apr 14 05:01:15 UTC 2015


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 <
arnaud at capital-match.com> 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. <dennis at deathbytape.com>
> 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 commercialhaskell+unsubscribe at googlegroups.com.
>> To post to this group, send email to commercialhaskell at googlegroups.com.
>>
> 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 | arnaud at capital-match.com |
> 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.*
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20150414/fdc29415/attachment.html>


More information about the Haskell-Cafe mailing list