Re: Deprecating fromIntegral

I agree! Silently changing semantics under one’s feet may be bad, but one needn’t remove the function itself. That’s just work for library maintainers! Cheers, Vanessa McHale

On Aug 9, 2020, at 10:43 PM, Carter Schonwald wrote:

The real issue here isn’t fromintrgral, but that everything defaults to wrapping semantics

Adding variants that do signaling/exceptions and clipping Variants Of finite word/Int data types rather than just wrapping is the right path forward.

On Sat, Aug 8, 2020 at 2:20 AM Herbert Valerio Riedel mailto:hvriedel@gmail.com> wrote: Btw, subtle correctness issues hiding throughout the vast monolithic codebase like these were part of the reason (other reasons are explained in https://old.reddit.com/r/haskell/comments/5lxv75/psa_please_use_unique_modul... https://old.reddit.com/r/haskell/comments/5lxv75/psa_please_use_unique_modul...) why cryptohash/cryptonite/foundation has been banned from our codebases not the least because it's hopeless to get something like cryptonite through formal certification for security critical applications. At the time the author made it clear he didn't welcome my bug reports (later I learned the author was merely peculiar as to what they consider an actual bug worth reporting). And whenever I mentioned this in the past on reddit as a PSA, I got defensive reactions and disbelief from certain people who were already invested in the cryptonite ecosystem and I was accused of spreading unfounded FUD... and so I stopped bringing up this kind of "heresy" publicly.

However, as you can see in

https://hackage.haskell.org/package/cryptohash-sha256/changelog https://hackage.haskell.org/package/cryptohash-sha256/changelog

this particular 32-bit overflow issue was one of the critical bugfixes I ran into and repaired in the very first release right after the initial-fork-release back in 2016. It's astonishing it took over 4 years for this bug to keep lingering in cryptonite/cryptohash before it was detected. You'd expect this to have been detected in code audits performed by Haskell companies that actively promote the use of cryptonite early on.

On Sat, Aug 8, 2020 at 5:09 AM Niklas Hambüchen via Libraries mailto:libraries@haskell.org> wrote:

...

Today I found another big bug caused by `fromIntegral`:

https://github.com/haskell-crypto/cryptonite/issues/330 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 mailto:Libraries@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

_______________________________________________ Libraries mailing list Libraries@haskell.org mailto:Libraries@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries _______________________________________________ Libraries mailing list Libraries@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries