Convert libglnx into a git subtree

[smcv]

• Remove libglnx submodule

  This will allow it to be re-added as a git subtree, which stores
  commit history inline in the flatpak git repository.

• Add 'subprojects/libglnx/' from commit '202b294e6079e23242e65e0426f8639841d1210b'

  This makes the flatpak project more self-contained, and would have
  avoided the problems we encountered with unintended changes in the
  1.14.7 release. See https://diziet.dreamwidth.org/14666.html for an
  opinionated description of some of the problems with submodules.

  If we can eliminate submodules altogether, then it will become possible
  to build Flatpak from a simple git clone or git archive, or from the
  source tarballs auto-generated by Github (which are equivalent to a git archive), without needing an extra step to populate the submodules. As
  well as reducing the support burden from users periodically complaining
  that our source releases are incomplete, this is a useful "nothing up
  my sleeve" mechanism to make it easy to verify that our source releases
  do not contain malicious changes hidden in vendored or generated files,
  like the one that made CVE-2024-3094 possible.

  Added with:

    git remote add --no-tags libglnx https://gitlab.gnome.org/GNOME/libglnx.git
    git fetch libglnx
    git subtree add -P subprojects/libglnx 202b294e6079e23242e65e0426f8639841d1210b
  

  To compare with upstream:

    git remote add --no-tags libglnx https://gitlab.gnome.org/GNOME/libglnx.git
    git fetch libglnx
    git diff HEAD:subprojects/libglnx libglnx/master
  

  After checking the diff, updates can be merged into this project with:

    git subtree merge -P subprojects/libglnx libglnx/master
  

  The commit merged here is the same one that was previously a submodule.
  A subsequent commit will update it to the latest version of libglnx,
  demonstrating how to review such updates.

  git-subtree-dir: subprojects/libglnx
  git-subtree-mainline: 7df25d6
  git-subtree-split: 202b294

• Remove variant-schema-compiler submodule

  Same reasoning as for libglnx.

• Add 'subprojects/variant-schema-compiler/' from commit 'cfc356c38edfcf73c8ac240d215479b950f91b1f'

  The workflow is the same as for libglnx.

  git-subtree-dir: subprojects/variant-schema-compiler
  git-subtree-mainline: 96a8e55
  git-subtree-split: cfc356c

• Use Meson wrap files for bubblewrap and xdg-dbus-proxy

  When combined with using git subtree for our mandatory vendored
  dependencies, this avoids differences between what we ship in our git
  repository (available to users via git clone or by unpacking the
  result of git archive), and what's in our official source code
  releases (which are the result of meson dist).

  Differences between those artifacts would provide an attractive place
  for attackers to hide malware, for example in CVE-2024-3094, so
  avoiding differences is a good "nothing up my sleeve" mechanism to
  make it less appealing for attackers to target Flatpak.

  With default Meson settings, the wrap files will be used automatically
  to download our suggested versions of these dependencies, unless
  the -Dsystem_bubblewrap=..., -Dsystem_dbus_proxy=... Meson options
  are used. In environments where automatic downloads are disabled via
  -Dwrap_mode=nodownload, for example many Linux distributions,
  specifying a system copy becomes mandatory.

• subprojects: Add a README explaining how to manage subprojects

[smcv]

To be able to use this technique, someone with admin powers on this repository will have to enable the "Allow merge commits — Add all commits from the head branch to the base branch with a merge commit" option. Rebasing or squashing subtree commits is undesired because it would cause the history that we merge from libglnx to be lost.

https://gitlab.steamos.cloud/steamrt/steam-runtime-tools is an example of a public project where I am already using the git subtree workflow for a copy of libglnx - please take a look at its history in gitk, gitg or similar if you are interested in how it looks.

[smcv]

smcv#1 is what the equivalent of #5799 would look like if we switched to using a subtree. I think it's a much more useful representation of the change.

If we go this route, we should follow it up by also converting variant-schema-compiler into a subtree, and probably replacing subprojects/bubblewrap and subprojects/dbus-proxy with Meson subprojects/bubblewrap.wrap and subprojects/dbus-proxy.wrap files similar to the ones in GLib.

