On fre, 2015-01-16 at 12:58 +0000, Simon McVittie wrote:
> On 16/01/15 04:10, Cosimo Cecchi wrote:
> > [adding Simon, since I'm not sure he's subscribed to this list]
>
> I am not working on Telepathy at the moment. I don't know whether I will
> be in future.
>
> > 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.
>
> In principle everything should cope gracefully with not being able or
> allowed to talk to the relevant services. The main place to "cut the
> trace" (and verify that things still work) is client <-> Mission Control
> 5, because well-behaved clients won't talk directly to a connection
> manager that isn't providing a Mission Control account.
>
> If you don't actually *want* Telepathy (I don't know what you're
> shipping) then a --without-telepathy configure option for e.g. Shell, or
> runtime detection if it's all done via g-i, seems sensible. If you're
> linking libtelepathy-glib.so.0 into C code then it would have to be a
> compile-time option whether to do so.
Well, this is not about gnome-shell really, just apps. I.e. packaging
the client libraries of telepathy inside the runtime that sandboxed apps
would use, and then accessing the server side from the host os.
> Telepathy used to have "everything over D-Bus, nothing assumes a shared
> filesystem" as a design principle, which is still the case in many
> places; but that might have been partially abandoned in more recent
> versions (e.g. in favour of mandating a shared avatar cache), on the
> basis that nobody actually used it like that and so it was wasted
> effort... basically, the more requirements people have for Telepathy to
> jump through hoops to work across container boundaries or stay
> backwards-compatible or whatever, the more of its maintainers' time it
> will take to get anything done. Like anything else, it's a trade-off.
With a fully sandboxed app there will be no access to e.g. a shared
avatar cache. However, one could run in non-sandboxed mode or we could
punch throught particular directories if we want to.
> > Could we do something between "full access" and "nothing" though?
>
> The major privilege represented by Telepathy is "can impersonate you on
> instant messaging services". Is that acceptable for your use case or not?
Well, what i meant was more like allowing apps access to a subset of
your account. I don't have any particular usecase here though, i'm just
speculating how this could be used in a sandboxed world.
> > Also, this essentially adds a new requirement on the host os session
> > when running this particular runtime (has telepathy >= 3.16 installed).
>
> Do you actually need Telepathy for your mysterious use-case?
I don't have a usecase atm, other than "apps may want to use telepathy,
maybe it should be part of the gnome supported/bundled APIs for apps".
> Is "if the host OS doesn't have vaguely recent Telepathy, then
> presence/IM/VoIP don't work" an acceptable fallback?
That is fine. We define a minimal server version and bundle some
specific client library version. My main worry is then if an app using
this older telepathy client library breaks if the server side is
upgraded.
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Alexander Larsson Red Hat, Inc
[email protected] [email protected]
He's a leather-clad chivalrous inventor who hangs with the wrong crowd.
She's a hard-bitten belly-dancing cab driver who believes she is the
reincarnation of an ancient Egyptian queen. They fight crime!
_______________________________________________
gnome-os-list mailing list
[email protected]
https://mail.gnome.org/mailman/listinfo/gnome-os-list
