[Haskell-cafe] SSL support for hackage and cabal

[Mike Izbicki]

What's the standard practice for how FOSS software actually keeps a private
key private?  This requirement is rather counter cultural, and so I imagine
it's often not done in a robust way.

Do you typically just trust that whomever is in charge of the project
didn't make any mistakes in the installation and didn't sellout the key to
someone else?  Or is there a way for other eyes to verify that everything
happened correctly without exposing the private key to every contributor?


On Sun, Nov 3, 2013 at 9:02 AM, Donn Cave <donn at avvanta.com> wrote:

> Quoth Johan Tibell,
> [ ... Re Haskell TLS implementation ]
>
> > True. Although to be honest I want something true and tested when it
> comes
> > to crypto.
>
> Don't believe in security by obscurity?
>
> How strongly do you feel about the cross platform and dependency issues?
>
> When I needed SSL encryption, I whipped up a little module with foreign
> calls to OpenSSL.  For an ordinary client, which is all I use it for any
> more, it's a simple interface -- init, connect, read, write, a couple
> error functions.  I have to link -lssl -lcrypto.  The great thing about
> this is, not only do I have a high degree of confidence in the
> implementation,
> I don't expect it to _ever_ change in a way that will inconvenience me.
> If my application ever needs to work on a platform with a different SSL,
> just need a new module with init/connect/write etc.
>
> Does that seem like a possibility, just write minimal interfaces to
> existing platform standard SSL implementations, and move on to more
> interesting problems?  Or is this really an area with interesting problems
> of its own that I'm missing?
>
>         Donn
> _______________________________________________
> 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/7079591a/attachment.html>