Collaboration on standard Wayland protocol extensions
Jasper St. Pierre
jstpierre at mecheye.net
Mon Mar 28 05:21:52 UTC 2016
On Sun, Mar 27, 2016 at 7:33 PM, Drew DeVault <sir at cmpwn.com> wrote:
> On 2016-03-27 4:41 PM, Jasper St. Pierre wrote:
> What are your specific concerns with it? I would tend to agree. I think
> that it's not bad as an implementation of this mechanic, but I agree
> that it's approaching the problem wrong. I think it would be wiser to
> start with how clients ask the compositor for permissions and how they
> receive them, then leave the details libwsm implements up to the
> I think a protocol extension would work just fine to implement a
> permission requesting/granting dialogue between clients and compositors.
That's what we should be doing, and that's why I'm not a huge fan of
WSM -- it provides a solution for the stuff that doesn't matter, and
doesn't make any progress on the part we need to tackle. I won't enjoy
using libwsm because it adds complexity and error cases (e.g. what
happens with no modules, like on a misconfigured system?), without
solving the actual problem.
Also, as I've mentioned in my emails before, APIs aren't exclusively
used through Wayland, they might also be on other systems like DBus,
which already has its own confusing policy system. It gets even worse
when protocols might cross both systems. So libwsm is already far in
the negative points bucket to me -- a Wayland-protocol centric
solution that ignores other IPCs and APIs, is configurable for no
purpose as far as I can tell, and still doesn't have an approachable
story about how it provides more security to the user.
I would rather the effort be spent making secure interfaces, exactly
as you've described.
> Drew DeVault
More information about the wayland-devel