Minutes: https://meetbot.fedoraproject.org/fedora-meeting-2/2017-12-18/workstation.20... Minutes (text): https://meetbot.fedoraproject.org/fedora-meeting-2/2017-12-18/workstation.20... Log: https://meetbot.fedoraproject.org/fedora-meeting-2/2017-12-18/workstation.20...
***
================================= #fedora-meeting-2: Workstation WG =================================
Meeting started by mcatanzaro at 14:10:33 UTC. The full logs are available at https://meetbot.fedoraproject.org/fedora-meeting-2/2017-12-18/workstation.20... .
Meeting summary --------------- * Roll call (mcatanzaro, 14:10:48)
* Langpacks UX and installation (mcatanzaro, 14:13:37) * Considering creating a LibreOffice wrapper app instead of modifying gnome-initial-setup to support langpacks (mcatanzaro, 14:19:10) * ACTION: juhp_ to continue investigating how best to handle langpack installation. (mcatanzaro, 14:28:03)
* Remove setroubleshoot (mcatanzaro, 14:29:45) * AGREED: Remove setroubleshoot from default Workstation install, without replacement. (mcatanzaro, 14:44:46) * LINK: http://cockpit-project.org/guide/latest/feature-selinux (juhp_, 14:45:12)
* Open floor (mcatanzaro, 14:49:58)
Meeting ended at 14:54:14 UTC.
Action Items ------------ * juhp_ to continue investigating how best to handle langpack installation.
Action Items, by person ----------------------- * juhp_ * juhp_ to continue investigating how best to handle langpack installation. * **UNASSIGNED** * (none)
People Present (lines said) --------------------------- * juhp_ (43) * mcatanzaro (35) * otaylor (20) * zodbot (10) * mclasen (6) * rdieter (5) * kalev_afk (0)
Generated by `MeetBot`_ 0.1.4
.. _`MeetBot`: http://wiki.debian.org/MeetBot
On Mon, 2017-12-18 at 09:01 -0600, mcatanzaro@gnome.org wrote:
- Remove setroubleshoot (mcatanzaro, 14:29:45)
- AGREED: Remove setroubleshoot from default Workstation install, without replacement. (mcatanzaro, 14:44:46)
14:49:54 <mcatanzaro> We'll see how it works out... fortunately, errors are quite rare nowadays.
A rather large part of the reason why errors are rare is that they are found, reported and fixed by pre-release testers. Removing setroubleshoot from the default desktop install *at a stroke* makes it vastly less likely that pre-release testers will do this. I'm not super happy with this call.
It seems rather baffling, honestly - it almost seems like you voted in favour of getting worse bug reports. Yes, maybe problems will still be reported, but you'll get reports against *your* components like "app doesn't start" or "app can't open file for some reason" rather than a report against selinux-policy that is a precisely targeted description of an selinux denial and, 90% of the time, will be *read and fixed by someone else without you ever having to see it*. Do you all really love doing triage work, or something?
On Mon, Dec 18, 2017 at 10:10 AM, Adam Williamson adamwill@fedoraproject.org wrote:
On Mon, 2017-12-18 at 09:01 -0600, mcatanzaro@gnome.org wrote:
- Remove setroubleshoot (mcatanzaro, 14:29:45)
- AGREED: Remove setroubleshoot from default Workstation install, without replacement. (mcatanzaro, 14:44:46)
14:49:54 <mcatanzaro> We'll see how it works out... fortunately, errors are quite rare nowadays.
A rather large part of the reason why errors are rare is that they are found, reported and fixed by pre-release testers. Removing setroubleshoot from the default desktop install *at a stroke* makes it vastly less likely that pre-release testers will do this. I'm not super happy with this call.
It seems rather baffling, honestly - it almost seems like you voted in favour of getting worse bug reports. Yes, maybe problems will still be reported, but you'll get reports against *your* components like "app doesn't start" or "app can't open file for some reason" rather than a report against selinux-policy that is a precisely targeted description of an selinux denial and, 90% of the time, will be *read and fixed by someone else without you ever having to see it*. Do you all really love doing triage work, or something?
I agree. But an improvement would be for abrt gui to be able to report AVC denials directly to bugzilla, filed against selinux policy.
On Mon, 2017-12-18 at 12:21 -0700, Chris Murphy wrote:
On Mon, Dec 18, 2017 at 10:10 AM, Adam Williamson adamwill@fedoraproject.org wrote:
On Mon, 2017-12-18 at 09:01 -0600, mcatanzaro@gnome.org wrote:
- Remove setroubleshoot (mcatanzaro, 14:29:45)
- AGREED: Remove setroubleshoot from default Workstation install, without replacement. (mcatanzaro, 14:44:46)
14:49:54 <mcatanzaro> We'll see how it works out... fortunately, errors are quite rare nowadays.
A rather large part of the reason why errors are rare is that they are found, reported and fixed by pre-release testers. Removing setroubleshoot from the default desktop install *at a stroke* makes it vastly less likely that pre-release testers will do this. I'm not super happy with this call.
It seems rather baffling, honestly - it almost seems like you voted in favour of getting worse bug reports. Yes, maybe problems will still be reported, but you'll get reports against *your* components like "app doesn't start" or "app can't open file for some reason" rather than a report against selinux-policy that is a precisely targeted description of an selinux denial and, 90% of the time, will be *read and fixed by someone else without you ever having to see it*. Do you all really love doing triage work, or something?
I agree. But an improvement would be for abrt gui to be able to report AVC denials directly to bugzilla, filed against selinux policy.
This is exactly what setroubleshoot *does*. I agree it'd be nice for them just to be one app with a decent interface, but we work with what we've got, not with wishes...
On Mon, Dec 18, 2017 at 1:13 PM, Adam Williamson adamwill@fedoraproject.org wrote:
On Mon, 2017-12-18 at 12:21 -0700, Chris Murphy wrote:
On Mon, Dec 18, 2017 at 10:10 AM, Adam Williamson adamwill@fedoraproject.org wrote:
On Mon, 2017-12-18 at 09:01 -0600, mcatanzaro@gnome.org wrote:
- Remove setroubleshoot (mcatanzaro, 14:29:45)
- AGREED: Remove setroubleshoot from default Workstation install, without replacement. (mcatanzaro, 14:44:46)
14:49:54 <mcatanzaro> We'll see how it works out... fortunately, errors are quite rare nowadays.
A rather large part of the reason why errors are rare is that they are found, reported and fixed by pre-release testers. Removing setroubleshoot from the default desktop install *at a stroke* makes it vastly less likely that pre-release testers will do this. I'm not super happy with this call.
It seems rather baffling, honestly - it almost seems like you voted in favour of getting worse bug reports. Yes, maybe problems will still be reported, but you'll get reports against *your* components like "app doesn't start" or "app can't open file for some reason" rather than a report against selinux-policy that is a precisely targeted description of an selinux denial and, 90% of the time, will be *read and fixed by someone else without you ever having to see it*. Do you all really love doing triage work, or something?
I agree. But an improvement would be for abrt gui to be able to report AVC denials directly to bugzilla, filed against selinux policy.
This is exactly what setroubleshoot *does*. I agree it'd be nice for them just to be one app with a decent interface, but we work with what we've got, not with wishes...
I don't see any UI in SELinux Troubleshooter to file a bug report. The Notify Admin button presents two options: Unix Mailspool (Movemail) and Newgroup account. Both of those sound Mesozoic, but as they have no meaning to me I could be wrong about their era.
On Mon, 2017-12-18 at 13:53 -0700, Chris Murphy wrote:
I don't see any UI in SELinux Troubleshooter to file a bug report. The Notify Admin button presents two options: Unix Mailspool (Movemail) and Newgroup account. Both of those sound Mesozoic, but as they have no meaning to me I could be wrong about their era.
It's under Troubleshoot. 'Troubleshoot', then 'Report Bug'. The 'Admin' in 'Notify Admin' refers to the *system* administrator - the idea being that if you're the user of a system maintained by someone else, you can alert them to the issue. I have no idea why this option (which is probably a fairly niche thing) is so prominent in the UI. I'm certainly not defending setroubleshoot as a shining example of great UI design. :P
On Mon, Dec 18, 2017 at 2:12 PM, Adam Williamson adamwill@fedoraproject.org wrote:
On Mon, 2017-12-18 at 13:53 -0700, Chris Murphy wrote:
I don't see any UI in SELinux Troubleshooter to file a bug report. The Notify Admin button presents two options: Unix Mailspool (Movemail) and Newgroup account. Both of those sound Mesozoic, but as they have no meaning to me I could be wrong about their era.
It's under Troubleshoot. 'Troubleshoot', then 'Report Bug'.
That's really funny. Many years have gone by, I've never seen this. I've always filed AVCs manually. Wow.
The 'Admin'
in 'Notify Admin' refers to the *system* administrator - the idea being that if you're the user of a system maintained by someone else, you can alert them to the issue. I have no idea why this option (which is probably a fairly niche thing) is so prominent in the UI. I'm certainly not defending setroubleshoot as a shining example of great UI design. :P
Of course not.
On Mon, 2017-12-18 at 14:23 -0700, Chris Murphy wrote:
On Mon, Dec 18, 2017 at 2:12 PM, Adam Williamson adamwill@fedoraproject.org wrote:
On Mon, 2017-12-18 at 13:53 -0700, Chris Murphy wrote:
I don't see any UI in SELinux Troubleshooter to file a bug report. The Notify Admin button presents two options: Unix Mailspool (Movemail) and Newgroup account. Both of those sound Mesozoic, but as they have no meaning to me I could be wrong about their era.
It's under Troubleshoot. 'Troubleshoot', then 'Report Bug'.
That's really funny. Many years have gone by, I've never seen this. I've always filed AVCs manually. Wow.
Heh. The thing that drives me nuts is I've never found a way to trigger this workflow from a CLI (even though I think it's ultimately backed by libreport), so for reporting AVCs from non-graphical installs I have to install a desktop or just do it manually (which means dupe detection with any setroubleshoot-filed reports that *do* exist won't work). Sigh.
On Mon, Dec 18, 2017 at 4:37 PM Adam Williamson adamwill@fedoraproject.org wrote:
On Mon, 2017-12-18 at 14:23 -0700, Chris Murphy wrote:
On Mon, Dec 18, 2017 at 2:12 PM, Adam Williamson adamwill@fedoraproject.org wrote:
On Mon, 2017-12-18 at 13:53 -0700, Chris Murphy wrote:
I don't see any UI in SELinux Troubleshooter to file a bug report.
The
Notify Admin button presents two options: Unix Mailspool (Movemail) and Newgroup account. Both of those sound Mesozoic, but as they have no meaning to me I could be wrong about their era.
It's under Troubleshoot. 'Troubleshoot', then 'Report Bug'.
That's really funny. Many years have gone by, I've never seen this. I've always filed AVCs manually. Wow.
Heh. The thing that drives me nuts is I've never found a way to trigger this workflow from a CLI (even though I think it's ultimately backed by libreport), so for reporting AVCs from non-graphical installs I have to install a desktop or just do it manually (which means dupe detection with any setroubleshoot-filed reports that *do* exist won't work). Sigh.
https://github.com/cockpit-project/cockpit/wiki/Feature:-SELinux-Troubleshoo...
Hi Adam,
While I appreciate that setroubleshoot can be a useful tool for testers to file bug reports, to be in the default install, I think it needs to meet some minimum requirement of good experience for users encountering it. - and when you consider setroubleshoot in the role of:
Average target user encounters an operating system defect and reports it
I just don't think it meets that target. In addition, as of gnome-3.26, we don't even show indicator icons unless you install an extension, so setroubleshoot isn't filling the expected role of notifying about problems.
Owen
On Mon, Dec 18, 2017 at 12:10 PM, Adam Williamson < adamwill@fedoraproject.org> wrote:
On Mon, 2017-12-18 at 09:01 -0600, mcatanzaro@gnome.org wrote:
- Remove setroubleshoot (mcatanzaro, 14:29:45)
- AGREED: Remove setroubleshoot from default Workstation install, without replacement. (mcatanzaro, 14:44:46)
14:49:54 <mcatanzaro> We'll see how it works out... fortunately, errors are quite rare nowadays.
A rather large part of the reason why errors are rare is that they are found, reported and fixed by pre-release testers. Removing setroubleshoot from the default desktop install *at a stroke* makes it vastly less likely that pre-release testers will do this. I'm not super happy with this call.
It seems rather baffling, honestly - it almost seems like you voted in favour of getting worse bug reports. Yes, maybe problems will still be reported, but you'll get reports against *your* components like "app doesn't start" or "app can't open file for some reason" rather than a report against selinux-policy that is a precisely targeted description of an selinux denial and, 90% of the time, will be *read and fixed by someone else without you ever having to see it*. Do you all really love doing triage work, or something? -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net _______________________________________________ desktop mailing list -- desktop@lists.fedoraproject.org To unsubscribe send an email to desktop-leave@lists.fedoraproject.org
On Tue, Dec 19, 2017 at 9:38 AM Owen Taylor otaylor@redhat.com wrote:
Hi Adam,
While I appreciate that setroubleshoot can be a useful tool for testers to file bug reports, to be in the default install, I think it needs to meet some minimum requirement of good experience for users encountering it. - and when you consider setroubleshoot in the role of:
Average target user encounters an operating system defect and reports it
I just don't think it meets that target. In addition, as of gnome-3.26, we don't even show indicator icons unless you install an extension, so setroubleshoot isn't filling the expected role of notifying about problems.
I'm really not sure "We made a terrible decision to suppress projects' notification mechanisms" == "this project isn't notifying about problems". The tool notifies... you just decided to stop showing that to the user and are now using that as a circular argument for why the tool is not useful.
There are valid complaints to make about the user experience. However, removing a tool that is eminently useful to developers of the system simply because you don't think it's pretty enough is cutting off your nose to spite your face.
The overwhelming majority of SELinux bugs get found and fixed because people like me use Rawhide/Branched and use SETroubleshoot to report them. This is why the Workstation WG seems to think that SELinux bugs don't happen that often... we're catching them before you notice most of the time.
Yes, people can still install the package after the fact, but honestly without it (and without the notifications you are suppressing by default), people often do not realize the denials are occurring.
I think we need to get this back in the default install and fix the misfeature of suppressing the system tray icon (even if this means installing TopIcons+ by default on Workstation).
On Tue, Dec 19, 2017 at 4:57 PM, Stephen Gallagher sgallagh@redhat.com wrote:
Yes, people can still install the package after the fact, but honestly without it (and without the notifications you are suppressing by default), people often do not realize the denials are occurring.
This is inaccurate. I'm running F27 with setroubleshoot installed right now, and when there's a SELinux AVC, I do get a notification, and I don't have any extensions insalled. setroubleshoot uses regular, modern desktop notifications, and doesn't depend on the "status icon" being visible.
I think we need to get this back in the default install and fix the misfeature of suppressing the system tray icon (even if this means installing TopIcons+ by default on Workstation).
I don't think re-introducing status icons is a good idea. There's a reason they were removed.
I wanted to mention the issue with the icons, because it seemed relevant, and something we'd need to think about if we kept the package. But certainly, the right thing to do if keeping setroubleshoot would be to make sure that setroubleshoot notifies via the normal mechanisms (which are what users are used to for updates, ABRT, etc) rather than to jump through hoops to keep a hard-to-identify yellow nag icon that shows up on the desktop.
It sounds like from what Elad says, that nothing is necessary - and that setroubleshoot was already using libnotify. That's good, and does slightly reduce the bar to retain setroubleshoot, but having looked at setroubleshoot UI again, I just don't feel there's a justification to notify the user in the default configuration that they need to visit this application - it's just not well suited to the task of walking a non-operating-system-export through reporting an issue with the operating system.
Owen
On Tue, Dec 19, 2017 at 9:57 AM, Stephen Gallagher sgallagh@redhat.com wrote:
On Tue, Dec 19, 2017 at 9:38 AM Owen Taylor otaylor@redhat.com wrote:
Hi Adam,
While I appreciate that setroubleshoot can be a useful tool for testers to file bug reports, to be in the default install, I think it needs to meet some minimum requirement of good experience for users encountering it. - and when you consider setroubleshoot in the role of:
Average target user encounters an operating system defect and reports it
I just don't think it meets that target. In addition, as of gnome-3.26, we don't even show indicator icons unless you install an extension, so setroubleshoot isn't filling the expected role of notifying about problems.
I'm really not sure "We made a terrible decision to suppress projects' notification mechanisms" == "this project isn't notifying about problems". The tool notifies... you just decided to stop showing that to the user and are now using that as a circular argument for why the tool is not useful.
There are valid complaints to make about the user experience. However, removing a tool that is eminently useful to developers of the system simply because you don't think it's pretty enough is cutting off your nose to spite your face.
The overwhelming majority of SELinux bugs get found and fixed because people like me use Rawhide/Branched and use SETroubleshoot to report them. This is why the Workstation WG seems to think that SELinux bugs don't happen that often... we're catching them before you notice most of the time.
Yes, people can still install the package after the fact, but honestly without it (and without the notifications you are suppressing by default), people often do not realize the denials are occurring.
I think we need to get this back in the default install and fix the misfeature of suppressing the system tray icon (even if this means installing TopIcons+ by default on Workstation).
desktop mailing list -- desktop@lists.fedoraproject.org To unsubscribe send an email to desktop-leave@lists.fedoraproject.org
In order to consistently enforce our minimum standards of quality for applications that are installed by default, we did indeed vote in favor of getting worse bug reports. I expect this will make it much more difficult to solve SELinux problems. If so, we will probably wind up discussing whether to disable SELinux altogether sooner rather than later. (That's never received nearly enough support in the past, but who can say what the future holds.) I suspect that the desktop team does not intend to assign resources to this problem, so it will be up to people who care about SELinux to work on a solution for avoiding this, if they care to do so.
My recommendation would be to add SELinux problem reporting functionality in a way that involves a very simple GUI and absolutely zero technical details. Or, perhaps it would be wisest to give up on having any UI for this and just send the bug report in the background, like ABRT does.
Previously, I had hoped that SELinux reporting functionality would be added to ABRT, but that has clearly stalled. I'm not sure if I would recommend this path anymore, because ABRT's bug reporting workflow is full of technical details that are probably not appropriate for Fedora Workstation, and you don't want to add SELinux reporting to ABRT only for us to later propose dropping the ABRT GUI. (Fortunately, ABRT is still useful even without the bug report GUI, because it reports problems to FAF without needing the GUI, and because bug reports get filed automatically when a problem is reported enough times to FAF.)
On Tue, Dec 19, 2017 at 04:13:52PM -0000, Michael Catanzaro wrote:
In order to consistently enforce our minimum standards of quality for applications that are installed by default, we did indeed vote in favor of getting worse bug reports. I expect this will make it much more difficult to solve SELinux problems. If so, we will probably wind up discussing whether to disable SELinux altogether sooner rather than later. (That's never received nearly enough support in the past, but who can say what the future holds.)
I'd be interested in seeing a workstation-targeted SELinux policy, covering:
* svirt for virtual machines * svirt for Docker/OCI/atomic containers * whatever sandboxing for flatpak * some of the very fundamental protections for X (are there equivalents in wayland?) * maybe a more carefully thought-through policy for firefox? it's hard! * maybe something wrapping tracker miners? or maybe we rely on secomp?
and basically just let everything else through. That would leave protection in some of the areas where it really makes a big difference, with fewer AVCs which don't really affect use. People who want to do development and want to opt-in to the stricter policy could.
I know that recently it seems like there hasn't been as much attention on SELinux issues in Fedora (see devel list threads), and I think having a simpler workstation policy would allow the limited maintenance time to be spent on things that have a big impact rather than on... yet another random program trying to write to tmp and it's really fine and whatnot.
I suspect that the desktop team does not intend to assign resources to this problem, so it will be up to people who care about SELinux to work on a solution for avoiding this, if they care to do so.
Well, if a reporting GUI is desired, we're gonna need someone with skill at making GUI apps, or else we get... well, the thing we have. :)
My recommendation would be to add SELinux problem reporting functionality in a way that involves a very simple GUI and absolutely zero technical details. Or, perhaps it would be wisest to give up on having any UI for this and just send the bug report in the background, like ABRT does.
That seems reasonable too.
desktop@lists.fedoraproject.org
-
Adam Williamson -
Chris Murphy -
Elad Alfassa -
Matthew Miller -
mcatanzaro＠gnome.org -
Michael Catanzaro
-
Owen Taylor -
Stephen Gallagher