[adding Simon, since I'm not sure he's subscribed to this list] On Thu, Jan 15, 2015 at 6:19 PM, Alexander Larsson <[email protected]> wrote:
> I don't really know telepathy all that well, but how well would it be > amendable to some level of sandboxing? I guess with kdbus we could ship > the client libraries and they would just error out completely if we > forbid the client talking to the telepathy daemon well known name. > > Could we do something between "full access" and "nothing" though? > > Are the telepathy dbus ABIs backwards compatible? For instance, if I > have some installed app that ships the 3.16 client libraries, but the > host is running the 3.18 dbys services, is this guaranteed to work? This > is something we have to start guaranteeing for things we bundle in the > runtime. > I am not really the best person to answer all these questions about the specifics of Telepathy either, but most of the communication happens already over DBus as you're saying, so putting policy there sounds like a good path forward; I guess you could also allow communication only over a subset of the interfaces. I know for sure that the Telepathy folks have traditionally payed a lot of attention to backwards compatibility though. Also, this essentially adds a new requirement on the host os session > when running this particular runtime (has telepathy >= 3.16 installed). > This is probably not a huge issue, but something that has to be > considered and recorded for each bundled thing that uses some form of > IPC (like dbus) with the host session. > Simon, what do you think? Thanks, Cosimo
_______________________________________________ gnome-os-list mailing list [email protected] https://mail.gnome.org/mailman/listinfo/gnome-os-list
