Invalid hash when cryptonite package is loaded, too

[larskuhtz]

The hash function returns a value with all bytes set to 0x00 when also the cryptonite package is loaded. The script below exposes the issue on my system. But it has been found to only show up randomly, so it may be necessary to build both packages in a sandbox a few times in order to reproduce the issue.

#!/bin/bash

cat > Tmp.hs << EOF
{-# LANGUAGE OverloadedStrings #-}
module Main where
import Crypto.Hash.BLAKE2.BLAKE2b
main = print $ hash 64 mempty "abc"
EOF

function get-id { ghc-pkg field $1 id | cut -d ' ' -f 2 ; }

rm -f out
ghc -package-id `get-id blake2` ./Tmp.hs -o out
./out

rm -f out
ghc -package-id `get-id blake2` -package-id `get-id cryptonite` ./Tmp.hs -o out
./out

[larskuhtz]

My guess is that this is due to a clash of C function names that are used in FFI calls. cryptonite and blake2 both use c-code from the Blake2 reference implementation. cryptonite wraps the C API functions from the Blake2 code into functions with a package specific prefix while the blake2 package uses them directly.

[fosskers]

Is the PackageImport necessary there?

[larskuhtz]

No, it's actually wrong. I updated the code snippet above.

[larskuhtz]

Here is a new version

#!/bin/bash

cat > Tmp.hs << EOF
{-# LANGUAGE OverloadedStrings #-}
module Main where
import Crypto.Hash.BLAKE2.BLAKE2b
main = print $ hash 64 mempty "abc"
EOF

function get-id { ghc-pkg field $1 id | cut -d ' ' -f 2 ; }

rm -f out
ghc ./Tmp.hs -o out
echo ghc ./Tmp.hs -o out
./out

rm -f out
ghc -package-id `get-id blake2` ./Tmp.hs -o out
echo ghc -package-id `get-id blake2` ./Tmp.hs -o out
./out

rm -f out
ghc -package-id `get-id cryptonite` ./Tmp.hs -o out
echo ghc -package-id `get-id cryptonite` ./Tmp.hs -o out
./out

rm -f out
ghc -package-id `get-id blake2` -package-id `get-id cryptonite` ./Tmp.hs -o out
echo ghc -package-id `get-id blake2` -package-id `get-id cryptonite` ./Tmp.hs -o out
./out

And here is the result on my system:

[1 of 1] Compiling Main             ( Tmp.hs, Tmp.o )
Linking out ...
ghc ./Tmp.hs -o out
"\186\128\165?\152\FSM\rj'\151\182\159\DC2\246\233L!/\DC4hZ\196\183K\DC2\187o\219\255\162\209}\135\197\&9*\171y-\194R\213\222E3\204\149\CAN\211\138\168\219\241\146Z\185#\134\237\212\NUL\153#"
Linking out ...
ghc -package-id blake2-0.2.0-9dub12qiajHByh7kWe0ZfC ./Tmp.hs -o out
"\186\128\165?\152\FSM\rj'\151\182\159\DC2\246\233L!/\DC4hZ\196\183K\DC2\187o\219\255\162\209}\135\197\&9*\171y-\194R\213\222E3\204\149\CAN\211\138\168\219\241\146Z\185#\134\237\212\NUL\153#"
Linking out ...
ghc -package-id cryptonite-0.25-EwabPtaZ5Zx3eI2SphxvvD ./Tmp.hs -o out
"\186\128\165?\152\FSM\rj'\151\182\159\DC2\246\233L!/\DC4hZ\196\183K\DC2\187o\219\255\162\209}\135\197\&9*\171y-\194R\213\222E3\204\149\CAN\211\138\168\219\241\146Z\185#\134\237\212\NUL\153#"
Linking out ...
ghc -package-id blake2-0.2.0-9dub12qiajHByh7kWe0ZfC -package-id cryptonite-0.25-EwabPtaZ5Zx3eI2SphxvvD ./Tmp.hs -o out
"\NUL\NUL\NUL\NUL\NUL\NUL\NUL\NUL\NUL\NUL\NUL\NUL\NUL\NUL\NUL\NUL\NUL\NUL\NUL\NUL\NUL\NUL\NUL\NUL\NUL\NUL\NUL\NUL\NUL\NUL\NUL\NUL\NUL\NUL\NUL\NUL\NUL\NUL\NUL\NUL\NUL\NUL\NUL\NUL\NUL\NUL\NUL\NUL\NUL\NUL\NUL\NUL\NUL\NUL\NUL\NUL\NUL\NUL\NUL\NUL\NUL\NUL\NUL\NUL"

[larskuhtz]

I guess, the first three cases are just luck, and one should simply refrain from using cryptonite and blake2 together to avoid name clashes for the c functions.

[vaibhavsagar]

@nh2

[centromere]

cryptonite wraps the C API functions from the Blake2 code into functions with a package specific prefix while the blake2 package uses them directly.

If one package is using wrapping and the other is not, how could a conflict exist?