On Tue, Apr 1, 2025 at 1:59 PM Thomas Goirand <zigo@debian.org> wrote:
Hi Jeremy,
Thanks for (wider) bringing this topic in this thread.
First, let's start by stating the obvious: dependency management is a hard problem to solve, and everyone starting or contributing to an existing project must keep in mind, as bad dependency management simply makes a (maybe good to begin with) project becomes a bad one.
On 4/1/25 18:38, Jeremy Stanley wrote:
On 2025-04-01 09:43:21 +0200 (+0200), Pierre Riteau wrote: [...]
I submitted a change to replace the minified apexcharts with the latest full version [1]. It needs to be tested because there could be major changes in apexcharts breaking blazar-dashboard. [...]
Longer term, it would be best if we can all work together to find a consistent workflow that avoids OpenStack projects embedding/vendoring random third-party libraries in their Git repositories.
Indeed, vendoring is best if avoided, for *all* libs and assets.
Skyline has a similar issue to tackle right now, which was very recently brought to light, and there's been long-running discussions in Horizon about how to get away from the xstatic package model which still has many of the same drawbacks.
The XStatic package thing is not ideal, but it at least fixes the issue of embedding libs, and offers downstream distribution an easy way to use whatever is already shipped by the distribution. So it has its own merits.
Ad for Skyline, I had a look, and seeing all of the npm things that was involved, I decided it was not practical for me to package it: there was too many JS dependencies.
Ideally, these dependencies would be sourced at install (or at least build) time from their own upstream release artifacts either securely over the Internet or from locally-supplied copies.
Well, that's part of the problem. As you may know, it's forbidden in many distribution, to download assets from the internet at build time in a package. It is at least forbidden in Red Hat, Ubuntu and Debian. Yes, we should be using upstream source as much as possible, but something like npm / grunt / you-name-it is a no-go: developers quickly make it download a dependency hell. A good example of that is Grafana, which I heard someone attempted to package for Red Hat, but quickly gave up, realizing that it's downloading up to 1600+ Javascript dependencies. Please do remember that, in a distribution, one is supposed to package these one by one, and track security support for all of them.
For Horizon, I can count 44 XStatic packages. That's somehow easy to manage, as packages are small, and as they don't themselves depend on other JS libs.
Though there's the hard problem that we need to track all of them for security. I've seen that most of these are getting old, and not being updated fast enough.
It's also to be noted that, when JS libraries are moving too fast in a non-backward compatible way, I had to stop de-embedding them from the Debian Xstatic packages (and therefore, stop using the Debian system otherwise provided version of the lib). Otherwise, Horizon would just fail. This is a big problem too: it breaks the security tracking the distro would otherwise provide. But for stuff like JQuery, I have very little hope... :(
The OpenStack community lacks the resources and tooling to track and react to vulnerabilities in our dependencies.
I agree.
What's the plan for blazar- dashboard if there's a security vulnerability in apexcharts? How do we expect to find out that we're shipping an outdated, vulnerable version of it to our users? Do blazar-dashboard releases even document what version of apexcharts they include, and notify users that they're on their own keeping track of when and whether they should apply security fixes for it?
Yes, that's a problem. And not only for Blazar, but for all of Horizon and all of its plugins.
Though for Blazar specifically, for addressing this specific issue, if it could make a separate XStatic package for that specific JS lib (ie: apexcharts). Again: that's not ideal, but that's the best thing we have currently.
Also see the long-standing TC resolution on Guidelines for Managing Releases of Binary Artifacts which points out many of these risks:
https://governance.openstack.org/tc/resolutions/20170530-binary- artifacts.html
I read it. It's good this document exists, thanks!
If we are to discuss this topic, I'll be happy to join and provide all of the input I can, from a downstream distribution perspective.
Ack; thank you both for the conversation here so far. I added this topic to the TC's PTG Etherpad for next week: https://etherpad.opendev.org/p/apr2025-ptg-os-tc (check around line 86) I'm also copying some skyline cores to this thread; since i'm unsure if they're subscribed, perhaps i can bubble this up in their mailboxes.
Cheers,
Thomas Goirand (zigo)