web: Update docker node from 24 to 24-alpine

[tygyh]

Description

Switch to alpine since it is smaller

Checklist

• I, a human, have self-reviewed this PR and fully understand the changes within.
• I have made or updated tests where possible.
• All of my commits are properly scoped, compile successfully, and pass all tests.
• This PR does not make sense to split up into smaller PRs.
• An LLM was involved in the authoring of this code.

[kjarosh]

This image is not used in production, it's used for building.

[tygyh]

Does that mean this PR is not relevant?

[kjarosh]

It means that these vulnerabilities can be exploited only during building.

For this specific Dockerfile, it means that https://github.com/WebAssembly/binaryen, https://sh.rustup.rs, a crate, or this repo would have to be malicious. We have to assume this repo cannot be malicious (the Dockerfile is a part of this repo). If a crate is malicious, we're doomed anyway. Even if https://github.com/WebAssembly/binaryen or https://sh.rustup.rs becomes malicious, how do they exploit a vulnerability in the image? In order to break out of the container they would have to exploit a vulnerability in dockerd or the kernel (which are not a part of the image). Without breaking out of the container they can do malicious stuff inside the container, which in this case means producing malicious outputs. But even without vulnerabilities in the image they can easily do that. Now, assuming that they can somehow exploit a vulnerability in the image—they run as root, so they can do whatever they want inside the image anyway.

So the possible vectors are extremely limited; I'm not even convinced there are any.

However, we might want to change the base image due to completely different reasons: build reproducibility and image size. Alpine is smaller, and pinning the version means that we cannot (or at least the probability is smaller) get a different image at different points in time. For that, there's the question of whether switching to Alpine won't break anything and whether we care about build reproducibility. I think @torokati44 knows more about these things.

If you really care about making the build image more secure you could: (1) add checksum checks for binaryen, and (2) install rust through the package manager and not rustup. This will make sure we're downloading what we expect inside the image. Option (2) is more difficult because node:24 uses Debian, which has ancient packages, so we would have to switch the distro anyway.

[torokati44]

This Dockerfile is not even used by us at all: it's provided only for the convenience and as compensation for lack of competence or concern for the reviewers at the Firefox add-on store (AMO).
I do remember them having issues with running out of disk space on their VMs they use to check the addons, and we even had to take some steps to alleviate this for them. So, if we can use a smaller base image with no issues, that would be nice also. Although, this hasn't been a problem for a while now, I think.
And about version pinning: this also hasn't been a problem, and I think we have enough lockfiles and pins in place that we can go with just node:24-alpine here, for the time being. That won't have to be bumped (and forgotten to be bumped) so often.

[torokati44]

Could you please manually trigger the "Test extension builder Dockerfile" workflow in your fork, for the branch that's the source of this PR, and link the run here?

[torokati44]

Seems like wget and/or tar would have to be installed manually - it makes sense, as the proposed base image is fairly bare as it comes.

[torokati44]

This works BTW:

torokati44@0657306
https://github.com/torokati44/ruffle/actions/runs/25735382419/job/75570902363

[torokati44]

The (compressed) base image size goes from 389.14 MB to 54.01 MB with this:
https://hub.docker.com/layers/library/node/24/images/sha256-ab2405755a2e7c7f3749f2d1a703d0a3f95bf6d59357da8f2bb309f79f67b573
https://hub.docker.com/layers/library/node/24-alpine/images/sha256-8e2c930fda481a6ec141fe5a88e8c249c69f8102fe98af505f38c081649ea749

EDIT: Although the apk add wget tar build-base command will install 278.8 MiB in 43 packages.
Still, the original goal of reducing vulnerabilities still holds, even if not of paramount importance (as commented above by @kjarosh).

[kjarosh]

I don't think we are actually reducing vulnerabilities, I think this is a security no-op. If you want to reduce vulnerabilities, you can make the dockerfile not download unchecked executables from the internet. Then, and only then, we can start caring about tar and wget vulnerabilities.

[tygyh]

I changed the description to get this done. I don't know how to do any of the other suggested changes, so let's leave it like this for now. :)