[horizon] patternfly?

Adrian Turjak adriant at catalyst.net.nz
Wed Jun 24 02:07:06 UTC 2020


On 24/06/20 1:05 am, Thomas Goirand wrote:
> Anyone dismissing how huge of a problem this is, isn't doing serious
> programming, for serious production use. That person would just be doing
> script kiddy work in the playground. Yes, it works, yes, it's shiny and
> all. The upstream code may even be super nice, well written and all. But
> it's *NOT* serious to put such JS bundling approach in production.
And yet people are running huge projects in production like this just
fine. So clearly people are finding sane practices around it that give
them enough security to feel safe that don't involve packaging each npm
requirement as an OS package. How exactly are all the huge powerhouses
doing it then when most of the internet's front end is giant js bundles
built from npm dependencies? How does gitlab do it for their omnibus?
>From a cursory glance it did seem like they did use npm, and had a rake
job to compile the js. Gitlab most definitely isn't "script kiddy work".

I'm mostly a python dev, so I don't deal with npm often. When it comes
to python though, other than underlying OS packages for python/pip
itself, I use pip for installing my versions (in a venv or container).
I've had too many painful cases of weird OS package versions, and I
dislike the idea of relying on the OS when there is a perfectly valid
and working package management system for my application requirements. I
can audit the versions installed against known CVEs, and because I
control the requirements, I can ensure I'm never using out of date
libraries.

Javascript and npm is only different because the sheer number of
dependencies. Which is terrifying, don't get me wrong, but you can lock
versions, you can audit them against CVEs, you can be warned if they are
out of date. How other than by sheer scale is it really worse than pip
if you follow some standards and a consistent process?
> Yes, I do consider nodejs-uglify as something dangerous that one should
> try to avoid: there's been proven security hole with it (please don't
> trust my words, and do your own research on it, it's easy to find, a few
> years ago someone even opened a thread in the
> debian-devel at lists.debian.org list about it).
Are we talking specifically about uglify-js, or minification in general?
Because there is nothing reportedly wrong with uglify-js itself that
hasn't been fixed:
https://snyk.io/node-js/uglify-js
https://www.cvedetails.com/vulnerability-list/vendor_id-16037/Uglifyjs-Project.html

I can understand the worry about potentially not trusting a minified
bundle from an external source, but if you control that minification
process it's less worrying.
> I currently don't see another way than XStatic. If you do, please share.
> We've discussed multiple times that it is contributor time consuming,
> we're all aware of it but found no other approach so far.
Xstatic feels like an awful approach to this problem. I get it in a way,
but just the idea of using python pip packages to wrap js code, which I
guess then also someone bundles into OS packages feels crazy.



More information about the openstack-discuss mailing list