Ghost-cli fails to upgrade under Node 18 (stable)?

npm WARN EBADENGINE Unsupported engine {
npm WARN EBADENGINE   package: 'ghost-cli@1.23.1',
npm WARN EBADENGINE   required: { node: '^12.22.1 || ^14.17.0 || ^16.13.0' },
npm WARN EBADENGINE   current: { node: 'v18.12.0', npm: '8.19.2' }
npm WARN EBADENGINE }

Any news on when ghost-cli will support latest Node stable release?

FYI - v18, was released in April, and Node stable was switched to v18 on 25th Oct.

looks like it’s in the pipeline…

See here for supported versions.

There’s no guarantee, but it usually takes 1-2 weeks for the latest LTS version to be supported.

1 Like

Thanks - but problem is that our mandated security policy is to apply the Node upgrade as soon as it goes Stable/LTS… (actually 3 days after).

We leave the Ghost instances running - using dead inodes - but clearly the lag is not good.

If there are any urgent security updates or a power cycle this may cause issues for all Ghost instances - in the worst case, all blogs offline until the pull request is merged and packaged for release.

I’ve noted this internally as a Ghost gotcha - expect Ghost instability for two weeks every October. I’ve asked - but the gods of security insist that Node upgrades take precedence over Ghost stability. :cry:

That’s an… interesting security posture :upside_down_face:

2 Likes

Yeah :) - We’re a bit paranoid about keeping Node and associated up-to-date given the dependency explosion. Node 18 has been in active use since April, we use it for a number of in-house apps, and this is also partly about making sure that unmaintained modules are identified soonest.

Once, many years ago (>20), forensics showed that we were about 15 minutes late in applying a patch on a late Monday morning. An active exploit defaced one of our non-critical static sites.

Never forget, never delay is now one of our maxims.

I have no qualms with this :smile: It’s just that generally new LTS versions of node won’t be any more secure than older LTS versions - so it’s more critical to be on the latest minor/patch than major (unless I’m missing something :stuck_out_tongue:).

Been 3 weeks now. In the past Ghost added the LTS versions inside a week at max from the looks of it.

Yay - I see that Ghost added support for Node 18 sometime in early January.

Timely given this mornings CVE notice on Node security releases going out now.

Assuming the CVEs are covered in the 2023-02 security releases, all maintained versions had updates. I completely agree that vulnerable versions of software should be upgraded ASAP, but I’m still having trouble understanding how node 18 LTS is any more (or less) secure than 16 LTS.

Node is used by packages other than Ghost - they don’t always backport fixes - including CVEs - to old versions of their packages on old versions of Node.

It’s the same for most infrastructure - generally databases, web servers, operating systems, hypervisors etc. recommend you run their latest stable versions when you can.

Good infra - like Node - continue to backport to old versions - so you can pin yourself to v16 if you want to. It’s surprising to make this a policy though, and I certainly wouldn’t recommend it - but you be you :blush:

I would be very surprised if an LTS version of node did not receive a security update. The entire premise of LTS/maintenance versions is for security :wink:

To be clear, I’m not suggesting that people should use v16. I’m saying that since v16 is receiving the same security support as v18, it’s wrong to imply that v16 is less secure, especially on public forums not targeting infrastructure/security people.

Yeah - but it’s not just Node itself you have to worry about - it’s the entire ecosystem of dependencies - and they don’t all follow the Node cadence.

If you are pinned to a maintenance version, npm audit might be a useful check.

Ahh, I missed that part in your initial response, and that’s a great point! However, in the case of an “app” (vs library) like Ghost, it still wouldn’t make a difference since Ghost’s policy is to support LTS node versions - so if a library releases a version that e.g. drops node 16 support in 2.5.0, Ghost would be pinned to e.g. 2.4.3 until node 16 is no longer LTS. If there was a security release (e.g. 2.5.3), it would be up to Ghost to either determine that staying on 2.4.3 is fine (e.g. the usage of the library in the app is such that the vulnerability can’t be exploited), or to get a version of the library with the security fix that also supports node 16.