Specifically this also changes the well-known name for flatpak from
"flatpak" to "org.flatpak". This would be a breaking change but there is
no released version of flatpak yet with security-context support.
Signed-off-by: Sebastian Wick <sebastian.wick@redhat.com>
"ask the client" isn't very clear. Let's use the word "configure"
which is more explicit: the client doesn't have a say in this.
(Note, wording in the following paragraphs is clearer and uses the
word "must".)
Signed-off-by: Simon Ser <contact@emersion.fr>
This was probably carried over from an early draft of the protocol.
This event is not a suggestion as the full description explains:
the client must ack it.
Signed-off-by: Simon Ser <contact@emersion.fr>
This protocol extension is ubiquitous. It's time to mark it as
stable.
The interface names are left unchanged, so that compositors and
clients don't need to be updated. In particular, the legacy "z"
prefix is still part of the interface name.
Signed-off-by: Simon Ser <contact@emersion.fr>
Stable protocols used to not have a version. But with the new
rules, they have one. Accomodate the build script for the new
rules.
Signed-off-by: Simon Ser <contact@emersion.fr>
EFL/Enlightenment hasn't been active in a while, doesn't seem to
have interest in the near future, and Mike is fine with ceasing
their membership. They can always be added back when interest
sparks again.
Signed-off-by: Simon Ser <contact@emersion.fr>
Closes: https://gitlab.freedesktop.org/wayland/wayland-protocols/-/issues/146
Specifically that after calling create_listener the only valid operation
on the sockets is to close them. They also must stay open and valid
until a round-trip after the call.
Signed-off-by: Sebastian Wick <sebastian.wick@redhat.com>
Clarify how and when initial wl_surface state provided by the core
protocol or by extensions to the wl_surface, like as
wp_fractional_scale_v1, is being delivered.
The motivation for such change is to make it clear that the first frame
for xdg-shell will be perfect, which implies that scaling and similar
properties affecting presentation would be delivered in time.
Signed-off-by: Kirill Chibisov <contact@kchibisov.com>
This is a variation of the unveil protocol I suggested in the Weston
issue about security contexts. This lets sandbox engines such as Flatpak
attach a security context to sandboxed clients. The compositor can then
restrict which features are made available to that client.
The protocol is designed around the assumption that the sandbox engine
uses this protocol when setting up the sandboxed application. After this
inital setup, the sandbox engine isn't necessarily running anymore.
For this reason, a special "close FD" is used to indicate when to stop
the security context listener: the sandbox engine can leak the FD into
the sandboxed app's process, and the OS will automatically close the FD
when the sandboxed app exits.
Signed-off-by: Simon Ser <contact@emersion.fr>
References: https://gitlab.freedesktop.org/wayland/weston/-/issues/206
Add a toplevel state to indicate that surface repaints have been
suspended. This may arise due to occlusion, output power state, etc.
In this state, clients can choose to take meaningful action such as
suspending any processing which would drive a repaint loop, or
communicating to the active browser tab that the tab is not
system-visible, or any other action that would be taken by a client not
expecting to repaint until further notice.
cf. discussion in wayland/wayland-protocols!99
Signed-off-by: Daniel Stone <daniels@collabora.com>
This should fix the following problem when I targeted a MR to
branch 'color' in Sebastian's fork of wayland-protocols:
$ ci-fairy check-commits --signed-off-by --junit-xml=results.xml
Traceback (most recent call last):
File "/usr/bin/ci-fairy", line 33, in <module>
sys.exit(load_entry_point('ci-fairy==0.1', 'console_scripts', 'ci-fairy')())
File "/usr/lib/python3.9/site-packages/click/core.py", line 1137, in __call__
return self.main(*args, **kwargs)
File "/usr/lib/python3.9/site-packages/click/core.py", line 1062, in main
rv = self.invoke(ctx)
File "/usr/lib/python3.9/site-packages/click/core.py", line 1668, in invoke
return _process_result(sub_ctx.command.invoke(sub_ctx))
File "/usr/lib/python3.9/site-packages/click/core.py", line 1404, in invoke
return ctx.invoke(self.callback, **ctx.params)
File "/usr/lib/python3.9/site-packages/click/core.py", line 763, in invoke
return __callback(*args, **kwargs)
File "/usr/lib/python3.9/site-packages/click/decorators.py", line 26, in new_func
return f(get_current_context(), *args, **kwargs)
File "/usr/lib/python3.9/site-packages/ci_fairy.py", line 1335, in check_commits
for commit in repo.iter_commits(commit_range):
File "/usr/lib/python3.9/site-packages/git/objects/commit.py", line 318, in _iter_from_process_or_stream
finalize_process(proc_or_stream)
File "/usr/lib/python3.9/site-packages/git/util.py", line 370, in finalize_process
proc.wait(**kwargs)
File "/usr/lib/python3.9/site-packages/git/cmd.py", line 447, in wait
raise GitCommandError(remove_password_if_present(self.args), status, errstr)
git.exc.GitCommandError: Cmd('git') failed due to: exit code(128)
cmdline: git rev-list cifairy/color..HEAD --
stderr: 'fatal: bad revision 'cifairy/color..HEAD'
'
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
This interface has no "enter" event. This was likely copy-pasted
from wl_pointer.set_cursor.
The event which indicates focus is proximity_in.
Signed-off-by: Simon Ser <contact@emersion.fr>
We merged a commit by mistake which doesn't have S-o-b. ci-fairy is
unhappy about it and will fail the check. Skip it if we aren't
running in a merge request context.
Signed-off-by: Simon Ser <contact@emersion.fr>
The xdg_surface window geometry can extend outside the base wl_surface
to e.g. accompany subsurfaces that extend outside it but is part of the
window itself. Spell out this bit explicitly.
Signed-off-by: Jonas Ådahl <jadahl@gmail.com>
The spec says that
When applied, the effective window geometry will be the set
window geometry clamped to the bounding rectangle of the combined
geometry of the surface of the xdg_surface and the associated
subsurfaces.
Thus, a client cannot assume the geometry will adapt to any subsequent
changes to any conditions that constrained the geometry.
Signed-off-by: Jonas Ådahl <jadahl@gmail.com>
Make it explicit in the protocol that [un]set_maximized and
the following configure event can't be reliably matched, and the
clients shouldn't try to do it.
Closes#106
Signed-off-by: Mikhail Gusarov <dottedmag@dottedmag.net>
This will let command-line Git tools re-map my name and e-mail address properly.
I'm using my personal e-mail address and not my Collabora address because I'm
not actively contributing to Wayland anymore and this is mostly for letting
people find me should they dig me up in the project history.
Signed-off-by: Faith Ekstrand <faith@gfxstrand.net>
The "logical size" as stated by the first paragraph corresponds to the
monitor size in the global compositor space.
To most clients, this is unnecessary information, and should be ignored,
but some used the listed examples to derive information that contradicts
the very definition of what this event communicates.
One example tried to add surface size assumptions, which was not
correct. Remove this part completely, clients should not try to
configure their surface sizes from the logical size of a monitor.
The other is the list of size examples; it tried to communicate that a
compositor sometimes may not scale the viewport of the monitor in its
global compositor coordinate space, in which case, the logical size
itself matches the actual resolution. Tweak this wording to make that
clear that it does not related to any surface size.
Signed-off-by: Jonas Ådahl <jadahl@gmail.com>
In the past, xdg-output had only the logical_position and
logical_size events, then the name and description events were
added. Later on, they were moved inside wl_output since they aren't
desktop-specific. However the goals section of the protocol overview
hasn't been updated accordingly.
Make it clear that this protocol's name and description events should
not be preferred over wl_output.
Signed-off-by: Simon Ser <contact@emersion.fr>
These have been merged into wl_output. Clients should prefer
using wl_output events instead of relying on xdg-output.
Signed-off-by: Simon Ser <contact@emersion.fr>
All other protocols in wayland-protocols are released under the MIT
license and this one was only merged with the ISC license by accident.
I am the only person who has touched this protocol in commits and the
only copyright holder, so relicensing to bring this protocol in line
with the rest is easy in this case.
References: https://gitlab.freedesktop.org/wayland/wayland-protocols/-/issues/119
Signed-off-by: Isaac Freund <mail@isaacfreund.com>
Clients such as swaylock [1] or waylock [2] provide options to fork and
detach from the controlling terminal when the session is locked. The
point of these options is avoid a race on suspending the system. A
command to suspend the system (e.g. zzz) may safely be chained with
e.g. waylock as so:
waylock -fork-on-lock && zzz
However, there is no guarantee that the compositor has actually
blanked all outputs before sending the locked event. Therefore there
is still a race as new "locked" frames may not have been presented on
all outputs before the system is suspended.
On my Linux system at least, the current framebuffer seems to be
preserved on suspend and restored on resume, leading to an "unlocked"
frame potentially being displayed when the system is resumed. Blanking
all outputs before suspend eliminates this vulnerability.
Currently clients could theoretically implement such -fork-on-lock
options a bit better if the compositor supports the presentation-time
protocol, however no clients I've seen currently do this and it seems
wise to make clients to do the right thing by default in this security
sensitive context. The presentation-time protocol is also not sufficient
in all cases, for example if the compositor has turned off power of an
output but still exposes it to clients. In this case the client would
wait forever to get a presentation feedback that will never come.
Unfortunately, the protocol currently states that the locked event will
be sent immediately on creation of the ext_session_lock_v1 object rather
than after all normal content is hidden.
Several different approaches have been considered for how to fix this in
the protocol specification.
One possibility would be to add a new event sent when all normal content
is hidden. This is however opt-in for clients and therefore less likely
to be properly implemented by all clients in practice.
Another alternative is to bump the version of the ext_session_lock_v1
interface and state that the semantics of when the compositor will send
the locked event. However, this still requires clients to opt-in by
binding version 2 of the interface. The compositor could technically
deny the attempts of any version 1 clients to lock the session, but this
would likely be a bad breaking change for users of version 1 clients.
While session lock clients should inform the user in some way that their
attempt to lock the session was denied (e.g. by exiting non-zero) it
does not seem to be the case that such exit codes are widely checked.
The option to fix the protocol that is all around the most secure is
changing the semantics of the locked event without bumping the version
of the interface. This is technically a breaking change, but the failure
mode is that a client relying on the locked event being sent immediately
hangs or crashes and the session stays locked.
I also have been unable to find any session lock client in the wild that
relies on the locked event being sent immediately.
The river wayland compositor [3] in fact already implements the fix for
this race condition since the 0.2.0 release and has not received any bug
reports about broken session lock clients yet.
Therefore, I think that making this technically breaking change to the
protocol is our all around best option in this situation. Prioritizing
security over compatibility seems like the right trade-off to make for a
security critical protocol.
[1]: https://github.com/swaywm/swaylock
[2]: https://github.com/ifreund/waylock
[3]: https://github.com/riverwm/river
Signed-off-by: Isaac Freund <mail@isaacfreund.com>
If the compositor advertises an output as a wp_drm_lease_connector_v1
and as wl_output, it should make the names match to allow clients to
identify the connection between the two outputs.
Signed-off-by: Xaver Hugl <xaver.hugl@gmail.com>
This protocols allows for communicating preferred fractional scales to
surfaces, which in combination with wp_viewport can be used to render
surfaces at fractional scales when applicable.
Signed-off-by: Kenny Levinsen <kl@kl.wtf>
For "ext" and "wp", the document uses the wording "ACKed by at
least 3 members". For "ext", the document uses the wording "ACKed
by at least one other member".
This is confusing, let's just use the same wording everywhere.
Signed-off-by: Simon Ser <contact@emersion.fr>
