13:06:33 <mclasen> #startmeeting Workstation WG
13:06:33 <zodbot> Meeting started Mon Mar 25 13:06:33 2019 UTC.
13:06:33 <zodbot> This meeting is logged and archived in a public location.
13:06:33 <zodbot> The chair is mclasen. Information about MeetBot at http://wiki.debian.org/MeetBot.
13:06:33 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
13:06:33 <zodbot> The meeting name has been set to 'workstation_wg'
13:06:40 <mclasen> #meetingname workstation
13:06:40 <zodbot> The meeting name has been set to 'workstation'
13:06:48 <mclasen> #topic roll call
13:07:04 <mclasen> .hello mclasen
13:07:05 <zodbot> mclasen: mclasen 'Matthias Clasen' <mclasen@redhat.com>
13:07:15 <otaylor> .hello2
13:07:16 <zodbot> otaylor: otaylor 'Owen Taylor' <otaylor@redhat.com>
13:08:28 <mcatanzaro> .hello catanzaro
13:08:31 <zodbot> mcatanzaro: catanzaro 'Michael Catanzaro' <mcatanzaro@gnome.org>
13:08:42 * mcatanzaro apologizes for lateness
13:10:11 <mclasen> ok, thats 3
13:10:15 <mclasen> still not enough
13:10:20 * mclasen gives it 5 more minutes
13:10:59 <ryanlerch> .hello ryanlerch
13:11:00 <zodbot> ryanlerch: ryanlerch 'Ryan Lerch' <rlerch@redhat.com>
13:11:41 * cschalle hi
13:12:09 <mcatanzaro> mclasen: Looks like quorum?
13:12:22 <mclasen> now it does
13:12:36 <mclasen> ok, so topic ?
13:12:49 <mclasen> I have two that I want to bring up
13:13:01 <mclasen> anybody else have something to discuss ?
13:13:36 <cschalle> nothing from me
13:14:36 <mclasen> ok. I would like to revisit the gamemode inclusion, considering the follow-up discussion on the list
13:15:22 <mclasen> here: https://lists.fedoraproject.org/archives/list/desktop@lists.fedoraproject.org/thread/33F4YP7EYNLKKTC57NEQWDHBN4Z5SVCG/
13:16:18 <mclasen> hmm, not quite the right link
13:16:48 <mclasen> in any case. Bastien pointed out that there's a number of possible security issues, and that we haven't done due diligence
13:17:42 <mclasen> and suggested that we should not include this by default until at least the worst issues have been addressed
13:20:24 <mcatanzaro> Are there actually known security issues? More likely just general concern due about a one-man project running as a system daemon?
13:20:37 <mcatanzaro> Anyway, no strong opinion here... reversing course seems fine
13:20:41 <mclasen> I could not find bastiens actual review email
13:20:52 <mclasen> but he pointed out a couple of buffer overflows in code that runs as root
13:21:10 <cschalle> mclasen, didn't Christian Kellner patch some/all of these issues?
13:21:39 <mclasen> lets see if we can find out
13:23:02 <mclasen> but even if we patched this up for now, what convidence do we have in the quality going forwards ?
13:23:31 <mcatanzaro> yup
13:23:33 <cschalle> mclasen, the same confidence we have in any open source software?
13:24:00 <mclasen> what confidence I have in a random piece of software depends a lot on who wrote it and his track record
13:24:32 <cschalle> which is to be fair information you probably do not have for 90% of the packages on your system :)
13:25:09 <otaylor> I haven't seen that mail from Bastien - I don't see anything in ckellner's branch that affects the two run-as-root helper binaries
13:25:09 <mcatanzaro> I think most of our system daemons are sufficiently-high quality that it would be unlikely to find buffer overflow in code that runs before dropping privileges during a cursory/low-effort code review
13:25:14 <cschalle> I think to me lets make sure we have taken a proper look, and then also see how upstream takes to our patches here. What deadline do we have for deciding this?
13:26:21 * mcatanzaro wonders if he has just written famous last words
13:27:10 <mclasen> gicmo says that bastien only sent the review to me and him, so no link
13:28:07 <mclasen> gicmo patched some of the issues, but hasn't sent the patches upstream yet
13:28:36 <mclasen> and they are not in fedora builds yet either
13:29:15 <cschalle> to suggest some concrete action items here before we go to the lenght of reversing previous decision. Lets aim at getting a second code review (maybe Hans can also take a look). Gicmo can then hopefully get everything patches and shipping in Fedora ASAP. Then we reach out to upstream to discuss this issue and see if they are prepared to work on maintaining security levels going forward
13:29:23 <mclasen> for me, this just turns my 0 vote from last time into a firm -1
13:30:19 <mclasen> its not right architecturally, and it doesn't work for flatpaks, and it is written sloppily
13:31:14 <cschalle> mclasen, then we need to reach out to Ferral and Valve, as this is what their games are using and shipping with, so if we need changes to improve Flatpak support it also falls on us to resolve this.
13:31:35 <mclasen> https://github.com/gicmo/gamemode/commits/secrev1 is gicmo's fixes
13:31:46 <mclasen> the first commit there addresses unsafe strncpy uses
13:33:02 <cschalle> so do anyone know when we need to have this resolved by? what is the cuttoff date when we need to have this in our out of the compose?
13:33:32 <mclasen> https://fedoraproject.org/wiki/Releases/30/Schedule
13:33:49 <mclasen> final freeze is mid-april
13:34:09 <mclasen> I think we should just decide this now, tbh
13:34:24 <mclasen> I don't see any compelling reason to ship something with security issues for a few fps
13:34:56 <cschalle> mclasen, what we should do is look at if we can get those security issues resolved, and if not then we decide to drop it again.
13:34:59 <mclasen> we don't hesitate to delay firefox/wayland to f31, we shouldn't have a problem doing the same with gamemode
13:35:21 <cschalle> mclasen, those two items are not even slightly comparable in scope
13:35:42 <cschalle> mclasen, gamemode is the size of a hello world application in comparison
13:36:00 <mclasen> the size doesn't matter if it is running as root and has holes
13:36:06 <otaylor> mclasen: it's not great that that's there, but there's no user->root escalation there. It's more in a "needs more eyes" category than "no idea what they are doing"
13:36:31 * mclasen shuts up and lets somebody else continue to run the meeting
13:36:58 <cschalle> yes, so lets do what we should have done to begin with, quickly get it reviewed and fix any important issues we find. And if we in the next meeting haven't gotten to an acceptable situation then we drop it
13:38:01 <mcatanzaro> It seems pretty unlikely that we can become confident in its code quality in the next two weeks? Especially considering the starting point.
13:38:08 <cschalle> and in the medium time frame lets do some outreach regarding flatpak
13:39:17 <otaylor> mcatanzaro: we are talking 467 lines of run-as-root code
13:40:01 <otaylor> mcatanzaro: (err, 560, anyways, a quite limited lumber)
13:41:18 <cschalle> lets invite gicmo to the next meeting and we discuss it then
13:42:59 <mclasen> next topic I was going to bring up is: f30 release readiness
13:43:18 <mclasen> adam w asked me last week about that for the workstation, and I wasn't really sure what to say
13:44:27 <cschalle> what are our concerns?
13:44:47 <mclasen> I told him what I know about the state of various silverblue things
13:45:02 <mclasen> I am pretty confident that we'll hit the things we wanted for f30 there
13:45:24 <mclasen> nvidia drivers, chrome, and g-s support rpm-ostree
13:45:45 <mclasen> still looking weak on flatpaks in the registry
13:45:58 <mclasen> and I don't know where we stand wrt to having those available out of the box
13:46:01 <aday> we've got a few issues left over from the app menu retirement still
13:46:09 <mcatanzaro> I've been using F30 for about two weeks and the only serious problem I notice is https://bugzilla.redhat.com/show_bug.cgi?id=1690429, already proposed blocker
13:46:36 <mcatanzaro> aday: What issues? There is the weird extra space that sometimes shows up in the menu?
13:46:42 <aday> like https://gitlab.gnome.org/GNOME/gnome-shell/issues/968 and https://gitlab.gnome.org/GNOME/gnome-shell/issues/1051
13:47:23 <aday> and i'm still not seeing the fix to https://gitlab.gnome.org/GNOME/mutter/issues/493
13:48:12 <mcatanzaro> Also: lots of inconsistent desktop icons: simple-scan, cheese, GIMP, almost all the old gnome-games, dfeet, dconf-editor, nm-connection-editor, gnome-characters, gnome-font-viewer, gnome-screenshot
13:48:30 <mcatanzaro> (Why is nm-connection-editor showing up again? We had that desktop file hidden for a reason!)
13:48:33 <aday> mcatanzaro: i think we're tracking most of those
13:48:52 <mcatanzaro> Would be good to know where!
13:48:58 <aday> a lot of them have fixes that still have to percolate through
13:49:31 <otaylor> How are we going to track issues we want to fixed for F30?
13:49:41 * aday has a spreadsheet :/
13:50:06 <cschalle> hmm ,why is otaylor set as the assignee in mcatanzaro linked bug report, is the Fedora bugzilla maintainer not updated for that package?
13:50:56 <cschalle> we could put the items into teams.fedoraproject.org
13:51:01 <mcatanzaro> cschalle: otaylor has been the Fedora maintainer for a long time.
13:51:08 <otaylor> cschalle: yeah, it's not updated. it doesn't matter a lot since fmuellner and jadahl get cc'ed on everything.
13:51:14 <cschalle> ah ok
13:51:57 <mcatanzaro> Most of the GNOME packages are assigned to a few devs who can't possibly read all the bugs reports, it's always been that way
13:52:15 <aday> mcatanzaro: this is the main place for tracking icons - https://gitlab.gnome.org/GNOME/Initiatives/issues/2 . doesn't cover cases where the icon never made it downstream due to release issues, though
13:52:16 <mcatanzaro> We should do something about it, find a way to forward the bugs upstream so they can be noticed/read, but that's a longstanding issue
13:52:35 <mclasen> there's more bug reports than anybody can read
13:52:43 <mcatanzaro> Thanks aday, I'll add anything there if I notice it missing
13:52:47 <mclasen> duplicating bugs across trackers doesn't make that better
13:53:03 <otaylor> mclasen: if there's actual triage in the forwarding, it does
13:53:28 <mclasen> but if its the same person on both ends...
13:54:36 <mclasen> blockers are one way to track things that we need to fix for f30
13:54:37 <otaylor> mclasen: true, shuffling bugs around isn't a useful activity
13:54:48 <mclasen> I don't think the icons qualify for that, though
13:55:18 <aday> mclasen: not a blocker, but something to try and have in a nice state
13:55:18 <otaylor> I feel that the blocker process doesn't do a good job of capturing things that's might be on aday's spreadsheet
13:55:32 <mclasen> aday: yes, worth fixing, for sure
13:55:40 <mclasen> otaylor: I agree
13:55:44 <aday> milestone perhaps
13:57:20 <cschalle> in the past we tracked our new features on the Fedora Workstation tasklist and I think teams.fedoraproject.org can be the new tasklist. And to me things like important polish like aday's items belong on such a list, but I wouldn't want to put them on the blocker list
13:59:52 <otaylor> feels heavyweight to me to have a teams user story for "make sure that bug X gets fixed"
14:00:54 * mclasen points out that we're at the hour mark
14:01:20 * cschalle needs to run
14:01:32 * mclasen takes the action to collect a list of f30 polish items
14:01:57 <aday> the reason we're having this conversation is bugzilla of course
14:02:09 <mcatanzaro> Bugzilla is not the problem
14:02:18 <mclasen> #action mclasen will collect a list of f30 polish items
14:02:20 <mcatanzaro> A poorly-considered bug report workflow is the problem
14:02:42 <mcatanzaro> Collecting bug reports downstream on RHBZ when only upstream has the capacity to actually read them and triage
14:03:21 <mcatanzaro> RHBZ should be reserved for downstream packaging issues and blocker bug proposals. Anyway, endmeeting? Happy Monday?
14:03:35 * aday finds a sandwich
14:04:09 <mclasen> #endmeeting