<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Sep 18, 2015 at 1:12 PM, Gershom B <span dir="ltr"><<a href="mailto:gershomb@gmail.com" target="_blank">gershomb@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">We can keep our eye on it, but our globalsign cert is fine for the<br>
time being in my opinion.<br>
<br>
For now, I'm happy to let Jason continue to manage the cert since<br>
transferring it is potentially a pain?<br></blockquote><div><br></div><div>First off, I don't mind managing it. I just interact with a webform once a year. Pretty minimal.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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?<br></div><div><br></div><div>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.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
In the future, turning management over to our admins seems a<br>
reasonable course of action. One of the nice things about the roots of<br>
trust system is that our package distribution is now secured<br>
_regardless_ of our cert, so it seems good to keep the cert managed<br>
the "typical" way (perhaps passing the register/renew stuff over to a<br>
current committee member if we prefer) rather than having to reinvent<br>
_all_ the wheels :-)<br>
<span class="HOEnZb"><font color="#888888"><br>
<br>
--gershom<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
On Wed, Sep 16, 2015 at 3:01 PM, Ryan Trinkle <<a href="mailto:ryan.trinkle@gmail.com">ryan.trinkle@gmail.com</a>> wrote:<br>
> Would Let's Encrypt be appropriate?  I don't know too much about it, but<br>
> it's "free, automated, and open", which sounds cool.  According to what<br>
> they've been saying, it *should* be ready in time.<br>
><br>
> On Wed, Sep 16, 2015 at 1:02 PM, Jason Dagit <<a href="mailto:dagitj@gmail.com">dagitj@gmail.com</a>> wrote:<br>
>><br>
>> Somewhat related to this, I got an email reminder from GlobalSign today<br>
>> saying our cert expires soon, mid-November. I've currently been the one that<br>
>> registers/renews the cert. Perhaps part of the discussion around our roots<br>
>> of trust will include a discussion of how to manage this cert?<br>
>><br>
>> Thanks,<br>
>> Jason<br>
>><br>
>> On Tue, Sep 15, 2015 at 6:35 PM, Gershom B <<a href="mailto:gershomb@gmail.com">gershomb@gmail.com</a>> wrote:<br>
>>><br>
>>> At the Haskell Implementor's Workshop at ICFP, Duncan gave a talk on<br>
>>> the work on security and package infrastructure that has been going<br>
>>> on:<br>
>>><br>
>>> <a href="https://www.youtube.com/watch?v=D9juHHlnayI" rel="noreferrer" target="_blank">https://www.youtube.com/watch?v=D9juHHlnayI</a><br>
>>><br>
>>> One element of that, which was turned over the committee to figure out<br>
>>> is who our actual roots of trust would be, in the same sense that<br>
>>> there are root certificates for TLS and https authentication, etc.<br>
>>><br>
>>> at the Haskell Symposium itself, I gave a quick lightning talk on the<br>
>>> work the committee had done in this regard:<br>
>>><br>
>>> <a href="https://www.youtube.com/watch?v=U8ISiSXV2c0" rel="noreferrer" target="_blank">https://www.youtube.com/watch?v=U8ISiSXV2c0</a><br>
>>><br>
>>> (If you are interested in verifying your communications with Duncan by<br>
>>> the way, and if you trust the video is undoctored, then his GPG key<br>
>>> fingerprint appears on it, which may be of some use.)<br>
>>><br>
>>> We did in fact get some keysigning done at the conference, and we also<br>
>>> secured a fair number of keys from the roots of trust we co-ordinated,<br>
>>> though some followup work remains to be done there. We certainly<br>
>>> already have enough in hand to bootstrap the process as the hackage<br>
>>> security work gets fully rolled out.<br>
>>><br>
>>> One related discussion we started to have was if we might want to do<br>
>>> haskell community funding for "phase two" of the update framework<br>
>>> rollout, as discussed in Duncan's talk -- that phase where we not only<br>
>>> implement server trust and signing, but also author signing.<br>
>>><br>
>>> Apropos of nothing, but a related thought/question I had was if there<br>
>>> would be interest in making cabal files themselves more potentially<br>
>>> secure in the manner of the LIO / HLIO work [1]. Having a better chain<br>
>>> of trust seems to somewhat obviate the need here, but it does seem<br>
>>> like something worth considering. Similar mechanisms might also be<br>
>>> worth integrating into template haskell IO for that matter. However,<br>
>>> one concern is that the worth of these approaches depends in part on<br>
>>> good SafeHaskell takeup, which has a whole bunch of obstacles in<br>
>>> itself :-)<br>
>>><br>
>>> Cheers,<br>
>>> Gershom<br>
>>><br>
>>> [1]<br>
>>> <a href="http://www.cse.chalmers.se/~russo/publications_files/hybrid-icfp2015.pdf" rel="noreferrer" target="_blank">http://www.cse.chalmers.se/~russo/publications_files/hybrid-icfp2015.pdf</a><br>
>>> and <a href="https://hackage.haskell.org/package/lio-0.11.5.0" rel="noreferrer" target="_blank">https://hackage.haskell.org/package/lio-0.11.5.0</a> and<br>
>>> <a href="http://www.scs.stanford.edu/~deian/pubs/stefan:2014:building-haskell.pdf" rel="noreferrer" target="_blank">http://www.scs.stanford.edu/~deian/pubs/stefan:2014:building-haskell.pdf</a><br>
>>> _______________________________________________<br>
>>> Haskell-community mailing list<br>
>>> <a href="mailto:Haskell-community@haskell.org">Haskell-community@haskell.org</a><br>
>>> <a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-community" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-community</a><br>
>><br>
>><br>
>><br>
>> _______________________________________________<br>
>> Haskell-community mailing list<br>
>> <a href="mailto:Haskell-community@haskell.org">Haskell-community@haskell.org</a><br>
>> <a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-community" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-community</a><br>
>><br>
><br>
</div></div></blockquote></div><br></div></div>