[bramblerose]

I find the repeated deprecations on GitHub Actions frustrating to work with. One of the key goals of a build system is to be able to come back to a project after several years and just having the build work out of the box.

Yet with GHA I need to update actions/checkout@v2 to actions/checkout@vwhatever (or, what I'm doing now, actions/checkout@main because the actual API haven't actually changed) because... some Node version is "out of maintenance"?!

GHA is literally code execution as a service. Why would I care whether the Node runner has a security vulnerability?

[toomuchtodo]

> GHA is literally code execution as a service. Why would I care whether the Node runner has a security vulnerability?

"Why do I care if there is a potentially insecure code interpreter in my arbitrary code execution service?"

As someone where appsec is a component of my work in financial services, please believe you should care.

[burnt-resistor]

NPM package security is a far bigger problem than some ephemeral invocation that probably isn't under PCI-DSS or HIPAA and doesn't serve content to the wild interwebs. Amount of caring should be nuanced for the use-case rather than projecting blanket, absolutist declarations.

[haskellshill]

I mean he's been running version 20 for years already, what's changed to make it now suddenly insecure?

[nicoburns]

Surely 101 of "come back to a project and it still works unchanged" is "dont use proprietary hosted services"?

[haskellshill]

As well as "don't use anything JS related"

[danpalmer]

I think GitHub Actions is missing a distinction between builds and automation.

When I build my software I care less about eliminating security vulnerabilities (after all, I need to build while updating to fix security issues), but also don't need, or ideally don't want any external access. A vulnerability in the build toolchain should be encoded into the artifacts but shouldn't necessarily prevent artifacts being generated.

However when I automate processes, like categorising bugs etc, I care a lot about eliminating security vulnerabilities because there is necessary external access, often write access, to my sensitive data.

GitHub considers these two things the same, but they're distinct use-cases with distinct approaches to maintenance, updating, and security.

[apatheticonion]

Then don't use the GitHub Actions defaults? Write your own Nodejs install script and use that instead.

That's what I do and it's pretty stable: https://github.com/alshdavid-templates/siteforge/blob/main/....

[koolba]

Why both the pipe into sh and eval? The latter could handle all everything.

Couple more thoughts and unsolicited feedback from a quick eyeball:

- Use https://

- Wrap everything in a shell function to ensure that partial content is not executed.

- Wrap variable substitutions with "${OUTPUT_DIR}" to prevent arg splitting if they contain whitespace. Line 124, `rm -rf $OUT_DIR_INSTALL` is pretty scary if invoked with whitespace in OUT_DIR.

- Download nodejs tarball to temp directory and then extract them to prevent partial extraction

[bramblerose]

   uses: actions/checkout@v4

That uses the Node that is provided by GitHub, and that will break in the future.

[easton]

> Why would I care whether the Node runner has a security vulnerability?

I’m guessing they know you don’t care, but the big company customers cant have a CVE anywhere and won’t accept a EOL node version so they can check a box on something.

(I guess there’s also people with self hosted runners, who might be running them inside networks that aren’t segmented.)

[Wowfunhappy]

Those are also the sorts of people who could pay for commercial support past the EOL date, no? (endoflife.date/nodejs indicates this exists.)

[csomar]

> Why would I care whether the Node runner has a security vulnerability?

Because that "build" process has free access to your repo and potentially your organization. If your repo is also where you deploy from, then potentially deploying a vulnerable version of your software, live to your users.

[turboponyy]

If that's something you care about, then don't define your CI build in terms of GitHub Actions steps. Instead, call your build that takes care of using whichever version of Node you want in CI.

[solid_fuel]

Real question here - why is `actions/checkout` dependent on Node at all? Seems like we wouldn't need to be on `actions/checkout@v5` at all if it was just written in, say, shell.

[madeofpalk]

You can host the GitHub actions runner yourself and decide which node versions you want to keep around

[thiht]

Are you serious? Is updating dependencies and runners controversial somehow?

Just update your dependencies, it's not that hard. And it's even easier when you do it routinely as part of a deprecation planning.

[rkagerer]

literally code execution as a service

As in, kills your old build code dead?

[cryptonector]

Stuff rots even when you self-host just because of OS updates.

[zenmac]

That's why we should have all the dependencies for the project in our own repo!

Then don't use Docker. You never know the image you are using will be outdated.

[tuananh]

you use their shared runner, that's what you should expect.

[tracker1]

... then your infrastructure deployment keys leak as a result.

[niffydroid]

I don't expect to come back after x years and a build system to work. You're very much at the mercy of multiple components in your stack and environment. For example you could be on a Mac and 2 years ago you were using x64, but now you are on ARM64. Whole load of stuff just breaks from that alone.