Owen Taylor píše v St 17. 04. 2019 v 10:09 -0400:
On Wed, Apr 17, 2019 at 4:01 AM Michal Konecny
<mkonecny(a)redhat.com>
wrote:
> Hi Owen,
>
> I already reported this to releng team [0], but here are some
> details:
> * flatpak version - flatpak-1.2.4-2.fc30.x86_64
> * application to update - org.mozilla.Thunderbird
> * output of flatpak update:
> ```
> Looking for updates…
>
>
> ID Arch Branch
> Remote Download
> 1. [✗] org.mozilla.Thunderbird x86_64 stable
> fedora < 60.2 MB
>
> Error: Can't pull from untrusted non-gpg verified remote
> Updates complete.
> error: There were one or more errors
> ```
Hmm, I wouldn't have thought it was possible, but you *might* be the
first person to have tried updating a flatpak from an OCI system
remote (most of my testing has been with user remotes). There seems
to
potentially a bug where the 'install' and 'update' code paths in the
Flatpak code are differently ordered.
In the install case, it's "is an OCI remote? do X - otherwise, is it
an unsigned GPG remote? error out"
In the update case it's "is it an unsigned GPG remote? error out -
otherwise, is it a is an OCI remote? do X"
I'm puzzling over how to reproduce this without rebuilding a Flatpak
and waiting for it to be pushed to the testing remote. May just be
easiest to extend the Flatpak test suite.
He's not the only one. It hasn't worked for me either. I just haven't
had time to look at it.
I've had problems updating other flatpaks in Software, too, because
it's effectively blocks "Update All" operation.
Jiri