Bug 739983 - zif 20110918 claims cups-pk-helper-0.1.3-2.fc15.x86_64 from updates is untrusted
Summary: zif 20110918 claims cups-pk-helper-0.1.3-2.fc15.x86_64 from updates is untrusted
Keywords:
Status: CLOSED NEXTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: zif
Version: 15
Hardware: All
OS: Linux
unspecified
unspecified
Target Milestone: ---
Assignee: Richard Hughes
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2011-09-20 15:37 UTC by Kevin Kofler
Modified: 2011-09-22 17:04 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2011-09-22 11:25:50 UTC


Attachments (Terms of Use)

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@hughsie.com>
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.


Note You need to log in before you can comment on or make changes to this bug.