Plugin-based auth/transport (WAS: SSH transport)

[Zeeshan Ali]

Hey Daniel!

> If we did provide a plugin system we'd have to be very careful about the
> way the concepts of auth & transport were tied together in the API. Some
> data transport methods may provide an authentication layer specific to
> their transport (eg SSL provides X509 certs, or SSH provides all sorts),
> but some transports may not provide any auth, while some auth schemes
> can be used with any transport. Also while many transports are socket
> based (existing UNIX/TCP ones, SSH, SSL, Layered over X), others may
> not be in the future - eg a shared memory transport. So we'd also have
> to be careful not to make a plugin API overly restrictive.

   Agreed.

> To be honest I'm not sure there is a pressing need for a plugin system
> in DBus - if OpenSSH had the ability to automatically tunnel forward
> existing DBus protocol in the same way it does for X, there'd be no
> need for any SSH support in libdbus itself.

1. OpenSSH does X forwarding because there is a widely-used use-case
for that: Joe ssh to his office computer and then happily uses X apps.
For remote dbus, I don't think that would be the most common use case,
it would be something like: Joe wants to play some music files in
format A on his internet tablet but the internet tablet's processor
isn't good enough to decode format A in real-time. Fortunately his
multimedia player app. supports using remote backend for
decoding/encoding using DBus. Joe wouldn't be very happy to start an
ssh session separately to make this work, would he?

2. OpenSSH doesn't support anything like that, yet.

> I could still imagine SSL
> being added to libdbus since SSL is a very good protocol for adding
> encrypted transports to apps. It is also trivially implemented by C#
> and Java native bindings - libssh would be significantly harder for
> them since since their standard library runtimes don't provide APIs
> for SSH. I think interoperability between the different DBus protocol
> implementations is of key importance. Every new auth/transport scheme
> implemented in libdbus will also have to be implemented in the C# and
> Java native bindings (which don't use libdbus) - so keeping to a small
> well defined set of transports/auth schemes (preferrably using standard
> protcols) is very important for maintainity interoperability between
> apps.

   As i said before, I would be more than happy to write an SSL
transport/auth instead of SSH but neither does SSL provide any
authentication mechanism nor any of our current authentication
mechanisms can be used with any type of remote transport, unless i am
missing something here?

-- Regards,

Zeeshan Ali
Design Engineer, SW
Open Source Software Operations
Nokia Multimedia