vmware-archive/runtimes

rebuild vulnerable Node.js images

knksmith57 opened this issue · 4 comments

A few of the Node.js images haven't been built in a long time and are vulnerable to various exploits; I'm not sure how to craft a PR that triggers a rebuild, but it'd be a really good idea to do so.

I'm here to help however I can 😄

Build dates for Node.js binaries included in current kubeless releases
❯ curl -sL 'https://raw.githubusercontent.com/kubeless/runtimes/master/stable/nodejs/nodejs.jsonnet' \
  | jsonnet - \
  | jq -r '.versions[].images[]|select(.phase=="runtime")|.image' \
  | xargs -I{} \
      docker run --rm --entrypoint node {} --version \
  | xargs -I{} \
      curl -sLH'accept: application/json' resolve-node.now.sh/{} \
  | jq -r '[.tag,.date]|@tsv' \
  | column -t
v6.17.1   2019-04-03
v8.16.0   2019-04-16
v10.16.0  2019-05-28
v12.5.0   2019-06-26
v14.5.0   2020-06-30
Kubeless versions vs available versions and their build dates
❯ curl -sL 'https://raw.githubusercontent.com/kubeless/runtimes/master/stable/nodejs/nodejs.jsonnet' \
  | jsonnet - \
  | jq -r '.versions[].images[]|select(.phase=="runtime")|.image' \
  | xargs -I{} \
      docker run --rm --entrypoint node {} --version \
  | xargs -I{} \
      curl -sLH'accept: application/json' resolve-node.now.sh/^{} \
  | jq -r '[.tag,.version,.date]|@tsv' \
  | column -t
^v6.17.1   v6.17.1   2019-04-03
^v8.16.0   v8.17.0   2019-12-17
^v10.16.0  v10.21.0  2020-06-02
^v12.5.0   v12.18.2  2020-06-30
^v14.5.0   v14.5.0   2020-06-30
Node.js security releases and their build dates for LTS release lines
❯ curl -sL nodejs.org/dist/index.json \
  | jq -r '.[]
    | select(.lts!=false)
    | select(.security==true)
    | select(.version|test("^v(6|8|10|12|14)"))
    | [.version,.date]
    | @tsv' \
  | column -t
v12.18.0  2020-06-02
v12.15.0  2020-02-05
v12.14.0  2019-12-16  <-- first of three security releases after 12.5.0
v10.21.0  2020-06-02
v10.19.0  2020-02-05
v10.18.0  2019-12-16
v10.16.3  2019-08-15  <-- first of four security releases after 10.16.0
v10.15.2  2019-02-28
v10.14.0  2018-11-27
v8.17.0   2019-12-17
v8.16.1   2019-08-15  <-- first of two security releases after 8.16.0
v8.15.1   2019-02-28
v8.14.0   2018-11-27
v8.11.4   2018-08-15
v8.11.0   2018-03-28
v8.9.3    2017-12-07
v6.17.0   2019-02-28
v6.15.0   2018-11-27
v6.14.4   2018-08-15
v6.14.0   2018-03-28
v6.12.2   2017-12-07
v6.11.5   2017-10-24
v6.11.1   2017-07-10

Additionally, it's probably worth calling out that both 6.x and 8.x are already EOL, and 10.x has entered maintenance-only mode. It is not safe to use either 6.x or 8.x in production and, ideally, those running 10.x should be on 10.21.0 minimum and those on 12.x should be on 12.18.0 minimum.

Thanks again and please let me know if there's anything I can do to assist!

relates to #75

/cc @andresmgot

Thanks @knksmith57 for all the info. I agree, take a look to #77

Awesome @andresmgot!

Heads up that I took a look at #77 and I don't think the new images pulled in the updated base images (eg: via docker build --pull). Snippet posted over in the PR thread demonstrating my findings.

versions look great now! thanks again!

for v in 10 12 14; do
  image=kubeless/nodejs:$v
  docker pull $image &>/dev/null
  docker run --rm --entrypoint node $image --version
done
v10.21.0
v12.18.2
v14.5.0