[blazar] Blazar-dashboard contains non-free files (ie: minified Javascripts)
Hi, I've been trying to package Blazar, all is already in Debian, but I can't get blazar-dashboard in, because upstream source contains non-free files. Namely: https://github.com/openstack/blazar-dashboard/blob/master/blazar_dashboard/s... is a minifed version of a much more complex package: https://github.com/apexcharts/apexcharts.js/tree/v3.31.0 Reminder: minified Javascripts are considered by most distributions (this includes Red Hat, Ubuntu, and in my case Debian) as non-free files that cannot be shipped in the distribution without the underlying source code, and packages must build from the not minified version. Could the Blazar team work on un-vendoring apexcharts.min.js, possibly removing it completely, or replacing it with a source-full version? Cheers, Thomas Goirand (zigo)
Hi Thomas, Thank you for bringing this to our attention. I was not aware of this packaging requirement about minified Javascript. 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. Cheers, Pierre [1] https://review.opendev.org/c/openstack/blazar-dashboard/+/946019 On Tue, 1 Apr 2025 at 08:50, Thomas Goirand <zigo@debian.org> wrote:
Hi,
I've been trying to package Blazar, all is already in Debian, but I can't get blazar-dashboard in, because upstream source contains non-free files. Namely:
https://github.com/openstack/blazar-dashboard/blob/master/blazar_dashboard/s...
is a minifed version of a much more complex package: https://github.com/apexcharts/apexcharts.js/tree/v3.31.0
Reminder: minified Javascripts are considered by most distributions (this includes Red Hat, Ubuntu, and in my case Debian) as non-free files that cannot be shipped in the distribution without the underlying source code, and packages must build from the not minified version.
Could the Blazar team work on un-vendoring apexcharts.min.js, possibly removing it completely, or replacing it with a source-full version?
Cheers,
Thomas Goirand (zigo)
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. 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. 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. The OpenStack community lacks the resources and tooling to track and react to vulnerabilities in our dependencies. 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? 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.ht... -- Jeremy Stanley
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. Cheers, Thomas Goirand (zigo)
On 2025-04-01 22:58:54 +0200 (+0200), Thomas Goirand wrote:
On 4/1/25 18:38, Jeremy Stanley wrote: [...] 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. [...]
Yes, the main problem I have with the xstatic approach is that OpenStack is still shipping copies of (arbitrarily old) Javascript libs we lack the bandwidth and coordination to track potential vulnerabilities in. But at least their versions and origin are (relatively) clear, so not as bad.
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. [...]
Which is why I mentioned that they should also be capable of utilizing locally-supplied copies instead, e.g. those provided by separate packages in GNU/Linux distributions. The point is to make it clear what versions of dependencies are expected and their provenance, without creating even more burden for distro package maintainers who would otherwise need to unvendor/debundle things shipped in the project's source code. As for Javascript dependency hell making projects unpackagable, yes that's what makes the entire NPM ecosystem an attractive nuisance for software development. Unfortunately, I don't have any great solutions to that problem. -- Jeremy Stanley
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)
participants (4)
-
Goutham Pacha Ravi
-
Jeremy Stanley
-
Pierre Riteau
-
Thomas Goirand