[Haskell-cafe] SSL support for hackage and cabal
bytbox at gmail.com
Sun Nov 3 17:49:39 UTC 2013
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 <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
>>> 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
>> 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?
>> Haskell-Cafe mailing list
>> Haskell-Cafe at haskell.org
More information about the Haskell-Cafe