----- Original Message -----
Hi,
Unfortunately the change deadline has passed, but our coredumpctl change is not testable due to [1]. Additionally, ABRT is broken due to [2]. We have workarounds for both issues, but it requires running SELinux commands locally. Accordingly, is likely that FESCo will reject the change at its next meeting.
I'm tired of prodding the SELinux developers via email and Bugzilla. This saga has been ongoing since last summer, which is way too long. I now have very, very serious doubts as to whether we should continue to ship with SELinux enabled in the Workstation product. We clearly cannot fix it even when it's breaking a critical developer feature that's a priority for the WG... so what happens when it breaks anything less important?
It broke creating galleries from Videos because of SELinux policies, it broke all the iOS devices integration, it still breaks fwupd checking for 8bitdo joypads. I usually run my systems with permissive SELinux, because it's too much of a pain.
Now that the new systemd with restrictions is in rawhide, I would rather we started using this functionality, meaning that the developers and maintainers of those daemons are the ones saying what is correct behaviour and what isn't.
For example, I recently restricted accesses in both fprintd and iio-sensor-proxy, which interact with hardware: https://cgit.freedesktop.org/libfprint/fprintd/tree/data/fprintd.service.in https://github.com/hadess/iio-sensor-proxy/blob/master/data/iio-sensor-proxy...
We need to start looking at shipping sandboxed applications. It makes adding dependencies much less painful, and actually enhances security.
Cheers