On a decently fast system, some files may be fetched, modified and then
fetched again within the same second. In that case, the web server
replies with a code 304 ("Not modified") to the 2nd query, causing some
tests to fail.
This commit forces the web server to ignore `If-Modified-Since` HTTP
headers, effectively disabling caching in order to mitigate the problem.
If we can get people to report security issues privately, then we can do
coordinated disclosure instead of having to rush to fix issues that are
already known to the public.
This is either a malicious/compromised app trying to do an attack, or
a mistake that will break handling of %f, %u and so on. Either way,
if we refuse to export the .desktop file, resulting in installation
failing, then it makes the rejection more obvious than quietly
removing the magic tokens.
Signed-off-by: Simon McVittie <smcv@collabora.com>
(cherry picked from commit 46b3ede524)
If we add new features analogous to file forwarding later, we might
find that we need a different magic token. Let's reserve the whole
@@* namespace so we can call it @@something-else.
Signed-off-by: Simon McVittie <smcv@collabora.com>
(cherry picked from commit 1e7e8fdb24)
When the portal's Spawn method is used with the environment cleared,
it's very likely that the "flatpak run" that ends up being run will be
in an environment without UTF-8 support.
If one of the files or directories we try to expose to the sub-sandbox
contains UTF-8/non-ASCII characters, then "flatpak run" would fail with:
error: Invalid byte sequence in conversion input
This is caused by GOption trying to parse the --filesystem option for
flatpak, as, when using the G_OPTION_ARG_CALLBACK argument type, GOption
will split the option name from its value, and try to convert the value
to UTF-8. Which will fail because there's no UTF-8.
It won't however do that if we tell the option parser that the value is
a filename using G_OPTION_FLAG_FILENAME, so set it.
(cherry picked from commit e67847e253)
OpenSUSE inherits the hostname value from DHCP without updating its X11
authentication cookie, and it keeps the initial value in
`XAUTHLOCALHOSTNAME`.
To avoid breaking the X11 applications, OpenSUSE patches libxcb so that
it also considers the value in `XAUTHLOCALHOSTNAME` as another possible
hostname.
https://bugzilla.opensuse.org/show_bug.cgi?id=262309
To cope with that behavior we need to check `XAUTHLOCALHOSTNAME` too
and, if we have a cookie with that address, propagate it inside the
container adjusting its address to the canonical hostname
`unames.nodename`.
Fixes: #4043
Signed-off-by: Ludovico de Nittis <ludovico.denittis@collabora.com>
(cherry picked from commit fd6a3b79f4)
This is either a malicious/compromised app trying to do an attack, or
a mistake that will break handling of %f, %u and so on. Either way,
if we refuse to export the .desktop file, resulting in installation
failing, then it makes the rejection more obvious than quietly
removing the magic tokens.
Signed-off-by: Simon McVittie <smcv@collabora.com>
If we add new features analogous to file forwarding later, we might
find that we need a different magic token. Let's reserve the whole
@@* namespace so we can call it @@something-else.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Distributions run these tests on other architectures, but hard-coding
x86_64 to look for in output dooms that to failure.
Signed-off-by: Simon McVittie <smcv@collabora.com>
The "new way" is supported since at least 2010 (!).
app/parse-datetime.y:302.1-12: warning: deprecated directive: ‘%pure-parser’, use ‘%define api.pure’ [-Wdeprecated]
302 | %pure-parser
| ^~~~~~~~~~~~
| %define api.pure
As it uses directives that POSIX yacc doesn't support:
app/parse-datetime.y:302.1-12: warning: POSIX Yacc does not support %pure-parser [-Wyacc]
302 | %pure-parser
| ^~~~~~~~~~~~
app/parse-datetime.y:307.1-7: warning: POSIX Yacc does not support %expect [-Wyacc]
307 | %expect 31
| ^~~~~~~
The serial number is supposed to appear only once per file, at the top
of it. Add a serial that matches the highest serial and remove the
in-text serials.
acinclude.m4:113: warning: the serial number must appear before any macro definition
acinclude.m4:321: warning: the serial number must appear before any macro definition
Use present tense consistently rather than gerunds for some headings in
"flatpak --help". Also tweak flatpak(1) to use similar wording but with
gerunds.
When the portal's Spawn method is used with the environment cleared,
it's very likely that the "flatpak run" that ends up being run will be
in an environment without UTF-8 support.
If one of the files or directories we try to expose to the sub-sandbox
contains UTF-8/non-ASCII characters, then "flatpak run" would fail with:
error: Invalid byte sequence in conversion input
This is caused by GOption trying to parse the --filesystem option for
flatpak, as, when using the G_OPTION_ARG_CALLBACK argument type, GOption
will split the option name from its value, and try to convert the value
to UTF-8. Which will fail because there's no UTF-8.
It won't however do that if we tell the option parser that the value is
a filename using G_OPTION_FLAG_FILENAME, so set it.
OpenSUSE inherits the hostname value from DHCP without updating its X11
authentication cookie, and it keeps the initial value in
`XAUTHLOCALHOSTNAME`.
To avoid breaking the X11 applications, OpenSUSE patches libxcb so that
it also considers the value in `XAUTHLOCALHOSTNAME` as another possible
hostname.
https://bugzilla.opensuse.org/show_bug.cgi?id=262309
To cope with that behavior we need to check `XAUTHLOCALHOSTNAME` too
and, if we have a cookie with that address, propagate it inside the
container adjusting its address to the canonical hostname
`unames.nodename`.
Fixes: #4043
Signed-off-by: Ludovico de Nittis <ludovico.denittis@collabora.com>
Currently if a user of libflatpak wants to list the related refs (such
as extensions and plugins) of something, they have three options:
1. They can parse the metadata manually with e.g.
flatpak_remote_ref_get_metadata() and then key-file operations, but
this means re-implementing parts of libflatpak and using key file
strings that are not actually public (FLATPAK_METADATA_KEY_...).
2. They can use flatpak_installation_list_installed_related_refs_sync()
but this only works for installed related refs not remote ones.
3. They can use flatpak_installation_list_remote_related_refs_sync() but
this lists all remotely available related refs, including ones that
may not be compatible with the installed version of the main ref
(because they don't match any of the values in the "versions"
metadata key).
So since none of these provide a way to get the remote related refs
corresponding to an installed application, add new API for that. For the
motivation of this see
https://gitlab.gnome.org/GNOME/gnome-software/-/issues/1132
FLATPAK_ERROR_ALREADY_INSTALLED can be returned from, for example,
flatpak_installation_add_remote(), so document that it applies to
remotes not just apps and runtimes.
There are various reasons why distro autobuilder environments might not
be able to use FUSE in build-time tests: they might not have
fusermount(1), they might be locked-down to be unable to load the FUSE
kernel module as a result of security hardening, they might not have the
/etc/mtab symlink, they might not have CAP_SYS_ADMIN in their capability
bounding set, or they might not have write access to /dev/fuse. Try to
check for all of these conditions.
Heavily based on code that I previously contributed to
xdg-desktop-portal. Disabling revokefs, instead of skipping the test
that needs it, is based on the patches applied in @alexlarsson's PPA.
Signed-off-by: Simon McVittie <smcv@collabora.com>
