[Haskell-cafe] Improvements to package hosting and security

Wed Apr 15 05:01:53 UTC 2015

On Tue, Apr 14, 2015 at 9:50 PM, Michael Snoyman <michael at snoyman.com>
wrote:

> 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).
>

Is it possible to separate out the concept of trusted revisions from a
distributed hackage (into 2 separate proposals) then?
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).

>
> On Wed, Apr 15, 2015 at 7:12 AM Greg Weber <greg at gregweber.info> wrote:
>
>> What security guarantees do we get from this proposal that are not
>> present from Chris's package signing work?
>> 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.
>>
>> 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?
>>
>> On Mon, Apr 13, 2015 at 3:02 AM, 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/CAKRanNCnSV%3Ddds4ZDmacNO8WMxSgDmEh6acc0StMh%2Btgz%3D09hA%40mail.gmail.com
>> <https://groups.google.com/d/msgid/commercialhaskell/CAKRanNCnSV%3Ddds4ZDmacNO8WMxSgDmEh6acc0StMh%2Btgz%3D09hA%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/20150414/9e96043e/attachment.html>