Update base or offer version with Debian Stretch

[fcanela]

Debian 9.0 was released June 17th, 2017 and given it is already in buildpack-deps, jessie have been marked as obsolete and stretch provides some updates that we could benefit: can we consider updating the base image or providing an stretch tag?

For example, I have some libraries that I am unable to install cleanly because the libc++ version provided by jessie is really outdated.

[chorrell]

I think providing a "stretch" variant until we figure out a transition plan for the other image variants could be useful.

Going from 8 --> 9 is a pretty significant change and we're unlikely to just swap jessie out for stretch for all the images at once. We've had similar conversations (and challenges) when considering updating Alpine.

[dgonzalez]

Just a quick note, if you scan the current latest image with Clair, there is a good amount of vulnerabilities... It might be worth to provide a stretch variant from the security point of view.

[chorrell]

Is Clair flagging similar things as what was noted in #374?

[dgonzalez]

No, report attached. This is the analysis of node:latest with the following layers:

Using default tag: latest
latest: Pulling from library/node
9f0706ba7422: Pull complete
d3942a742d22: Pull complete
62b1123c88f6: Pull complete
2dac6294ef18: Pull complete
fd18c4867ed6: Pull complete
c8b70cd3e56f: Pull complete
29ac67902531: Pull complete
dd362c63c80a: Pull complete
Digest: sha256:2a3fe9a32d0de074bb2dbd46273ec452f3610cd055a2ea8bb94b020c9ff61f20

analysis-node-latest.html.zip

[dgonzalez]

The majority of these vulnerabilities are fixed on Stretch but not in Jessie. This might be a show stopper for a lot of companies.

[chorrell]

Following the links in the attached report, most if not all of the high severity issues are flagged as "no-dsa" or "not-affected".

For example:

https://security-tracker.debian.org/tracker/CVE-2016-1908
https://security-tracker.debian.org/tracker/CVE-2016-4448
https://security-tracker.debian.org/tracker/CVE-2014-9940

[dgonzalez]

