[packagekit] Treating untrusted and trusted operations differently

[Richard Hughes]

On Mon, 2008-04-21 at 19:59 -0400, David Zeuthen wrote:
>  - If I had kids, I want to make sure they don't install random
>    software off Fedora.

Sure.

> I do agree that the default user on a laptop shouldn't have to type in
> his password to install trusted software. So by default we'd use
> allow_active="yes" for the polkit action required to install trusted
> software. Then we can always lock it down on a per user basis using
> polkit-auth(1) for example.

Exactly.

> So this is confusing. Why would the caller need to pass trusted=TRUE or
> trusted=FALSE in. Clearly, the PackageKit daemon can check if all
> packages are properly signed by a trusted key before really starting the
> transaction. Implementation-wise you would do after all the RPM's have
> been downloaded but before the transaction runs. [1]

We can't do this. It's asking for input after the transaction has
started, when PackageKit is designed as fire-and-forget. Get the auth,
then do the action; not do half the action, get the auth, do the other
half.

> [1] : Every time I mention that this is the only secure way to do it
> someone mentions "but yum and rpm is hard!" and then nothing happens

Well, PackageKit is not designed for yum and rpm. It has to be suitable
for all backends. I know yum is difficult and rpm is sometimes a bit
wacky, but I'm not sure comments like that are particularly helpful
given we are trying to work on a cross platform solution.

> (Btw, I'd also use the same PolicyKit action for installing local RPM's
> versus installing from a repository or installing from a Service Pack
> [sic] disc or whatever. The point really isn't where the user gets an
> RPM from (it's utterly uninteresting actually), the point is whether
> it's trusted (e.g. signed by a trusted key))

Sure, and we don't know what until the download phase has been
completed. You're also assuming the transaction goes
download[1,2,3]->installing[1,2,3] when some backends can do downloading
and installing in parallel.

Richard.