As explained in bubblewrap commit f6ca3690, libraries should
always go in LDADD and not LDFLAGS, because the order of arguments
to the linker matters. Many distributions' linkers are tolerant
enough that it doesn't matter in practice, but it matters for
static linking, and it might also matter on Ubuntu.
Signed-off-by: Simon McVittie <smcv@debian.org>
Listing variables whose values are conditional in EXTRA_DIST is
problematic: if Flatpak was configured without installed-tests,
we would not distribute those files. This is a problem during
distcheck, where installed-tests are disabled.
For files not placed in a special subdirectory, glib-tap.mk handles
this for us. For the keyring and the databases, we have to do it
ourselves, by arranging for them to be in a dist_ variable that is
special to Automake - when determining what to distribute, Automake
includes anything that is selected for distribution under any
combination of conditionals.
While I'm here, include test keyring's README in tarballs: its advice
is equally applicable in a tarball release.
Signed-off-by: Simon McVittie <smcv@debian.org>
According to the FHS, applications which place internal libraries in
/usr/libexec should not also use /usr/lib for this purpose:
http://refspecs.linuxfoundation.org/FHS_3.0/fhs/ch04s07.html
As several flatpak helpers are already installed in libexecdir, move
the bwrap helper to /usr/libexec/flatpak-bwrap.
Bubblewrap is a new tool from project atomic. Its similar to the old
xdg-app-helper, but even more minimal, and a bit more generic. Its designed
to be easy to git submodule install, but at some point we will probably
support using the system installed version too.
Using bubblewraps lets us share the load of security mainainance and
allows other people to use bubblewrap to do their own unprivileged
sandboxes.
The FHS specifies a limited number of subdirectories for /var,
which do not include xdg-app. Packaging systems like RPM and dpkg
use a subdirectory of /var/lib, so it seems appropriate for system-wide
xdg-app runtimes and apps too.
Signed-off-by: Simon McVittie <smcv@debian.org>
This avoids exporting glnx_*, calc_sizes(), etc. However, we do want to
export xdg_app_error_quark(), so do that.
Signed-off-by: Simon McVittie <smcv@debian.org>
This is a highlevel library for working with xdg-app without using
the commandline interface. The primary usecase for this is for
creating a graphical frontend for app installation/update.
This moves a all source code into separate subdirs per binary. The
helper and the generic stuff goes into lib/ which is then used by all
the others. For now this is a completely internal library, but at
some point we will probably clean it up and expose some subset.
Also, we move the dbus proxy to libexecdir.
We disallow any network family but inet, inet6, unix and netlink
as the rest are generally weird old unused things.
We also have a blacklist of syscalls, some are just old unnecessary
things, some are things that are "risky", like NUMA/VM control, and
setting up custom sub-namespaces.