RFC: libei - emulated input in Wayland compositors

Peter Hutterer peter.hutterer at who-t.net
Fri Jul 31 09:03:50 UTC 2020

On Fri, Jul 31, 2020 at 11:00:53AM +0300, Vlad Zahorodnii wrote:
> > c) allows you to e.g. suspend the client when convenient or just ignore
> > certain sequences altogether. The two made-up examples are: suspend EI
> > during a password prompt, or allow EI from the software yubikey *only*
> > during a password prompt.
> We don't want any application be able to inject input events. How should
> a program such as synergy authenticate itself? or is it completely up to
> the compositor to decide what the authentication process looks like?

yes...ish. there are two kinds of applications, the ones that run in a trusted
sandbox (flatpak) and the ones that don't. For the ones outside the sandbox
you can provide some information and even auto-fill it, but in the end the
information is going to be untrustworthy. libei could (and probably should)
pack the protocol with things like /proc/$pid/commandline but in the end you
can't verify any of this. X, which basically always runs outside the sandbox
could add _NET_WM_NAME but that's a voluntary property. So my current
expectation is that we'll have *some* API in libei that provides for a
key-value store and we'll likely agree on some keys that should go in
there and classifies as untrusted but still usable data. e.g.
"proxy=xwayland" or something.

For flatpaks we have the app-id which is, AIUI, somewhat unfakable [1] and
the portal can pass that to the libeis backend. And, again AIUI, the portal
implementations already have some mechanisms to remember decisions,
so once you allow com.whatever.synergy, it'll always be permitted. But
either way, we're not adding anything new to that part of the process.

In the end, the *decision* what's being accepted and what isn't is still
outside, I think we can only provide data here. The backends will be
different enough that I'm not sure we can provide some common thing here but
I'm happy to be convinced otherwise.


[1] installing applications that misidentify themselves is out of scope here

More information about the wayland-devel mailing list