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@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-Proje...
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)