Bug 1591270
| Summary: | GS is not able to install any application | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | Red Hat Enterprise Linux 7 | Reporter: | Martin Krajnak <mkrajnak> | ||||||
| Component: | gnome-software | Assignee: | Milan Crha <mcrha> | ||||||
| Status: | CLOSED WONTFIX | QA Contact: | Desktop QE <desktop-qa-list> | ||||||
| Severity: | high | Docs Contact: | Marek Suchánek <msuchane> | ||||||
| Priority: | high | ||||||||
| Version: | 7.9 | CC: | desktop-qa-list, klember, mclasen, pvlasin, rhughes, tpelka, tpopela | ||||||
| Target Milestone: | rc | Keywords: | Reopened | ||||||
| Target Release: | --- | ||||||||
| Hardware: | x86_64 | ||||||||
| OS: | All | ||||||||
| Whiteboard: | |||||||||
| Fixed In Version: | Doc Type: | Known Issue | |||||||
| Doc Text: |
.`GNOME Software` cannot install packages from unsigned repositories
`GNOME Software` cannot install packages from repositories that have the following setting in the *.repo file:
gpgcheck=0
If you attempt to install a package from such repository, `GNOME software` fails with a generic error. Currently, there is no workaround available.
|
Story Points: | --- | ||||||
| Clone Of: | |||||||||
| : | 1638755 (view as bug list) | Environment: | |||||||
| Last Closed: | 2021-02-15 07:39:34 UTC | Type: | Bug | ||||||
| Regression: | --- | Mount Type: | --- | ||||||
| Documentation: | --- | CRM: | |||||||
| Verified Versions: | Category: | --- | |||||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||||
| Embargoed: | |||||||||
| Attachments: |
|
||||||||
|
Description
Martin Krajnak
2018-06-14 12:35:28 UTC
Created attachment 1451345 [details]
log for first reproducer
Created attachment 1451346 [details]
log for second reproducer
Looks like a PolicyKit issue to me. (In reply to Richard Hughes from comment #6) > Looks like a PolicyKit issue to me. Hi Richard, based on your comment I would like to ask 2 questions: 1.So, Should I switch the component to PolicyKit? 2.Is it ok that flatpak installation process is without autentication? I know that apps are sandboxed but it somehow look wrong to me. Thanks. I was debugging this together with Martin and here's what we found out: Martin's .repo files include internal repos that have gpgcheck=0. When the transaction includes packages that are from gpgcheck=0 repos, then it hits a packagekit code path for unsigned repos. pkcon has a "Do you want to install unsigned packages..." question for that, but gnome-software doesn't have that and just fails with a generic error. Customers should hopefully not get that error at all as the public repos have gpgcheck=1. I don't think it's a regression or anything, just something that came up with testing with internal repos that have gpgcheck=0. There's two things we could do here: a) If we don't want to allow installing from gpgcheck=0 repos at all, then we need a better error message in gnome-software. b) If we'd like to make gpgcheck=0 repos work in gnome-software (which I think is the pragmatic thing to do to) we should be able to wire up the packagekit "Do you want to install unsigned packages..." in gnome-software. Or alternatively just install without the question. From quick irc discussion hughsie prefers option a. > then we need a better error message in gnome-software
Ahh, I was under the impression we didn't show anything. "...as not supported." as a notification is actually true -- we don't support installing unsigned software insecurely. I don't think having a dialog saying "Do something that's hugely dangerous [Yes] [No]" is helpful, or a good idea. If the user wants to install unsigned builds over http:// then they can use dnf on the command line as the root user.
I'm not sure I can come up with a non-technical explanation of this suitable for an in-app notification, and even if we did we'd have no way of getting the new localized string into RHEL7.6 without a whole heap of translator pain.
I guess one thing we could do is show the long detailed error -- but that makes the design team unhappy. Given that gpgcheck=no is the uncommon (and unsupported) case, I don't think we should do anything for this bug. Sorry.
The only-being-able-to-install-as-root issue isn't the same cause, and I'd wager it's some kind of policykit/gnome-shell/gnome-session issue. GNOME Software doesn't even issue the requests -- they come from packagekitd out of band back to the desktop and back again.
I agree that having a notification like that is not useful. Development Management has reviewed and declined this request. You may appeal this decision by reopening this request. Even with rhel-7 out I have problem with installing packages: 14:19:55:0332 Gs failed to call gs_plugin_app_install on packagekit: could not do untrusted question as no klass support looks like the problem is the same as in rhel-8 Adding the repo used on new freshly installed rhel machine: [test@beaker-gnome-software-rhel-7 /]$ cat etc/yum.repos.d/repofile.repo [RHEL-7.6-20181010.0_Server] name=RHEL-7.6-20181010.0_Server baseurl=http://download.eng.rdu2.redhat.com/rel-eng/RHEL-7.6-20181010.0/compose/Server/x86_64/os/ enabled=1 gpgcheck=0 skip_if_unavailable=1 [RHEL-7.6-20181010.0_Server-optional] name=RHEL-7.6-20181010.0_Server-optional baseurl=http://download.eng.rdu2.redhat.com/rel-eng/RHEL-7.6-20181010.0/compose/Server-optional/x86_64/os/ enabled=1 gpgcheck=0 skip_if_unavailable=1 I couldn't find gpg key within the repo but I don't think it is only a signature problem aj I am getting slightly different message: Unable to install Brasero: you don't have permission to install the software I am running the app under the regular user with sudo configured. If you are sure that it is only caused by the missing gpg signatures please Close Still hitting this in 7.7, but not I can confirm for sure that it's because of applications not being signed since I am able to install apps from epel without problem, so I think this should be documented as known issues - An unsigned application cannot be installed by Application Installer After evaluating this issue, there are no plans to address it further or fix it in an upcoming release. Therefore, it is being closed. If plans change such that this issue will be fixed in an upcoming release, then the bug can be reopened. |