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? _______________________________________________ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list