Flatpak update prompts about unsigned artifacts for previously installed PGP-signed artifacts

[mickaelistria]

Steps to reproduce:

1. From a Flatpak installation
2. Install test framework from https://download.eclipse.org/eclipse/updates/4.23-I-builds/
3. Restart and wait

EXPECTED: everything is fine
GOT: a popup requesting to update test framework (is it really necessary here?), and then a popup mentioning artifacts are unsigned.

There can be many approach to this issue:

• Why are the artifacts updated, is it really necessary?
• Are they really unsigned?

[mbooth101]

Hi @mickaelistria Is this because you get the migration wizard?

[mickaelistria]

Hi @mbooth101 ! Yes, I think the migration wizard, and the fact that it tried to reinstall things that were already installed/trusted previously causes the issue. I'm pretty sure the issue is reproducible without flatpak, but I don't have a scenario yet.

[mbooth101]

@mickaelistria This will happen in any read-only installation scenario. E.g. if we still had RPMs you would see it there too -- it is not a Flatpak-specific problem.

Here's how to reproduce it with upstream eclipse.org I-build tarballs:

Steps

Step 1: Extract an I-build (not the latest, because we want to upgrade during the test) and make it a read-only installation (you can easily do it just by changing ownership to root):

$ wget https://download.eclipse.org/eclipse/downloads/drops4/I20220213-0600/eclipse-platform-I20220213-0600-linux-gtk-x86_64.tar.gz
$ mkdir eclipse-upgrade-test && tar -C $_ -x -f eclipse-platform-I20220213-0600-linux-gtk-x86_64.tar.gz
$ sudo chown -R root:root eclipse-upgrade-test/

Step 2: Start Eclipse with a configuration area in a place where your user has write permissions:

$ ./eclipse-upgrade-test/eclipse/eclipse -configuration $HOME/eclipse-upgrade-test-config-area/config

Step 3: Install test framework bundles to match the I-build, e.g. from: https://download.eclipse.org/eclipse/downloads/drops4/I20220213-0600/eclipse-test-framework-I20220213-0600.zip

Now we get the Trust dialog for the following five bundles:

• assertj-core
• net.bytebuddy.byte-buddy
• net.bytebuddy.byte-buddy-agent
• org.mockito.mockito-core
• org.objenesis

Hit "trust selected" and close Eclipse.

Step 4: Let's simulate upgrade to the latest I-build how Flatpak and RPM would; by deleting the old installation and installing from scratch:

$ sudo mv eclipse-upgrade-test eclipse-upgrade-test-old
$ wget https://download.eclipse.org/eclipse/downloads/drops4/I20220213-1800/eclipse-platform-I20220213-1800-linux-gtk-x86_64.tar.gz
$ mkdir eclipse-upgrade-test && tar -C $_ -x -f eclipse-platform-I20220213-1800-linux-gtk-x86_64.tar.gz
$ sudo chown -R root:root eclipse-upgrade-test/

Step 4: Start Eclipse again with same configuration area as last time:

$ ./eclipse-upgrade-test/eclipse/eclipse -configuration $HOME/eclipse-upgrade-test-config-area/config

Now we get the Migration Wizard -- this is normal for read-only installations. Since your p2 profile lives in the configuration area and not the installation area, the profile is now out of date because it contains references to the old I-build bundles. It must be regenerated to include the new I-build bundles and the bundles previously installed into the configuration area. It seems to do this by just reinstalling them into a new p2 profile.

Now we get the Trust dialog again -- same five bundles as last time.

Questions

Are these untrusted bundles really unsigned? Let's inspect. You can see the plug-ins installed into your writable configuration area, and not the Eclipse installation directory:

$ find $HOME/eclipse-upgrade-test-config-area/plugins -name \*.jar
/home/mbooth/eclipse-upgrade-test-config-area/plugins/net.bytebuddy.byte-buddy-agent_1.12.2.jar
/home/mbooth/eclipse-upgrade-test-config-area/plugins/org.junit.platform.launcher_1.8.1.v20211018-1956.jar
..... etc .....

List the contents of one of these jars:

$ unzip -vl /home/mbooth/eclipse-upgrade-test-config-area/plugins/net.bytebuddy.byte-buddy-agent_1.12.2.jar

• They do not contain the customary META-INF/ECLIPSE_.SF and ECLIPSE_.RSA files, so maybe they don't come from Orbit? Do they come direct from Maven Central?
• If so, then they must be GPG signed at least. Is p2 not checking GPG signatures?
• Why is our "trust these bundles" preference not preserved across upgrades?

[mbooth101]

@mickaelistria I hope you can see from the above that this is a p2 issue, not a Flatpak issue, so I will probably close this bug.

If you think the behaviour should be different here, or there is a genuine bug with p2 checking GPG signatures then please file a bug against p2 -- feel free to copy/paste my reproduction instructions above into such a bug :-)

Edit: I forgot to mention that you only see the Migration Wizard when the platform is upgraded. You probably didn't realise that your platform was upgraded because IIRC on recent Fedoras gnome-software and/or flatpak is configured by default to automatically update your installed flatpak applications in the background.

[mickaelistria]

Thanks. Are you willing to open the p2 bug or should I? I think you deserve the honor since you identified steps to reproduce :)

[akurtakov]

What is the status of this one? Should it be closed now?

[akurtakov]

Closing due to no reply in years.