KF centraldashboard: upgrade base image

[saffaalvi]

The PR for the SAS manage contributors error message #1254 required downgrading to alpine 12.22.12. This was the only way to get the builds passing again. Have to look into this as we want it updated to alpine 16.

[saffaalvi]

In the centraldashboard Dockerfile, I had to change it from latest-stable to v3.15, which they had in upstream. The commit in upstream is here: kubeflow/kubeflow@a9d449e where they explain the error with latest-stable and why they switched to v3.15

I also changed the alpine version in the Dockerfile from node:16-alpine to node:12.22.12-alpine

Some errors that were showing up in the build before I did this were:

The command '/bin/sh -c apk add --no-cache bash chromium@stable nss@stable freetype@stable harfbuzz@stable ttf-freefont@stable libstdc++@stable' returned a non-zero code: 4

ERROR: nss-3.78-r0: package mentioned in index not found (try 'apk update')

ERROR [launcher]: Cannot start ChromeHeadless Error relocating /usr/lib/libpango-1.0.so.0: hb_ot_layout_get_horizontal_baseline_tag_for_script: symbol not found

Cannot start ChromeHeadless Error relocating /usr/lib/libpango-1.0.so.0: hb_ot_layout_get_horizontal_baseline_tag_for_script: symbol not found

The build failure can be seen here: https://github.com/StatCan/kubeflow/runs/7544589178?check_suite_focus=true

[saffaalvi]

The error above was resolved by removing stable from the packages: StatCan/kubeflow@cfe0200

But now there's a new error:

npm ERR! code ERESOLVE
npm ERR! ERESOLVE could not resolve
npm ERR! 
npm ERR! While resolving: [email protected]
npm ERR! Found: [email protected]
npm ERR! node_modules/pug
npm ERR!   dev pug@"^3.0.2" from the root project
npm ERR! 
npm ERR! Could not resolve dependency:
npm ERR! peer pug@"^2.0.0" from [email protected]
npm ERR! node_modules/pug-loader
npm ERR!   dev pug-loader@"^2.4.0" from the root project
npm ERR! 
npm ERR! Conflicting peer dependency: [email protected]
npm ERR! node_modules/pug
npm ERR!   peer pug@"^2.0.0" from [email protected]
npm ERR!   node_modules/pug-loader
npm ERR!     dev pug-loader@"^2.4.0" from the root project
npm ERR! 
npm ERR! Fix the upstream dependency conflict, or retry
npm ERR! this command with --force, or --legacy-peer-deps
npm ERR! to accept an incorrect (and potentially broken) dependency resolution.
npm ERR! 
npm ERR! See /root/.npm/eresolve-report.txt for a full report.

npm ERR! A complete log of this run can be found in:
npm ERR!     /root/.npm/_logs/2022-08-03T04_04_23_928Z-debug-0.log
The command '/bin/sh -c npm rebuild &&     if [ "$(uname -m)" = "aarch64" ]; then         export CFLAGS=-Wno-error &&         export CXXFLAGS=-Wno-error &&         npm install;     else         npm install;     fi &&     npm test &&     npm run build &&     npm prune --production' returned a non-zero code: 1

I think this has something to do with removing the node_modules and pushing again, but it isn't working when I try building it locally either.

[saffaalvi]

My branch with all the builds is here: https://github.com/StatCan/kubeflow/tree/upgrade-alpine

[Jose-Matsuda]

