Deprecating fromIntegral

[Carter Schonwald]

well said.

On Mon, Aug 10, 2020 at 12:12 PM Eric Mertens <emertens at gmail.com> wrote:

> 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> 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>
>> 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>
>> 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/
>>> )
>>> 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
>>>
>>> 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> 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 at haskell.org
>>> > 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
>>>
>> _______________________________________________
>> Libraries mailing list
>> Libraries at haskell.org
>> 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
>
>
> _______________________________________________
> 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/a61f7cd6/attachment.html>