Bug 739983

Summary:	zif 20110918 claims cups-pk-helper-0.1.3-2.fc15.x86_64 from updates is untrusted
Product:	[Fedora] Fedora	Reporter:	Kevin Kofler <kevin>
Component:	zif	Assignee:	Richard Hughes <hughsient>
Status:	CLOSED NEXTRELEASE	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	15	CC:	cody, hughsient
Target Milestone:	---
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2011-09-22 11:25:50 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Kevin Kofler 2011-09-20 15:37:55 UTC

Description of problem:
Updating my system with KPackageKit and PackageKit-zif, I got the following warning:
The package cups-pk-helper-0.1.3-2.fc15.x86_64 (updates) is untrusted.

Why does it think an official update is untrusted? (And if it really thinks the package is untrusted, why can it be updated to without the root password?)

Version-Release number of selected component (if applicable):
zif-0.2.4-0.78.20110918git.fc15.x86_64
PackageKit-zif-0.6.17-1.fc15.libzif.so.3.x86_64
kpackagekit-0.6.3.3-2.fc15.plasma.x86_64
(The KPackageKit build is the same as the official kpackagekit-0.6.3.3-2.fc15 except that I backported my Plasma services patch.)

How reproducible:
I don't know.

Steps to Reproduce:
1. Update your system using KPackageKit.
  
Actual results:
Warning about untrusted package.

Expected results:
No warning about untrusted package (unless something's really wrong with the signature, in which case I expect an error or an authentication prompt).

Comment 1 Kevin Kofler 2011-09-21 03:34:48 UTC

This seems always reproducible, today's updates were also claimed to be untrusted.

Comment 2 Richard Hughes 2011-09-21 12:19:57 UTC

Yup, there's a logic bug in pk-backend-zif.c -- basically the result from zif_package_get_trust_kind() is only valid after zif_transaction_prepare() has been called.

I'll have to work something out so we can have the same behavior as the yum backend, where we take the hack of repo trust to be an early return to the trusted, and a proper trusted check when the packages have actually been downloaded.

Comment 3 Richard Hughes 2011-09-22 11:25:50 UTC

You need a new zif (from master) and a new PK (from master) unfortunately.

commit 03ea59f3b7be8ebb4e5ef0d03fdda579eae6cbdf
Author: Richard Hughes <richard>
Date:   Thu Sep 22 12:16:16 2011 +0100

    zif: Do not always ask for untrusted authentication for trusted repos
    
    Packages are only marked ZIF_PACKAGE_TRUST_KIND_PUBKEY after the transaction has
    been prepared (and the packages downloaded), and until then the trust is
    unknown.
    
    From Zif 0.2.4 (commit 48691cfee89e90b90d469d62f29ac335430970be) they will be
    set to either ZIF_PACKAGE_TRUST_KIND_PUBKEY_UNVERIFIED when the repo has public
    key support, or ZIF_PACKAGE_TRUST_KIND_NONE if the repo does not.
    
    This allows us to skip the transaction straight to only_trusted=FALSE for
    transactions involving untrusted packages after simulate which avoids the double
    authentication.
    
    After the packages are downloaded we have either ZIF_PACKAGE_TRUST_KIND_PUBKEY
    or ZIF_PACKAGE_TRUST_KIND_NONE and this allows us to fail the transaction in
    the normal way prompting a warning dialog like the the yum backend does.
    
    Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=739983

Comment 4 Kevin Kofler 2011-09-22 17:04:33 UTC

Looks like I need to somehow upgrade the PackageKit (or at least the zif backend) in my repo too, or backport the changes somehow. I'll see what I can do.