14:00:43 #startmeeting Security Team Meeting - Agenda: https://fedoraproject.org/wiki/Security_Team_meetings 14:00:43 Meeting started Thu May 28 14:00:43 2015 UTC. The chair is Sparks. Information about MeetBot at http://wiki.debian.org/MeetBot. 14:00:43 Useful Commands: #action #agreed #halp #info #idea #link #topic. 14:00:46 #meetingname Fedora Security Team 14:00:46 The meeting name has been set to 'fedora_security_team' 14:00:51 #topic Roll Call 14:00:53 * Sparks 14:01:02 * d-caf 14:01:16 .fas fleite 14:01:17 FabioOlive: fleite 'Fabio Olive Leite' 14:01:25 .hellomynameis pjp 14:01:26 pjp: pjp 'None' 14:02:52 pjp: Hello 'None' 14:03:23 Sparks: Heh, hi! :) 14:05:02 Okay, lets get started... 14:05:15 jsmith: pre-ping 14:05:27 * jsmith is on a phone call, but will try to multi-task 14:05:33 ack 14:05:41 #info Participants are reminded to make liberal use of #info #link #help in order to make the minutes "more better" 14:05:48 #topic Follow up on last week's tasks 14:06:01 jsmith: What say you regarding rubygem-activesupport? 14:08:04 #action jsmith to patch rubygem-activesupport as provenpackager (BZ 905374) 14:08:15 I just need to push the update 14:08:22 jsmith: Really? 14:08:23 I'll do it by EOB today 14:08:40 #info jsmith to push the fix today 14:09:17 pjp: Whatever happened with the nonresponsive maintainer for this package? 14:09:50 Sparks: I did ping the Fedora maintainer for it, no response yet -> https://bugzilla.redhat.com/show_bug.cgi?id=1209124#c13 14:09:58 Okay 14:09:59 I'll follow-up on it, 14:10:25 Last resort, is to seek a new co-maintainer for the package via -devel list 14:10:34 And then there's the team goal... 14:10:39 #topic 90-Day Challenge 14:10:47 #link https://ethercalc.org/90-day-challenge 14:10:52 #info 90-Day Challenge has a goal to close all 2014 and prior Important CVEs in Fedora 14:11:02 #info As of 2015-05-28, of the 38 target bugs 14 have been closed, 1 is On_QA, and 23 are Open 14:11:26 There were no changes from last week. 14:11:58 We've got about a month left in the challenge. Maybe we can get a last minute push? 14:12:20 Sparks: Almost all of those bugs look taken by FST folks, there aren't any which nobody is looking at, right? 14:12:22 #action Sparks to blog about the challenge at 2/3 the way through. 14:12:47 pjp: Well, there are a few that are "owned" by nonresponsive FST members. 14:12:55 Ah, 14:12:56 * jsmith may have to steal a few... 14:13:00 * pjp found 1024650 14:13:13 pjp: I was thinking I'd go through them today and unown some that were stagnant. 14:13:24 Sparks: That sounds great :-) 14:14:02 I have one, likely two I need to go non-response on, but haven't started the process 14:14:04 Sparks: Yes, that'll help 14:14:24 #action Sparks to remove FST owners from 90-day challenge tickets that are stagnant (from a FST point of view) 14:15:33 #topic Outstanding BZ Tickets 14:15:38 #info Thursday's numbers: Critical 1, Important 41 (+1), Moderate 376 (+6), Low 163 (+3), Total 585, Trend +10 14:15:42 #info Current tickets owned: 108 (~19%) 14:15:47 #info Tickets closed: 318 (+3) 14:15:49 #info Tickets closed: 318 (+3) 14:16:30 Anyone have anything regarding tickets? 14:16:58 Nope, picked up several new important and started working them, one is held up by an upstream change needed. 14:17:31 Nope, 14:17:44 #topic New Meeting Time 14:17:53 #info Looking for a potential new meeting time 14:17:58 #link http://whenisgood.net/98rtz7p 14:18:02 Not sure there is a better new time 14:18:04 #link http://whenisgood.net/98rtz7p/results/eyz7qkh 14:18:16 Also, poll doesn't make it clear if it's EDT or EST when I select the time zone 14:18:18 d-caf: never hurts to revisit. 14:18:36 i would like to go on record of my dislike for daylight savings time 14:18:40 d-caf: Current time. You should change it to your local TZ 14:19:21 Sparks: Thursday mornings (EDT) are becoming increasingly difficult for me 14:19:24 * Sparks could change this to UTC as he should have done. 14:19:50 Yes, that'll help, 14:20:01 pjp: Could you add some additional times to your availability? Four hours a week really isn't helpful (unless you are really that rushed). 14:21:59 Okay, I just changed the thing to default to UTC. 14:22:01 Sparks: Not that, but the available times are such that the current time is best suitable, either day 14:22:09 * pjp checks 14:22:24 pjp: Right, but we want options. 14:22:36 pjp: Include best and okay times. :) 14:24:10 * FabioOlive submits lots of times 14:24:28 Cool 14:24:37 #topic Open floor discussion/questions/comments 14:24:44 Okay, anyone have anything? 14:25:30 fedora-kernel folks have conveyed that if someone reports an issue to FST, they be intimated of the same at the earliest 14:26:20 Last week someone reported a kernel issue on #fedora-security, I'm processing it today, it seems to have caused some issue for them 14:26:42 can we automate the non-responsive maintainer thing? I haven't done anything with it, but by reading your messages I see it is a very manual process. 14:27:11 perhaps an apps.fedoraproject.org thing that automatically flags someone as unresponsive given some condition, and that handles notifications and also un-owning all the bugs and packages that the unresponsive person has? 14:27:23 FabioOlive: I wonder if we shouldn't be reporting security issues to secalert@? 14:27:38 I would also like to see engagement rules as to how long before we hit the unresponsive processes 14:27:55 FabioOlive: Yes, I've a script to ping unattended bugs, but the process requires to see human responses to the bugs 14:27:58 Okay, hold on everyone. 14:28:13 #topic Reporting security issues to FST 14:28:22 Lets capture this real quick. 14:28:47 I wonder if we should be pointing folks to Red Hat Product Security for security issues they find. 14:29:16 Sparks, it sound like a good idea 14:29:23 These issues may appear in more places and it's more likely to get a CVE and other stuff faster. 14:29:35 Nope, it could cause some political friction, 14:29:36 And then, of course, it trickles down to us. 14:29:49 pjp: Political friction? 14:30:08 yeah, I don't believe "equating" Fedora Security Team to Red Hat Product Security is a good thing. 14:30:11 Sparks: what about epel packages? 14:30:23 pjp: The problem is that by disclosing security issues on IRC is a good idea. 14:30:34 FabioOlive: Correct. We have different missions and capabilities. 14:30:43 d-caf: Even EPEL packages. 14:31:08 Contrary to popular belief, Red Hat Product Security does actually give a crap about Fedora and EPEL. 14:31:39 I mean, that's where all these bugs come from now. 14:31:41 Sparks: I mean Fedora people see it as community effort, involving RH team for security stuff sounds dicey 14:31:48 Sparks: I'm sure they do, but do they have time/mandate to deal with misc epel packages that aren't part of there core packages? 14:32:12 yeah, that is a good point. I believe notifying secalert@rh.c of new flaws/bugs is nice, but relying on that, nope. 14:32:12 d-caf: They already do. 14:32:14 Sparks: Agreed, even then it could limit or come in the way of more participation 14:32:18 work together 14:32:37 d-caf: Yes, they do have a mandate for all Fedora issues 14:33:03 I'm not saying that we do anything different but if we don't report security issues at the top of the process we potentially delay getting things fixed upstream. 14:34:05 Sparks: Right, maybe a better thing would be to have security@fedoraproject.org, 14:34:48 Sparks: it could be used to relay information further to other addresses too, like upstream ones etc. 14:35:05 pjp: We have that address but I forget where it goes. 14:35:06 I may be missing something, but almost all bugzilla tickets I've worked have had links to redhat products. Are we talking about notifications outside these tickets? 14:35:15 Qemu project for example, has their own security process, same is true for kernel 14:35:27 d-caf: We're talking about people reporting security issues they find. 14:36:04 Sparks: I think we(FST) need to control the security@fp.o inbox 14:36:19 Sparks: so pre-ticket process (initial report stuff) and the spreading that info to relevant parties 14:36:25 pjp: I think it's a distribution address. 14:36:32 d-caf: correct 14:36:51 Sparks: Sure, we could be one of the folks to have access to it, 14:37:01 Let's try to find out, 14:37:23 pjp: For what purpose should we be advertising the address? 14:37:41 Sparks: for reporting security issues in Fedora packages, 14:37:53 pjp: No, we should be sending those up. 14:38:16 pjp: Why delay getting the information to the people that are actually going to start working the problem? 14:38:24 Sparks: Yes, that's what security@fp.o could relay it further 14:38:47 pjp: Plus, how are we going to handle sensitive submissions? 14:39:53 * Sparks thinks pointing people to a different address would cause confusion and potentially delay the process. 14:40:01 Sparks: No, I'm only saying instead of directing folks RH product security, fp.o address is better, 14:40:27 Sparks: We could create a process for handling sensitive submissions, that is doable 14:41:20 Let's first see what kind of submissions we get, 14:41:25 currently 14:41:34 pjp: And what happens when everyone that is watching that address goes away? 14:42:26 Sparks: They all go away at the same time with no replacements? 14:42:49 Sparks: I think that can be handled, currently Fedora does have critical infrastructure that requires such attention, 14:42:50 d-caf: We've seen this team go from twenty or so people to, well, the four or five of us. 14:43:07 pjp: ? 14:43:21 Sparks: I would hope the last person leaving shop would point it to something relevant (like redhat sec) 14:43:44 Sparks: I mean, as far as paying attention to security@fp.o submissions go, it can be handled 14:44:32 Sparks: at least 4-5 of us across different continents are on-line all days, 14:44:38 pjp: I just don't think it's sustainable. It's incredibly complicated to deal with potentially embargoed submissions AND what are we going to do but to hand it all over to Red Hat Product Security anyway? 14:45:39 Sparks: That's what, even if we forward it to RH product security, first point of contact for the community folks must be @fp.o address, 14:45:50 pjp: Why? 14:46:15 pjp: I tell you what, write this up and send it to the list for further discussion. 14:46:23 yep, sounds good 14:46:24 Sparks: because people see Fedora as community effort, and involving a corporate side for security tasks looks dicey 14:47:03 Sparks: to fedora-security ? 14:47:23 Sparks: it could come in the way of more participation 14:47:28 pjp: Except that's what they've been doing the entire time. We don't have the manpower, technology to properly handle security issues in realtime. 14:47:49 pjp: To security-team@l.fp.o 14:47:54 Sparks: Yes, I agree, 14:48:15 Sparks: okay 14:48:32 #topic Nonresponsive maintainer 14:48:51 FabioOlive: I think you had an idea regarding automating the process. How would that work? 14:50:55 I was thinking that we could have an automated job that, 14:51:23 searched bugs that go stale for X days, and groups that by maintainer, and sends a notification to the maintainer, 14:52:00 * pjp has a script to ping on bugzilla's for bugs > 90 days old 14:52:11 and if the maintainer does not log into some apps.fp.o thing after Z days, they automatically get flagged as non-responsive, and their bugs and packages go unowned and 14:52:19 pjp: Yeah, have you run that recently? I remember the last time you did. 14:52:34 so make it automatic, instead of a boring, sensitive, complex human process 14:52:44 Sparks: Recently was I think last month, when we started the 90 days challenge, 14:52:47 FabioOlive: I think it's an interesting idea. 14:52:53 pjp: Okay 14:52:59 The thing is, processing human reply to such pings is tricky 14:53:20 * pjp trying to see how to process them, 14:53:23 it is a volunteer project, yes, but one must be willing and able to put in the hours regularly, or personally flag themselves as "on leave" or soemthing and give up their packages 14:54:44 so maybe if all packagers agree to being subject to this automated "clock in to Fedora work" we would spend that time in more important stuff 14:55:39 I'm not a maintainer and I haven't even been active in the project, so I can't really weigh in. It's just an idea. 14:56:09 FabioOlive: Can you write this up and send it to security-team@l.fp.o? I think it's an interesting idea. 14:56:48 sure, will do. 14:57:19 #topic Open floor discussion/questions/comments 14:57:24 Okay, anyone have anything else? 14:57:49 #action FabioOlive will propose automated non-responsive maintainer process on the FST list. 14:57:55 Yes, nirik on #fedora-admin mentioned -> 14:57:55 security: security-private@lists.fedoraproject.or 14:58:21 looking at the list archives, it just has spam in it. 14:58:30 I'm not even aware of that list. 14:58:37 * jsmith didn't know about it either 14:58:39 exactly, same here 14:58:48 bressers is owner. ;) 14:58:55 More documentation of stuff needed... ;-) 14:58:56 Ha..ha.. :) 14:58:56 nirik: That says a lot. 14:58:57 * Sparks runs 14:59:00 Sparks: Time to beat up your boss... 14:59:07 I wonder if he is aware of it ;) 14:59:22 #action Sparks to follow up with nirik regarding security-private@l.fp.o. 14:59:30 Okay, anyone have anything else? 14:59:36 * jsmith has nothing 14:59:49 BTW, IMHO, we definitely need a better non responsive maintainer process, but it's pretty complex. ;( 14:59:54 Yes, we need a legit security@fp.o address, that is well known 15:00:05 nirik: +1 15:00:16 Okay, we've found the end of our string. 15:00:29 Catch you all on the lists and #fedora-security-team channel. 15:00:32 #endmeeting