Cross-compilation support was broken in 55c018a350 because wayland-scanner from the host system is used with that change.
This patch changes it back to use wayland-scanner from the build system.
For normal (non-cross) compilation this shouldn't change anything.
Meson also uses the build machine wayland-scanner binary:
- c649a2b8c5/mesonbuild/modules/unstable_wayland.py (L48-L53)
It seems this gets forgotten before doing a release.
Like last time: https://github.com/swaywm/swaylock/pull/84
So this time I will try differently and set it to the (probably)
next version number :-)
fish completions should never be installed to share/fish/completions/ as
that directory is reserved exclusively for completions shipped as part
of the fish source code.
Use the same vendor_completions.d/ directory which the default fish
configuration uses.
Let's set the version in the meson file instead of declaring it outside.
In case git is installed we use the git hash as version. Instead it
isn't (like on a clean build system), let's use the version defined in
the project.
This implements a simpler version of the wlroots logger for swaylock.
With this logger, the dependency on wlroots can be dropped. This also
adds a debug flag and disables debugging output by default
Today I learned that GNU flaunts the POSIX standard in yet another
creative way. Additionally, this adds some security improvements,
namely:
- Zeroing out password buffers in the privileged child process
- setuid/setgid after reading /etc/shadow
It's better to use DT_RPATH dynamic section of the elf binary to store
the paths of libraries to load instead of overwriting LD_LIBRARY_PATH
for the whole environment, causing surprises. This solution is much more
transparent and perfectly suitable for running contained installations
of wayland/wlroots/sway.
The code unsetting the LD_LIBRARY_PATH/LD_PRELOAD was also deleted as
it's a placebo security at best - we should trust the execution path
that leads us to running sway, and it's way too late to care about those
variables since we already started executing our compositor, thus we
would be compromised anyway.
This involves setuid'ing swaylock, which then forks and drops perms on
the parent process. The child process remains root and listens on a pipe
for requests to validate passwords against /etc/shadow.
The "login" PAM configuration means somathing entirely different on
FreeBSD than on Linux: if you try to authenticate as the calling user,
it OKs the request without prompting for password. The "passwd" config
implements the desired functionality, therefore it should be used by
swaylock.
