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