elmPackages.elm: Fix runtime TLS connection to package.elm-lang.org

[turboMaCk]

Resolves #414208 by downgrading version of TLS library used to compile executables.

See upstream issue for more context elm/compiler#2325

• Built on platform(s)
  • x86_64-linux
  • aarch64-linux
  • x86_64-darwin
  • aarch64-darwin
• For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)
  • sandbox = relaxed
  • sandbox = true
• Tested, as applicable:
  • NixOS test(s) (look inside nixos/tests)
  • and/or package tests
  • or, for functions and "core" functionality, tests in lib/tests or pkgs/test
  • made sure NixOS tests are linked to the relevant packages
• Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
• Tested basic functionality of all binary files (usually in ./result/bin/)
• Nixpkgs 25.11 Release Notes (or backporting 24.11 and 25.05 Nixpkgs Release notes)
  • (Package updates) Added a release notes entry if the change is major or breaking
• NixOS 25.11 Release Notes (or backporting 24.11 and 25.05 NixOS Release notes)
  • (Module updates) Added a release notes entry if the change is significant
  • (Module addition) Added a release notes entry if adding a new NixOS module
• Fits CONTRIBUTING.md.

---

Add a 👍 reaction to pull requests you find important.

[YievCkim]

Hello,

I still have the issue:

$ elm init
Hello! Elm projects always start with an elm.json file. I can create them!

Now you may be wondering, what will be in this file? How do I add Elm files to
my project? How do I see it in the browser? How will my code grow? Do I need
more directories? What about tests? Etc.

Check out <https://elm-lang.org/0.19.1/init> for all the answers!

Knowing all that, would you like me to create an elm.json file now? [Y/n]: 
-- PROBLEM LOADING PACKAGE LIST ------------------------------------------------

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!

[miniBill]

@YievCkim what commit of nixpkgs are you on? Make sure you are using one which includes this PR

[YievCkim]

@YievCkim what commit of nixpkgs are you on? Make sure you are using one which includes this PR

Hello @miniBill How can I check that ? I have upgraded my packages just after seen this PR five minutes ago. I follow the channels of last release (2025-05) :

$ sudo nix-channel --list
[sudo] password for mik: 
home-manager https://github.com/nix-community/home-manager/archive/release-25.05.tar.gz
nixos https://channels.nixos.org/nixos-25.05
nixos-unstable https://channels.nixos.org/nixos-unstable

I usually upgrade my packages with:

nixos-rebuild switch --upgrade

Is there something to do ?

[YievCkim]

I found it:

$ nixos-version
25.05.804113.6c64dabd3aa8 (Warbler)

But I have no idea if this one is before or after.

Maybe I have to wait...

[YievCkim]

Ok I think the PR was merged in master but not in release-25.05

[ElvishJerricco]

@NixOS/security

This change downgrades the version of the Haskell tls library used by the Elm compiler to one that's 2 years old and still supports deprecated TLS 1.0 and 1.1 protocols (removed in newer versions of the library). Thankfully, it seems the server in this case is not using those protocols, but the error occurs because the server does not support RFC 7627, aka Extended Master Secret (EMS), which the tls library requires by default as of 2.0.0.

I think downgrading the tls library is not the right solution and poses a security threat to users of Elm package management. For that reason, it seems necessary to me to mark the tls library in this PR with knownVulnerabilities indicating the risk.

An alternative solution would be to patch the Elm compiler to disable EMS when it uses the tls library. I'm not 100% sure, but EMS does not seem relevant to the security of the Elm compiler, so it may be that disabling that would allow it to use the up-to-date version of tls without adding knownVulnerabilities.

---

Finally, it seems abundantly clear that Elm is no longer properly maintained upstream. The compiler repo itself was last committed to almost two years ago. It does not seem appropriate for nixpkgs to include packages like this that are not maintained and require security downgrades to package. I understand there is still an active elm community, but until that community revives maintenance on its core tools and infrastructure, I think removal from nixpkgs could very well be the right decision.

[LeSuisse]

Thanks for the ping and the summary @ElvishJerricco !
I'm not used to Elm but from what I can see the last release of Elm was 6 years ago and parts of the ecosystem seem to be behind in terms of maintenance.

Downgrading the TLS library does not seem like an appropriate solution (there are pretty good reasons why TLS 1.0 and 1.1 and some setups are disabled).

That does not seem like a nixpkgs specific issue. Given it seems there is little chance for short term progress upstream, is there any reason left for us at nixpkgs to tag the whole thing with knownVulnerabilities due to lack of upstream maintenance?

[supermario]

There are Elm users (myself included) who would like to be able to continue using Elm via nixpkgs. I've also tagged Elm's author on Slack to make him aware.

That said – there's definitely something more to this as that original issue referenced is not consistently reproducible (we run Lamdera, a full-stack Elm PaaS with thousands of Elm apps that continues to install packages from packages.elm-lang.org just fine) so I'm skeptical the current assessment of the failure mode has the full picture.

We're actively looking into this.

[turboMaCk]

Elm compiler is using TLS in client code connecting to server running on https://package.elm-lang.org/ The main point of downgrade is to make it compatible with the server.

For hardcode nix users this might not be a big problem. If you're using nix to build your elm you're probably using elm2nix and don't need to use elm binary to fetch dependecies.

Long term elm users might not run into issues either. Elm has a local cache located in $ELM_HOME which by default is $HOME/.elm and another project specific caching layer in elm-stuff directories. Only if you don't have these caches it will try to connect to the server.

