We discussed this at the PTG, and sending out a recap has been on my to do list for a few months. Sorry about the delay!
The tl;dr here is that OpenStack is effectively serving as the upstream distributor for (often vulnerable versions of) JavaScript software we didn't make, and downstream consumers like GNU/Linux distributions are then directly repackaging our copies of these things, and assuming we've taken care of any security vulnerabilities for them.
In the early days, we needed a way to make it possible for Horizon to consume JavaScript libraries installed on systems, typically supplied by Linux distros via system level package management. XStatic was and still is a good framework for this, providing a means of bundling up metadata which can be adjusted in deployments to tie in local copies of JS libs so that Horizon can find them, and also allowing us to conveniently use the same sorts of mappings for upstream testing as well. The original idea was that we were shipping XStatic metadata packages, and distributions would take care of supplying the actual JS bits since that's not our specialty as a community.
To make our own testing easier, we embedded copies of the actual JS within our XStatic packages, which is where all of this started going horribly wrong. The rationale at the time was that distro package maintainers would know to devendor (unbundle and replace) the JS inside our XStatic packages, substituting standard ones from their distribution. What has happened instead, likely due to a confluence of convenience and lack of clear communication on our part, is that the distros took the entirety of these XStatic packages and redistributed them, JS and all.
Why is that bad? Well, our approach to Python dependencies is that we freeze the versions we use at the time of our coordinated release, on the assumption that distros backport any relevant security fixes for them. That's generally okay because we're not shipping those dependencies ourselves, someone else does and takes care of fixing and communicating vulnerabilities in them. For many of the XStatic packages Horizon relies on, however, distros are treating us as the upstream supplier of that software, including the JS bundled inside it. We don't (and really can't reliably) track security vulnerabilities in our dependencies, and JS is no exception in this regard. Unfortunately, when it comes to the outdated versions of JS libs we're redistributing inside those packages, many distros assume we are doing exactly that. Worse, it's not just the Linux distros, but even our own deployment projects following the same pattern.
How can we address this?
The first and fastest thing we should do is to start clearly communicating that we make no effort to track or fix vulnerabilities for JS inside our XStatic packages. Readme files in all of them should get a big disclaimer added, as visible as possible, that the included "convenience" copies of JS libs in them are not for production use and should be considered insecure, to be replaced at deployment time with actual upstream copies instead (this will be noticed not just when browsing our source code, but for any subsequent releases on PyPI too). Also update any places in our documentation where XStatic packages are mentioned to point this situation out. Ideally, we should reach out to distros and deployment projects we know are installing our copies of the embedded JS libs to make sure they're aware of this problem too.
In the long term, we really need to gut the JS content from the source trees of our XStatic packages and make our test jobs use something like NPM or Yarn to fetch the relevant versions at deployment time, installing them into the expected locations pointed to by the XStatic metadata. This will make it more obvious that we're not taking responsibility for the security of those libraries, since we're no longer directly supplying them. I've only got the loosest understanding of how XStatic integration works, and not much familiarity with Horizon or its testing, so am relying on Horizon's contributors to weigh in on whether this course of action is sensible and, more importantly, achievable.