[Haskell-cafe] Improvements to package hosting and security

Sun May 3 15:49:36 UTC 2015

storage for every package ever released on hackage in the history of
haskell on s3 totals < 30 cents per month  (probably closer to 10 cents).
If their s3 host had super high usage, the most it'd cost per month
bandwidth is 50-90 dollars (and likely overestimating by at least 10x). a
small engineering team probably spends more than that on coffee per month.

haskell.org hosting and infrastructure is largely donated by various
organizations. If you can get AWS to top the rackspace+dreamhost infra
sponsorship, Gershom and others would probably love to hear about it.

On Sun, May 3, 2015 at 7:09 AM, Blake Rain <blake.rain at gmail.com> wrote:

> Hi All,
>
> I have only just found the time to read through this discussion. I thought
> perhaps I would offer a few thoughts.
>
> It seems that we are all in agreement that the security of Hackage/Cabal
> is a problem: insecure transmission and no way to verify package
> authorship. This is something which I feel we must address:
>
> Where I work we have a lot of compliance to consider, and a few products
> require us to provide vary degrees of assurance about the code we link
> against. This usually leads to the decision to use a third party piece of
> kit. Going forward, we will need to replace these systems with our own
> solutions. I would prefer to use Haskell, but swapping out Hackage/Cabal
> due to security concerns is undesirable from my point of view and the lack
> of package security will be a show-stopper for senior management.
>
> Using git and S3 as Michael suggests seems a good solution to me. To my
> mind, the increased transparency, ability to create mirrors of S3 and git
> to access the package metadata offers a number of desirable features.
>
> Regarding the use of git: I don't think that we need to implement our own
> solution, and depending on git is not an issue: Most of our CI uses git
> anyway.
>
> A final point I feel I must raise is that it seems that FP Complete are
> going to be footing the bill for the S3 hosting. Long term, this seems
> unfair to FP Complete. Is this something that the haskell.org could take
> on? Or at the very least some other mechanism to either pay for or offer
> compensation long term?
>
> Kinds Regards,
>
> - B.
>
> On 13 April 2015 at 11:02, Michael Snoyman <michael at snoyman.com> 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/CAKA2JgL4MviHic52_S3P8RqxyJndkj3oFA%2BPVG11AAgMhMJksw%40mail.gmail.com
>> <https://groups.google.com/d/msgid/commercialhaskell/CAKA2JgL4MviHic52_S3P8RqxyJndkj3oFA%2BPVG11AAgMhMJksw%40mail.gmail.com?utm_medium=email&utm_source=footer>
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>  --
> 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/CANUq-hHWexCeL%2Bp%2BWSU7PNgpdpWo_j0uPJ47-ui7QRjdktZ9sg%40mail.gmail.com
> <https://groups.google.com/d/msgid/commercialhaskell/CANUq-hHWexCeL%2Bp%2BWSU7PNgpdpWo_j0uPJ47-ui7QRjdktZ9sg%40mail.gmail.com?utm_medium=email&utm_source=footer>
> .
>
> For more options, visit https://groups.google.com/d/optout.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20150503/64a8428d/attachment.html>