[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
different.
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
needed.
David
More information about the PackageKit
mailing list