[packagekit] Debconf and PackageKit Was Re: Packagekit and Ubuntu

[Colin Watson]

On Tue, Feb 09, 2010 at 04:52:00AM -0800, Daniel Nicoletti wrote:
> Well I'd like to discuss the options but anyway
> I'll put here how I'd like to see it.
> 
> we create a debconf-communicate-dbus,
> this app will do pretty much of what debconf-communicate
> does but will not work with SDTIN/STDOUT.

My current code already has a debconf-dbus program
(https://code.launchpad.net/~cjwatson/debconf/dbus).

> When I created that new frontend Richard helped me
> with DBus to create a simple/secure way of talking 2 application
> so this app woud register in DBus:
> - an interface like org.debian.debconf
>  - which has 2 methods and a signal,
>  - putData(string), string getData() and a hasDataSignal().
> > this will work like debconf-communicate
> ** putData(string) acts like sending data to STDIN
> ** string getData() acts getting data from STDOUT
> ** and hasData() tell us that we can getData()
> The signal here instead of a data(string) is because
> signals are broadcasted so any app could view your
> mysql password for example.

Sorry, I'm not keen on this model.  What we have here is something that
feels like neither debconf nor D-Bus, which is not what I'm looking for
from debconf D-Bus bindings!  Neither this putData/getData layout nor
the use of signals map very well to how debconf works.  Each debconf
protocol command would be best mapped to a separate method: for example,
get('debconf/frontend') should be equivalent to sending 'GET
debconf/frontend', waiting for a reply, and returning it.  This is a
much cleaner way to lay out the RPC, and it's trivial to implement - all
you need is a table of protocol commands and the types of their
arguments.  I already have this code, as well as an extension to the
passthrough frontend to use it, and it works just fine.

This gives you something that not only feels just like typical language
bindings to debconf, but also actually looks like a proper D-Bus object
(with individual documented methods for each debconf protocol command,
and so on), rather than something that's blatantly a foreign object
wrapped up in a very thin and not very convenient D-Bus layer.  I would
much rather do the former than the latter.

The piece I haven't yet written is the activated-process/transaction
scheme (as described by James, or as modified by the discussion with
Richard), allowing the root debconf backend process to securely talk to
a non-root debconf UI process.  This is of course vital, but I wanted to
understand how to handle transaction identifiers with PackageKit before
writing it.

> This interface being placed in /etc allow us to only let
> root applications to access it's methods thus making
> this comunication secure.

I don't see what /etc has to do with it.  Presumably you mean that it's
on the system bus, whose default policy is deny.  But we do not want
only root applications to access these methods!  What we want is to be
able to permit a *selected non-root application* to access the methods.

If only root processes can access these methods, then the whole point of
all this PackageKit stuff is reduced.  You might as well just run the
package manager directly.  The important thing we gain from running this
over D-Bus even on the local machine is that we don't have to run the UI
as root.

(And yes, you could have a root process talk on the system bus and proxy
things down to a user UI process, but why bother?  D-Bus can already do
this kind of thing.)

You see, I want something more flexible than just a quick hack for
PackageKit here.  I want real bindings.  debconf-communicate is a poor
model for this; it was only ever intended for quick debugging tasks.
Applications should never need to know about the raw format of the
debconf protocol; for example, that might mean that in the future they
would need to manually handle escaping of metacharacters rather than
letting debconf handle it.  Bindings should always be in a
command(arguments) style.

> Now how to integrate this in Pk, is really simple:
> KPackageKit or Gnome-PackageKit starts
> debconf-communicate-dbus which prints to STDOUT
> it's connection ID, this value is then passed to 
> PK via setHints("connection-id", connID);
> now aptcc or apt backends sets this value to an ENVVAR
> and sets the passthrough backend to use dbus
> so that when debconf dialogs starts it will see these
> vars and start a pont-to-point communication.
> 
> This is nice cause the only thing that need changes is
> on the backends, Pk already has setHints(string, string);

Thanks for the note about SetHints (though as far as I can see, we need
to explicitly enumerate the hints we use in pk_transaction_set_hint).
However, I'm not sure this is necessary if Richard is already going to
add the transaction ID as an environment variable.  We don't need to
invent another ID if PackageKit already has one.

Regards,

-- 
Colin Watson                                       [cjwatson at ubuntu.com]