<div dir="auto"><span style="font-family:sans-serif;font-size:12.8px">I agree the situation now is actually quite dire. It would be much, much better to be partial than to corrupt data. Sadly even something as ubiquitous as + and - suffer from a similar problem. The issue is in many ways polymorphism. These functions are far less polymorphic than their signatures.</span><div dir="auto" style="font-family:sans-serif;font-size:12.8px"><br></div><div dir="auto" style="font-family:sans-serif;font-size:12.8px">What if we introduced partial versions of these functions and deprecated the rest. Then if someone wants to guarantee there are no exceptions they need to resort to more advanced tactics but at the very least we don't corrupt.</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, Aug 8, 2020, 9:45 AM Vanessa McHale <<a href="mailto:vamchale@gmail.com">vamchale@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">-1 from me, massive work to overhaul the ecosystem.<br>
<br>
Maybe a haddock comment first?<br>
<br>
> On Aug 7, 2020, at 10:08 PM, Niklas Hambüchen via Libraries <<a href="mailto:libraries@haskell.org" target="_blank" rel="noreferrer">libraries@haskell.org</a>> wrote:<br>
> <br>
> Today I found another big bug caused by `fromIntegral`:<br>
> <br>
>    <a href="https://github.com/haskell-crypto/cryptonite/issues/330" rel="noreferrer noreferrer" target="_blank">https://github.com/haskell-crypto/cryptonite/issues/330</a><br>
> <br>
> Incorrect hashes for all hash algorithms beyond 4 GiB of input. SHA hash collisions in my productions system.<br>
> <br>
> Restating what I said there:<br>
> <br>
> * Until we deprecate fromIntegral, Haskell code will always be subtly wrong and never be secure.<br>
> * If we don't fix this, people will shy away from using Haskell for serious work (or learn it the hard way). Rust and C both do this better.<br>
> * If the authors of key crypto libraries fall for these traps (no blame on them), who can get it right? We should remove the traps.<br>
> <br>
> The wrong code,<br>
> <br>
>    hashInternalUpdate ctx d (fromIntegral $ B.length b)<br>
> <br>
> exists because it simply does not look like wrong code. In contrast,<br>
> <br>
>    hashInternalUpdate ctx d (fromIntegralWrapping $ B.length b)<br>
> <br>
> does look like wrong code and would make anyone scrolling by suspicious.<br>
> <br>
> We can look away while continuing to claim that Haskell is a high-correctness language, or fix stuff like this and make it one.<br>
> _______________________________________________<br>
> Libraries mailing list<br>
> <a href="mailto:Libraries@haskell.org" target="_blank" rel="noreferrer">Libraries@haskell.org</a><br>
> <a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries" rel="noreferrer noreferrer" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries</a><br>
<br>
_______________________________________________<br>
Libraries mailing list<br>
<a href="mailto:Libraries@haskell.org" target="_blank" rel="noreferrer">Libraries@haskell.org</a><br>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries" rel="noreferrer noreferrer" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries</a><br>
</blockquote></div>