Open mickaelistria opened 2 years ago
Hi @mickaelistria Is this because you get the migration wizard?
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.
@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:
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.
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
META-INF/ECLIPSE_.SF
and ECLIPSE_.RSA
files, so maybe they don't come from Orbit? Do they come direct from Maven Central?@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.
Thanks. Are you willing to open the p2 bug or should I? I think you deserve the honor since you identified steps to reproduce :)
What is the status of this one? Should it be closed now?
Steps to reproduce:
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: