2025-10-28, Version 24.11.0 'Krypton' (LTS)

[richardlau]

2025-10-28, Version 24.11.0 'Krypton' (LTS), @richardlau

Notable Changes

This release marks the transition of Node.js 24.x into Long Term Support (LTS)
with the codename 'Krypton'. It will continue to receive updates through to
the end of April 2028.

Other than updating metadata, such as the process.release object, to reflect
that the release is LTS, no further changes from Node.js 24.10.0 are included.

---

Checklist

Pre-release:

• Create lts-watch-v24.x label

Day of release:

• Add mapping for Node.js 24 → Krypton nodejs-latest-linker#20
• doc: mark Node.js 24 as LTS Release#1123
• blog: add Migrating from Node.js 22 to Node.js 24 nodejs.org#8270 or content(userland-migration): make up to date nodejs.org#8053
• Blog: v24.11.0 release post nodejs.org#8280

[nodejs-github-bot]

CI: https://ci.nodejs.org/job/node-test-pull-request/69881/

📦: https://ci-release.nodejs.org/job/iojs+release/11358/

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 90.02%. Comparing base (9b72b88) to head (3a6b2fa).
⚠️ Report is 3 commits behind head on v24.x.

Additional details and impacted files

@@            Coverage Diff             @@
##            v24.x   #60414      +/-   ##
==========================================
- Coverage   90.04%   90.02%   -0.03%     
==========================================
  Files         663      663              
  Lines      198537   197905     -632     
  Branches    38723    38700      -23     
==========================================
- Hits       178770   178156     -614     
- Misses      12151    12167      +16     
+ Partials     7616     7582      -34     

see 113 files with indirect coverage changes

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[richardlau]

@nodejs/releasers https://github.com/nodejs/node/actions/runs/18811044629/job/53672232661?pr=60414 is failing due to #60050. #60419 will skip the test on macOS on main -- I propose we land that on v24.x-staging after this release (i.e. do not hold the release up for this).

https://github.com/nodejs/node/actions/runs/18811033522/job/53672242950?pr=60414 fails with:

Expected CHANGELOG section title: ## 2025-10-28, Version 24.11.0 'Krypton' (LTS), @
Actual: ## 2025-10-28, Version 24.11.0 'Krypton' (LTS), @richardlau
node:internal/modules/run_main:123
    triggerUncaughtException(
    ^

AssertionError [ERR_ASSERTION]: Release commit is not the last commit in the proposal

75 !== 0

    at file:///home/runner/work/node/node/tools/actions/lint-release-proposal-commit-list.mjs:87:8 {
  generatedMessage: false,
  code: 'ERR_ASSERTION',
  actual: 75,
  expected: 0,
  operator: 'strictEqual'
}

Node.js v20.19.5

which is weird because the release commit is the only commit in the proposal. Is the linter confused because there is no

### Commits

section?

[ChALkeR]

24.x branch currently zero-fills allocUnsafe, likely accidentally (see #60423), since 24.0.0

That causes a significant perf drop in some scenarios compared to 22.x, as it also affects internal allocations
Not sure how realistic those scenarios are actually though (i.e. if that affects real-world usage)

Zero-filling allocUnsafe should likely never be reverted (in 24.x branch) if it gets into LTS release

Upd: see #60423 (comment), I think at this point reverting that is likely semver-major already, regardless of LTS release

[ChALkeR]

Per #60423 (comment) + #60423 (comment), fixing allocUnsafe in 24.x branch should be a blocker here.

And disabling zero-fill-by-default should be mentioned in significant changes for visibility

cc @nodejs/tsc

[mcollina]

We should ideally include a fix for #60423, in this PR or immediately after in a patch release.

[ChALkeR]

immediately after in a patch release.

That would work too if it won't get blocked and will be released e.g. same day

Whatever would prevent ecosystem lock-in on the zero-fill behavior on LTS should work, technical details like patch version number don't matter much (unlike timing)

[ChALkeR]

Ideally isaacs/node-tar#446 also should get in as npm subdep if we disable zero-fill
Not sure if npm uses the problematic codepath though, but the issue was introduced to codebase in #60012

Upd: #60430

[richardlau]

I'm struggling to see that this is a blocker for the LTS transition. The argument seems to be that there code might depend on undocumented behaviour in Node.js, which is a bug in that code. The buffer being zero filled does not break the API description of being uninitialized (it could "just happen" to all be zeros). If the code is depending on the buffer being zero filled then it is already broken on Node.js 22.

From a practical point of view, AFAIK there is no fix proposed for #60423 and suggestions that even if a fix was ready we should not land it until node-tar and npm are updated. That all sounds like a lot of unknowns in terms of how soon this can happen and, if we delayed the transition release, it would not be clear when the new transition date would be.

Also concerns about reverting the zero filling being semver-major implies to be that we should then only revert as a security fix (i.e. in a security release). We have existing provisions for security fixes that are breaking (i.e. normally semver-major) landing in a semver-minor security release (ideally with a --security-revert-* flag).

[ChALkeR]

until node-tar and npm are updated.

#60430 should fix that concern

From a practical point of view, AFAIK there is no fix proposed
That all sounds like a lot of unknowns in terms of how soon this can happen and
would not be clear when the new transition date would be.

The problem already happened, we are already in an unoptimal state
Just ignoring it won't make it go away

Fixing it now would be much better for the ecosystem then disabling zero-fill in an LTS

Also concerns about reverting the zero filling being semver-major implies to be that we should then only revert as a security fix

It is definitely not a security fix. It's the opposite - disabling zero-fill will introduce security issues

--security-revert-* is not applicable here, unless it's the other way around - the behavior is kept to zero-fill and a --no-zero-fill flag is introduced (but that would also come with another pit of problems)

[richardlau]

Let's say for the sake of argument then that we do agree (I'm not sure I do) that we need to hold up the LTS transition.
Per policy, things in LTS are supposed to have been in a current release for two weeks (as additional insurance against regressions). I would be against just landing changes directly into LTS.

So we would need to push out fixes into a Node.js 25 release and then wait two weeks before they could go out in a delayed LTS transition.

The other worry about delaying the LTS transition is that the transition date has been baked into the release schedule.json for over two years and people are just going to assume that Node.js 24 is LTS once the date (28 October) passes.

cc @nodejs/releasers

[richardlau]

@ChALkeR How would you feel about this release happening tomorrow without code changes but messaging in the changelog/release blog post that the behaviour would change as a "bug fix" in a subsequent release? That could draw people's attention to the issue and potentially give them time to evaluate their own code.

[ChALkeR]

@richardlau Which percentage of users/lib authors would you expect to read those release notes?
It will reduce the fallout by about that percentage

Per policy, things in LTS are supposed to have been in a current release for two weeks (as additional insurance against regressions). I would be against just landing changes directly into LTS.

This is actually a very good concern...
Perhaps @nodejs/tsc should decide if reverting the zero-fill should get in then

The problem is what to do if 24 LTS doesn't get it
Will it ever be mergable into LTS then?

In two weeks, a large portion of the ecosystem will update to a version that zero-fills...

people are just going to assume that Node.js 24 is LTS once the date (28 October) passes.

Also a good concern!

Delaying for two weeks doesn't seem to be a viable option

[ChALkeR]

about this release happening tomorrow without code changes

How fast can a fix + #60430 get in if LTS is cut tomorrow without it and includes some messaging about this?

[bolt-juri-gavshin]

Just a random person passing by.
As a user, I can confirm that Buffer.allocUnsafe is used in the actual production code (not only in the libraries) and the intention is indeed to save some CPU cycles, because the whole buffer is overwritten later.

IMHO, the worst decision is to have zero-filling allocUnsafe in v24 medium-to-long term.
If LTS is postponed or 24.12.x contains a fix, both options are much better.

UPD: Everybody upgrading to the latest LTS (especially from v22) should read the notes, changes are quite big.
I personally would read it for sure 😄

[richardlau]

about this release happening tomorrow without code changes

How fast can a fix + #60430 get in if LTS is cut tomorrow without it and includes some messaging about this?

Node.js 25 is scheduled to have a release this week (also tomorrow, but would have less expectations on exact dates). If the fix(es) can get into that then the usual policy would be two weeks after the Node.js 25 release containing the fixes went out.

[ChALkeR]

Reverting zero-filling in an LTS version a month after labeling it LTS is a huge security problem...

[marco-ippolito]

I believe we should proceed with the release. It doesnt seem to me a compelling reason enough to block, we can fix it in the next patch

[ChALkeR]

we can fix it in the next patch

@marco-ippolito how exactly and in what timeline?

[richardlau]

Re. my concerns over the "two weeks in current before LTS" policy, assuming the fix(es) can get into #60436 and that releases tomorrow (or in the next few days) then we're looking at two week's time (i.e. 11 November) to release in Node.js 24 LTS.

There appears to be some disagreement in #60423 as to whether reverting the zero-filling is semver-major or patch. If it is semver-major then we likely cannot revert in Node.js 24 (as 24.0.0 was the semver-major release -- any semver-major related reverts have always been within a few weeks of the *.0.0 release). The LTS transition release is not a mechanism for landing semver-majors in a release line.

My preference is still to release Node.js 24.11.0 as the LTS transition tomorrow (28 October) as planned, and then either a patch release in two weeks (around 11 November) containing the revert or we never revert at all (and live with the performance penalty). I am still not convinced there is a compelling case to delay the LTS transition.

If people want words/warnings/communication to go out in the release blog post or migration document please suggest appropriate words.

[ChALkeR]

What is the performance impact for realistic loads?

[bolt-juri-gavshin]

There appears to be some disagreement in #60423 as to whether reverting the zero-filling is semver-major or patch.

IMHO, reverting zero-filling in allocUnsafe can be classified as a bugfix, meaning it is a patch.
Just 2 cents from a user passing by 😄

[Gabrola]

If there's any code or library (and there is, as demonstrated) that has a security issue because of incorrect usage of allocUnsafe, then it's an already existing security issue for essentially 100% of the users of these libraries since practically no one is on 24.x or 25.x at the moment.

If 24 LTS ships initially with zero-filled allocUnsafe buffers and then gets patched, say in two weeks. That means whoever or whatever is consuming any libraries with existing allocUnsafe-related security issues would go from an vulnerable state (< 24) to a non-vulnerable state (24.11.0), and then back to a vulnerable state (probably 24.11.1). LTS shipping initially with zero-fill behavior only temporarily masks the problem as a side-effect.

I can see this could have been a problem if the zero-fill behavior has been in Node.js for years, and changing this behavior would suddenly make existing non-vulnerable code become vulnerable for millions or thousands of users. However, in this case, releasing LTS initially with zero-fill behavior won't suddenly bring the ecosystem to a vulnerable state.

In my opinion existing applications moving from pre-24 Node.js to 24 LTS is inconsequential of the zero-fill behavior. If they had already existing vulnerable code, they'd stay vulnerable regardless, with just a slight chance of having a blip of an non-vulnerable period. The "risk" of locking-in on the "safe" version and gaining a false sense of security feels like a quite improbable scenario — it would require someone actively checking to gain any sense security in the first place —probably the same kind person that reads docs, release notes, and understand how allocUnsafe should behave 😁

I'd even wager that any chatter around the flip-flopping of this behavior would actually spur some action into checking and fixing existing security issues.

[ChALkeR]

If there's any code or library (and there is, as demonstrated) that has a security issue because of incorrect usage of allocUnsafe, then it's an already existing security issue for essentially 100% of the users of these libraries since practically no one is on 24.x or 25.x at the moment.

Currently, yes. As mentioned earlier, I think if we get this in now it should be likely fine as the usage of 24 is still relatively low.

Even if an LTS version is initially released with zero-fill and then patched in the next few days with proper messaging, it would be effectively the same. #60414 (comment)

