
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.
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.
On Sat, Aug 8, 2020, 9:45 AM Vanessa McHale
-1 from me, massive work to overhaul the ecosystem.
Maybe a haddock comment first?
On Aug 7, 2020, at 10:08 PM, Niklas Hambüchen via Libraries < libraries@haskell.org> wrote:
Today I found another big bug caused by `fromIntegral`:
https://github.com/haskell-crypto/cryptonite/issues/330
Incorrect hashes for all hash algorithms beyond 4 GiB of input. SHA hash
collisions in my productions system. > > Restating what I said there: > > * Until we deprecate fromIntegral, Haskell code will always be subtly wrong and never be secure. > * 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. > * 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. > > The wrong code, > > hashInternalUpdate ctx d (fromIntegral $ B.length b) > > exists because it simply does not look like wrong code. In contrast, > > hashInternalUpdate ctx d (fromIntegralWrapping $ B.length b) > > does look like wrong code and would make anyone scrolling by suspicious. > > We can look away while continuing to claim that Haskell is a high-correctness language, or fix stuff like this and make it one. > _______________________________________________ > Libraries mailing list > Libraries@haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
_______________________________________________ Libraries mailing list Libraries@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries