On Fri, Sep 18, 2015 at 1:12 PM, Gershom B <gershomb@gmail.com> wrote:
We can keep our eye on it, but our globalsign cert is fine for the
time being in my opinion.

For now, I'm happy to let Jason continue to manage the cert since
transferring it is potentially a pain?

First off, I don't mind managing it. I just interact with a webform once a year. Pretty minimal.

Second, at the moment the biggest pain point on my end is safely and securely transferring the cert files to the people who need them. In the past, I think we used gpg + email. So if we simply did it in a better way that pain point would go away. I should probably be using scp to transfer the files to a secure directory on the server where the admin team can pick it up.

I don't know if transferring the responsibility will be painful. The folks at GlobalSign really like the opportunity to support the Haskell community with the cert and they are responsive, so I doubt it will be painful.

I should play around with the GlobalSign website and see if I can use it to delegate to others. Could we set it up so that one person authorizes the creation of the cert, but grants others access once it's created?

I'm most interested in redundancy (in case something happens to me or I'm unavailable at the right time) and also interested in secure handling of the cert.


In the future, turning management over to our admins seems a
reasonable course of action. One of the nice things about the roots of
trust system is that our package distribution is now secured
_regardless_ of our cert, so it seems good to keep the cert managed
the "typical" way (perhaps passing the register/renew stuff over to a
current committee member if we prefer) rather than having to reinvent
_all_ the wheels :-)


--gershom

On Wed, Sep 16, 2015 at 3:01 PM, Ryan Trinkle <ryan.trinkle@gmail.com> wrote:
> Would Let's Encrypt be appropriate?  I don't know too much about it, but
> it's "free, automated, and open", which sounds cool.  According to what
> they've been saying, it *should* be ready in time.
>
> On Wed, Sep 16, 2015 at 1:02 PM, Jason Dagit <dagitj@gmail.com> wrote:
>>
>> Somewhat related to this, I got an email reminder from GlobalSign today
>> saying our cert expires soon, mid-November. I've currently been the one that
>> registers/renews the cert. Perhaps part of the discussion around our roots
>> of trust will include a discussion of how to manage this cert?
>>
>> Thanks,
>> Jason
>>
>> On Tue, Sep 15, 2015 at 6:35 PM, Gershom B <gershomb@gmail.com> wrote:
>>>
>>> At the Haskell Implementor's Workshop at ICFP, Duncan gave a talk on
>>> the work on security and package infrastructure that has been going
>>> on:
>>>
>>> https://www.youtube.com/watch?v=D9juHHlnayI
>>>
>>> One element of that, which was turned over the committee to figure out
>>> is who our actual roots of trust would be, in the same sense that
>>> there are root certificates for TLS and https authentication, etc.
>>>
>>> at the Haskell Symposium itself, I gave a quick lightning talk on the
>>> work the committee had done in this regard:
>>>
>>> https://www.youtube.com/watch?v=U8ISiSXV2c0
>>>
>>> (If you are interested in verifying your communications with Duncan by
>>> the way, and if you trust the video is undoctored, then his GPG key
>>> fingerprint appears on it, which may be of some use.)
>>>
>>> We did in fact get some keysigning done at the conference, and we also
>>> secured a fair number of keys from the roots of trust we co-ordinated,
>>> though some followup work remains to be done there. We certainly
>>> already have enough in hand to bootstrap the process as the hackage
>>> security work gets fully rolled out.
>>>
>>> One related discussion we started to have was if we might want to do
>>> haskell community funding for "phase two" of the update framework
>>> rollout, as discussed in Duncan's talk -- that phase where we not only
>>> implement server trust and signing, but also author signing.
>>>
>>> Apropos of nothing, but a related thought/question I had was if there
>>> would be interest in making cabal files themselves more potentially
>>> secure in the manner of the LIO / HLIO work [1]. Having a better chain
>>> of trust seems to somewhat obviate the need here, but it does seem
>>> like something worth considering. Similar mechanisms might also be
>>> worth integrating into template haskell IO for that matter. However,
>>> one concern is that the worth of these approaches depends in part on
>>> good SafeHaskell takeup, which has a whole bunch of obstacles in
>>> itself :-)
>>>
>>> Cheers,
>>> Gershom
>>>
>>> [1]
>>> http://www.cse.chalmers.se/~russo/publications_files/hybrid-icfp2015.pdf
>>> and https://hackage.haskell.org/package/lio-0.11.5.0 and
>>> http://www.scs.stanford.edu/~deian/pubs/stefan:2014:building-haskell.pdf
>>> _______________________________________________
>>> Haskell-community mailing list
>>> Haskell-community@haskell.org
>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-community
>>
>>
>>
>> _______________________________________________
>> Haskell-community mailing list
>> Haskell-community@haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-community
>>
>