SUMMARY If you configure a yum/dnf-style repo that contains unsigned packages with `gpgcheck=0`, then try to install any packages from that repo using Discover, it will show an unrecoverable error, "There was an issue installing this update. Please try again later". It should either just allow the install, or show a warning the user can click through. STEPS TO REPRODUCE 1. Set up a repository containing unsigned packages 2. Write a yum/dnf config file for the repo, including the directive `gpgcheck=0` 3. Attempt to install or update a package from the repo using Discover OBSERVED RESULT Unrecoverable error message EXPECTED RESULT No error, or a warning that can be accepted to proceed SOFTWARE/OS VERSIONS Linux/KDE Plasma: Fedora Rawhide KDE Plasma Version: 6.0.90 ADDITIONAL INFORMATION See GNOME Software tickets https://gitlab.gnome.org/GNOME/gnome-software/-/issues/603 and https://gitlab.gnome.org/GNOME/gnome-software/-/issues/2246 for some background on how this was discussed and handled there. The behaviour of dnf in this case is that if the repo config says `gpgcheck=0` it will not run any GPG verification or post any warnings and will happily install unsigned or unverifiable packages from the repo.
This is specifically an issue for doing openQA testing of side tags in Fedora, which we do for e.g. the Python mass rebuilds. The packages in the side tag are not signed. We set up a repo config with `gpgcheck=0`, which makes dnf happily install and test the packages. GNOME Software at least just shows a warning we can make openQA click through. But we cannot make the Discover test work at all in this scenario.
Agreed. I'm curious about how GNOME software does this, though. Maybe they've hardcoded something by searching for the error text in PackageKit output? In general in Discover we want to avoid that kind of thing as it's fragile and a maintenance burden. So of the two options you presented: > It should either just allow the install, This is feasible, but it can't be done by Discover; the PackageKit backend plugin would have to implement it. In this case, the DNF plugin. > show a warning the user can click through. Unfortunately this is not feasible because PackageKit does not expose choices in its API for software center apps to show to users. This is a deliberate design decision in PackageKit that the PackageKit maintainers are not interested in changing. See https://github.com/PackageKit/PackageKit/issues/604 for more information. I would recommend talking to the DNF PackageKit plugin maintainers about changing the behavior in their code, For more relevant historical information, see also https://bugzilla.opensuse.org/show_bug.cgi?id=1163737.
On a quick look, it seems like PK does actually provide an interface for this which g-s is using. g-s sets an `untrusted_question` attribute on some class (there is too much obfuscation for me to bother figuring out what kind of class it is exactly, god I hate C): https://gitlab.gnome.org/GNOME/gnome-software/-/blob/4ca259f74911d39ccf5c93b4c0e323b62819623d/plugins/packagekit/gs-packagekit-task.c#L194 it seems like the other end of that isn't in gnome-software, but in PackageKit, unless I'm misreading: see https://github.com/PackageKit/PackageKit/blob/e5df9e89e5841f102cd1f5587aaf987083e32562/lib/packagekit-glib2/pk-task.c#L881 . It occurred to me you can get the "just go ahead" behaviour by implementing a "question" callback which isn't interactive, it just says everything's fine, and sure enough, there seems to be an implementation within PK itself which does this: https://github.com/PackageKit/PackageKit/blob/e5df9e89e5841f102cd1f5587aaf987083e32562/lib/packagekit-glib2/pk-task-wrapper.c#L50 . I don't know if it's possible to do this *only* in the case that the repo config has `gpgcheck=0`, though, or something like that. I don't know the exact contours of when PackageKit would trigger this 'untrusted_question' mechanism vs doing something else.
Oh wow, I had no idea PackageKit offered a specific API for exactly this situation! I guess they just don't have a generic thing. Anyway, that's a great find. I think we can implement this.
Adam, could you provide more detailed steps to reproduce, like with an actual public repository we can test with? That would be useful so we can make sure any changes do succeed in addressing the issue.
well, I ran into this testing Fedora side tags, which are designed to be ephemeral unfortunately. There aren't any permanent ones AFAIK. It should be relatively easy to just build a dummy RPM package and create a repo containing it, though. That would not be signed, obviously.
I don't know how to do that, can you provide instructions?
actually, I *think* https://fedorapeople.org/groups/qa/openqa-repos/openqa-testrepo-2/ should fit the bill, it contains an unsigned package. This repo definition should work: [openqa-testrepo-2] name=openQA test repo 2 baseurl=https://fedorapeople.org/groups/qa/openqa-repos/openqa-testrepo-2 enabled=1 metadata_expire=30 gpgcheck=0 then try to install the package called "testpackage"...
What I fail to wrap my head around is: if you disable gpgcheck then why would we even get a signature failure out of packagekit? I think this needs taking up with packagekit upstream first. The way I see it the dnf backend should honor gpcheck=0 and not perform signature checks, no?
I think there was some debate about that in the GNOME issue(s), which is partly why I linked there...