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