[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.

[toomuchtodo]

I believe the guidance holds true regardless: only maintained code should run in these execution contexts. Otherwise, you are assuming more risk (needlessly, imho). How much more risk? I cannot say. Everyone’s risk appetite is different, but hosted providers clearly have an incentive to reduce their risk, as do most businesses.

If you want to run builds with old containers running old code on your personal equipment, sure, that’s fine, the impact is likely limited to you. A person has little financial, liability, or reputational risk.

[goku12]

Why is Github enforcing that decision rather than leaving it to the developer to enforce it as part of their workflow? At the bare minimum, why not give the developer the option to override the decision? Something on the lines of "Do you really want to run node 20?"

The article shows that such an option does exist. But it will be phased out in 3 stages, making it impossible to run node 20 eventually. This really does disrupt the standard software development practice of reproducible builds. Safety determinations must be implemented orthogonally to reproducible builds.

Ultimately, this is the next stage in the war on computing freedom and general purpose computing. They're moving from "We decide what you're allowed to run." to "We decide what you're allowed to develop." I know that many will object to this calling it an overreaction and claim that nobody is forced to use their CI/CD system. But as history has shown time and again, lock-in and restrictions come in numerous small doses that are individually too small to trigger the alarm bells among the general population.

[bingo-bongo]

> Why is Github enforcing that decision..

Because at the end of the day, Github is responsible for _their_ runners.

If you want full control, install and use your own runners, which flips the responsibility to you.

[goku12]

> If you want full control, install and use your own runners, which flips the responsibility to you.

It's a bit tedious to have to explain that service providers have certain responsibilities and obligations too. Corporate culture has given bigtech a blank cheque to behave the way they want. That aside, based on the way you framed your reply, let me assure you that I don't trust them with even my projects, much less the CI system or their runner. And time and again, they vindicate that decision. I have posted the full argument as a reply to your sibling comment.

[siva7]

I'm still paying for these github runners. There is also some line between fully dictating which versions of languages and packages you are allowed to use and a managed runner that doesn't get in your way like a control freak.

[cowl]

because your "yes" might mean you are putting other projects at risk depending on the vulnerability. Computing freedom applies only on machines YOU control. you can't expect to be able to do everything you want on hardware others control.

go buy some servers, put any github lookalike service in there and you are completely free to run with Node v1 if you really want.

[jstanley]

But it's a CI system! It is literally running code you provide. You could put Node 20 in there if you wanted anyway.

[electroly]

You can absolutely install Node 20 yourself on GitHub's runners if you want and GitHub is fine with that. GitHub itself, and other projects, are protected by isolation from your workloads. Their security does not depend on the software you're running in your workflow. TFA is just talking about the version that comes preinstalled and is used by JavaScript-based actions.

[goku12]

> because your "yes" might mean you are putting other projects at risk depending on the vulnerability.

By ruining build reproducibility through such short sighted decisions, you are actually compromising a security measure. And I already proposed a way to overcome this problem if you insist on disabling node 20 by default - provide a way to explicitly override it when needed.

Besides, the security model you suggest isn't even the correct way to deal with supply chain vulnerabilities. They have to be version-flagged at the artifact distribution point, not at the CI stage by unilaterally imposing backwards-incompatible restrictions.

> Computing freedom applies only on machines YOU control. you can't expect to be able to do everything you want on hardware others control.

There are two fundamental issues with that argument here. Any user depends on services like these after entering an agreement with a service provider (Github). Even free tier users agree to the ToS. This is significant because the developer(s) are making an investment on the provider's service. GAs are not seamlessly transferrable to any competing service, even ones that try to replicate GA. The users are basically soft locking themselves in to the platform. It takes nontrivial effort from the user if they want to migrate away. In such situations, it's only ethically and morally correct for the service provider to never blindly pull the rug from under the users like this. This is especially true with paying customers.

The second problem with that argument is that it's not fair for the service provider to keep shifting the goal post once the restrictions have been agreed upon by both parties. In case of GA, the developers are not doing whatever they please on Github's servers. Their actions are executed within a restricted context with predefined restrictions. Any damage is restricted to that context and is ephemeral. Arbitrary modification of those restrictions later on only creates headache for the developers without any meaningful benefits.

> go buy some servers, put any github lookalike service in there and you are completely free to run with Node v1 if you really want.

I stay away from GH as much as possible precisely because this uncaring attitude of theirs. As I explained earlier, it's not trivial to migrate even to GA lookalikes. I would rather target a different platform that wouldn't randomly rugpull from under me like this.

[burnt-resistor]

You're spreading FUD, assuming unprofessionalism, and making a strawman argument based on nebulous hypotheticals and assuming the worst intention and stupidity. There are plenty of vendors who $upport "unsupported" versions of many languages, libraries, and frameworks with backported security and functionality patches for things that matter that are too expensive to update and are outside of FOSS support. For other things that don't matter, sometimes prototyping or one-of runs the functionality of executing is far more important than any or all CVEs that aren't exposed in any material manner. This is the definition of nuance.

[toomuchtodo]

I am sharing my professional opinion based on real world experience and subject matter expertise, so others can take what is of value and disregard what is not. You are free to disregard it in its entirety if you wish.

My day job org is a Github customer with a few hundred thousand dollars of annual spend with them, so while we get their ear, we don't move the needle with regards to product changes (their customer success team is very helpful when they can be though). I imagine the situation is not as great if you are a free user, or someone with immaterial spend with them; you're simply along for the ride.

As always, do what is best for your risk and threat model.

[haskellshill]

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

[pixl97]

Everything is insecure, the question is has anyone found the vulnerability in it yet

[haskellshill]

That's a very stupid gotcha because the newly released code is just as insecure, only it's been audited for shorter

[toomuchtodo]

I look at it as “The risk of running unmaintained code on an old interpreter version is difficult to quantify and therefore it is low cost and effort to require it run on a maintained, recent version.” Developers will argue their time is too valuable to require such code be updated to run on recent interpreter versions, and I’ll argue it’s cheaper than chasing successful exploits and any footholds established. Dev Vs Ops, a tale as old as time.

Perhaps having had to run down potential exposure across a large enterprise from the recent npm supply chain attack has made me a bit more paranoid lately around supply chain and cicd security. But, I get paid to be paranoid, so it is what it is. Run your own runners I suppose? Hard to complain when someone else is running the infrastructure for you (and you’re not paying enterprise prices). Supply chain and hosted/multi tenant execution code security is just fundamentally hard and fraught with peril. Ongoing deprecations to keep up with current state are therefore unavoidable.

[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"

[pjmlp]

It works as long as one keeps to vanillaJS, it is a great framework.

[haskellshill]

No, sorry, poking fun at the uselessness of JS frameworks still does not make JS a good language

[nicoburns]

Whether it's good or not is subjective, but plain JS definitely has a very good story around backwards compatibility.

[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

[apatheticonion]

I could be wrong but I don't think you can set shell variables from the pipe, right?

    echo "export FOO=bar" | bash
    echo $FOO

I am trying to set the variables in the current shell

   eval $(echo "echo 'export FOO=bar'" | bash)
   echo $FOO

So my script writes variables to stdout and redirects everything else to stderr. I use this to update a `.bashrc` while also updating the current shell

[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.