For now this is a purely client side setting which lets you store
the default branch to use for a remote. This is mostly meant to
be used for UI tools, although the CLI could also be made to use this.
You can set this manually in the CLI with --default-branch, or via a
flatpakrepo file (new key DefaultBranch).
It turns out that live apps were exporting files with dashes
other than "-symbolic". For instance "org.libreoffice.LibreOffice" was
exporting "org.libreoffice.LibreOffice-writer.desktop".
Allowing any dashes in the last segment like this is really no diffent
than allowing org.libreoffice.LibreOffice.writer.desktop which we
already do. Any conflicts here are under the control of the owner
of the org.libreoffice prefix.
However, allowing dashes in the earlier segments is more problematic.
For instance, any file exported by "org.my-foo.App" could conflict with
an app called "org.my" if this was allowed.
So, as a middle ground, we're allowing dashes in the last segment of
the App id only.
This adds a new "multiarch" feature which allows bundling e.g. 32-bit
binaries to be run in a x86_64 environment. By default, the seccomp
filter is configured to allow only the native architecture. When the
"multiarch" feature is enabled, the filter will be configured to allow
running binaries of additional architectures supported. For x86_64, this
allows x86 32-bit binaries; and for Aarch64, allows 32-bit ARM binaries.
Application bundles can use the feature e.g. in order to ship 32-bit
binaries alongside with a mostly-64-bit application. This is particularly
interesting when for applications that might launch themselves prebuilt
programs for which 64-bit versions do not exist. For example, the Steam
application is available as a 64-bit executable, but some of the games
available are 32-bit only. A Flatpak bundle for the Steam application
with "multiarch" enabled is able launch the 32-bit games -- without the
feature enabled, the seccomp filter would prevent them from running.
Multiple-architecture support is enabled by adding the "multiarch" value
for the "features" key in the metadata file for a Flatpak:
[Context]
features=multiarch;
The corresponding "--allow=multiarch" command line option is supported
in "flatpak build-finish" as well.
This means that the remote is there, but disabled.
This is needed for e.g. bundles without origin url, and when bundles
starting using this codepath this regressed like in:
https://github.com/flatpak/flatpak/issues/314
For a long time we have been disallowing "-" in application names,
which is different than what dbus allows for bus names. Also "-" used
to be not allowed by GApplication in glib. This is in part because
dbus object paths do *not* allow dashes, so you can't legally map
from e.g. a valid name like "org.foo-bar.gazonk" to a valid path
like "/org/foo-bar/gazonk".
This is a problem because many existing apps already use "-" in the
name, either as the last part (org.gnome.font-viewer) or because
the dns name it refers to has a dash.
This was recently discussed in the dbus community, and the result
is to recommend that "-" in the bus names be converted to "_" in object
paths.
This change makes it also allowed to have "-" in a flatpak app id.
For flatpak specifically we were relying on "-" not being allowed to
handle the case of exporting "org.foo.App-symbolic.png". If "-" is
allowed this name can conflict between apps called "org.foo.App-symbolic"
and "org.foo.App".
To handle this we add two special cases:
* App ids can't end with "-symbolic".
* Apps are allowed to export files with $appid-symbolic as prefix.
Commit 352e761c0e started the trend
to print the errno error code when unable to open a file, make all
occurrences where files are opened print the same kind of message.
These are similar to .flatpakrepo, but for a single app.
For example, if you have a file gedit.flatpakref with this:
[Flatpak Ref]
Title=GEdit
Name=org.gnome.gedit
Branch=stable
Url=http://sdk.gnome.org/repo-apps/
IsRuntime=False
GPGKey=mQENBFUUCGcBCAC/K9WeV4xCaKr3NKRqPXeY5mpaXAJyasLqCtrDx92WUgbu0voWrhohNAKpqizod2dvzc/XTxm3rHyIxmNfdhz1gaGhynU75Qw4aJVcly2eghTIl++gfDtOvrOZo/VuAq30f32dMIgHQdRwEpgCwz7WyjpqZYltPAEcCNL4MTChAfiHJeeiQ5ibystNBW8W6Ymf7sO4m4g5+/aOxI54oCOzD9TwBAe+yXcJJWtc2rAhMCjtyPJzxd0ZVXqIzCe1xRvJ6Rq7YCiMbiM2DQFWXKnmYQbj4TGNMnwNdAajCdrcBWEMSbzq7EzuThIJRd8Ky4BkEe1St6tuqwFaMZz+F9eXABEBAAG0KEdub21lIFNESyAzLjE2IDxnbm9tZS1vcy1saXN0QGdub21lLm9yZz6JATgEEwECACIFAlUUCGcCGwMGCwkIBwMCBhUIAgkKCwQWAgMBAh4BAheAAAoJEArkz6VV0VKBa5cH/0vXa31YgEjNk78gGFXqnQxdD1WYA87OYxDi189l4lA802EFTF4wCBuZyDOqdd5BhS3Ab0cR778DmZXRUP2gwe+1zTJypU2JMnDpkwJ4NK1VP6/tE4SAPrznBtmb76BKaWBqUfZ9Wq1zg3ugvqkZB/Exq+usypIOwQVp1KL58TrjBRda0HvRctzkNhr0qYAtkfLFe0GvksBp4vBm8uGwAx7fw/HbhIjQ9pekTwvB+5GwDPO/tSip/1bQfCS+XJB8Ffa04HYPLGedalnWBrwhYY+G/kn5Zh9L/AC8xeLwTJTHM212rBjPa9CWs9C6a57MSaeGIEHLC1hEyiJJ15w8jmY=
You can then install gedit with
flatpak install --from gedit.flatpakref
This is no longer needed, as we don't hard-require systemd --user.
We keep the opion there, but hidden in order to be backwards compatible
with old code that used this.
This has two advantages. First of all (and most important) it
lets us put a /.flatpak-info file in it, so that the dbus peers
it talks to have the right "source" app id and sandboxed status.
Secondly, it lets us run the bus with readonly access to things,
thus being somewhat more secure.
The info file is always standalone, as it never needs to stack on top
of another context. This means we can remove all "negative" attributes
such as "shared=!network", making it easier to parse this file.
The old location keeps working because we create a symlink.
The interesting part of this is that the sandbox now can't modify,
remove or replace the file, and it is in a fixed position. This means
that given a sandboxed pid, we can find this file as
"/proc/$pid/root/.flatpak-info".
This is very nice for two reasons:
* We can use this instead of the cgroup to find out if a pid is
sandboxed or not. This means we can drop the dependency on
systemd --user for this.
* We can get more information about the peer process that the
app id. For instance, we can see what permissions the sandboxed
app has.
This lets any client, possibly in a sandbox if it has access to the
session helper, spawn a process on the host, outside any sandbox.
Clearly this is not something you typically want a sandboxed app to
do. However, it is sometimes very useful when using flatpak mainly
for distribution. For instance, an IDE needs to use this to launch a
flatpak build operation inside the sandbox. (Because otherwise recursive
calls to flatpak will not work.)
This enables support for ptrace and perf for the app, similar
to what run -d manually gave you before. This is nice to be
able to package an app like gnome-software.
