fedora_security_team
LOGS
14:00:43 <Sparks> #startmeeting Security Team Meeting - Agenda: https://fedoraproject.org/wiki/Security_Team_meetings
14:00:43 <zodbot> 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 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
14:00:46 <Sparks> #meetingname Fedora Security Team
14:00:46 <zodbot> The meeting name has been set to 'fedora_security_team'
14:00:51 <Sparks> #topic Roll Call
14:00:53 * Sparks 
14:01:02 * d-caf 
14:01:16 <FabioOlive> .fas fleite
14:01:17 <zodbot> FabioOlive: fleite 'Fabio Olive Leite' <fabio.olive@gmail.com>
14:01:25 <pjp> .hellomynameis pjp
14:01:26 <zodbot> pjp: pjp 'None' <pj.pandit@yahoo.co.in>
14:02:52 <Sparks> pjp: Hello 'None'
14:03:23 <pjp> Sparks: Heh, hi! :)
14:05:02 <Sparks> Okay, lets get started...
14:05:15 <Sparks> jsmith: pre-ping
14:05:27 * jsmith is on a phone call, but will try to multi-task
14:05:33 <Sparks> ack
14:05:41 <Sparks> #info Participants are reminded to make liberal use of #info #link #help in order to make the minutes "more better"
14:05:48 <Sparks> #topic Follow up on last week's tasks
14:06:01 <Sparks> jsmith: What say you regarding rubygem-activesupport?
14:08:04 <Sparks> #action jsmith to patch rubygem-activesupport as provenpackager (BZ 905374)
14:08:15 <jsmith> I just need to push the update
14:08:22 <Sparks> jsmith: Really?
14:08:23 <jsmith> I'll do it by EOB today
14:08:40 <Sparks> #info jsmith to push the fix today
14:09:17 <Sparks> pjp: Whatever happened with the nonresponsive maintainer for this package?
14:09:50 <pjp> 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 <Sparks> Okay
14:09:59 <pjp> I'll follow-up on it,
14:10:25 <pjp> Last resort, is to seek a new co-maintainer for the package via -devel list
14:10:34 <Sparks> And then there's the team goal...
14:10:39 <Sparks> #topic 90-Day Challenge
14:10:47 <Sparks> #link https://ethercalc.org/90-day-challenge
14:10:52 <Sparks> #info 90-Day Challenge has a goal to close all 2014 and prior Important CVEs in Fedora
14:11:02 <Sparks> #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 <Sparks> There were no changes from last week.
14:11:58 <Sparks> We've got about a month left in the challenge.  Maybe we can get a last minute push?
14:12:20 <pjp> Sparks: Almost all of those bugs look taken by FST folks, there aren't any which nobody is looking at, right?
14:12:22 <Sparks> #action Sparks to blog about the challenge at 2/3 the way through.
14:12:47 <Sparks> pjp: Well, there are a few that are "owned" by nonresponsive FST members.
14:12:55 <pjp> Ah,
14:12:56 * jsmith may have to steal a few...
14:13:00 * pjp found 1024650
14:13:13 <Sparks> pjp: I was thinking I'd go through them today and unown some that were stagnant.
14:13:24 <jsmith> Sparks: That sounds great :-)
14:14:02 <d-caf> I have one, likely two I need to go non-response on, but haven't started the process
14:14:04 <pjp> Sparks: Yes, that'll help
14:14:24 <Sparks> #action Sparks to remove FST owners from 90-day challenge tickets that are stagnant (from a FST point of view)
14:15:33 <Sparks> #topic Outstanding BZ Tickets
14:15:38 <Sparks> #info Thursday's numbers: Critical 1, Important 41 (+1), Moderate 376 (+6), Low 163 (+3), Total 585, Trend +10
14:15:42 <Sparks> #info Current tickets owned: 108 (~19%)
14:15:47 <Sparks> #info Tickets closed: 318 (+3)
14:15:49 <Sparks> #info Tickets closed: 318 (+3)
14:16:30 <Sparks> Anyone have anything regarding tickets?
14:16:58 <d-caf> Nope, picked up several new important and started working them, one is held up by an upstream change needed.
14:17:31 <pjp> Nope,
14:17:44 <Sparks> #topic New Meeting Time
14:17:53 <Sparks> #info Looking for a potential new meeting time
14:17:58 <Sparks> #link http://whenisgood.net/98rtz7p
14:18:02 <d-caf> Not sure there is a better new time
14:18:04 <Sparks> #link http://whenisgood.net/98rtz7p/results/eyz7qkh
14:18:16 <d-caf> Also, poll doesn't make it clear if it's EDT or EST when I select the time zone
14:18:18 <Sparks> d-caf: never hurts to revisit.
14:18:36 <d-caf> i would like to go on record of my dislike for daylight savings time
14:18:40 <Sparks> d-caf: Current time.  You should change it to your local TZ
14:19:21 <jsmith> 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 <pjp> Yes, that'll help,
14:20:01 <Sparks> 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 <Sparks> Okay, I just changed the thing to default to UTC.
14:22:01 <pjp> 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 <Sparks> pjp: Right, but we want options.
14:22:36 <Sparks> pjp: Include best and okay times.  :)
14:24:10 * FabioOlive submits lots of times
14:24:28 <Sparks> Cool
14:24:37 <Sparks> #topic Open floor discussion/questions/comments
14:24:44 <Sparks> Okay, anyone have anything?
14:25:30 <pjp> 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 <pjp> 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 <FabioOlive> 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 <FabioOlive> 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 <Sparks> FabioOlive: I wonder if we shouldn't be reporting security issues to secalert@?
14:27:38 <d-caf> I would also like to see engagement rules as to how long before we hit the unresponsive processes
14:27:55 <pjp> FabioOlive: Yes, I've a script to ping unattended bugs, but the process requires to see human responses to the bugs
14:27:58 <Sparks> Okay, hold on everyone.
14:28:13 <Sparks> #topic Reporting security issues to FST
14:28:22 <Sparks> Lets capture this real quick.
14:28:47 <Sparks> I wonder if we should be pointing folks to Red Hat Product Security for security issues they find.
14:29:16 <lnxslck> Sparks, it sound like a good idea
14:29:23 <Sparks> These issues may appear in more places and it's more likely to get a CVE and other stuff faster.
14:29:35 <pjp> Nope, it could cause some political friction,
14:29:36 <Sparks> And then, of course, it trickles down to us.
14:29:49 <Sparks> pjp: Political friction?
14:30:08 <FabioOlive> yeah, I don't believe "equating" Fedora Security Team to Red Hat Product Security is a good thing.
14:30:11 <d-caf> Sparks: what about epel packages?
14:30:23 <Sparks> pjp: The problem is that by disclosing security issues on IRC is a good idea.
14:30:34 <Sparks> FabioOlive: Correct.  We have different missions and capabilities.
14:30:43 <Sparks> d-caf: Even EPEL packages.
14:31:08 <Sparks> Contrary to popular belief, Red Hat Product Security does actually give a crap about Fedora and EPEL.
14:31:39 <Sparks> I mean, that's where all these bugs come from now.
14:31:41 <pjp> Sparks: I mean Fedora people see it as community effort, involving RH team for security stuff sounds dicey
14:31:48 <d-caf> 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 <FabioOlive> 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 <Sparks> d-caf: They already do.
14:32:14 <pjp> Sparks: Agreed, even then it could limit or come in the way of more participation
14:32:18 <FabioOlive> work together
14:32:37 <pjp> d-caf: Yes, they do have a mandate for all Fedora issues
14:33:03 <Sparks> 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 <pjp> Sparks: Right, maybe a better thing would be to have security@fedoraproject.org,
14:34:48 <pjp> Sparks: it could be used to relay information further to other addresses too, like upstream ones etc.
14:35:05 <Sparks> pjp: We have that address but I forget where it goes.
14:35:06 <d-caf> 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 <pjp> Qemu project for example, has their own security process, same is true for kernel
14:35:27 <Sparks> d-caf: We're talking about people reporting security issues they find.
14:36:04 <pjp> Sparks: I think we(FST) need to control the security@fp.o inbox
14:36:19 <d-caf> Sparks: so pre-ticket process (initial report stuff) and the spreading that info to relevant parties
14:36:25 <Sparks> pjp: I think it's a distribution address.
14:36:32 <Sparks> d-caf: correct
14:36:51 <pjp> Sparks: Sure, we could be one of the folks to have access to it,
14:37:01 <pjp> Let's try to find out,
14:37:23 <Sparks> pjp: For what purpose should we be advertising the address?
14:37:41 <pjp> Sparks: for reporting security issues in Fedora packages,
14:37:53 <Sparks> pjp: No, we should be sending those up.
14:38:16 <Sparks> pjp: Why delay getting the information to the people that are actually going to start working the problem?
14:38:24 <pjp> Sparks: Yes, that's what security@fp.o could relay it further
14:38:47 <Sparks> 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 <pjp> Sparks: No, I'm only saying instead of directing folks RH product security, fp.o address is better,
14:40:27 <pjp> Sparks: We could create a process for handling sensitive submissions, that is doable
14:41:20 <pjp> Let's first see what kind of submissions we get,
14:41:25 <pjp> currently
14:41:34 <Sparks> pjp: And what happens when everyone that is watching that address goes away?
14:42:26 <d-caf> Sparks: They all go away at the same time with no replacements?
14:42:49 <pjp> Sparks: I think that can be handled, currently Fedora does have critical infrastructure that requires such attention,
14:42:50 <Sparks> d-caf: We've seen this team go from twenty or so people to, well, the four or five of us.
14:43:07 <Sparks> pjp: ?
14:43:21 <d-caf> Sparks: I would hope the last person leaving shop would point it to something relevant (like redhat sec)
14:43:44 <pjp> Sparks: I mean, as far as paying attention to security@fp.o submissions go, it can be handled
14:44:32 <pjp> Sparks: at least 4-5 of us across different continents are on-line all days,
14:44:38 <Sparks> 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 <pjp> 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 <Sparks> pjp: Why?
14:46:15 <Sparks> pjp: I tell you what, write this up and send it to the list for further discussion.
14:46:23 <FabioOlive> yep, sounds good
14:46:24 <pjp> Sparks: because people see Fedora as community effort, and involving a corporate side for security tasks looks dicey
14:47:03 <pjp> Sparks: to fedora-security ?
14:47:23 <pjp> Sparks: it could come in the way of more participation
14:47:28 <Sparks> 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 <Sparks> pjp: To security-team@l.fp.o
14:47:54 <pjp> Sparks: Yes, I agree,
14:48:15 <pjp> Sparks: okay
14:48:32 <Sparks> #topic Nonresponsive maintainer
14:48:51 <Sparks> FabioOlive: I think you had an idea regarding automating the process.  How would that work?
14:50:55 <FabioOlive> I was thinking that we could have an automated job that,
14:51:23 <FabioOlive> 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 <FabioOlive> 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 <Sparks> pjp: Yeah, have you run that recently?  I remember the last time you did.
14:52:34 <FabioOlive> so make it automatic, instead of a boring, sensitive, complex human process
14:52:44 <pjp> Sparks: Recently was I think last month, when we started the 90 days challenge,
14:52:47 <Sparks> FabioOlive: I think it's an interesting idea.
14:52:53 <Sparks> pjp: Okay
14:52:59 <pjp> 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 <FabioOlive> 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 <FabioOlive> 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 <FabioOlive> 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 <Sparks> 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 <FabioOlive> sure, will do.
14:57:19 <Sparks> #topic Open floor discussion/questions/comments
14:57:24 <Sparks> Okay, anyone have anything else?
14:57:49 <FabioOlive> #action FabioOlive will propose automated non-responsive maintainer process on the FST list.
14:57:55 <pjp> Yes, nirik on #fedora-admin mentioned ->
14:57:55 <pjp> <nirik> security: security-private@lists.fedoraproject.or
14:58:21 <pjp> <nirik> looking at the list archives, it just has spam in it.
14:58:30 <Sparks> I'm not even aware of that list.
14:58:37 * jsmith didn't know about it either
14:58:39 <pjp> exactly, same here
14:58:48 <nirik> bressers is owner. ;)
14:58:55 <d-caf> More documentation of stuff needed... ;-)
14:58:56 <pjp> Ha..ha.. :)
14:58:56 <Sparks> nirik: That says a lot.
14:58:57 * Sparks runs
14:59:00 <jsmith> Sparks: Time to beat up your boss...
14:59:07 <pjp> I wonder if he is aware of it ;)
14:59:22 <Sparks> #action Sparks to follow up with nirik regarding security-private@l.fp.o.
14:59:30 <Sparks> Okay, anyone have anything else?
14:59:36 * jsmith has nothing
14:59:49 <nirik> BTW, IMHO, we definitely need a better non responsive maintainer process, but it's pretty complex. ;(
14:59:54 <pjp> Yes, we need a legit security@fp.o address, that is well known
15:00:05 <pjp> nirik: +1
15:00:16 <Sparks> Okay, we've found the end of our string.
15:00:29 <Sparks> Catch you all on the lists and #fedora-security-team channel.
15:00:32 <Sparks> #endmeeting