On 6/23/20 2:32 AM, Adrian Turjak wrote:
Unless you are reviewing all the code yourself before packaging it (which sounds impossible)
Since I'm packaging all of OpenStack, no, that's not possible! Though I'm hoping that everyone that's actually using a particular piece of code in OpenStack is potentially someone who could raise a security concern in this list. There's also the Debian security team which constantly reviews CVEs, and fills bugs against my packages when needed. All of this would go away if we switch to "npm install ... and forget" kind of model.
the most you can really do is follow: https://docs.npmjs.com/packages-and-modules/securing-your-code Or any other vuln scanning toolkits.
The part here that says: "Auditing package dependencies for security vulnerabilities" would clearly not be possible with 600+ npm dependencies (like gitlab does, for example).
In Python, at least, there's a central repository, with administrator (trying to?) keeping things safe, and the chain of dependency isn't THAT insane.
Oh the js ecosystem is totally broken, but that's what we have to work with, that's where the world of front end interfaces is right now. The best we can do is work with it/around it. :(
Yeah. We absolutely *DO NOT* need to adopt all the bad practices, and the best we can do, is work around them. This includes avoiding the dependency hell by well selecting which libraries to depend on.
But really pip isn't much better.
In Javascript, even if a function ABI is backward compatible, there's no guarantee of what that function/method will return. The result is unnoticed brokenness at many levels.
You still really want to be auditing your pip and npm libraries versions against known vulnerabilities.
Yeah, just like any other language. Any given program is as weak as its weakest dependency.
I don't have a solution, but packaging each npm dep for an application that is ultimately a js blob that can be compiled anywhere feels kind of redundant to me. I can understand the need for golang or c libraries that need to be compiled locally because a binary compiled somewhere else may not work depending on host differences, but js is js, and where it is compiled doesn't matter one bit really for where it will run (the browser).
In this decade, mostly everyone is actually compiling JS and concatenating libraries into a huge file. In this regard, JS is no longer any different from other languages. I'd say it's comparable to Go, since every program is actually bundling (which is equivalent to statically linking) all the libraries. I'm super satisfied that for Horizon, we found a nice way to do that (ie: at package install, and using triggers whenever a JS dependency package is updated, so that it can be rebuilt). Do you think JS are a special case? They also *must* be free software, and easily patch-able, just like any other piece of code.
The biggest thing for me is that Horizon or any eventual future dashboard for OpenStack needs to adopt modern js standards, frameworks,
Yes, but not at all costs.
and development processes to remain relevant.
If by "development processes" you are referring to the "npm install and don't care" pattern I described above, then hopefully, that's not what's going to happen.
Having downstream maintainers as one of the reason against ever going in that direction, makes ever reaching that future much harder. :(
Who said security and maintainability is easy? :) Last word (and repeating to make sure my ideas are reaching): this is *NOT* a downstream distribution concern *ONLY*. :P Cheers, Thomas Goirand (zigo)