[Haskell-cafe] Improvements to package hosting and security

[Michael Snoyman]

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

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/20150415/651be364/attachment.html>