#60414 (comment) drew timeline of about three weeks+, which is more concerning, as by then a major part of users will update already and start building stuff. 22.x LTS transition was rapid (3.5x in a month)

[Gabrola]

#60414 (comment) drew timeline of about three weeks+, which is more concerning, as by then a major part of users will update already and start building stuff. 22.x LTS transition was rapid (3.5x in a month)

Yeah, but even if it's a month, I wouldn't say it's a big deal. It's not like people will suddenly start building things with a newfound discovery that allocUnsafe is zero-filling buffers.

• A user that does not read docs and writes code using allocUnsafe incorrectly, probably still would, regardless of the state of the LTS release.
• If you're the kind of user who understands allocUnsafe, especially given the name of the function, you wouldn't assume that the function initializes the buffer, therefore it's not something you'd actively check to lead you to observe this behavior in the first place. Plus, observing that a buffer is full of zeros is not a definite indication that allocUnsafe pre-filled the buffer. Hard to see someone consciously making this conclusion.
• If you're not writing any allocUnsafe code, but instead depending on libraries that might incorrectly use allocUnsafe. This kind of user will probably never be aware of this zero-fill behavior, and therefore this does not affect their course of action. If LTS were to release initially with no zero-fill behavior, their apps would be vulnerable from day 1, rather than be non-vulnerable and then become vulnerable after a while. They would not be aware of the fact at all. The majority of the responsibility here lies on library authors issuing security updates.

[Waldenesque]

I happened to check on this issue for a completely unrelated reason, and stumbled into this unexpected drama. I should have just ignored it, but I'm a child in an adult's body, so I ended up writing two-and-a-half rather lengthy responses to "someone," first more vehement, then less vehement, and finally about halfway back to more vehement. However, I'm going to strive diligently now to at least pretend that I somewhat resemble something approximately mistakable for an adult, if you're not looking too hard anyway, and just leave all that noise unsaid. Instead, I will confine myself to an alternative comment.

Let me offer my thanks to the core Node.js developers for handling this situation in what now looks like it will probably be a sane fashion. In real life everything is always messy, and clinging too hard to theoretical rules to please angels dancing on the heads of pins is often the worst option. In this case I believe the overall best interest of both JS devs and end users would be to continue with the v24 release and LTS transition as normal, call out this allocUnsafe zero-fill matter in the blog post, and then treat the fix as semver-minor or simply a bugfix. Just push it out to v25 and then v24 like you would any other commit, so it will only take a month to get fixed in v24. Or squeeze in an extra v24 release after two weeks if you really want to, but I doubt more than one single person on earth cares too much. And some peeps will always find another molehill to surmount as if the spiritual heirs of Tenz & Ed, so ya just can't please everybody.

It appears that this is exactly how you are likely to proceed. So let me just say, hopefully on behalf of a more general and representative audience of your users...

THANK YOU!

[ChALkeR]

Given the fix exists and is reviewed and landed (thanks, @joyeecheung!) I would suggest to get the change into LTS asap, as initially proposed in #60414 (comment), and not waiting for two weeks

Not necessary in the very first release (if that is not possible), but at least shortly after it

Waiting is just a rule of thumb here that should be bypassable with a TSC decision

Turning the zero-filling off two-three weeks into LTS timeline is most likely worse / more risky than bypassing a rule which entire point is to ensure stability, not reduce it

tar vuln is non-blocking anymore: #60430 (comment), #60012 (comment)

---

Upd: I consider it a breaking change, but it's better to do that earlier and not later into LTS timeline for that reason
It is very unlikely that we'll want to revert it after merging even if it breaks some limited number of setups (e.g., but not limited to, chardet on small files)
The usual stability concerns are bypassed here (so can we get this in earlier than 2-3 weeks?)

[bolt-juri-gavshin]

@richardlau
allocUnsafe is not mentioned in changelog/release notes, only in the blog post, which I didn't expect.
Not everybody (me included) actually reads blog posts, some people read only release notes. Maybe it is worth to add it to the changelog/release notes too?

[richardlau]

@bolt-juri-gavshin #60467