Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

make use_crypton default true (or automatic?) #13

Open
bmillwood opened this issue Jul 16, 2024 · 1 comment · May be fixed by #15
Open

make use_crypton default true (or automatic?) #13

bmillwood opened this issue Jul 16, 2024 · 1 comment · May be fixed by #15

Comments

@bmillwood
Copy link

bmillwood commented Jul 16, 2024

@ocheron in #12 (comment) says:

The library has support for crypton through optional flag use_crypton.
I don't plan to make it default at this point.

In the current state with use_crypton manual and default false, I can't write a library that depends on crypton and cryptostore, because I can't specify in my build-depends that I need the flag to be true. (Clients can fix this by specifying constraint: cryptostore +use_crypton in their project file, but I can't make this happen from my cabal file.)

I think removing manual: True to allow the solver to try enabling the flag seems like a harmless improvement, but I'm not sure it would fix the problem. The issue I witness is a type mismatch in my library between cryptonite types coming from cryptostore, and crypton types coming from elsewhere. Since this issue comes up in the build phase and not dependency resolution, I don't think the solver will be able to notice that it should try changing the flag.

For my part, given that the cryptonite package is deprecated on Hackage and seems unlikely to see new versions, I don't see why you'd want to default the flag false or even to continue to support cryptonite at all, but I haven't followed the situation and given your above comment presumably you have a good reason for doing things that way. (I'm not at all opinionated on the difference between cryptonite and crypton, except that I'm trying to use other dependencies that have already switched to crypton.)

bmillwood added a commit to bmillwood/haskell-jwt that referenced this issue Jul 16, 2024
This also requires updating dependencies to use crypton.

Unfortunately, cryptostore will only use crypton if the use_crypton
Cabal flag is enabled, and we can't make that happen from our cabal
file. I opened an issue to ask them to remove `manual: True` from their
flag, so that the solver can try enabling it. See:
ocheron/cryptostore#13
@bmillwood bmillwood changed the title make use_crypton automatic (or default true) make use_crypton default true (or automatic?) Jul 16, 2024
@marinelli
Copy link

Given that cryptonite is not maintained anymore, wouldn't it be more simple to just remove the flag and use crypton only?

9999years added a commit to 9999years/cryptostore that referenced this issue Oct 31, 2024
Remove the `use_crypton` flag, making it the default.

`cryptonite` is unmaintained and deprecated.

> The maintainer has decided to cease all activities in the Haskell
> ecosystem, and for some select packages, forks have been set in place.
> The TLS libraries have been handed over to a new maintainer, but most
> things have been abandoned with no intent to hand over maintainership.

See: https://hackage.haskell.org/package/cryptonite
See: haskell-infra/hackage-trustees#396
See: ocheron#13
@9999years 9999years linked a pull request Oct 31, 2024 that will close this issue
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants