Deprecating fromIntegral

[Carter Schonwald]

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
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20200810/357a88ef/attachment.html>