[Q] Software Bill Of Materials?

[solofoA45]

For security and compliance concerns, it would be good to have a list of dependencies for example to assess which security vulnerabilities affect Xpra: https://en.wikipedia.org/wiki/Software_supply_chain

While this is rather clear for linux (RPM) packages, this is less clear for windows packages and HTML5 client packages.

• For windows packages it seems not clear which MSYS packages were used to build the packages and their versions
• For HTML5 client, the libraries (aurora,...) seem to be included in html5/js/lib/ but not origin, version, patches,...

Is there already a way to get these informations?

[totaam]

Here are some starting points and initial thoughts.

This should tie into the Usage : Security documentation since some issues can be mitigated or bypassed using a tight configuration.

The closest thing we have to an overview of the dependencies is here: https://github.com/Xpra-org/xpra/blob/master/docs/Build/Dependencies.md (and includes some pretty diagrams)

MacOS

The MacOS builds are by far the easiest to track since we define and build every single library ourselves. The list can be found by checking out the build repository at the date matching that of the release: https://github.com/Xpra-org/gtk-osx-build There are a few extra packages in there that are only used on MacOS for packaging (ie: xar, etc), those are not shipped.

MS Windows

The full MSYS2 package list on the build system at time of writing has 179 packages:

$ pacman -Qe | wc -l
179

There are also python dependencies which do not have corresponding MINGW packages and are installed via pip: https://github.com/Xpra-org/xpra/blob/15bce9d2ec162ce4984c86aa4279ea2218445194/packaging/MSWindows/SETUP.sh#L38-L42 Then there are also some manual steps: https://github.com/Xpra-org/xpra/blob/15bce9d2ec162ce4984c86aa4279ea2218445194/packaging/MSWindows/SETUP.sh#L46 for:

• packaging tools
• printing libraries
• documentation packaging
• theming
• CUDA

Packages we do not update as often as others

There can be many reasons why some packages are not updated as regularly as others:

• incessant package releases (often causing breakage): setuptools, zeroconf
• buggy releases (see above)
• avoiding the risk of breaking things (ie: build and packaging tools)
• harder to update (non automatic updates via pip): pip3 list --outdated
• unsupported build environments: some projects no longer support python2, or ancient versions of python3, etc - and this has a cascading effect
• effectively abandoned (ie: pyu2f): should we remove them?

Opaque packages:

• libyuv : google repository with no actual releases - who really knows what's going on there?

3.1

Some issues are magnified in 3.1:

• there is a very long list of packages we build - some of these packages may be provided by the distribution directly (ie: RHEL >= 8 provides libwebp and libvpx, RHEL 7 does not):
  • RPMs: https://github.com/Xpra-org/xpra/tree/v3.1.x/src/packaging/rpm - see build lists: https://github.com/Xpra-org/xpra/tree/v3.1.x/src/packaging/rpm/distros
  • DEBs: https://github.com/Xpra-org/xpra/tree/v3.1.x/src/packaging/debian
• python2 / RHEL7 compatibility means running ancient libraries that have not been maintained for years
• libjpeg-turbo: probably has CVEs against it
• lz4 + python-lz4: python wrapper abandoned python2.. v2.2.1 is the last version that can be built for python2
• python-pillow stuck on 6.2.2
• pycuda 2020.1 is the last version that builds with python2

On the whole, I don't think that it is reasonable to expect the 3.1.x to have the same level of maintenance as current versions. CUDA

[totaam]

We should probably split the dependencies into categories - this is probably too many:

• filter out build time dependencies that aren't actually used (just installed as a transitive dependency of something else)
• build time dependencies that aren't shipped (ie: gcc though libgcc might be?, bash, etc)
• shipped but without the faulty component (ie: libtiff CVE was for an executable we do not include, not the libtiff library we do ship)
• shipped but unused (ie: unused ffmpeg codecs: 20bb5f04233dc650022bc67d5904566d1b158af9, other parsers)
• shipped and used, but not exploitable (ie: requires a specific format or API call argument)
• runtime and used but can be disabled (ie: --video-decoders=none)
• runtime, used and cannot be disabled (ie: GTK, cairo, etc)
• runtime, network facing - the danger zone: lz4, rencodeplus, python interpreter. etc.

[totaam]

The MS Windows dependencies can be recorded in xpra/build_info.py. We can get most of the packages from pacman - and perhaps trim most of the build time dependencies as those aren't very relevant? The python pip dependencies are going to be a pain.

[totaam]

This seems relevant: Understanding the NSA’s latest guidance on managing OSS and SBOMs

[totaam]

Both MacOS and MS Windows builds will now record the libraries and python modules present on the build system when the installer is generated. This will include dependencies we don't really care about: build tools, libraries we don't bundle, etc. But it is safer to record too much than too little, and filtering was hard and would also have required constant fine tuning.

The feature for the html5 client is now tracked here: https://github.com/Xpra-org/xpra-html5/issues/277

---

Next up:

• use a better format: preserve the package names in full using string keys rather than a variable name with prefix
• cleanup the macos pip3 freeze output - what is the checksum for?
• query more details for python projects using https://pypi.org/pypi/$PROJECT/json
• use https://cyclonedx.org/use-cases/ file format?
• make it easier to access this information, include this together with the exe / dmg packages in the download area?
• tie it to the dependency page?
• some kind of automated tracking?

[totaam]

Another tricky one to handle is pdfium-binaries releases - this release page does show a line that says something like "This version was built with branch chromium/6337 of PDFium". The archive containing the DLL we need also contains a VERSION file:

$ cat pdfium/VERSION 
MAJOR=124
MINOR=0
BUILD=6337
PATCH=0

The easiest way might be to create a "fake" pacman PKGBUILD for it.

[totaam]

The new script that I am working on would flag: liblzma-5.dll as belonging to /mingw64/bin/liblzma-5.dll is owned by mingw-w64-x86_64-xz 5.6.1-2. (current DLL should be fine but it was previously owned by the vulnerable version of xz-utils: 5.6.1-1)

Fixed in: https://github.com/msys2/MSYS2-packages/commit/eb7abbb627d1ccfc5a3a6ca31b98150ee733c366 First vulnerable version was added in: https://github.com/msys2/MSYS2-packages/commit/d153a0914cd45d74acae8a3ade74d0b0d8df5ec6 So any builds between 2024-02-25 and today are shipping the vulnerable library.

On the plus side, the exploit seems to target a specific function in openssh - with glibc, and we don't use openssh by default, and no glibc, and not as a server... So no need to panic.

---

Good links on the subject:

• backdoor in upstream xz/liblzma leading to ssh server compromise
• FAQ on the xz-utils backdoor
• tangent: Xz format inadequate for long-term archiving

[totaam]

Forgot another packages missing from MSYS2 that we should contribute upstream: https://github.com/Xpra-org/xpra/blob/79d8e18dc7544d019bef79374b0bdd51c6d42723/packaging/MSWindows/SETUP.sh#L70 Trivial to install: meson build && ninja install.

[totaam]

cyclonedx-python-lib: This Python package provides data models, validators and more, to help you create/render/read CycloneDX documents.