[TingPing]

Using a subtree is very new to me and I don't see it often.

That said the reasoning is compelling and this looks pretty good.

To be able to use this technique, someone with admin powers on this repository will have to enable the "Allow merge commits

Done.

[TingPing]

please take a look at its history in gitk, gitg or similar if you are interested in how it looks.

This repo crashes git-cola. It's not a tool I use often but I happened to have around; Not a blocker or anything but worth mentioning.

[smcv]

This repo crashes git-cola. It's not a tool I use often but I happened to have around; Not a blocker or anything but worth mentioning.

For what it's worth, git-cola 3.12.0-2 (Debian stable) seems OK when browsing steam-runtime-tools. I'd suggest reporting a git-cola bug if an apparently valid repo can crash newer versions.

[smcv]

If we go this route, we should follow it up by also converting variant-schema-compiler into a subtree, and probably replacing subprojects/bubblewrap and subprojects/dbus-proxy with Meson subprojects/bubblewrap.wrap and subprojects/dbus-proxy.wrap files similar to the ones in GLib.

I've updated the branch with those changes. What do maintainers think?

I'd particularly appreciate opinions from @alexlarsson, @GeorgesStavracas, @mwleeds or anyone else who might make me less of a single point of failure for our release procedure.

[smcv]

If we're happy with bubblewrap and xdg-dbus-proxy being somewhat mature, we could also consider making the defaults for system_bubblewrap and system_dbus_proxy be bwrap and xdg-dbus-proxy, respectively, so that a system copy is used by default, and backporting to old LTS distros requires -Dsystem_bubblewrap="" -Dsystem_dbus_proxy="". But perhaps that's a step too far?

(It's not trivial to use Meson wraps as a fallback here, like it would be if they were libraries, because bubblewrap and xdg-dbus-proxy don't have .pc files and it isn't trivial to discover their version number while cross-compiling. But perhaps the answer to that is to make them install /usr/share/pkgconfig/bubblewrap.pc and the equivalent for x-d-p? Pull requests against the dependencies welcome...)

[TingPing]

I've updated the branch with those changes

👍 wrap files are fine for this.

If we're happy with bubblewrap and xdg-dbus-proxy being somewhat mature, we could also consider making the defaults for system_bubblewrap and system_dbus_proxy be bwrap and xdg-dbus-proxy, respectively, so that a system copy is used by default, and backporting to old LTS distros requires -Dsystem_bubblewrap="" -Dsystem_dbus_proxy="". But perhaps that's a step too far?

I would expect every mainstream distro to already use a system version honestly. I think its a reasonable default. I might nitpick the option's name at that point since its unclear to use an empty value.

[smcv]

I would expect every mainstream distro to already use a system version honestly. I think its a reasonable default.

For the distro itself, yes, I would expect this: if you're regularly updating Flatpak in a rolling release (Debian unstable, Fedora rawhide, Arch, ...) then you can also update bubblewrap and xdg-dbus-proxy when required, and if you're holding back bubblewrap updates for a slow-moving release (Debian stable, Ubuntu LTS, RHEL, ...) then you also shouldn't be updating Flatpak, beyond taking stable/security releases which don't normally bump the dependency.

The reason why we want to give the option to use a vendored copy is for people who are running a slow-moving platform, but want to build a newer Flatpak on that platform - Flatpak developers themselves, or users who want to run newer Flatpak apps on their older OS (via https://launchpad.net/~flatpak/+archive/ubuntu/stable or a similar backport). I would personally be OK with that requiring a couple of extra options to opt-in to using a vendored copy.

I might nitpick the option's name at that point since its unclear to use an empty value.

I'm having a hard time thinking of a better representation for the three things we want to allow (system bubblewrap with its normal name bwrap; system bubblewrap with a non-default name or path like /usr/libexec/flatpak/bwrap-backport; vendored copy) but I'm open to suggestions, particularly if they're in the form of a PR.