Starting the kdbus discussions

[Kevin Krammer]

On Thursday, 2014-01-02, 02:03:29, Lennart Poettering wrote:
> On Wed, 01.01.14 22:24, Kevin Krammer (krammer at kde.org) wrote:

> > Assuming the latter also applies to software using the ported GDBus and
> > libdbus1 libraries (or wrappers of those), what kind of information
> > measures are you planning in order to reach them and/or what kind of
> > diagnostic facilities will be in place that alert them of the changed
> > requirements during build or runtime?
> 
> Note sure I really understood your question, but I think you are asking
> how an app should deal with the fact that gdbus might transparently get
> updated to a different backend, which even though everything still
> compiles fine suddenly makes different requirements regarding activation
> files to install?

Yes, exactly!

And I should have specified that I was mostly asking from the perspective of 
session bus usage, sorry.

My primary concern is that larger group of developers which a very wider range 
of understanding of internals than system service developers.
Also because their users (end users) are less likely to be able to provide 
such details about their system unless aided by respective utilities.

> The way I'd suggest that bus APIs solve this is by making applications
> indicate to the bus library they use whether they do their own security
> checks. And if an app does not explicitly tell a library "I do my own
> security checks" then the library would connect via the socket transport
> rather than kdbus directly in order to take benefit of the bus proxy's
> enforcement of the old XML policy.

Opt-in sounds like a good idea indeed.

> Note that all what I discuss above only really applies to the system
> bus, since the user bus knows no policy and all clients that can connect
> to it at all are trusted anyway. For user bus clients the entire problem
> set goes away.

Right, sorry again, should have been more precise.

> Coming back to the original question (or what I think the question was):
> I figure the trusted/untrusted thing is also something that would
> translate to whether people should ship unit files or dbus1 service
> activation files. (That all said, thinking about it, maybe we should
> just drop the requirement for native unit files or the user bus, and
> just keep it in for the system bus).

I think that would be nice, though my understanding from your other reply is 
that dbus-daemon will handle that as usual anyway, at least for the not too 
distant future.

Cheers,
Kevin
-- 
Kevin Krammer, KDE developer, xdg-utils developer
KDE user support, developer mentoring
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 190 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.freedesktop.org/archives/dbus/attachments/20140102/8779ce96/attachment.pgp>