Open Stack

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.
-- 
Jeremy Stanley
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 963 bytes
Desc: not available
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20220802/c78375f6/attachment-0001.sig>