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

		case PK_ERROR_ENUM_GPG_FAILURE:
		case PK_ERROR_ENUM_BAD_GPG_SIGNATURE:
		case PK_ERROR_ENUM_MISSING_GPG_SIGNATURE:
		case PK_ERROR_ENUM_CANNOT_INSTALL_REPO_UNSIGNED:
		case PK_ERROR_ENUM_CANNOT_UPDATE_REPO_UNSIGNED:

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

https://github.com/hughsie/PackageKit/blob/d73cab2a44a112365228b27ca4641c43f2981543/backends/aptcc/apt-intf.cpp#L1567

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

https://github.com/Debian/apt/blob/1d9e29c9e2a5591b42a99a721b901fc003ed9149/apt-private/private-download.cc#L43

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.