14:02:58 <Sparks> #startmeeting Security Team Meeting - Agenda: https://fedoraproject.org/wiki/Security_Team_meetings
14:02:58 <zodbot> Meeting started Thu Mar 26 14:02:58 2015 UTC.  The chair is Sparks. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:02:58 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
14:03:01 <Sparks> #meetingname Fedora Security Team
14:03:01 <zodbot> The meeting name has been set to 'fedora_security_team'
14:03:06 <Sparks> #topic Roll Call
14:03:08 * Sparks 
14:03:18 <bvincent> .fas bvincent
14:03:19 <zodbot> bvincent: bvincent 'Brandon Vincent' <Brandon.Vincent@asu.edu>
14:03:24 <d-caf> here
14:04:47 <FabioOlive> .fas fleite
14:04:48 <zodbot> FabioOlive: fleite 'Fabio Olive Leite' <fabio.olive@gmail.com>
14:05:26 <pjp_> Hi,
14:06:04 <d-caf> .fas dcafaro
14:06:05 <zodbot> d-caf: dcafaro '' <dac@cafaro.net>
14:06:16 <pjp_> .fas pjp
14:06:17 <zodbot> pjp_: pjp '' <pj.pandit@yahoo.co.in> - pjpedro 'PJ Pedro' <pjpedro@rogers.com> - sandeepj 'sandeepj' <sandeepjp22@gmail.com>
14:06:40 <FabioOlive> I should register a new Fedora account and not use gmail... :-/
14:07:21 <pjp_> FabioOlive: You don't have FAS account? 0_0 ;)
14:07:32 <FabioOlive> I said "a new one"
14:07:38 <Sparks> Agenda has been updated.
14:07:42 <Sparks> Okay, lets get started.
14:07:48 <FabioOlive> ok
14:07:55 <Sparks> #info Participants are reminded to make liberal use of #info #link #help in order to make the minutes "more better"
14:08:09 <Sparks> #topic Outstanding BZ Tickets
14:08:15 <Sparks> #info Thursday's numbers: Critical 1, Important 46 (-2), Moderate 376 (+7), Low 163 (-1), Total 586, Trend +4
14:08:21 <Sparks> #info Current tickets owned: 171 (~29%)
14:08:27 <Sparks> #info Tickets closed: 247 (+2)
14:08:42 <Sparks> Does anyone have anything WRT BZ tickets?
14:09:54 <pjp_> Nope, it seems,
14:10:17 <d-caf> No, just strugling to get people to respond, as normal
14:10:30 <Sparks> d-caf: I suspect that will be a continuing effort.
14:10:49 <d-caf> Sparks: I suspect you are correct :-/
14:11:15 * pjp_ wonders why folks don't respond? o_0
14:12:26 <Sparks> I think many people drop packages in the repos and then promptly ignore them.  They don't actually believe in it being a continuing effort.
14:12:51 <FabioOlive> Do we have mechanisms for taking over packages from unresponsive maintainers?
14:13:00 <pjp_> Sparks: true
14:13:05 <pjp_> FabioOlive: Yes,
14:13:13 <FabioOlive> ok I'll read about that
14:13:32 <d-caf> FabioOlive: Do we have the resources to take over packages?  I.e. who will maintain them going forward?
14:14:13 <pjp_> FabioOlive: Fedora has non-responsive maintainer policy -> https://fedoraproject.org/wiki/Policy_for_nonresponsive_package_maintainers
14:14:19 <d-caf> Question is do we leave them in if the maintainer drops, then leaves and then an Major sec bug is found with no one to patch
14:15:18 <d-caf> pjp_: that seems to cover it well
14:15:24 <Sparks> We should be working with release engineering on these questions.
14:15:31 <pjp_> d-caf: depends if there are current users for the package
14:15:43 <Sparks> If a package ends up being orphaned they now have a policy for removing those packages from the repos.
14:16:09 <Sparks> pjp_: We never know if anyone is actually using a package.
14:16:18 <pjp_> d-caf: if there are users using it, dropping such packages would be tricky,
14:16:49 <d-caf> pjp_: True, but leaving them exposed (and thinking they are going to get updates) is tricky as well
14:16:58 <pjp_> Sparks: True, one way to know is shout on the -devel & -users lists, then wait for a week or two before dropping it,
14:17:13 <pjp_> d-caf: I agree,
14:18:10 * pjp_ wonders if packagedb or yum repositories could give some stats about which packages are installed/pulled by users and which not
14:19:56 <Sparks> d-caf: Agreed
14:20:43 <Sparks> d-caf: I've not really found a good answer to this question.  We have options but none have actually been great options.
14:21:02 <d-caf> I fear there is no good solution out there right now
14:21:18 <d-caf> Would likely need to update the functionality of both rpm and yum to handle it
14:21:33 <Sparks> #idea We create a list of packages that have been retired.  yum/dnf checks this list against what it knows is installed on the system and alerts the user/admin when something they have installed shows up on the list.
14:24:30 <d-caf> Ideally it would be nice to cover both package retirements or significant functionality downgrades (like what happened with intels microcode update for haswell cpus)
14:25:21 <d-caf> wow did that one bite me hard...
14:25:35 <Sparks> Sure, it could be multi-functional
14:27:59 <Sparks> Okay, I'll try to write something up on my blog about this later in hopes of sparking some discussino.
14:28:03 <Sparks> discussion, even.
14:28:18 <Sparks> #topic Open floor discussion/questions/comments
14:28:22 <Sparks> Anyone have anything?
14:28:39 <d-caf> Sparks: be sure to share the link to the blog post when you do so comments can be added :-)
14:29:07 <Sparks> Okay.  I should be on the planet as well.
14:30:53 <Sparks> Anyone?  Anything?
14:31:56 <Sparks> Okay, everyone have a good day.
14:31:59 <Sparks> #endmeeting