Currently it's based on Alpine 3.4 and support for it already ended - https://wiki.alpinelinux.org/wiki/Alpine_Linux:Releases. Maybe we could use Alpine 3.7?
Node 6 is going to get Alpine 3.7 on the next non security update. Alpine and Yarn versions are pinned and only change on update.
Any clue when non-security update to Node 6 will be released?
Unfortunately I don't.
From what I see latest releases was on 2018-06-12 (3 days ago, https://nodejs.org/en/download/releases/) - 6.14.3 and it still uses alpine:3.4 (https://github.com/nodejs/docker-node/blob/e3ec2111af089e31321e76641697e154b3b6a6c3/6/alpine/Dockerfile#L1).
That was a security update https://nodejs.org/en/blog/vulnerability/june-2018-security-releases/
Is this also true for node 8? Do you have a timeline for when the next non-security update would be?
The issue is that alpine 3.6 has multiple open vulnerabilities on packages. Upgrading to 3.7 would remove these .. so while this is not a node security update, it is a security update.
It's true of all versions.
It is unlikely that node 6 will run Alpine 3.7 because it's in maintenance mode.
Pull request that updates the Node 6, 8, and 10 Docker images: https://github.com/nodejs/docker-node/pull/811.
If this patch set cannot be merged in, then I suggest as an alternative creating Alpine images with the Alpine version number (like node:6-alpine3.8)
Brian
We can't do multiple alpine variants because of how long it takes to build each alpine image. Adding variants for 3.8 would increase the builds times significantly.
@chorrell @masneyb we have a micro service running on boron-alpine (alpine-3.4) in Kubernetes and we see that its vulnerable in production environment. what is the fix you suggest here ?
Mohammeds-Macbook-Pro:k8s Omar$ docker exec -it 995 sh
/opt/ibm/app $ cat /etc/issue
Welcome to Alpine Linux 3.4
Kernel \r on an \m (\l)
/opt/ibm/app # curl --version
curl 7.59.0 (x86_64-alpine-linux-musl) libcurl/7.59.0 OpenSSL/1.0.2n zlib/1.2.11 libssh2/1.7.0
CVE-2018-1000300
Policy Status
Active
Summary
curl version curl 7.54.1 to and including curl 7.59.0 contains a CWE-122: Heap-based Buffer Overflow vulnerability in denial of service and more that can result in curl might overflow a heap based memory buffer when closing down an FTP connection with very long server command replies.. This vulnerability appears to have been fixed in curl < 7.54.1 and curl >= 7.60.0.
curl version curl 7.20.0 to and including curl 7.59.0 contains a CWE-126: Buffer Over-read vulnerability in denial of service that can result in curl can be tricked into reading data beyond the end of a heap based buffer used to store downloaded RTSP content.. This vulnerability appears to have been fixed in curl < 7.20.0 and curl >= 7.60.0.
Vendor Security Notice IDs Official Notice
ALPINE-CVE-2018-1000300
Affected Packages Policy Status How to Resolve Security Notice
curl Active Upgrade curl to >= 7.60.0-r0 ALPINE-CVE-2018-1000300
CVE-2018-1000301
Policy Status
Active
Summary
curl version curl 7.54.1 to and including curl 7.59.0 contains a CWE-122: Heap-based Buffer Overflow vulnerability in denial of service and more that can result in curl might overflow a heap based memory buffer when closing down an FTP connection with very long server command replies.. This vulnerability appears to have been fixed in curl < 7.54.1 and curl >= 7.60.0.
curl version curl 7.20.0 to and including curl 7.59.0 contains a CWE-126: Buffer Over-read vulnerability in denial of service that can result in curl can be tricked into reading data beyond the end of a heap based buffer used to store downloaded RTSP content.. This vulnerability appears to have been fixed in curl < 7.20.0 and curl >= 7.60.0.
Vendor Security Notice IDs Official Notice
ALPINE-CVE-2018-1000301
Affected Packages Policy Status How to Resolve Security Notice
curl Active Upgrade curl to >= 7.60.0-r0 ALPINE-CVE-2018-1000301
OK
If switching to 8-alpine or 10-alpine is an option, that would get you a newer version of alpine that is still receiving updates. Also the EOL date for Node v6 is April 2019, so you'll need to upgrade eventually anyway. v10 would be better since the EOL date is April 2021
For now we've ended up with:
FROM node:6.14.3-alpine as node
FROM alpine:3.8
COPY --from=node /usr/local /usr/local
ENV GRAPHITE_HOST=localhost\
PORT0=8125\
STATSD_USER=statsd
RUN set -eux \
&& apk --update --no-cache add \
dumb-init \
libstdc++ \
&& npm install [email protected] \
&& npm cache clear --force \
&& adduser -S $STATSD_USER
COPY config.js /etc/statsd.js
EXPOSE 8125/udp 8130
USER $STATSD_USER
ENTRYPOINT ["dumb-init"]
CMD ["/node_modules/statsd/bin/statsd", "/etc/statsd.js"]
to have Node.js on Alpine 3.8 which is used to have StatsD.
Very clever!! It works fine?
yes, works fine.
@chorrell I wonder if we could document this as a workaround for alpine versions?
@mlowicki cool!
I also copied /opt directory because I need yarn.
A1) Regarding this hack, which looks clever https://github.com/nodejs/docker-node/issues/789#issuecomment-406594229, I get this error (full Travis log):
Error loading shared library libstdc++.so.6: No such file or directory (needed by /usr/local/bin/node)
A1) The good news is that I built the node image 8.11.4 using alpine:3.8 and it works perfectly.
B) Proposal: I think the 'Docker Hub Node' project could use the same syntax as the 'Docker Hub Python' project where the core OS image have different versions.

It has been proposed before. The blocker is build time. Compiling Node in alpine takes 40 minutes so supporting multiple versions would make the build way too long.
@LaurentGoderre OK, I wasn't aware that this was a challenge.
Do I understand that building all nodes images via Travis would take more than 24 hours?
Plus in the Hub, it gets built for multiple architecture so we would end up with so much build time.
The latest node:6-alpine image (v6.15.1) is now based on Alpine Linux v3.8
Most helpful comment
For now we've ended up with:
to have Node.js on Alpine 3.8 which is used to have StatsD.