node20 (and other version) binary used for running actions should be fully statically linked (including libc)

[alex]

Description

Currently the node binary that's used to run external actions dynamically links against libc. This has the effect that when used with containers, actions break because of libc symbols not being available:

• https://github.com/pyca/bcrypt/actions/runs/7221890745/job/19677826890 Error relocating /__e/node20/bin/node: fcntl64: symbol not found
• https://github.com/pyca/bcrypt/actions/runs/7221730927/job/19677334188 /__e/node20/bin/node: /lib64/libm.so.6: version 'GLIBC_2.27' not found (required by /__e/node20/bin/node), etc.

In order to insulate the node binary from containers it's running in, it should be fully statically linked.

This can be accomplished with --fully-static argument to configure when building node (https://github.com/nodejs/node/blob/main/configure.py#L155-L160)

Platforms affected

• Azure DevOps
• GitHub Actions - Standard Runners
• GitHub Actions - Larger Runners

Runner images affected

• Ubuntu 20.04
• Ubuntu 22.04
• macOS 11
• macOS 12
• macOS 13
• Windows Server 2019
• Windows Server 2022

Image version and build link

Current runner version: '2.311.0'

Is it regression?

No

Expected behavior

node binary can be invoked inside of alpine containers or other environments with different libc

Actual behavior

Crashes with various dynamic linking errors

Repro steps

1. Set up a self-hosted arm64 runner
2. Run an image such as alpine or pyca/cryptography-manylinux2014 that has a different libc (musl and old, respectively)
3. Attempt to use any node20 action, such as actions/checkout@v4
4. See it fail

[mikhailkoliada]

Hey, we do not build static binaries and have no plans to do so (we do not build anything from source code at all), if you are using alternative libc we are unlikely to offer any help, because musl is not prioritised across major linux distributions and all the builds are gibc-centric, as far as I am aware, there are no official node ports to support musl even

[mikhailkoliada]

transferring to setup-node, might be they have anything to add, but I guess not much.

[alex]

While I recognize that in many respects alpine is the "odd distro out", it's extremely widely used for building containers. Similarly, older libc from distributions like Red Hat are still widely used in the enterprise.

As an open source maintainer, I need to support a wide variety of platforms for my software.

The reason I suggest static linking, and not official support for these platforms, is precisely to minimize the ongoing work for for the Actions team.

[marko-zivic-93]

Hello @alex
Thank you for creating this issue. We will investigate it and come back to you with our findings.

[alex]

Thanks. Please let me know if there's any other questions I can answer.

…

On Mon, Dec 18, 2023, 10:13 AM Marko Zivic ***@***.***> wrote: Hello @alex <https://github.com/alex> Thank you for creating this issue. We will investigate it and come back to you with our findings. — Reply to this email directly, view it on GitHub <#922 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAAAGBBTTGR53WI3ZT3MGCLYKBMSXAVCNFSM6AAAAABAXUCAE2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQNRQG43TKNJUGU> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[priyagupta108]

Hello @alex ! Thank you for reporting. The actions/setup-node action, as detailed in the README.md, provides the functionality to setup a Node.js environment in a GitHub Action workflow environment. It doesn't handle the building or linking of Node.js. Instead, it downloads pre-built Node.js binaries from the official Node.js distribution site.
Statically linking the Node.js binary, including libc, depends primarily on how Node.js itself is built, not something that can be controlled or modified by the actions/setup-node action. Therefore, to have a fully statically linked Node.js binary, changes would have to be made at the level of Node.js build process, which is outside the scope of the setup-node repository.

Hope this clarifies! :)

[alex]

I understand the role that actions/setup-node plays.

I originally filed this bug against the runner image, because this impacts the use of any node20 action. It seems like what you are saying is that in order to resolve this, the runner image would need to stop using setup-node, and build its own version of node for use running actions themselves, is that correct?

[dominykas]

Node.js project provides an official Alpine container, source: https://github.com/nodejs/docker-node

That official Alpine container, ironically, contains an unofficial build of Node.js build inside, source: https://github.com/nodejs/unofficial-builds

We've been using the official Node.js Alpine containers in production for many years now.

Perhaps these unofficial builds could be downloaded and used for the Alpine scenarios that you need, although I wonder if it's up to actions/setup-node to provide that.

[priyagupta108]

Hello @alex. I've tried to investigate the issue deeper and it seems like the errors encountered are due to the fact that the Node.js binary built for Actions is linked dynamically against libc. When this binary is used in environments with a different libc or in Alpine Linux containers (which use musl libc), the symbols can't be resolved, causing errors.
One way to solve this issue could be to use an unofficial Node.js binary that's statically linked against musl instead of glibc.

As @dominykas mentioned for alpine images unofficial-builds.nodejs.org builds are used or nodejs is built from source code.