[packagekit] libpackagekit-gnome

[David Zeuthen]

On Mon, 2008-04-14 at 19:13 +0100, Richard Hughes wrote:
> On Mon, 2008-04-14 at 13:09 -0400, David Zeuthen wrote:
> > No, that won't work - there's a ton of attack vectors. My point isn't
> > to try and secure the PackageKit UI tools right now; that's a separate
> > thing. My point is simply that you don't want libpackagekit-gnome; you
> > want a D-Bus service instead. What do you think about that?
> 
> I don't think so - I think the issues are orthogonal. If we use a dbus
> service then we loose the auth-per-application feature. 

No, the D-Bus _session_ service would always ask the user for consent
even if the user happens to be authorized. That's the only sane thing to
do; you really don't want your application to start installing codecs
without your consent. Do you disagree?

> Then is there is
> an exploit, we are then double screwed.

Exploit in what?

> I do understand why it would help however, but applications don't want
> to add packagekit-gnome DBUS API and then depend on a git version of
> packagekit so they can install extensions for MyLeetApp
> 
> Applications typically want "get this: /usr/share/clipart/ponies.png" -
> they don't want all the junk with doing GPK hacking.
> 
> Doing per-app interfaces seems like a metric ton of work, when other
> apps know exactly what they want.

This is confusing. Please explain how this pseudo-code

 dbus_message_send (
   session_bus_connection,
   "org.freedesktop.PackageKit.SessionService.InstallFile",
   "/usr/share/clipart/ponies.png");

is essentially different from

 libpackage_gnome_install_file ("/usr/share/clipart/ponies.png");

Except of course this is different for the reasons I've already
mentioned [1].

     David

[1] : - it would be desktop dependent
      - impossible to lock down
      - all the other fun with shared libraries