14:00:35 <Sparks_too> #startmeeting Security Team Meeting - Agenda: https://fedoraproject.org/wiki/Security_Team_meetings
14:00:35 <zodbot> Meeting started Thu Dec  4 14:00:35 2014 UTC.  The chair is Sparks_too. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:00:35 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
14:00:38 <Sparks_too> #meetingname Fedora Security Team
14:00:38 <zodbot> The meeting name has been set to 'fedora_security_team'
14:00:42 <Sparks_too> #topic Roll Call
14:00:43 * Sparks_too 
14:00:49 * pjp here
14:00:55 * jtaylor90 here
14:01:02 * jrusnack here
14:01:20 <mhayden> .fas mhayden
14:01:22 <zodbot> mhayden: mhayden 'Major Hayden' <major@mhtx.net>
14:01:25 <bvincent> .fas bvincent
14:01:28 <zodbot> bvincent: bvincent 'Brandon Vincent' <Brandon.Vincent@asu.edu>
14:01:50 <jsmith> .hellomynameis jsmith
14:01:55 <zodbot> jsmith: jsmith 'Jared Smith' <jsmith.fedora@gmail.com>
14:05:44 <Sparks_too> Okay, lets get started
14:06:06 <Sparks_too> #info Participants are reminded to make liberal use of #info #link #help in order to make the minutes "more better"
14:06:13 <Sparks_too> #topic Outstanding BZ Tickets
14:06:20 <Sparks_too> #info Wednesday's numbers: Critical 1, Important 49, Moderate 419, Low 158, Total 627, Trend +27
14:06:48 <Sparks_too> Looks like a bot has started working some of these cases reminding people that their tickets are still open.
14:07:22 <pjp> Yes,
14:07:38 <jrusnack> how any tracking bugs were touched by bot ?
14:07:59 <pjp> jrusnack: the script I wrote
14:08:22 <jrusnack> * how many ..
14:08:31 <pjp> Around 134 bugs > 90 days old were touched yesterday
14:08:41 <pjp> Please see -> https://bugzilla.redhat.com/buglist.cgi?bug_status=NEW&bug_status=ASSIGNED&bug_status=POST&bug_status=MODIFIED&bug_status=ON_DEV&bug_status=ON_QA&bug_status=VERIFIED&bug_status=RELEASE_PENDING&classification=Fedora&email1=pj.pandit%40yahoo.co.in&emailtype1=exact&keywords=Security%2C%20SecurityTracking%2C%20&keywords_type=anywords&list_id=3061628&order=changeddate%20DESC%2Cbug_status%2Cpriority%2Cassigned_to%2Cbug_id&product=Fe
14:08:41 <pjp> dora&query_based_on=&query_format=advanced&status_whiteboard=fst_ping%3D1&status_whiteboard_type=substring
14:08:43 <Sparks_too> pjp: You can likely filter out the orphaned packages since they won't be getting any love.
14:09:10 <pjp> Sparks_too: yes, I need to find those out first,
14:09:32 <Sparks_too> pjp: They should be assigned to an orphaned email address.
14:09:59 <jrusnack> pjp: nice !
14:10:03 <pjp> Sparks_too: the bugs should be assigned to an orphaned email?
14:10:33 <pjp> Sparks_too: ex. see -> https://bugzilla.redhat.com/show_bug.cgi?id=1029469
14:10:52 <pjp> It's a non issue, an they say the package is unmaintained upstream
14:10:58 <pjp> s/an/and
14:11:25 <pjp> jrusnack: Thank you. :)
14:11:28 <Sparks_too> pjp: https://bugzilla.redhat.com/show_bug.cgi?id=800667
14:11:50 <Sparks_too> Just because a package is retired doesn't make these problems go away.
14:12:41 <Sparks_too> It is possible that the package exists on someone's system and while it's still out there in the wild (at least within the support window) the ticket should be open in some form.
14:12:44 <pjp> Sparks_too: Right, but does it happen automatically when package is retired?
14:12:54 <Sparks_too> pjp: No, it doesn't.
14:13:11 * Sparks_too wrote something about this on his blog but didn't publish it.
14:14:37 <pjp> Sparks_too: so the package retires, but its bugs remain open?
14:14:46 <Sparks_too> correct
14:15:01 * pjp thinks we need to fix the retirement process
14:15:07 <Sparks_too> pjp: How so?
14:15:19 <jrusnack> Sparks_too: the question is can they be fixed ?
14:15:30 <Sparks_too> jrusnack: Define "they"
14:15:40 <jrusnack> open bugs in retired package
14:15:43 <pjp> Sparks_too: like when bodhi pushes updates, it closes the respective bugs.
14:16:24 <Sparks_too> pjp: Right, but a retired package doesn't mean that the bugs go away.  The packages could be installed somewhere.  And what happens if someone unretires the package?
14:16:52 <jrusnack> Sparks_too: so they can be fixed if the package is unretired. Ok, thanks!
14:17:29 <Sparks_too> Right, it's a tough place to be until the package is outside the support window.
14:17:45 <pjp> Sparks_too: Right, at least the bugs against rawhide could be closed. And the ones against older still supported should get notifications, but still need to be fixed.
14:18:04 <pjp> *supported releases
14:18:06 <Sparks_too> pjp: Why close against rawhide?
14:18:30 <pjp> Sparks_too: Because we won't be pushing the retired package in the upcoming release, no?
14:18:53 <Sparks_too> We need to verify that they didn't make it in.
14:19:03 <pjp> Yep,
14:19:19 <Sparks_too> There is a very large hole in the auditing process.
14:20:14 <pjp> Sparks_too: in finding the which packages to push?
14:21:11 <Sparks_too> I'm sure things have slipped through the cracks.  We really have no idea what's vulnerable in the repos right now.  We have a clue but not a clear picture.
14:21:56 * pjp agrees
14:22:06 <jrusnack> that sounds terrible
14:22:45 <jrusnack> could we work on a list of things we think need to be fixed process-wise and propose it to fesco ?
14:22:55 <pjp> Yep,
14:23:32 <Sparks_too> I've already been working on a way for packages to be checked against a list of security vulnerabilities so that when the package gets built there will be some sort of action.
14:23:56 <jrusnack> Sparks_too: that is not the only thing on the list
14:24:08 <jrusnack> its like:
14:24:18 <jrusnack> 1) how to push criticals faster
14:24:37 <jrusnack> 2) how to fix unresponsive maintainers for criticals/important faster
14:24:51 <jrusnack> 3) how to change the process so that nothing falls through
14:25:07 <jrusnack> and some more I bet
14:25:54 <pjp> jrusnack: unresponsive maintainer is a tricky issue to solve, for it would probably require human replacement.
14:26:50 <jrusnack> pjp: yes, we talked about it last time quite exhaustively
14:26:59 <pjp> True
14:27:02 <pjp> :)
14:28:27 <pjp> Sparks_too: another ex. -> https://bugzilla.redhat.com/show_bug.cgi?id=1110333
14:28:41 <pjp> jrusnack: ^^
14:29:06 <pjp> So the guy says he has orphaned the package, and the bug is open against F20, which needs to be fixed. :(
14:30:05 <Sparks_too> I spoke with bressers about marking these bugs as orphaned in some way so we can not have to look at them for what needs to be done.
14:30:40 <pjp> Sparks_too: but what about fixes for the existing users?
14:30:48 <Sparks_too> pjp: I wonder if he has actually orphaned them or not.
14:31:13 <pjp> Sparks_too: his mail says he'll do it in one week -> https://lists.fedoraproject.org/pipermail/java-devel/2014-December/005426.html
14:31:23 <pjp> Sparks_too: he sent it today
14:31:30 <Sparks_too> pjp: You'll need to convince a super packager (or whatever they are called) to push a fix.
14:31:36 <Sparks_too> pjp: Yeah, I'm reading that now.
14:32:00 <pjp> Sparks_too: I'll see if he can still push it and close this bug, let's see..
14:33:45 <pjp> Like I said last time, I'll probably send this list of these 130 bugs to all the proven packagers for them to have a look and see which ones they can fix.
14:34:06 <Sparks_too> PROVEN packagers.  That's the word I was looking for.
14:34:15 <pjp> Heh...:)
14:37:15 <pjp> Not sure if these are all of them -> https://badges.fedoraproject.org/badge/proven-packager/rss
14:37:43 <Sparks_too> pjp: You can just email the FAS group.
14:38:14 <pjp> Oh, not sure how to do that,
14:38:21 * pjp makes a note to figure that out
14:41:14 <Sparks_too> Okay, anything else on this topic?
14:43:58 <pjp> Nope, I guess
14:44:09 <Sparks_too> #topic Open floor discussion/questions/comments
14:45:22 <bvincent> Any update on the PermitRootLogin issue?
14:45:36 <Sparks_too> There was discussion
14:45:39 <bvincent> There were a couple of mailing list threads about it.
14:45:41 <pjp> bvincent: yes
14:46:11 <pjp> bvincent: feature request is up for F22 release, it'll go through a review process once F21 is out, and then they'll decide if it should be included or not
14:47:23 <bvincent> pjp: Thanks. Do you have a link to the feature request. I must have missed it.
14:47:43 <pjp> bvincent: Sure -> https://fedoraproject.org/wiki/Changes/SSHD_PermitRootLogin_no
14:48:02 <jrusnack> sorry gotta run
14:48:12 <pjp> bvincent: So far, response to it has been more positive than negative, so I'm hopeful about it.
14:48:32 <bvincent> pjp: That's good to hear.
14:48:45 <sgallagh> PermitRootLogin may be a viable use-case for different defaults on different Flavors as well
14:49:02 <sgallagh> (Like we have different default firewall rules for Server and Workstation)
14:49:03 <pjp> sgallagh: True.
14:50:55 <Sparks_too> I've got one for F22...
14:51:21 <Sparks_too> How about include the Mozilla recommended ciphers in mod_ssl's config file.
14:56:04 <pjp> Sparks_too: as in support for specific encryptions?
14:56:26 <Sparks_too> No, as in support of sane defaults.
14:57:22 <pjp> Sparks_too: Yes, makes sense, at least we need to start a discussion about it.
14:57:24 <Sparks_too> https://wiki.mozilla.org/Security/Server_Side_TLS#Recommended_configurations
14:57:33 * pjp clicks
14:57:58 <Sparks_too> I'll write something up in security@ this morning and see who says what.
14:58:13 <pjp> Yep,
14:58:16 <bvincent> I'd be interested in the discussion.
14:58:52 <bvincent> The only true secure configuration (minus known attacks) is TLS 1.2 with GCM. Anything else introduces trade offs.
14:58:55 <mhayden> Sparks_too: totally in support of that
14:59:51 <Sparks_too> bvincent: Well, I wouldn't go so far as to say "true[ly] secure"
15:00:27 <Sparks_too> Okay... we're seconds away from the end [of the meeting time].
15:00:32 <Sparks_too> #endmeeting