Open Stack

On 6/24/20 4:07 AM, Adrian Turjak wrote:
> 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".

It's not because a project is widely spread and use that it's well
managed on all aspects.

Seeing how the Gitlab project manages its JS dependency chain (ie: a
moving target that changes on each single release), I do not trust at
all that part of the Gitlab project, and it feels very weak. If you
don't trust me, you could discuss with the Debian team that is
attempting to package Gitlab in Debian. Yes, they do intend to package
all of the 600+ npm dependencies as independent modules, and having a
really hard time doing that. The result probably will be that Gitlab
will never reach Debian proper, not only because there's too much work
to package, but also because everything 2 weeks old is considered
obsolete by upstream, and therefore, cannot be maintained long enough.
Considering the big majority of OpenStack deployments are lagging many
versions behind (according to the user survey), we cannot reasonably
adopt this way of managing Horizon.

> 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 would you manage if you discover that an indirect dependency is
pinning to a JS library version which has a CVE open, but is
incompatible with the newer upstream release (and maybe lagging many
years behind)?

> How other than by sheer scale is it really worse than pip
> if you follow some standards and a consistent process?

What I'm calling for is that big "if"! If we make sure that we aren't
bundling 1600+ npm dependencies in a careless way like Grafana is doing,
then it's probably ok.

>> 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

Uglify-js specifically. It's IMO attempting to do too much, which
inevitably leads to mistakes.

> 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.

Will you do the work of checking that 100% of dependencies are being
minified at build time? That would be a huge audit work, that you'd need
to restart often.

Cheers,

Thomas Goirand (zigo)