14:00:11 #startmeeting Security Team Meeting - Agenda: https://fedoraproject.org/wiki/Security_Team_meetings 14:00:11 Meeting started Thu Nov 27 14:00:11 2014 UTC. The chair is pjp. Information about MeetBot at http://wiki.debian.org/MeetBot. 14:00:11 Useful Commands: #action #agreed #halp #info #idea #link #topic. 14:00:25 #meetingname Fedora Security Team 14:00:25 The meeting name has been set to 'fedora_security_team' 14:00:38 #topic Roll Call 14:00:54 * pjp here 14:01:35 * jrusnack too 14:02:56 #info Participants are reminded to make liberal use of #info #link #help in order to make the minutes "more better" 14:04:12 #topic Follow up on last week's action items 14:04:59 So, I was suppose to write to fedora-devel list about disabling the remote root login facility in sshd(8), ie. to set PermitRootLogin=no. 14:05:46 I did start the discussion here -> https://lists.fedoraproject.org/pipermail/devel/2014-November/204530.html 14:06:07 pjp: we saw the thread - do you think it`s going to be resolved ? 14:06:18 The discussion is still alive, bug in general consensus seems it is okay to disable it. 14:06:41 jrusnack: Yes, I hope so. 14:07:02 The due feature request is also filed here -> https://fedoraproject.org/wiki/Changes/SSHD_PermitRootLogin_no 14:08:27 It's the first feature request from FST! That's some reason to cheer up!! :) 14:10:10 Apart from the SSH feature, I was also working on a tool to automate non responsive maintainer policy. 14:10:30 Which brings us to 14:10:32 #topic Outstanding BZ Tickets 14:11:42 #info today's numbers: Critical 1, Important 48, Moderate 421, Low 155, Total 625, Trend +25 14:12:09 #info Current tickets owned: 178 (~28%) 14:13:08 So, there has been slight increase in the number of moderate issues. 14:15:23 #topic Open floor discussion/questions/comments 14:16:26 So, we are open to further discussion/conversation 14:19:16 jrusnack: anything interesting you are working on? 14:19:29 not really 14:19:39 :) 14:19:40 the rails stack was updated 14:19:56 but otherwise people just ignore the work 14:20:14 jrusnack: how is rails stack in terms of security? 14:20:17 also I have bad experience with unresponsive maintainer policy 14:20:22 jrusnack: ignore your work? 14:20:34 jrusnack: Oh, what happened? 14:20:46 which I invoked against kanarip, who doesn`t even have valid mail address to send bugzilla messages to 14:21:01 but it was mostly ignored and he still owns ton of issues 14:21:04 * pjp thinks it's important to discuss these issues to in our meetings 14:21:37 jrusnack: I see, are all of these issue related to Ruby on Rails? 14:22:05 pjp: rails stack in epel was badly broken, now its less, but its epel, so sure there will always be security issues 14:22:23 jrusnack: I see, 14:22:30 pjp: no, but ruby packages (gem) 14:24:19 jrusnack: Could you please list down the issues that are owned by kanarip in one place, maybe your blog or security list ? 14:25:24 jrusnack: We need to find a way to involve proven-packagers in pushing these fixes to bodhi. 14:25:40 But before they could do that, someone need to patch upstream sources too. 14:26:07 jrusnack: is kanarip the upstream developer too? 14:26:40 pjp: so, I am not saying you are wrong, but I don`t think we should go that way 14:26:51 jrusnack: which way? 14:27:16 if we start patching and pushing security issues ourselves, whether with proven packagers or as co maintainers, it will not scale 14:27:43 jrusnack: Yes, I totally agree. 14:27:48 even though these are security issues, they are still issues, 14:28:04 and if maintainer does not solve issues, fedora has mechanisms to deal with it 14:28:31 I would rather make unresonsive maintainer policy *much quicker* if invoked by FST based on impact of a flaw 14:28:35 and see what happends 14:28:41 jrusnack: Not that we'll patch & push fixes, one option is to involve proven packagers where possible otherwise proceed towards retiring the package. 14:29:04 jrusnack: True. 14:30:07 jrusnack: if you publish a list of these packages, maybe someone could take them or fix them or we'll know if they are used at all. 14:31:34 pjp: isn`t it what we`re already doing ? 14:31:51 jrusnack: already doing? 14:32:01 the list is the bz query we use, we take the flaws and work on them 14:33:35 jrusnack: True, that is triaging part. To make someone take ownership of the packages, we'll have to ping folks on -devel or -security lists. 14:34:40 jrusnack: We need to raise these issues to wider audience so that they can help in some way. As you said, we can not patch and push all security fixes. 14:35:12 pjp: heh, triage. I don`t want to even start this discussion again :) 14:35:31 jrusnack: Even when we apply unresponsive maintainer policy, it involves finding a new maintainer, 14:35:40 jrusnack: which discussion? 14:36:14 pjp: sure, good point. so I think this breaks down to us not having much influence on fedora processes 14:37:06 pjp: I don`t think we triage anything, or that we should, and I frequently find other people have different understandings of the word :) please ignore 14:37:17 jrusnack: Sure, but we shall only have influence when we raise these issues and make more people pay attention. 14:37:42 maybe. 14:37:45 jrusnack: Oh that, yep I understand. 14:38:12 I can try to invoke unresponsive maintainer against kanarip once more and see what happens 14:38:17 I suspect nothing great 14:38:33 jrusnack: when you say invoke policy, what do you do? 14:38:55 write mail to fedora devel 14:39:18 jrusnack: and then? 14:39:33 usually you should open up a bugzilla and wait like 3 weeks for him to respond, but he has no mail 14:39:46 jrusnack: Right, 14:39:50 pjp: and that`s it. his account should be terminated 14:41:09 jrusnack: That's now all. You need to raise a FESCo ticket citing all the possible steps which you took and which failed. And request to takeover the package. 14:41:13 s/now/not 14:41:30 no, because I don`t want to tak over his packages 14:41:53 jrusnack: Exactly, in that case you need to fiind someone who is willing, 14:42:43 jrusnack: If noone is willing, maybe we could see if the package could be retired. 14:42:51 I see something wrong with this. I shouldn`t look for volunteers in order to get any security issue fixed 14:43:27 jrusnack: Well, then how would the packages find volunteers? 14:44:41 pjp: why is that a question ? 14:46:42 jrusnack: Because we want the security issues to be fixed. 14:47:14 jrusnack: 1. We have unattended security issues. 2. Current maintainer is not fixing them. 3. We can not fix them all ourselves. 4. Unless we ask, we won't find new maintainers. 14:47:21 pjp: you volunteer for that when you become a maintainer. i 14:47:46 jrusnack: I'm already a maintainer, :) 14:49:08 pjp: I think FST should not waste time on work maintainer can a should do: a) build and push packages b) find new maintainer if I don`t have time to maintains 14:49:26 we should just solve these two applying existing processes 14:49:42 and focus on actually cracking through issues, "triaging" them etc. 14:50:39 jrusnack: Agreed. But that cracking requires we involve wider community folks. 14:50:59 agree :) 14:51:24 jrusnack: Because the FOSS projects mostly work on the individual interest/hobby basis, we can not expect them to find new maintainer for their packages. 14:52:55 jrusnack: if we repeatedly raise these issues and report about unattended open issues, over time we'll find more contributors to fix these bugs. 14:55:20 jrusnack: It's easier said than done, but still we need to keep doing it. 14:56:12 pjp: ok ! 14:56:24 I think we are reaching end of our meeting time, let's continue this discussion on the list? 14:58:00 sure 14:58:40 jrusnack: Cool! Please consider writing to your blog or security list or both about the kanarip packages and open issues. 14:59:14 I'll conclude today's meeting with that. 14:59:21 Thank you for joining. :) 14:59:34 pjp: thank YOU! 15:00:20 #endmeeting