I understand that there is a need to fork the popular memory package, from version 0.18.0.
memory is a dependency of Stack and I have been thinking: “Perhaps I could step up and do that?” However, I have hesitated, thinking: “But surely there is somebody else better placed than me?”
So, I raise this topic here, in case others are thinking much the same, and also hesitating, for much the same reason.
The need for a fork arises because the maintainers of memory do not wish to develop it further but its primary author also does not want to introduce other people as maintainers, for the reasons that he has set out elsewhere. I’m not raising this topic to debate those reasons, but with the aim of moving things forward.
If I published a fork, I am thinking that memoria would be a good name. It is Latin for memory and it chimes with the word for memory in a number of European languages.
I suggest migrating libraries that use memory to alternative libraries(e.g. Base16, Base32, or Base64 encoding). Features without replacements could be divided into smaller libraries.
if you believe you can either maintain the package or add maintainers to do so for you then you probably could just publish a fork. while maybe someone will even then eventually publish a fork, a chance of having 2 forks is better than a chance of having 0
For the password / password-types packages, we’re mostly only using memory because it’s one of the few packages I’ve found to have a constant time equality function for Bytes(trings).
If we can find a different package (or bytestring could get one) then we wouldn’t need the memory dependency anymore.
My motivation was not so much ‘because Stack depends on memory…’ but more ‘as Stack depends on memory…’. However:
Stack uses Crypto.Hash.hashWith from the crypton package (the fork of cryptonite, now maintained by Kazu Yamamoto) to hash bytes into a digest - and crypton depends on memory.
However, I hope you have a maintenance strategy. Just forking and leaving it on life support is probably not a good idea, especially for this type of package.
“Community maintenance” is mostly a pipe dream, imo. Drive by contributions mess up the original design and no one really establishes deep expertise.
“Community maintenance” is mostly a pipe dream, imo. Drive by contributions mess up the original design and no one really establishes deep expertise.
Agreed.
Security is a full-time job, and often a thankless one at that. So relying on “wandering minstrels” or “giggers” isn’t only impractical, it can give a false sense of security, as amusingly illustrated in this XKCD rendering (chosen by the maintainer of cryptonite and memory):
with the last/only security “minstrel” or “gigger” being some other random person in Nebraska.
That a full-time security taskforce for Haskell wasn’t available to take charge of cryptonite before it was forked is unfortunate: that is now history. But how many more times will that history be repeated:
Which hashes in particular? It seems SHA-1 and SHA-256 from searching the source code from github.
I think people generally use cryptohash-* libraries for a simple dependency. It seems that cryptohash-sha256 is already in the dependency closure of stack and there is the cryptohash-sha1 package which provides a SHA-1 hash implementation.
