On tis, 2014-12-16 at 10:20 +0200, Tanu Kaskinen wrote: > On Tue, 2014-12-16 at 08:41 +0100, Alexander Larsson wrote: > > On tis, 2014-12-16 at 09:48 +0530, Arun Raghavan wrote: > > > Yes, kdbus is something that could be useful to plug this leak (though > > > we'd also need to make sure we don't add much overhead). In general, > > > securing the protocol is something we'd like to have, but is a huge > > > can of worms right now -- securing the protocol post-facto will be > > > hard to do right. > > > > kdbus should have very nice performance characteristics for this kind of > > use, but yeah, there are always risks with switching to an unknown > > system. > > > > I wonder if it could be possible to support both a new protocol and the > > old one at the same time. Then one could ignore security concerns in the > > old one and force contained apps to use the new one. > > If we add a kdbus protocol implementation, in my opinion that should > anyway exist side by side with the current native protocol, if only for > backward compatibility reasons. The only reason I can see why anyone > would object to that is that it means more code to maintain.
I agree, that this would be nice. For instance, it would allow the work i'm currently doing to continue work with old bundled pulse client libs as the host moves to kdbus. But i don't have a bone in this fight as i don't have to maintain anything. I just want ponies. _______________________________________________ gnome-os-list mailing list [email protected] https://mail.gnome.org/mailman/listinfo/gnome-os-list
