It is allowed to make a self-executable zip, it will then be an ELF file
on Linux. The problem is that the current stripping code somehow breaks
that file (i.e. ./file.zip doesn't work anymore after stripping).
Signed-off-by: Niv Sardi <xaiki@endlessm.com>
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 completely regressed, and it seems complicated to fix it without
requiring extra privileges. So, the new version requires you to sudo
to run it, which is not great, but at least it makes it work for
all cases.
This is nice because it guarantees that we get a new commit id
which fixes various issues we had with conflicting commit ids
overriding each others signatures.
