Elm built with current Haskell versions (e.g. via nixpkgs) seems to have a tls issue with the package list website:
I need the list of published packages before I can start initializing projects,
so I tried to fetch:
https://package.elm-lang.org/all-packages
But my HTTP library is giving me the following error message:
InternalException (HandshakeFailed (Error_Protocol "peer does not support Extended Main Secret" HandshakeFailure))
Are you somewhere with a slow internet connection? Or no internet? Does the link
I am trying to fetch work in your browser? Maybe the site is down? Does your
internet connection have a firewall that blocks certain domains? It is usually
something like that!
It works fine with the binary release from github.
I believe it may be due to this setting, which defaults to “RequireEMS” nowadays: Network.TLS
Welcome to the Elm community! There are some possible causes and solutions:
Outdated TLS Version or Cipher Support
The server might require a newer TLS version than your system supports. Try updating your system’s OpenSSL or TLS library.
Server-Side Configuration Issues
If the registry (https://package.elm-lang.org/all-packages) is down or misconfigured, you might need to wait or check official channels for updates.
Network Issues (Firewall or Proxy)
If you’re behind a strict firewall or proxy, it might be blocking the secure connection. Try accessing the URL directly in a browser to see if it loads.
Slow or Unreliable Internet Connection
A weak connection might disrupt the handshake. Try using a different network.
That means it was introduced between nixpkgs commits b024ced1aa and dda3dcd3fe. I can try to bisect further, but the ghc 9.6.6 → 9.8.4 and tls 1.8.0 → 2.1.1 updates in there are certainly my first guesses.
Security: BREAKING CHANGE: TLS 1.2 servers require EMS(extended main secret) by default. supportedExtendedMasterSec is renamed to supportedExtendedMainSecret.
My guess is that the elm compiler code uses some higher-level library than tls to make its connection to package.elm-lang.org, and that higher-level library may well not expose these low-level TLS protocol details.
So there may not be an easy way to patch this in the compiler – assuming that’s even a desirable thing! After all, we don’t really want to build a version of the compiler that’s vulnerable to some sort of attack against its communication with the package server. (I am definitely not a TLS expert!)
Just bumped into this after updating nix! It seems like this has been an issue for at least a year, even if it’s only starting to affect nix users now. What do folks see as the most likely path forward in resolving this? Are there admins for the elm package server who are active and reachable who might be willing to update? Or should this be tackled on the nixpkgs side of thing?
I believe it would also be possible to pin an older version of ghc in nixpkgs, but it does seem like supporting the TLS extension on the server would be the better option.
I think we will need to apply patch downstream in nixpkgs because this won’t be accepted upstream anytime soon. Which we could do. There is now even an issue you can subscribe to