gvfs status report

[David Zeuthen]

On Wed, 2007-02-21 at 22:12 -0500, Havoc Pennington wrote:
> ssh forwarding would work for DBUS_SESSION_BUS_ADDRESS exactly as it 
> does for DISPLAY, and would also encrypt/compress the protocol stream. 
> The problem of course is that someone has to patch ssh.

Yea, so this wouldn't even require the TCP/IP bits. I wonder how a
server on the session bus would determine if a caller is remote; he
probably wouldn't be able to since ssh would make this transparent. 

As such, the mechanisms employed by gvfs to set up peer to peer dbus
connections / UNIX domain sockets would have to take machine uuid's [1]
into account and fall back to session bus communication if server and
client machine uuid's differ.

> I don't see any good solution other than patching ssh, though. 
> Unfortunately people are just hacking around things by using dbus-launch 
> to give apps their own private bus on the remote system, which in most 
> cases is all kinds of broken - it's just that few apps rely on dbus all 
> that heavily yet, so it's possible to get by without patching ssh.

Writing this patch and getting it into openssh sounds like great Google
Summer of Code project for the D-Bus project.

     David

[1] : such as /var/lib/dbus/machine-id - btw, why isn't the function
_dbus_read_local_machine_uuid() public? Wasn't one point of the whole
uuid thing that people should use the machine uuid from D-Bus instead of
making up their up hacks?