Open Stack

On 22/06/20 11:31 pm, Thomas Goirand wrote:
> On 6/22/20 6:42 AM, Adrian Turjak wrote:
>> Thomas, I think that's something that downstream maintainers will
>> eventually need to seriously consider and figure out, because any modern
>> front end service these days will end up being built with npm pieces,
>> and various js libraries.
> That's not like if we don't want to do it, it's just that it's kind of
> very hard considering the amount of work that it implies.
>
> So what would be your suggestion to fix the problem exactly?
I don't have one. :(

Then again I'm also not your target audience, because I'd never deploy
Horizon from an OS deb package. I'd either build it myself into a
container (which is what we do), or much like the Gitlab omnibus
container, use an existing official upstream container that met my
requirements if it existed, and trust their final deliverable.

Unless you are reviewing all the code yourself before packaging it
(which sounds impossible), the most you can really do is follow:
https://docs.npmjs.com/packages-and-modules/securing-your-code
Or any other vuln scanning toolkits.

And that can be built into the build pipeline of your js blob.
> My own opinion on this, is that the Javascript "ecosystem" is completely
> broken, and another approach should be considered than the one of
> blindly fetching dependencies. The current npm way doesn't feel safe at
> all for something to put in production, as it could be the source of
> security problems. How, for example, does one ensures that none of the
> dependency contains malicious code that is gathering browsing
> information? How do you ensure there's no privacy breach? How do you
> know none of the upstream libraries are malicious?
>
> 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. :(

But really pip isn't much better. The only difference is the
dependencies are less convoluted. You still really want to be auditing
your pip and npm libraries versions against known vulnerabilities.

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). You can/should audit the dependencies at build time, but I
think the js blob is ultimately what should already be built somewhere
else rather than on the host.

Disclaimer though, I know little to nothing about OS packaging, so take
anything I say with a grain of salt, and apologies for any flagrant
ignorance.

The biggest thing for me is that Horizon or any eventual future
dashboard for OpenStack needs to adopt modern js standards, frameworks,
and development processes to remain relevant. Having downstream
maintainers as one of the reason against ever going in that direction,
makes ever reaching that future much harder. :(