Open Stack

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)