----- 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.service.in We need to start looking at shipping sandboxed applications. It makes adding dependencies much less painful, and actually enhances security. Cheers _______________________________________________ desktop mailing list -- desktop@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to desktop-leave@xxxxxxxxxxxxxxxxxxxxxxx
