[packagekit] Treating untrusted and trusted operations differently

[David Zeuthen]

On Tue, 2008-04-22 at 01:29 +0100, Richard Hughes wrote:
> > 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.

Then PackageKit is _broken_. Seriously. Think about it. You are creating
an abstraction over packaging systems. If you can't even support
different authorization levels for when a package is trusted vs. not
trusted then you have not really achieved much. Because, as I've tried
to explain via private mail, there's a big fat security problem in the
way things works without this feature: At best, PackageKit wouldn't be
able to retain authorizations for anything if you can't make this
distinction.

FWIW, this is not hard to solve and the edge cases where untrusted
packages are used are few. So only in those instance we'd abort in the
middle (or pause) and the user would need to acquire an authorization to
install untrusted software. Big deal.

> > [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.

Oh, please. As if this problem is Fedora specific. It's _not_ Fedora
specific. It's about common sense and avoiding designing software that
isn't secure: You simply don't treat trusted software and untrusted
software the same way.

(Nice try playing that card though.)

> 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.

Sure, you can start installing some packages if the user has the
authorization required. But as soon as you encounter an untrusted
package and the user lacks an authorization for this, then you either
need to either abort the transaction or somehow get the user to obtain
it if applicable.

     David