Skip to content

Require tls >= 2.1.2 (close #548) #563

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

Merged
merged 1 commit into from
Mar 26, 2025
Merged

Require tls >= 2.1.2 (close #548) #563

merged 1 commit into from
Mar 26, 2025

Conversation

sol
Copy link
Collaborator

@sol sol commented Mar 26, 2025

No description provided.

@sol
Copy link
Collaborator Author

sol commented Mar 26, 2025

http-client-tls-0.3.6.4 needs a Hackage revision to add tls >= 2.1.2.

@snoyberg if you give me the appropriate permissions, then I'm happy to add it.

@snoyberg
Copy link
Owner

Thanks @sol. I think you should have permissions on Hackage now, though there may be some cache bug on Hackage (the edit page shows you as part of the maintainer set, but the view page doesn't). Let me know if you have any issues.

@sol
Copy link
Collaborator Author

sol commented Mar 26, 2025

@snoyberg everything working, thanks a lot.

@sol sol merged commit b683436 into master Mar 26, 2025
20 of 22 checks passed
@sol sol deleted the deps branch March 26, 2025 11:04
@snoyberg
Copy link
Owner

And thank you for all the work on these packages!

@adamgundry
Copy link

This revision appears to have ruled out some legitimate install plans, e.g. https://www.stackage.org/lts-22.43 includes tls-1.8.0 and http-client-tls-0.3.6.4, but that is now out of bounds. Perhaps it is too restrictive?

@sol
Copy link
Collaborator Author

sol commented Mar 26, 2025

@adamgundry I only confirmed that tls == 2.1.1 results in a build failure. Let me see what I can do.

@sol
Copy link
Collaborator Author

sol commented Mar 26, 2025

@adamgundry from what I understand, the underlying issue is that various versions of tls do not build, likely due to wrong constraints. I'm not in a position to debug this.

How I see it, it is not harmful for new users to use a more recent version of tls.

As for existing build plans (aka version pinning, freeze files) they also need to pin the exact Hackage revision.

I would hope that both cabal freeze and Stackage handle this correctly.

@adamgundry does this lower bound cause any issues for you?

@adamgundry
Copy link

It's not a major issue for me, because indeed I can pin the Hackage index-state and/or bump tls. I was just slightly confused as by coincidence I was constructing a build plan this morning based on LTS-22.43, and tripped over the fact that the constraints in https://www.stackage.org/lts-22.43/cabal.config aren't solvable given the latest index-state. But I'm happy for you to judge what if anything should be done about this. :-)

@sol
Copy link
Collaborator Author

sol commented Mar 26, 2025

@adamgundry I added another Hackage revision that I think addresses this.

To make this more robust in the future I assume Stackage would just need to set the index-state of the generated cabal.config to an appropriate value (and I guess those files should really be called cabal.config.freeze). If you happen to open a feature request for this, then please tag me.

@adamgundry
Copy link

Thanks! That does indeed permit the LTS-22.43 install plan to go through.

I've opened commercialhaskell/stackage-server#344 with the Stackage feature request.

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 this pull request may close these issues.

3 participants