Ghc 8.10

[mightybyte]

This is an update to phadej's pull request bumping the bounds for tasty and criterion to trigger CI.

[mightybyte]

Marked as ready for review to trigger CI.

[mightybyte]

It looks like these changes have passed CI. https://travis-ci.org/github/haskell-hvr/cryptohash-sha512

[dbaynard]

Would it be possible for one of the maintainers to review this PR?

[nbouscal]

@hvr

[nbouscal]

@hvr Can we please get this merged? It's the last thing blocking us on 8.10.

[nbouscal]

@hvr I guess tagging you isn't a good way to bring this to your attention, but here's one last try

[nbouscal]

Just noted that the whole cryptohash* family is deprecated: https://github.com/vincenthz/hs-cryptohash#readme in favor of cryptonite family, SHA512 is there also. — @Anton-Latukha

From the package description in this repository:

NOTE: This package has been forked off @cryptohash-0.11.7@ because the @ cryptohash@ package has been
deprecated and so this package continues to satisfy the need for a lightweight package
providing the SHA512 hash algorithm without any dependencies on packages other than
@ base@ and @ bytestring@.

[Anton-Latukha]

I made a fork of this PR and brought it up to date, made package support for both epochs of base16-bytestring, the new one was released quite recently. Package also seems to work with new bytestring as well as old one. Also removed some dependency bounds to make stale package in use not constrain the versions in projects downstream and so the patch for hardcode override would work for some time without changes:

The fork is in https://github.com/Anton-Latukha/cryptohash-sha512/tree/ghc-8.10

To override - add the cabal.package file with:

packages: .

source-repository-package
    type: git
    location: https://github.com/Anton-Latukha/cryptohash-sha512
    tag: 48f827eb09a73ad5ee43dd397a06ebdbf51ab856

Sorry - there the Git history is quite messy, well because two downstream projets wanted different things and I had not cared to clean-up the onetime override patch.

We currently have a small stack of software built on it: hnix-store-core, hnix-store-remote, hnix and what depends on them, we run test suites and CI for hashing also, today the hnix-store projets had releases. I do not need to tell you that we now need to migrate from the library asap, or normalize this situation somehow.

I also wrote to the HVR on the email quite a while ago, but then I also was puzzled about the situation: https://github.com/haskell-hvr/cryptohash-sha512.

No wonder he can be quite overwhelmed with stuff.

[sjakobi]

I've asked the Hackage Trustees to make a revision: haskell-infra/hackage-trustees#289

[endgame]

I have used hackage trustee powers to apply the updated bounds in this PR as a new metadata revision. I have not copy/pasted the whole cabal file because the description changed: the description is shorter and drops the discussion of the wider cryptohash-* ecosystem. What's the status of the other cryptohash-* packages, and do they need PRs and metadata updates?

[Anton-Latukha]

What's the status of the other cryptohash-* packages, and do they need PRs and metadata updates?

We use the whole cryptohash-* family and this is the first package to turn stale.
Probably soon would need to update others. SHA-512 just is a less used lib, so updates to it got later, so got in the unresponcive window. If the window continues - of course the next base the other packages would follow.

[ysangkok]

@Anton-Latukha

Just noted that the whole cryptohash* family is deprecated: https://github.com/vincenthz/hs-cryptohash#readme in favor of cryptonite family, SHA512 is there also.

Apparently cryptonite will have trouble upgrading to GHC 9.2. It sounds like cryptohash-sha512 is easier to port. It now has a revision for GHC 9. So maybe there is also an argument for not migrating an existing cryptohash-sha512 codebase to cryptonite given that Vincent is also not very active?

[Anton-Latukha]

That statement (citation that people keep citing) is wrong (as I forgot about that shenanigans story, therefore I deleted statement to stop mislead people). I would abstrain from restating/comments on the story, but we observe the current results.

At least they'd both needed to make sure that enough active/interested people have infrastructure access...

As it can be said (stating the obvious) ... khm cryptohash-* package family was not worked on from the fork/split, the whole set rolled down on the drive-by contributor fixes & version bumps, but eventually no one shows up to merge them.

As you see - the cryptohash-* family is abandonned (to put lightly & shortly), even the 8.10 PR merge is stalled. Therefore so is #8. It is also why https://github.com/Anton-Latukha/cryptohash-sha512/tree/ghc-8.10 was there (but I forgot if all those changes are right).

GHC 8.10.1 was 2020-03-24 (1.25y ago) & its support not merged. GHC 9.0 was more then a half year ago. That meant cryptohash-* set shown its nature. Which meant a set of problems & effort of troubleshooting & workarounds {HNix{,-Store-{Core,Remote},DHall{,-Nix{,pkgs}}, I forgot how much time infra back&forth patching took for me, but it was ~2-4 days, ~5-7 days if to count related effort, which was essentially a wasted time & that is was only me with HNix packages...

To not have that - I already ported projects to cryptonite.

As we see in the mentioned haskell-infra/hackage-trustees#305 (comment)

cryptonite will be massively broken by sized primitives in GHC 9.2, see https://gitlab.haskell.org/ghc/head.hackage/-/blob/master/patches/basement-0.0.12.patch

It means that somebody (this time it was RyanGlScott) developed the patches, and the patches are out of the "project" tree. & that means that cryptohash in fact can 9.2 (if Vincent ever shows-up to merge the done work), but would recieve a API breackage (which I am Ok with).

The proper solution at this point is to take over this hashing stuff, otherwie - deprecate all these abandonments & take over this hashing stuff.