[Haskell-cafe] SSL support for hackage and cabal

[Eli Frey]

> Theres a Haskell-infrastructure team that is now managing much of the
community infrastructure, talk with them if you want to get involved.
they're often found on the #haskell-infrastructure irc channel on freenode
and they're amazingly responsive (despite being all volunteers)

> What we need is not a 'drive by' volunteer just for one-time certificate
deployment (which is easy). Volunteers for hackage and cabal to tackle the
bigger technical issues described above would be much more important. Join
the cabal-devel mailinglist, or hang out in #hackage on irc, or both.

Good points, I'll quit back seat driving :P.



On Sun, Nov 3, 2013 at 11:00 AM, Gershom Bazerman <gershomb at gmail.com>wrote:

> On various topics:
>
> Security is a multifaceted beast with many related issues, depending on
> which attack vectors we're concerned about, with what degree of assurance.
>
> Ultimately, we rely on trusted parties, and so of course don't have a
> defense (other than 'many eyes') if someone were to hand e.g. SPJ or Austin
> or the maintainer of a key package in the Platform a swiss bank account
> with some quantity of gold sufficient to induce them to put in a backdoor,
> or perhaps just steal their computers, passwords, and keys to put in a
> backdoor themselves.
>
> That said, even if we consider that we 'trust' key individuals involved,
> as well as the security of their keys and identity, we still have other
> vectors to prevent. Here's my summary of what I understand (thanks to
> Duncan for helping me sort this out on IRC. Most insights his, all
> omissions mine).
>
> 1) Only those individuals who own packages should be able to upload their
> packages.
>     A) This is solvable soon and directly by adding SSL to hackage, so
> that they can upload (via the web interface) in a secure manner.
>     B) To upload securely via "cabal upload" we'll need cabal to have
> access to the right secure protocols.
>     C) The "easy" answer here is to shell out to curl or the like, and
> place the obligation on the end user to have the right security-enabled
> binaries on their system.
>     D) Other than that, we need to use e.g. "tls" and "tls-extras"
>     E) To trust those, we should encourage outreach to the security
> community as a whole to examine, harden, etc. the code. It is in the
> interests of many, not just in the haskell world, to have more, different,
> and reliable open-source implementations of our open protocols for secure
> communication.
>     F) Even if we don't 'trust' tls sufficiently to bless it for the
> platform, we can still bake it into platform-distributed cabal-install
> binaries, as better than nothing.
>
> 2) When I download a package, I should be able to trust that the package I
> download is one uploaded by a verified uploader.
>     A) This is about signing and verification, not a secure protocol as
> such.
>     B) It requires a different design. The library support is easier than
> that for SSL. However, there are more options for "how verified" we want
> the chain of trust to be -- is it sufficient for hackage to sign the
> tarballs, or do we want to let users sign their own tarballs and allow
> verification of that, etc.
>
> On a related topic:
>
>
> On 11/3/13 1:19 PM, Niklas Hambüchen wrote:
>
>> There seem to be a lot of volunteers around who would like to help (for
>> example, I have asked for this multiple times over the last years and this
>> thread shows that there are many more people interested in it).
>>
>
> What we need is not a 'drive by' volunteer just for one-time certificate
> deployment (which is easy). Volunteers for hackage and cabal to tackle the
> bigger technical issues described above would be much more important. Join
> the cabal-devel mailinglist, or hang out in #hackage on irc, or both.
>
> On reducing the load on the core infra team, what would be best is people
> able to devote a consistent (even if small) amount of time on a prolonged
> basis. Someone familiar with various virtualization technologies and
> deployment on linux would be ideal. Join the #haskell-infrastructure
> channel on irc, the haskell-infrastructure list hosted by galois, email
> admin at haskell.org, or email me directly, and we'll see where you might
> fit in best. It's great if people want to jump in -- there's plenty of work
> to be done. Let's centralize what people have to offer, so that we can work
> most efficiently!
>
> Cheers,
> Gershom
>
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20131103/c7611165/attachment.html>