Downgrade of this library as you can see is local specifically to the elm package. It doesn't leak anywhere. It's not specific to nixpkgs version. Official binaries, homebrew etc all have the tls 1.* code.

Regarding maintenance - It's fair to say that elm is some 6 years old at this point. But it's still used heavily - including by http://search.nixos.org

[emilazy]

If the issue is that the Elm package server doesn’t support Extended Main Secret and it’s agreed that this is not a meaningful security issue (it seems like lack of EMS breaks the security of session resumption, which the package server advertises support for, but it may be that Elm does not use it on the client end, or it can be disabled), then it seems like using the latest version of tls but explicitly disabling the EMS requirement (at the call site if possible, otherwise via patch) would be preferable to the security risk of using a downgraded package that is vulnerable to downgrade attacks with insecure versions of TLS.

Of course ideally the server would be fixed instead.

[turboMaCk]

@emilazy 100% agree.

I think this merge (downgrade) is not as big of a problem as it might seem. the TLS client really is used only for contacting packages.elm-lang.org.

That's said definitely preferrable option to me would be:

1. open PR that resolves the compatibility issue upstream
2. use this patch on our side and relax the tls again so that security patches will apply

But I don't think removing elm or marking it as vunerable in meantime is necessary. Of course I'm open to arguments.

[YievCkim]

Could you please tell me when this fix will be available in unstable channel ? I try to find the information but excepted checkout the repo I don't see a way to do that from github directly.

[turboMaCk]

@YievCkim This doesn't really belong here and is in general hard to tell because we know nothing about your setup. But in general:

let nipkgsElmFix = fetchFromGithub { ....this is the revision };
in (import nixpkgsElmFix {}).elmPackages.elm

See https://nixos.wiki/wiki/FAQ/Pinning_Nixpkgs

here is one example from my old repo (pre flakes) https://github.com/turboMaCk/planning-game/blob/e505701295ffb9e2fcd6b417d17f31db83d15c97/default.nix#L2-L7

If you're using flake use flake way to do this. There is no black magic. Just get the version of nixpkgs you want to get in a way that makes sense to get in your setup.

[YievCkim]

thank you @turboMaCk for the way to fetch directly from GH. I would like to know when the PR was merged in official channels. Because I follow channels for update. I didn't even know that some people directly follow the master in their setup until today.
So my setup is very simple and basic.
I feel like I'm the only one following the channels for package updates. 😆

[turboMaCk]

This question is impossible to answer since you did not even mention which channel you are actually using. But I would suggest to continue this discussion on https://discourse.nixos.org/ where we can be more specific and it would also be more visible to people more people. I would normally not mind discussing this under PR but there is still some ongoing discussion with security team which needs resolving and dragging all these people through an off topic is not very respectful. Please open a thread there - I'll be checking it.

[YievCkim]

unstable:

Could you please tell me when this fix will be available in unstable channel ?

But we can continue on discourse with pleasure:
https://discourse.elm-lang.org/t/elm-init-tls-issue/10231/14

Or slack:
https://elmlang.slack.com/archives/C0K8VHA6B/p1750090559103629

or matrix:
https://matrix.to/#/!6oudZq5zJjAyrxL2uY:0upti.me/$xpU6Z99Rmd-7IY2nJhkspT6nVxtNdIrQXYJ3dv3rsxg?via=lossy.network&via=matrix.org&via=envs.net

[bmillwood]

Fix purely in elm-compiler: bmillwood/elm-compiler@c8ca5e1

I tested that a previously-failing elm install was able to go ahead with the binary compiled from this branch. I haven't yet gone so far as to make this version of elm the one I use daily. I'm perhaps still hoping that @supermario will get hold of Evan and get this sorted on the server side.

[YievCkim]

oh yes a 0.19.2 🤩

[bmillwood]

I now have this in environment.systemPackages (inside a with pkgs;):

    (haskell.lib.compose.overrideSrc {
      src = fetchFromGitHub {
        owner = "bmillwood";
        repo = "elm-compiler";
        rev = "c8ca5e14650a77446a6577eb356ddd09c3928bac";
        sha256 = "sha256-H9+dOILnszejlylsV7Dd7TFuXuKGc/+7kYeNhN4SVXg=";
      };
    } elmPackages.elm)

I do not know how to turn this into a nixpkgs PR. I'm hoping someone else more familiar with the elm packaging will be able to pick that up.

[turboMaCk]

@bmillwood thanks for stepping up. I think I can open PR for nixpkgs side of things.

[turboMaCk]

Haskell TLS library is no longer pinned to 1.9.0 in master. I believe this resolves all current security concerns. That being said I do aknowledge that

Finally, it seems abundantly clear that Elm is no longer properly maintained upstream. The compiler repo itself was last committed to almost two years ago. It does not seem appropriate for nixpkgs to include packages like this that are not maintained and require security downgrades to package. I understand there is still an active elm community, but until that community revives maintenance on its core tools and infrastructure, I think removal from nixpkgs could very well be the right decision.

is and will keep being problematic. The best we can do is try to resolve all problems as they arise until we will no longer be able to.

Unconfortable as this might be for people who are, like me, invested in keeping elm around I appriciate the honesty @ElvishJerricco

[different-error]

417682 resolved elm init for me!

[miniBill]

@turboMaCk This should now be fixed on the server side, so we can probably revert it?

[turboMaCk]

Yes we no longer need patch for this.

[turboMaCk]

PR #442132