[Haskell-cafe] SSL support for hackage and cabal

Carter Schonwald carter.schonwald at gmail.com
Mon Nov 4 06:37:30 UTC 2013


broadly speaking, believing that a communication is secure/valid changes
the behavior of communicating participants vs if communication is not
secure. this is how most social engineering security issues come to pass.

for matters of security, being conversative about possible risks is a
responsible strategy.

That said, if some folks comfortable with security and the like could do
some white hat auditing/hammering on hs-tls, I think that would be the
*ideal* way to help get buy in to that proposed approach. (not sure if such
volunteers exist, but that would be the ideal scenario). I could ask 1-2
folks i know if they have any suggestions.




On Mon, Nov 4, 2013 at 1:24 AM, Vincent Hanquez <tab at snarc.org> wrote:

> On 2013-11-03 17:48, Scott Lawrence wrote:
>
>> One could argue that the potential for a false sense of security could
>> make (very) bad encryption worse than no encryption.
>>
>>  Well. No, false sense of security is bad, however is has no link with
> your absolute level of security.
>
> Even bad cryptographic implementation provide some security in a sense, at
> worse by obscurity
> (which is very poor security, but not zero), and In the best case (of the
> bad) a rather hard problem
> for resource-less people.
>
> Now i'm not saying that bad implementations are OK, and certainly I hope
> that's not the case in tls,
> but in the context where we got nothing, just as John Wiegley rightfully
> mentioned, the risk is
> quite small.
>
> it's rather sad to see the "i'ld rather have *no* security whatsoever,
> than maybe have some" hard line.
>
>
>  Personally, I've always been a bit uncomfortable with the small number of
>> widely-used implementations (AFAIK OpenSSL and GnuTLS combined account for
>> pretty much all TLS-using open-source software), and I think pushing
>> another one into wider usage would be a good thing (while acknowledging
>> that it's likely more vulnerable than the older implementations).
>>
>>
> That, and also that half of openssl CVE in the past 20 years were buffer
> overflow/underflow.
> Nothing to do with cryptography, but rather just simple memory management.
> I think this got to give some security points for a (mostly) haskell
> implementation.
>
> --
> Vincent
>
> _______________________________________________
> 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/20131104/d64b8358/attachment.html>


More information about the Haskell-Cafe mailing list