1 patch for repository http://darcs.net/screened:

patch 00a15f41d126b499e6bf6f68b5098c75ae73715b
Author: Ben Franksen <ben.franksen@online.de>
Date:   Fri Sep 21 16:25:54 CEST 2018
  * use cryptonite instead of cryptohash and random
  
  This also replaces our own implementation of SHA1.
  
  It is unfortunate that we have to add the memory package as a dependency
  but there is currently no other way to get at the content of a Digest.

Attachments

• patch-preview.txt
• unnamed
• use-cryptonite-instead-of-cryptohash-and-random.dpatch

I am hesitating to screen this because I am unsure wether replacing 
randomRIO with seedToInteger <$> seedNew makes any sense. I may 
decide to rebase the patch with this change undone.

BTW I opened an issue with cryptonite re having to add memory as a 
dependency but received no replies yet.

After reading a bit through the sources of both cryptonite and random 
package I decided that using cryptonite here makes sense. Granted, 
the patch hashes which rely on the system entropy aren't temper proof 
anyway, since they hash only the meta data and not the patch content. 
Still, what the standard implementation of randomRIO uses to seed its 
RNG is really extremely simple minded: it just reads the system 
clock! So if we depend on cryptonite anyway we might as well use its 
high quality system entropy source, if only to discourage future 
contributors from using the function from the random package when it 
might actually hurt us.

I am screening this patch now as it is.

Darcs.Util.Compat still imports System.Random on Win32 (so screened
now doesn't compile on Windows).

Should we just restore the random dependency conditionally on Win32, 
or is there a better approach?

I think Darcs.Util.Compat is obsolete and should be replaced by using
the temporary package which claims to be portable. The remaining code in
there should be transferred to Darcs.Util.File. A good move in any case:
yet another piece of obscure low-level hackery removed from our code
base is worth adding this (small) package, that does exactly what we
need and nothing more, as a dependency.

We should also support hard links on Windows. NTFS has them and the 
possibility that the filesystem does not support hard links is 
covered anyway (I have been using a FAT formatted memory stick with 
no problems). We already depend on unix-compat which gives us 
portable hard-linking via re-exports from either unix or win32 
package and I checked that hard-linking is supported. There would be 
a little more to do to support replacing a file with a hard link but 
that shold be easy.

I can do the coding but I need somone to test that it works on 
Windows and perhaps other OSes.

See issue2604 for another part of Darcs.Util.Compat that we can and 
should get rid of.

Accepting this now as the Windows build was fixed by patch1742.
The actual code change is a good cleanup.