boostrap v3 is EOL upstream; migrate to bootstrap v5

[juliangilbey]

This was reported as https://bugs.debian.org/1088418 and I quote from there.

Unfortunately, bootstrap versions 3 and 4 have been EOL'ed by upstream and it is difficult to provide security support for them.

Projects depending on the unmaintained bootstrap versions are encouraged to migrate to bootstrap v5 (src:bootstrap-html). Please note that bootstrap v5 is not just a drop-in replacement, and some work on the upstream side may be needed. Upstream provides these migration guides that may help:

https://getbootstrap.com/docs/4.6/migration/ (for migrating first from v3 to v4, which is also EOL, before the v4 to v5 migration)
https://getbootstrap.com/docs/5.3/migration/

Please, consider migrating to bootstrap v5.

Thank you!

[krassowski]

I agree this would be desirable as JupypterHub migrated to Bootstrap 5 not long ago (in JupyterHub v5). That said I would think the security implications are minimal as it seems jupyter-server only uses the CSS part of bootstrap and not any JS.

[juliangilbey]

Ah, thanks @krassowski - that's a good spot!

[dlqqq]

Just got pinged about this internally since our services run CVE scanners to find vulnerabilities in our dependencies. I agree that there's no security issue with this, but it would be nice to remove bootstrap from the project entirely to suppress these alerts for other server operators.

@krassowski Would the community be open to hard-coding the CSS files into our repository and removing the NPM dependency here? bootstrap^3 has reached EOL, so presumably those CSS files are no longer being updated anyways. The only caveat I see is that we need to ensure that we properly indicate the license & authorship of the copied Bootstrap CSS.

[krassowski]

I cannot speak for the community, but personally I would not do that. I would either upgrade to bootstrap 5, drop bootstrap altogether, or just correctly classify false positive warnings as exactly that.

[dlqqq]

I'm comfortable with that too. I personally don't see a problem with vendoring an EOL dependency just to use the CSS files that we're interested in. We do vendor yarn as jlpm in JupyterLab after all.

The approaches you suggested involve more effort, but they are probably the better choice in the long-term. Just exploring if there's a quick fix for this.