(btw Saffa you should unsubscribe from this issue because I will probably leave lots of comments as I find things, not @'ing you just in case you already unsubscribed in which case wow good stuff)

[Jose-Matsuda]

Current environment is I am trying to build it locally, and in doing so I also switched my node version to be node 16 with npm 8.11 so that I am the same as well the Dockerfile

Re: removing node_modules, it seems like that itself is done whenever we run npm ci.

On my current environment trying that results in the same error Saffa ran into

Looking at the npmjs site for both pug and pug-loader it appears as if 3.0.2 and 2.4.0 are both the absolute latest, and I am surprised that the build was working before.

Found an issue pugjs/pug-loader#126 talking about this might look to this for some "inspiration"

This is how you resolve the "npm build error" when attempting to use a newer version of npm.

[Jose-Matsuda]

Information found upstream

Hmm the folks up at kubeflow still use node:12.22.12-alpine. I seem to have upgraded the version in the past to address some vulnerabilities StatCan/kubeflow#75 so I will build it again now and try to see if those are there.

If they are there, I may look to upstream kubeflow again to see if they addressed anything (which looking at their history they did do something recently).

It does seem like there are these two vulnerabilities still here

of which in the recent fixes to upstreams centraldashboard there have not been fixes or any issues about this.

One of the critical vulnerabilities is itself baked into the node:12.22.12-alpine image

Note that the image of node:16-alpine itself seems to be a long-lived tag as when I scanned it this morning, there was a CVE on it but upon rebuilding the CVE that was popping up went away.

[Jose-Matsuda]

Fixing the building of the image

---

Trying to use the --legacy-peer-deps option

What does this option do? StackOverflow answer. Could also look into the alternative posted by the earlier github comment, also called pug-loader and is more actively maintained, would need to look into if there are any big differences though.

Goodness me it worked

Unfortunately there is a CVE here (need to check if this requires root)

Another entirely different question is if the image behaves properly and nothing breaks

-- Note that if ROOT is required to exploit the CVE then it's not a concern

[Jose-Matsuda]

Addressing the CVE

---

Looking into the upgrade-ability of the packages

Used npm why y18n and got the following list (this is after pruning it to just be the packages that we can see in the package.json,

@google-cloud/monitoring@"^2.1.1" from the root project
dev copy-webpack-plugin@"^5.1.1" from the root project
dev karma-jasmine-html-reporter@"^1.4.2" from the root project
dev nyc@"^15.1.0" from the root project
dev webpack@"^4.44.1" from the root project
dev babel-loader@"^8.0.6" from the root project
dev copy-webpack-plugin@"^5.1.1" from the root project
dev css-loader@"^2.1.1" from the root project
dev eslint-loader@"^2.2.1" from the root project
dev file-loader@"^3.0.1" from the root project
dev html-webpack-plugin@"^3.2.0" from the root project
dev script-ext-html-webpack-plugin@"^2.1.4" from the root project
dev istanbul-instrumenter-loader@"^3.0.1" from the root project
dev karma-webpack@"^4.0.2" from the root project
dev mini-css-extract-plugin@"^0.5.0" from the root project
dev raw-loader@"^2.0.0" from the root project
dev script-ext-html-webpack-plugin@"^2.1.4" from the root project
dev terser-webpack-plugin@"^4.1.0" from the root project
dev url-loader@"^1.1.2" from the root project
dev webpack-cli@"^3.3.9" from the root project
dev karma-webpack@"^4.0.2" from the root project
dev webpack-dev-server@"^3.11.0" from the root project
dev webpack-cli@"^3.3.9" from the root project
dev webpack-dev-server@"^3.11.0" from the root project
dev concurrently@"^5.3.0" from the root project

All that is to say that's a lot of packages that may need updating, and the effects of updating those packages are unknown to me. Additionally, for the second package down, dev copy-webpack-plugin@"^5.1.1" from the root project that is the most 'recent' version that does not contain any breaking changes (as in the very next release increments to 6.x.y), I suspect it would be the same for many of the packages below it

What is y18n?

Just a bare-bones internationalization library used by yargs which is used for "Yargs helps you build interactive command line tools, by parsing arguments and generating an elegant user interface."

Conclusion

I do not think that this is so important to resolve and fix.

With all of these packages that depend on y18n, it would get increasingly difficult to seek and update each package, where some of them do not have clear upgrade paths and I do not have intimate knowledge of kubeflow and how to test everything confidently and of course is baked into the kubeflow application