Deprecating fromIntegral

Mon Aug 10 16:11:34 UTC 2020

Step one is to build the new preferred API and then step two is to worry about moving the whole ecosystem over. I’d love to have some safer numeric conversion functions around. Is there a good starting point already or do we need to build something new?

> On Aug 10, 2020, at 6:49 AM, Carter Schonwald <carter.schonwald at gmail.com> wrote:
> 
> Agreed! 
> 
> And 1-2 maintainers egregious bugs isn’t evidence enough for baby and bath water. 
> 
> As david and others say, there’s a lot of different semantics for mapping integers to finite words and groups etc, and the issue here is ultimately a bad choice in target. Int32 is never a portable size for byte arrays.  In c or Haskell. 
> 
> On Mon, Aug 10, 2020 at 7:10 AM Vanessa McHale <vamchale at gmail.com <mailto:vamchale at gmail.com>> wrote:
> 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 <carter.schonwald at gmail.com <mailto:carter.schonwald at gmail.com>> 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 <hvriedel at gmail.com <mailto:hvriedel at 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_module_names_when_uploading/dbzegx3/ <https://old.reddit.com/r/haskell/comments/5lxv75/psa_please_use_unique_module_names_when_uploading/dbzegx3/>)
>> 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
>> <libraries at haskell.org <mailto:libraries at 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 at haskell.org <mailto:Libraries at haskell.org>
>> > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries <http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries>
>> _______________________________________________
>> Libraries mailing list
>> Libraries at haskell.org <mailto:Libraries at haskell.org>
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries <http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries>
>> _______________________________________________
>> Libraries mailing list
>> Libraries at haskell.org <mailto:Libraries at haskell.org>
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries <http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries>
> 
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20200810/571edf32/attachment.html>