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