[packagekit] Treating untrusted and trusted operations differently

[Richard Hughes]

On Mon, 2008-04-21 at 20:45 -0400, David Zeuthen wrote:
> 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.

No, I'm saying that we can't pause a transaction half way through to ask
for an auth depending on the status of a downloaded file. It's the same
logic that we don't allow debian and ipkg scripts to ask random things
and block the transaction during the install phase.

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

I've tried to explain in my previous mail. Surely the fix is simple:
make all transactions fail if _any_ of packages are not trusted (read
has valid GPG key). The corner case of installing the livna rpm needs to
be handled (as this is untrusted, and we need to install it so that we
can add the key for other package installs. This can be done using the 2
stage attempt like I explained earlier.

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

I'm not saying you should.

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

If we abort it, and then re-queue this with a different role, then this
matches pretty much what I said in my first mail. Isn't it?

Richard.