Detachable libpurple - RPC system

[gillou.ray at free.fr]

On Sun, 6 Jun 2010 07:06:24 +0200
gillou.ray at free.fr wrote:

> Currently we would have to avoid
> authentication, or to implement another authentication method in DBus
> and get it accepted by the DBus developpers. The same goes for the
> encryption that relies to DBus and isn't implemented [2]. So # 6 and 7
> would remain unachieved.

I have a new idea. What if the secured channel was created by
libpurple, which would tell dbus to connect to itself and it would route
its connection to the tunnel? We would get something like:
1. UI client's libpurple establish a secure tunnel to the libpurple
   daemon. Let's say with TLS or some preshared keys (as in openvpn).
   This ensure both authentication and encryption.
2. The libpurple daemon sees an authenticated incoming connection, so
   it connects to its dbus local server (with a simple TCP or unix
   socket) and relays the data from/to it (local-dbus <-> tunnel).
3. The UI client's listen for incoming TCP on localhost port P.
4. The UI client's fires dbus using the TCP layer and tells it to
   connect to localhost:P.
5. Once the UI client is sure that dbus (and not another process!)
   connected to localhost:P, it relays the data
   (localhost:P <-> tunnel).

Finally here is what would be the complete path of an UI client call:

.-> purple-client ==tunnel=> purple-daemon --> dbus-server--+
`-- dbus-call                        ^                      |
                                     +----------<-----------+

We could use a local domain socket instead of localhost:P, but I'm not
sure if such a thing is portable to windows. If the UI client and the
daemon are on the same machine, of course no need to do all this,
just use dbus the normal way. I may do a nice drawing about all this
detachable libpurple stuff (later).

I think this solution is good; it provides security and allows the use
of the power of DBus. Approved?

		-- Gilles
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://pidgin.im/pipermail/devel/attachments/20100610/e55231cd/attachment.sig>