6 ms·

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 afte

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?

turboponyy 1y ago
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.
easton 1y ago
> 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 1y ago
  Those are also the sorts of people who could pay for commercial support past the EOL date, no? (endoflife.date/nodejs indicates this exists.)
tracker1 1y ago
... then your infrastructure deployment keys leak as a result.
- niffydroid 1y ago
  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.
nicoburns 1y ago
Surely 101 of "come back to a project and it still works unchanged" is "dont use proprietary hosted services"?
- haskellshill 1y ago
  As well as "don't use anything JS related"
  - pjmlp 1y ago
    It works as long as one keeps to vanillaJS, it is a great framework.
    - haskellshill 1y ago
      No, sorry, poking fun at the uselessness of JS frameworks still does not make JS a good language
      - nicoburns 1y ago
        Whether it's good or not is subjective, but plain JS definitely has a very good story around backwards compatibility.
toomuchtodo 1y ago
> 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.
- haskellshill 1y ago
  I mean he's been running version 20 for years already, what's changed to make it now suddenly insecure?
  - toomuchtodo 1y ago
    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.
  - pixl97 1y ago
    Everything is insecure, the question is has anyone found the vulnerability in it yet
    - haskellshill 1y ago
      That's a very stupid gotcha because the newly released code is just as insecure, only it's been audited for shorter
zenmac 1y ago
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.
apatheticonion 1y ago
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/.github/workflows/deploy.yaml#L23 https://github.com/alshdavid-templates/siteforge/blob/main/....
- koolba 1y ago
  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 1y ago
    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 1y ago
  uses: actions/checkout@v4 That uses the Node that is provided by GitHub, and that will break in the future.
danpalmer 1y ago
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.
csomar 1y ago
> 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.
tuananh 1y ago
you use their shared runner, that's what you should expect.
thiht 1y ago
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.
madeofpalk 1y ago
You can host the GitHub actions runner yourself and decide which node versions you want to keep around
rkagerer 1y ago
literally code execution as a service As in, kills your old build code dead?
cryptonector 1y ago
Stuff rots even when you self-host just because of OS updates.
solid_fuel 1y ago
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.

turboponyy 1y ago

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.

easton 1y ago

> 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 1y ago
Those are also the sorts of people who could pay for commercial support past the EOL date, no? (endoflife.date/nodejs indicates this exists.)

tracker1 1y ago

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

niffydroid 1y ago
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.

nicoburns 1y ago

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

haskellshill 1y ago
As well as "don't use anything JS related"
- pjmlp 1y ago
  It works as long as one keeps to vanillaJS, it is a great framework.
  - haskellshill 1y ago
    No, sorry, poking fun at the uselessness of JS frameworks still does not make JS a good language
    - nicoburns 1y ago
      Whether it's good or not is subjective, but plain JS definitely has a very good story around backwards compatibility.

toomuchtodo 1y ago

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

haskellshill 1y ago
I mean he's been running version 20 for years already, what's changed to make it now suddenly insecure?
- toomuchtodo 1y ago
  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.
- pixl97 1y ago
  Everything is insecure, the question is has anyone found the vulnerability in it yet
  - haskellshill 1y ago
    That's a very stupid gotcha because the newly released code is just as insecure, only it's been audited for shorter

zenmac 1y ago

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.

apatheticonion 1y ago

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/.github/workflows/deploy.yaml#L23 https://github.com/alshdavid-templates/siteforge/blob/main/....

koolba 1y ago
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 1y ago
  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 1y ago
uses: actions/checkout@v4 That uses the Node that is provided by GitHub, and that will break in the future.

danpalmer 1y ago

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.

csomar 1y ago

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

tuananh 1y ago

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

thiht 1y ago

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.

madeofpalk 1y ago

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

rkagerer 1y ago

literally code execution as a service As in, kills your old build code dead?

cryptonector 1y ago

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

solid_fuel 1y ago

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.