nodejs:22 base image — bundled /var/lang/lib/libcrypto.so.3 (OpenSSL 3.3.5) conflicts with dnf-installed python3 requiring OPENSSL_3.4.0, breaking node-gyp builds

[t-hashimoto-01]

Summary

Starting with the public.ecr.aws/lambda/nodejs:22 base image rebuilt on 2026-04-17, installing
python3 via dnf and then running any node-gyp-driven native build (e.g. pnpm install / npm install of a package that depends on iconv) fails at the gyp configure step with:

ImportError: /var/lang/lib/libcrypto.so.3: version `OPENSSL_3.4.0' not found
(required by /usr/lib64/python3.9/lib-dynload/_hashlib.cpython-39-x86_64-linux-gnu.so)

Environment

• Image: public.ecr.aws/lambda/nodejs:22
• Digest: sha256:3c4a402df777d16146af69a6bc4d50010307cff6fba6f5c688727ae514fc87ae
• Created: 2026-04-17T16:25:04Z
• Architecture: linux/amd64
• Node: v22.22.2 (bundled OpenSSL 3.3.5)
• AL2023 system OpenSSL: openssl-snapsafe-libs-3.5.5-1.amzn2023.0.4.x86_64
• node-gyp: v11.5.0 (shipped with npm 10.9.7 in the image)

Minimal reproduction

docker run --rm --platform linux/amd64 --entrypoint sh public.ecr.aws/lambda/nodejs:22 -c '
  dnf install -y python3 >/dev/null &&
  python3 -c "import hashlib; print(hashlib.sha256(b\"x\").hexdigest())"
'

Output:

Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "/usr/lib64/python3.9/hashlib.py", line 77, in <module>
    import _hashlib
ImportError: /var/lang/lib/libcrypto.so.3: version `OPENSSL_3.4.0' not found
(required by /usr/lib64/python3.9/lib-dynload/_hashlib.cpython-39-x86_64-linux-gnu.so)

The same failure occurs with python3.11 (also packaged against the new system OpenSSL).

End-to-end reproduction via a real Dockerfile (node-gyp path):

# syntax=docker/dockerfile:1
FROM public.ecr.aws/lambda/nodejs:22
RUN dnf install -y gcc-c++ make python3
RUN npm install -g pnpm && mkdir /app && cd /app && \
    npm init -y >/dev/null && \
    npm install iconv@3.0.1

Fails at iconv install with the same _hashlib ImportError from node-gyp.

Evidence that the two OpenSSL copies coexist

Inside the image:

$ env | grep LD_LIBRARY_PATH
LD_LIBRARY_PATH=/var/lang/lib:/lib64:/usr/lib64:/var/runtime:/var/runtime/lib:/var/task:/var/task/lib:/o
pt/lib

$ ls -la /var/lang/lib/libcrypto.so.3 /usr/lib64/libcrypto.so.3
lrwxrwxrwx 1 root root       18 Apr  7 23:16 /usr/lib64/libcrypto.so.3 -> libcrypto.so.3.5.5
-rwxr-xr-x 1 root root 20832912 Apr  9 18:00 /var/lang/lib/libcrypto.so.3

$ rpm -qf /var/lang/lib/libcrypto.so.3
file /var/lang/lib/libcrypto.so.3 is not owned by any package

$ rpm -qf /usr/lib64/libcrypto.so.3
openssl-snapsafe-libs-3.5.5-1.amzn2023.0.4.x86_64

$ ldd /var/lang/bin/node | grep crypto
      libcrypto.so.3 => /var/lang/lib/libcrypto.so.3

$ /var/lang/bin/node -p "process.versions.openssl"
3.3.5

$ objdump -T /var/lang/lib/libcrypto.so.3 \
    | grep -oE "OPENSSL_[0-9]+\.[0-9]+\.[0-9]+" | sort -u
OPENSSL_3.0.0
OPENSSL_3.0.3
OPENSSL_3.0.8
OPENSSL_3.0.9
OPENSSL_3.1.0
OPENSSL_3.2.0
OPENSSL_3.3.0

$ objdump -T /usr/lib64/libcrypto.so.3 \
    | grep -oE "OPENSSL_[0-9]+\.[0-9]+\.[0-9]+" | sort -u
OPENSSL_3.0.0
OPENSSL_3.0.1
OPENSSL_3.0.3
OPENSSL_3.0.8
OPENSSL_3.0.9
OPENSSL_3.1.0
OPENSSL_3.2.0
OPENSSL_3.3.0
OPENSSL_3.4.0
OPENSSL_3.5.0

So:

• node itself requires the bundled libcrypto at /var/lang/lib.
• System tooling installed via dnf (python3, and anything linked against openssl-libs) requires the
  system libcrypto with the OPENSSL_3.4.0 symbol.
• The LD_LIBRARY_PATH ordering forces every child process to resolve libcrypto.so.3 to the bundled
  (older) copy first, which breaks system tooling.
• The bundled libcrypto exposes version tags up to OPENSSL_3.3.0 (matching process.versions.openssl
  = 3.3.5 reported by Node), while _hashlib.so needs EVP_MD_CTX_get_size_ex from OPENSSL_3.4.0,
  provided only by the system libcrypto.

[juipero]

Confirming the same issue on nodejs:24.

Working image (Apr 13):
public.ecr.aws/lambda/nodejs:24@sha256:6a71cc96455b1357273239aebf6b98a812fccadfed8f4693133e533d997abcac

Broken image (Apr 17):
public.ecr.aws/lambda/nodejs:24@sha256:82d54b805e1ee80093cffd4dcc5c470c74b36e88ca9e4338685bc41e7f6d2108

Same root cause — the bundled /var/lang/lib/libcrypto.so.3 is identical between both images (OpenSSL 3.3.x, symbols up to OPENSSL_3.3.0). The break came from the AL2023 side: python3-libs updated from 3.9.25-1.amzn2023.0.3 to .0.4, and _hashlib.so now requires OPENSSL_3.4.0.

In our case npm rebuild @tensorflow/tfjs-node --build-from-source fails because node-gyp configure spawns Python which crashes on import hashlib.

Same workaround applies:
RUN LD_LIBRARY_PATH="" npm rebuild @tensorflow/tfjs-node --build-from-source

[reedham-aws]

We are experiencing this issue as well for nodejs 20, 22, and 24.

I think this is related to #137 as well, but some new update just caused it to start happening for dnf before it even gets to running python.