[packagekit] Signed packages again again

David Zeuthen david at fubar.dk
Thu Nov 15 15:08:44 PST 2007

On Thu, 2007-11-15 at 23:03 +0000, Richard Hughes wrote:
> On Thu, 2007-11-15 at 17:52 -0500, David Zeuthen wrote:
> > On Thu, 2007-11-15 at 22:44 +0000, Richard Hughes wrote:
> > > > Probably yum legends can comment on how hard this is to check?
> > > 
> > > Well, we have to check all the things it depends on; for instance if we
> > > have to install an unsigned package as a dep to a signed package is that
> > > unsigned or signed?
> > 
> > I think if just one of the packages that is part of the transaction is
> > untrusted, the whole transaction would be untrusted, yes?
> Currently we check for permission then run the transaction. If we have
> to check for the type after we do it then we have to resolve and
> get-depends for each remove or update. This is likely to be slow...

I think the problem is that you can't check the signature of a package
before it's actually downloaded... e.g. the sig is in the RPM header;
IIRC it's not in the yum metadata. Other backends than yum/rpm may be

So this would mean, in the worst, you would have to ask for more auths
in the middle of the transaction. I can see how this can be a problem.
Then again, this should rarely happen; basically only if 

 1. The repo screws up (it actually happens sometimes in Fedora) and
    forget to sign packages

 2. someone injected badware in the repos

But definitely 2. is something you want to catch...

> Also, how do we define trusted?

Didn't I define that with this

 where "untrusted" means that the package isn't signed by a key that the
 user has decided to trust. Specifically for rpm this means that the
 user hasn't done 'rpm --import <key>' for the key the package is signed
 with. Specifically if the rpm isn't signed, this action will be


More information about the PackageKit mailing list