~roguescholar/flatpak/+git/trunk:T30368-upstream

Last commit made on 2020-10-15
Get this branch:
git clone -b T30368-upstream https://git.launchpad.net/~roguescholar/flatpak/+git/trunk

Branch merges

Branch information

Name:
T30368-upstream
Repository:
lp:~roguescholar/flatpak/+git/trunk

Recent commits

367a3f3... by Phaedrus Leeds <email address hidden>

Make listing refs work for sideload repos

This commit makes
flatpak_installation_list_remote_refs_sync() work for local URIs
pointing at sideload repos, e.g.
"file:///media/mwleeds/flatpaks/.ostree/repo" where a command "flatpak
create-usb /media/mwleeds/flatpaks ..." was previously run. This is
important because the Endless fork of gnome-software uses that API to
list apps on a USB drive. The API worked before Flatpak 1.7.1 so making
it work again basically involves reverting parts of
336a127f5515f69c7d5c6aa7943076035c59bf84.

This commit also makes the remote-ls command work for file:// URIs to
sideload repos, which is useful behavior for debugging, and is also the
behavior mentioned in this blog post:
https://blogs.gnome.org/mclasen/2018/08/26/about-flatpak-installations/

6c79a57... by Philip Withnall <email address hidden>

http: Return HOST_UNREACHABLE on error 500

Sometimes a server might return a HTTP error 500 (this seems to happen
sometimes with Microsoft’s VSCode server, for example). Map this to
`G_IO_ERROR_HOST_UNREACHABLE` for now, which is a bit more specific than
returning `G_IO_ERROR_FAILED`, but without the hassle of introducing a
new public error domain which could give more detail.

In particular, this should allow gnome-software to show an error message
to the user for such failed downloads, rather than hiding the error and
logging the following:
```
not handling error failed for action download: While downloading http://packages.microsoft.com/repos/vscode/pool/main/c/code/code_1.45.1-1589445302_amd64.deb: Server returned status 500: Internal Server Error
```

Signed-off-by: Philip Withnall <email address hidden>

0200348... by Yuri Chornoivan <email address hidden>

Update Ukrainian translation

180d807... by Alexander Larsson <email address hidden>

oci-authenticator: Fix crash if anon auth fails and no_interaction is set

We were clearing the error from the anon test, and then not doing any
non-anon auth, so error was NULL, causing a crash when returning an
error message.

33d1d7b... by Alexander Larsson <email address hidden>

transaction: Fix error handling in authentication failures

We were not correctly returning in case of error, which caused
a cascading "owerwrite gerror" problem.

aec1f62... by Alexander Larsson <email address hidden>

CLI: Ask for transaction confirmation before authentication

If possible, ask for confirmation of the entire transaction before
starting to do the per-ref authentication. We do this by splitting
the current "ready" callback into two parts, one in ready-pre-auth
and the rest in ready.

There is some complexity added because if we do any authentication
between the two signals we can't back-patch the transaction list we
already printed. To handle this we detect this case and re-print the
table if this happens.

d7716f4... by Alexander Larsson <email address hidden>

libflatpak: Report available updates for password-protected refs too.

flatpak_installation_list_installed_refs_for_update() now uses the
ready-pre-auth signal instead of the ready signal. This means we will
report updates even for refs that require authentication to install.

bf8ac3c... by Alexander Larsson <email address hidden>

Transaction: Add ready-pre-auth signal

This is similar to the ready signal, except it is called before
per-ref authentication. Apps can use this if they want to be able
to ask for user input on progress before asking for authentication.

This is nice to be able to do in general, but it is also required for
the implementation of
flatpak_installation_list_installed_refs_for_update(), as it doesn't
install any authentication handler, so it will never report updates
for protected refs if using the ready signal.

Note: In special cases we will require authentication even earlier
if authenticating is needed during the resolve operation. This happens
for instance if you are doing a update to a particular commit (rather
than the lastest commit) where we need to get the commit object directly.

ff2e7d6... by Ryan Gonzalez

transaction: Don't crash on invalid ref names

It is very much possible for an invalid ref name to occur, either due to
lack of validation on Flatpak creation like #3887, or just any
manually-written ref name due to skipping Flatpak tooling or malicious
intent. Regardless, this shouldn't crash, so check the names before
creating the transaction ops.

Fixes #3887.

719eeee... by Ryan Gonzalez

build-init/finish: Validate extension names

Otherwise, it becomes easy to accidentally create extensions with
invalid names. Ref #3887.