Bug 101935 - `pkcon -y` turns off signature checking for all repos ?!
Summary: `pkcon -y` turns off signature checking for all repos ?!
Alias: None
Product: PackageKit
Classification: Unclassified
Component: client-library (show other bugs)
Version: unspecified
Hardware: Other All
: high normal
Assignee: Richard Hughes
QA Contact:
Depends on:
Reported: 2017-07-26 18:48 UTC by Alan Jenkins
Modified: 2018-08-21 15:52 UTC (History)
0 users

See Also:
i915 platform:
i915 features:


Note You need to log in before you can comment on or make changes to this bug.
Description Alan Jenkins 2017-07-26 18:48:30 UTC
Initially marked as priority "high".  This is security-relevant, and two different people told me they had difficulty understanding my first description.  That may have contributed to it being overlooked for a year.  It would be great to reach agreement on a description of the issue without waiting another year :-P.


`dnf -y` is specified as "Automatically answer yes for all questions".

`pkcon -y` is specified as "Install packages without asking for confirmation".

`dnf -y` may sound alarming, but I believe it is not a security issue.  In that if `dnf` finds unsigned packages in a repo which is configured as signed, it correctly treats this as a hard failure.[1]  It will not ask the user if they want to go ahead anyway and install the bad packages.

[1] https://bugzilla.redhat.com/show_bug.cgi?id=1315076

Therefore `dnf -y` is guaranteed not to install unsigned packages so long as the repo is configured with signing enabled.

But looking at the code which implements `pkcon -y` aka `pkcon --noninterative`, it raises alarm bells.  I find no hint that it prevents unsigned packages being installed from a signed repo.

pkcon uses the newer, more convenient pk_task API.  This API will automatically retry non-interactive transactions with (flags & PK_TRANSACTION_FLAG_ENUM_ONLY_TRUSTED == 0), if any of the following errors occurs


E.g. take the apt backend (method AptIntf::checkTrusted)


Compare this to apt-get (methods CheckAuth and AuthPrompt)


The code for `pkcon -y` appears to automatically install untrusted packages, whereas the code for `apt-get -y` will show a prompt.

(Ideally `apt-get -y` would hard-fail like dnf.  But at least it does not conflate the untrusted prompt, with any other prompt you might want to skip.  (Ignore the deprecated --force-yes option)).

The other facet of this, is that confirming `pkcon local-install ./locally-built.rpm` would
also ignore signature failures on any dependencies which are pulled in from the distribution repos.

Currently I believe the scope of this issue is limited, but only because the two callsites where this would be critical are still using the old pk_client API!

1. *Once this issue is fixed, we need to raise the dependency of GNOME Software, so that it will be safe for GNOME Software to switch to pk_task.*
2. *Until this issue is fixed, we need to make sure pk-offline-update keeps using the old pk_client API*

(I think either one is sufficient to maintain security).

Possible solution:

Fix the meaning of !ONLY_TRUSTED.  All it should do is ignore signature failures which occur on user-provided files (pkcon local-install).  Ensure that backends never ignore signature failures on files which they downloaded to the PK cache.

We would like this to be crystal-clear in the API and core code, as well as fixing the backend behaviour.  Unfortunately I don't have a suggestion how to fix that; the best I can think of is to add a comment on the definition of ONLY_TRUSTED.

This will also improve the security of users when running interactive tasks like installing a new app.  Prompting users "something is insecure, but you can continue anyway?" is known to be very dangerous.  There's no reason to do that.

Repo key changes

hughsie points out !ONLY_TRUSTED could in theory be used if a repo changes its key... and your system missed the transition period.  Or you don't support key transitions (cough, rpm).  Or the key was immediately removed, which is the more plausible case where a key is compromised.

Existing code used for upgrades with PK - GNOME Software - did not appear to support forced key changes, unsurprisingly.  The few people who use pkcon for upgrades, should still be able to use the system's traditional package manager to update the key, which will have more specific options than PK.  It's most likely that any transition instructions would be written using the traditional package manager anyway.
Comment 1 Alan Jenkins 2017-08-22 09:39:18 UTC
> *Until this issue is fixed, we need to make sure pk-offline-update keeps using the old pk_client API*

hmm, nope, that part is telling me it's already unsafe?  maybe everything is already unsafe?  anyone?

Jul 23 22:36:09 alan-laptop systemd[1]: Started PackageKit Daemon.
Jul 23 22:36:09 alan-laptop PackageKit[790]: uid 0 is trying to obtain org.freedesktop.packagekit.package-install-untrusted auth (only_trusted:0)
Jul 23 22:36:09 alan-laptop systemd[1]: Created slice User and Session Slice.
Jul 23 22:36:09 alan-laptop systemd[1]: Starting Login Service...
Jul 23 22:36:09 alan-laptop pk-offline-update[774]: status wait
Jul 23 22:36:09 alan-laptop pk-offline-update[774]: status waiting-for-auth
Jul 23 22:36:09 alan-laptop PackageKit[790]: new update-packages transaction /9493_dabaeaeb scheduled from uid 0
Jul 23 22:36:09 alan-laptop PackageKit[790]: uid 0 obtained auth for org.freedesktop.packagekit.package-install-untrusted
Comment 2 Richard Hughes 2018-08-21 15:52:34 UTC
We moved the upstream bugtracker to GitHub a long time ago. If this issue still affects you please re-create the issue here: https://github.com/hughsie/PackageKit/issues
Sorry for the impersonal message, and fingers crossed your issue no longer happens. Thanks.

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.