Re: [Haskell-cafe] SSL support for hackage and cabal

Even if you do expose the private key to other people, there's no way for them to know that the administrator didn't also send it somewhere else -- you can't prove that somebody hasn't duplicated information, without making sure they don't have access to the information (which the admin must). At the end of the day, trusting admins is what almost always happens. The other route is for packages to be individually signed by developers. As I recall, that's been explicitly discussed and informally rejected here before, on the grounds that it makes the uploading process significantly more cumbersome for many people. On Sun, 3 Nov 2013, Mike Izbicki wrote:

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 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@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

-- Scott Lawrence