I actually find it missleading... it clearly says that jessie is vulnerable... what does no-dsa mean (haven't heard that before)?

Thanks

[chorrell]

Yeah, this comes up a lot and it's not intuitive. "no-dsa" means the Debian security team considers the issue to be minor and not worth an update:

https://wiki.debian.org/LTS/Development#CVE_triaging_in_the_LTS_release

The "no-dsa" or "not-affected" status is typically found in the "Notes" section for given CVE, like https://security-tracker.debian.org/tracker/CVE-2016-1908

Scanners like Clair don't usually take that into account, which is unfortunate.

[fcanela]

Hello.

Any estimate on when will the stretch tag be provided? Our team is struggling with 25 min dist-upgrade runtime each time they want to build a microservice.

[chorrell]

There's no ETA for this as yet.

Rather than doing a dist-upgrade, you could build your own image if you are up for it. For example for 8.1.4, just swap out jessie for stretch:

FROM buildpack-deps:stretch

RUN groupadd --gid 1000 node \
  && useradd --uid 1000 --gid node --shell /bin/bash --create-home node

# gpg keys listed at https://github.com/nodejs/node#release-team
RUN set -ex \
  && for key in \
    9554F04D7259F04124DE6B476D5A82AC7E37093B \
    94AE36675C464D64BAFA68DD7434390BDBE9B9C5 \
    FD3A5288F042B6850C66B31F09FE44734EB7990E \
    71DCFD284A79C3B38668286BC97EC7A07EDE3FC1 \
    DD8F2338BAE7501E3DD5AC78C273792F7D83545D \
    B9AE9905FFD7803F25714661B63B535A4C206CA9 \
    C4F0DFFF4E8C1A8236409D08E73BC641CC11F4C8 \
    56730D5401028683275BD23C23EFEFE93C4CFFFE \
  ; do \
    gpg --keyserver pgp.mit.edu --recv-keys "$key" || \
    gpg --keyserver keyserver.pgp.com --recv-keys "$key" || \
    gpg --keyserver ha.pool.sks-keyservers.net --recv-keys "$key" ; \
  done

ENV NPM_CONFIG_LOGLEVEL info
ENV NODE_VERSION 8.1.4

RUN curl -SLO "https://nodejs.org/dist/v$NODE_VERSION/node-v$NODE_VERSION-linux-x64.tar.xz" \
  && curl -SLO --compressed "https://nodejs.org/dist/v$NODE_VERSION/SHASUMS256.txt.asc" \
  && gpg --batch --decrypt --output SHASUMS256.txt SHASUMS256.txt.asc \
  && grep " node-v$NODE_VERSION-linux-x64.tar.xz\$" SHASUMS256.txt | sha256sum -c - \
  && tar -xJf "node-v$NODE_VERSION-linux-x64.tar.xz" -C /usr/local --strip-components=1 \
  && rm "node-v$NODE_VERSION-linux-x64.tar.xz" SHASUMS256.txt.asc SHASUMS256.txt \
  && ln -s /usr/local/bin/node /usr/local/bin/nodejs

ENV YARN_VERSION 0.24.6

RUN set -ex \
  && for key in \
    6A010C5166006599AA17F08146C2130DFD2497F5 \
  ; do \
    gpg --keyserver pgp.mit.edu --recv-keys "$key" || \
    gpg --keyserver keyserver.pgp.com --recv-keys "$key" || \
    gpg --keyserver ha.pool.sks-keyservers.net --recv-keys "$key" ; \
  done \
  && curl -fSLO --compressed "https://yarnpkg.com/downloads/$YARN_VERSION/yarn-v$YARN_VERSION.tar.gz" \
  && curl -fSLO --compressed "https://yarnpkg.com/downloads/$YARN_VERSION/yarn-v$YARN_VERSION.tar.gz.asc" \
  && gpg --batch --verify yarn-v$YARN_VERSION.tar.gz.asc yarn-v$YARN_VERSION.tar.gz \
  && mkdir -p /opt/yarn \
  && tar -xzf yarn-v$YARN_VERSION.tar.gz -C /opt/yarn --strip-components=1 \
  && ln -s /opt/yarn/bin/yarn /usr/local/bin/yarn \
  && ln -s /opt/yarn/bin/yarn /usr/local/bin/yarnpkg \
  && rm yarn-v$YARN_VERSION.tar.gz.asc yarn-v$YARN_VERSION.tar.gz

CMD [ "node" ]

That should be faster than a distilled-upgrade.

Or for slim:

FROM buildpack-deps:stretch-curl

RUN groupadd --gid 1000 node \
  && useradd --uid 1000 --gid node --shell /bin/bash --create-home node

# gpg keys listed at https://github.com/nodejs/node#release-team
RUN set -ex \
  && for key in \
    9554F04D7259F04124DE6B476D5A82AC7E37093B \
    94AE36675C464D64BAFA68DD7434390BDBE9B9C5 \
    FD3A5288F042B6850C66B31F09FE44734EB7990E \
    71DCFD284A79C3B38668286BC97EC7A07EDE3FC1 \
    DD8F2338BAE7501E3DD5AC78C273792F7D83545D \
    B9AE9905FFD7803F25714661B63B535A4C206CA9 \
    C4F0DFFF4E8C1A8236409D08E73BC641CC11F4C8 \
    56730D5401028683275BD23C23EFEFE93C4CFFFE \
  ; do \
    gpg --keyserver pgp.mit.edu --recv-keys "$key" || \
    gpg --keyserver keyserver.pgp.com --recv-keys "$key" || \
    gpg --keyserver ha.pool.sks-keyservers.net --recv-keys "$key" ; \
  done

ENV NPM_CONFIG_LOGLEVEL info
ENV NODE_VERSION 8.1.4

RUN buildDeps='xz-utils' \
    && set -x \
    && apt-get update && apt-get install -y $buildDeps --no-install-recommends \
    && rm -rf /var/lib/apt/lists/* \
    && curl -SLO "https://nodejs.org/dist/v$NODE_VERSION/node-v$NODE_VERSION-linux-x64.tar.xz" \
    && curl -SLO --compressed "https://nodejs.org/dist/v$NODE_VERSION/SHASUMS256.txt.asc" \
    && gpg --batch --decrypt --output SHASUMS256.txt SHASUMS256.txt.asc \
    && grep " node-v$NODE_VERSION-linux-x64.tar.xz\$" SHASUMS256.txt | sha256sum -c - \
    && tar -xJf "node-v$NODE_VERSION-linux-x64.tar.xz" -C /usr/local --strip-components=1 \
    && rm "node-v$NODE_VERSION-linux-x64.tar.xz" SHASUMS256.txt.asc SHASUMS256.txt \
    && apt-get purge -y --auto-remove $buildDeps \
    && ln -s /usr/local/bin/node /usr/local/bin/nodejs

ENV YARN_VERSION 0.24.6

RUN set -ex \
  && for key in \
    6A010C5166006599AA17F08146C2130DFD2497F5 \
  ; do \
    gpg --keyserver pgp.mit.edu --recv-keys "$key" || \
    gpg --keyserver keyserver.pgp.com --recv-keys "$key" || \
    gpg --keyserver ha.pool.sks-keyservers.net --recv-keys "$key" ; \
  done \
  && curl -fSLO --compressed "https://yarnpkg.com/downloads/$YARN_VERSION/yarn-v$YARN_VERSION.tar.gz" \
  && curl -fSLO --compressed "https://yarnpkg.com/downloads/$YARN_VERSION/yarn-v$YARN_VERSION.tar.gz.asc" \
  && gpg --batch --verify yarn-v$YARN_VERSION.tar.gz.asc yarn-v$YARN_VERSION.tar.gz \
  && mkdir -p /opt/yarn \
  && tar -xzf yarn-v$YARN_VERSION.tar.gz -C /opt/yarn --strip-components=1 \
  && ln -s /opt/yarn/bin/yarn /usr/local/bin/yarn \
  && ln -s /opt/yarn/bin/yarn /usr/local/bin/yarnpkg \
  && rm yarn-v$YARN_VERSION.tar.gz.asc yarn-v$YARN_VERSION.tar.gz

CMD [ "node" ]

[dgonzalez]

@chorrell thanks for the explanation... yes... it is unfortunate and inconvenient... The fact that also there is no explanation on why Debian Security team considers a potential remote code execution as no-dsa it is also quite a challenge trying to explain this to people...

[chorrell]

Also see #465

[LaurentGoderre]

Closing since stretch is now the default.