When we already have a token for the first repository after probing
for no-auth authenticator or testing user-entered credentials, just
use that, don't request it again in the loop over repositories.
This gives a significant optimization of the prompted-credentials
case for registry.redhat.io, which takes 4-5 seconds to generate a
token, hopefully avoiding the user thinking something has gone wrong.
Signed-off-by: Owen W. Taylor <otaylor@fishsoup.net>
Fix problems overwriting a GError when we retry multiple times.
One of these was introduced with the recent change
e3f17a89a flatpak-oci-authenticator: try getting a token without credentials
but the other was existing.
Signed-off-by: Owen W. Taylor <otaylor@fishsoup.net>
flatpak_bwrap_bundle_args() for some reasons does:
data = g_new (gchar, data_len);
*data = 0;
And then it starts copying in the data into the allocation, overwriting
the initial 0. If data_len is 0 this causes a write past end of
allocation, so just drop the second line above.
When storing the token-type in the commit and the summary cache we
hardcode it to little-endian.
In theory this breaks the "ABI", but in practice this change is a
no-op on little-endian systems which is what most are. Additionally as most
servers are little-endian this also fixes using big-endian clients with
such servers.
This fixes:
https://github.com/flatpak/flatpak/issues/3434
New users who jump directly into this command might think this command is to init a project or application dictionary but it actually creates somehow a directory for *built* app to run inside.
plus, fix not working example
Sorry for such minor and boring commit.
If no scope parameter is supplied in the WWW-Authenticate header,
docker and libpod will make up their own of the form
repository:<reponame>:pull when requesting a bearer token. Match that.
Signed-off-by: Owen W. Taylor <otaylor@fishsoup.net>
Some registries require getting a token even to download an image
anonymously. So, if no auth has been configured, before prompting
the user for username/password, try without a BasicAuth header.
Signed-off-by: Owen W. Taylor <otaylor@fishsoup.net>
If it's an opaque integer on the host system, it might as well be an
opaque integer in the container too.
Fixes: #3416
Signed-off-by: Simon McVittie <smcv@collabora.com>
We can't use the built-in bsearch from the codegen because its an array
instead of a dict, so we have to keep that but its now not using
variant at least.
These are subsets of the host keyword, which provide access to operating
system files but not to users' personal files.
In particular, the experimental support for namespace-based sandboxes
in the Steam Runtime[1] uses the graphics stack from the host system,
which requires access to the host /usr/libQUAL, /libQUAL (even if the
host OS has undergone the /usr merge, the canonical paths of ELF
interpreters start with /lib), /etc/ld.so.cache, and for some libraries
on Debian-based systems, /etc/alternatives. It will not be possible to
do similar things in Flatpak without either allowing full host
filesystem access (which exposes personal files, and in any case cannot
be done by the Steam app because it is incompatible with --persist=.),
or adding the ability to expose /usr and related directories without
including the rest of the host filesystem.
To the best of my knowledge, host-etc is not necessary for anything;
I've mainly provided it for symmetry, since it's the other significant
thing that we mount in /run/host and cannot get via --filesystem=/path.
Some notes on the security/privacy implications of the new keywords:
- Neither new keyword allows anything that was not already allowed
by "host".
- Neither new keyword can allow anything that was not already allowed
to the user outside the sandbox.
- "host-os" allows enumeration of the installed packages on the host
system, and often their version numbers too. A malicious app could
use this to look for exploitable security vulnerabilities on the
host system. An app could also use this for fingerprinting, although
this is not a regression, because the systemd/D-Bus machine ID,
MAC addresses, hostname, kernel boot UUID, DMI product ID and many
other unique or relatively unique properties are already available
inside the sandbox.
- "host-os" allows read access, and possibly write access (if the user
has it outside the sandbox, for example members of group 'staff' in
older Debian installations), to /usr/local.
- "host-etc" allows reading configuration files whose contents might
be considered sensitive, such as /etc/passwd.
[1] https://steamcommunity.com/app/221410/discussions/0/1638675549018366706/
Signed-off-by: Simon McVittie <smcv@collabora.com>
