Update base image OS versions

[marvinruder]

What is the problem this feature would solve?

I would like to have a Bun container with more recent operating systems (Debian Bookworm, Alpine 3.19). They offer more recent packages (notably OpenSSL 3 in Bookworm instead of 1.1 in Bullseye), have less security vulnerabilities (Bullseye shows 26, Bookworm 18 low vulnerabilities in Docker Scout) and are generally expected to include other improvements.

What is the feature you are proposing to solve the problem?

Replacing the base images

alpine:3.18                           -> alpine:3.19
debian:bullseye                       -> debian:bookworm
debian:bullseye-slim                  -> debian:bookworm-slim
gcr.io/distroless/base-nossl-debian11 -> gcr.io/distroless/base-nossl-debian12

in both build and final steps for consistency. For the distroless build step, an additional bind mount to /etc/alternatives is required to provide the which command.

What alternatives have you considered?

Like Node.js, Bun could also start publishing images for different OS versions, e.g. :alpine3.19, :alpine3.18, :bookworm, :bullseye, :bookworm-slim, :bullseye-slim etc.

[simonecervini]

Like Node.js, Bun could also start publishing images for different OS versions, e.g. :alpine3.19, :alpine3.18, :bookworm, :bullseye, :bookworm-slim, :bullseye-slim etc.

+1, I find this feature very useful in Node.js. I leverage it to ensure that apk add chromium always installs a very specific version of Chromium depending on the very specific version of Alpine, so that Puppeteer and its dependencies always work well together.

For example, with FROM node:20.11.1-alpine3.19, I know that apk add chromium=122.0.6261.128-r0 is possible, and I can easily check the package by visiting https://pkgs.alpinelinux.org/packages?name=chromium&branch=v3.19&repo=&arch=&maintainer=

[pmbanugo]

+1

[JayPe69]

https://github.com/oven-sh/bun/issues/14610

Lot of vulnerabilities on the bullseyes image :

[paschun]

I just copied and pasted the bun bullseye Dockerfile into bookworm and it worked. So not sure why the hesitation.

https://github.com/oven-sh/bun/blob/main/dockerhub/debian-slim/Dockerfile

[Jarred-Sumner]

Bullseye is necessary to support glibc 2.27, which is used by Amazon Linux 2 and Vercel (for Node v18).

[spiffytech]

Can you elaborate on how those platforms prevent the Docker image from being updated to Bookworm? I'm having trouble understanding, given Vercel doesn't support Docker, and the host doesn't care about the container's glibc anyway.

Doubly confused since Bullseye ships with glibc 2.31.

[JayPe69]

Bullseye is necessary to support glibc 2.27, which is used by Amazon Linux 2 and Vercel (for Node v18).

Ok but lot of users use Node v20+. And AWS is not the only one cloud provider.

So they could create both images bookworm and bullseye

[Jarred-Sumner]

Can you elaborate on how those platforms prevent the Docker image from being updated to Bookworm? I'm having trouble understanding, given Vercel doesn't support Docker, and the host doesn't care about the container's glibc anyway.

Doubly confused since Bullseye ships with glibc 2.31.

oh, i misunderstood

this issue is about Bun's published Docker images, not about the Docker images we compile Bun itself with.

Yeah we should just update the published Docker images.

The ones we compile Bun with do need the oldstable version of Debian to support Node 18 & Amazon Linux 2. We get away with the lower minimum glibc requirement because we force the linker to use older versions of various symbols, and that workaround gets harder the more distant the actual glibc version used for linking is. The problem there is we need to use C++ 20 (WebKit minimum), but libc++ used in older glibc versions has an ABI-breaking change where std::span has pointer and length flipped. We're stuck on Clang 16 until we find a suitable workaround or manually compile glibc with the later version of libc++ and LLVM.

[notramo]

Is there any update on this? It's literally just a replacement of 2 words in the Dockerfile.