Meeting minutes... kind of.

[Eric Christensen]

I started this morning's meeting and no one showed up.  I understand that the 
time isn't great (did it used to be great?) and we should probably revisit it.  
I also want to convey that participation in the meetings is *not* a 
prerequisite to participating on the team.

Below is the agenda for today's meeting along with some discussion points I 
wanted to make.  Please feel free to reply and comment on things inline so we 
can continue the discussion.

* #topic Follow up on last week's tasks
** jsmith to patch rubygem-activesupport as provenpackager (BZ 905374)

I believe this is still in progress.  Jared, can you comment?

** pjp started non-responsive maintainer against rubygem-activesupport in 
EPEL6

Whatever happened with this?

** Team Goal: All important CVEs from 2014 and before should be fixed by the 
end of June.

More on that below...

* #topic 90-Day Challenge
** #link https://ethercalc.org/90-day-challenge
** #info 90-Day Challenge has a goal to close all 2014 and prior Important 
CVEs in Fedora
** #info As of 2015-04-29, of the 38 target bugs 14 have been closed, 1 is 
On_QA, and 23 are Open

We had a few bugs that were On_QA move over to the Closed-Errata status since 
the last time I looked.  We're currently up to a little over a third of our 
target bugs being closed.  We've got a little over a month to get the rest of 
them done.  Lets see if we can make a big push over the coming week.

* #topic Outstanding BZ Tickets
** #info Thursday's numbers: Critical 1, Important 40 (+2), Moderate 370 
(+22), Low 160 (0), Total 571, Trend +24
** #info Current tickets owned: 107 (~19%)
** #info Tickets closed: 315 (+11)

While cases are still getting closed, the number of tickets actively being 
worked (or owned, really) is being reduced.  It would appear that we aren't 
picking up new cases to work.  I've noticed over the past few months that 
participation has dropped significantly, too.  I'd love to know why.

* #topic Loss of momentum
** #info The FST has been around for almost a year.  Our participation is 
dropping like flies.

Anyone have any ideas?  A new meeting time?  Rewards/swag?  Something more 
interesting to do?

I know this isn't the most fun job in Fedora but I'd like to think we're 
making a difference.  Perhaps we need to talk more about what we're doing in 
public (or, more in public)?

--Eric

[David Cafaro]

On 05/21/2015 11:26 AM, Eric Christensen wrote:
>  I started this morning's meeting and no one showed up.  I
> understand that the 
>  time isn't great (did it used to be great?) and we should probably revisit it.  
>  I also want to convey that participation in the meetings is *not* a 
>  prerequisite to participating on the team. 
Currently the problem is the change from EST to EDT time (silly day
light savings).  So now the meeting is at 10am instead of 9am which
pushes it more into prime work day.  I had planned on making the meeting
this week (I did get online at about 10:25, but well over by then) but
things got busy.

>  
>  Below is the agenda for today's meeting along with some discussion points I 
>  wanted to make.  Please feel free to reply and comment on things inline so we 
>  can continue the discussion.
>  
>  * #topic Follow up on last week's tasks
>  ** jsmith to patch rubygem-activesupport as provenpackager (BZ 905374)
>  
>  I believe this is still in progress.  Jared, can you comment?
>  
>  ** pjp started non-responsive maintainer against rubygem-activesupport in 
>  EPEL6
>  
>  Whatever happened with this?
>  
>  ** Team Goal: All important CVEs from 2014 and before should be fixed by the 
>  end of June.
>  
>  More on that below...
>  
>  * #topic 90-Day Challenge
>  ** #link https://ethercalc.org/90-day-challenge
>  ** #info 90-Day Challenge has a goal to close all 2014 and prior Important 
>  CVEs in Fedora
>  ** #info As of 2015-04-29, of the 38 target bugs 14 have been closed, 1 is 
>  On_QA, and 23 are Open
>  
>  We had a few bugs that were On_QA move over to the Closed-Errata status since 
>  the last time I looked.  We're currently up to a little over a third of our 
>  target bugs being closed.  We've got a little over a month to get the rest of 
>  them done.  Lets see if we can make a big push over the coming week. 
I've had a lot of tickets start moving forward lately, and still have
one ticket I need to push into non-responsive maintainer.

>  
>  * #topic Outstanding BZ Tickets
>  ** #info Thursday's numbers: Critical 1, Important 40 (+2), Moderate 370 
>  (+22), Low 160 (0), Total 571, Trend +24
>  ** #info Current tickets owned: 107 (~19%)
>  ** #info Tickets closed: 315 (+11)
>  
>  While cases are still getting closed, the number of tickets actively being 
>  worked (or owned, really) is being reduced.  It would appear that we aren't 
>  picking up new cases to work.  I've noticed over the past few months that 
>  participation has dropped significantly, too.  I'd love to know why. 
I picked up about 5 new important tickets this week to start working as
well, but hard to pick up new tickets when it takes so much effort to
get the old tickets moving.

>  
>  * #topic Loss of momentum
>  ** #info The FST has been around for almost a year.  Our participation is 
>  dropping like flies.
>  
>  Anyone have any ideas?  A new meeting time?  Rewards/swag?  Something more 
>  interesting to do?
>  
>  I know this isn't the most fun job in Fedora but I'd like to think we're 
>  making a difference.  Perhaps we need to talk more about what we're doing in 
>  public (or, more in public)? 

Some things that might help:

1. Some kind of official swag award is nice (would love something) but
not sure that will pull in long term participants.

2. Meeting time is always going to be hard, specially with daylight
savings time in the US messing everything up.  But 9am is fine, and 10am
isn't to bad, but will cause some conflicts some times.  Given
participants across the globe, not sure there is a better time.

3. Clear rules and standards.  I think we need to set down some hard
fast rules that are agreed upon by not just the security team but to
some extant Fedora management as well.  Things we need defined:

3.a. How much time and/or attempts to reach a maintainer is allowed
before they are considered non-responsive.

3.b. Policy on Critical/Important tickets regarding non/slow response
maintainers.  Should we give them less time than say moderate or less
issues.  Can we have a list of volunteer proven packagers that can help
us push through criticals/importants when we are having issues with the
maintainers.

I think the above would help eliminate some of the indecision and
dragging on of some of the work.  It get's frustrating pinging someone
who never responds for months because it's not clear when you have the
authority to say this ends.

4. Continue to improve the security page documentation on the process
and rules of engagement and good links for how to instigate certain
procedures (assume people are unfamiliar with the ways of fedora
packaging procedures).


If we can get more of the above in place it might make it less daunting
to the new recruits.  I certainly know it's been a fair amount of
learning for myself (know security, don't know fedora ways), I'm just
stubborn enough to stick it out.

Cheers,
David

[Eric Christensen]

On Friday, May 22, 2015 03:02:35 PM David A. Cafaro wrote:
>  On 05/21/2015 11:26 AM, Eric Christensen wrote:
>  > I started this morning's meeting and no one showed up.  I understand that
>  > the time isn't great (did it used to be great?) and we should probably
>  > revisit it. I also want to convey that participation in the meetings is
>  > *not* a prerequisite to participating on the team.
>  
>  Currently the problem is the change from EST to EDT time (silly day
>  light savings).  So now the meeting is at 10am instead of 9am which
>  pushes it more into prime work day.  I had planned on making the meeting
>  this week (I did get online at about 10:25, but well over by then) but
>  things got busy. 
Well, I don't want to over emphasis the meeting and its importance to the 
overall operation of the team.  It really serves no purpose other than a 
rallying time for everyone to be online at the same time and perhaps a 
convenient time for people to ask questions.

That said, I'll send out a new whenisgood poll on a new message to get 
everyone's feedback.

>  3. Clear rules and standards.  I think we need to set down some hard
>  fast rules that are agreed upon by not just the security team but to
>  some extant Fedora management as well.  Things we need defined:
>  
>  3.a. How much time and/or attempts to reach a maintainer is allowed
>  before they are considered non-responsive. 
We've been following the current policy for nonresponsive package 
maintainers[0] and I feel good about using that policy.  It's simple and 
accepted by the development community.

>  3.b. Policy on Critical/Important tickets regarding non/slow
> response
>  maintainers.  Should we give them less time than say moderate or less
>  issues.   
Probably.  Critical and important issues are... well... important.  If you 
look at the moderate and low categories you'll see that they are difficult to 
exploit and/or have limited results.  Honestly, I've really not looked at 
moderates or lows for closure since we have so many important (and that one, 
pesky, critical) CVEs in Fedora/EPEL now.

>  Can we have a list of volunteer proven packagers that can help
>  us push through criticals/importants when we are having issues with the
>  maintainers.
>  
>  I think the above would help eliminate some of the indecision and
>  dragging on of some of the work.  It get's frustrating pinging someone
>  who never responds for months because it's not clear when you have the
>  authority to say this ends. 
I think that's a good resource to have.  I know jsmith has offered up his 
services but I'm sure there are others.  As far as our "authority" we seem
to 
be operating under the good graces of release engineering.  They care about 
security vulnerabilities in their repos and have been very reponsive to 
getting packages retired when we've hit the end of our rope.  I think 
consistency is important here and we should all be on the same page when it 
comes to dealing with the bugs.

>  4. Continue to improve the security page documentation on the
> process
>  and rules of engagement and good links for how to instigate certain
>  procedures (assume people are unfamiliar with the ways of fedora
>  packaging procedures). 
+1

[0] 
https://fedoraproject.org/wiki/Policy_for_nonresponsive_package_maintainers

--Eric

[David Cafaro]

On 05/27/2015 04:19 PM, Eric Christensen wrote:
>  On Friday, May 22, 2015 03:02:35 PM David A. Cafaro wrote:
> > 3. Clear rules and standards.  I think we need to set down some hard
> > fast rules that are agreed upon by not just the security team but to
> > some extant Fedora management as well.  Things we need defined:
> >
> > 3.a. How much time and/or attempts to reach a maintainer is allowed
> > before they are considered non-responsive.
>  
>  We've been following the current policy for nonresponsive package 
>  maintainers[0] and I feel good about using that policy.  It's simple and 
>  accepted by the development community. 
True, but how long do we wait from first contact on a security ticket
before we start the non-responsive policy?  3 pings on a ticket?  1
month after first ping on a ticket?  That's the policy we need to set to
trigger a start of the non-responsive package maintainer process.

>  
> > 3.b. Policy on Critical/Important tickets regarding non/slow response
> > maintainers.  Should we give them less time than say moderate or less
> > issues.  
>  
>  Probably.  Critical and important issues are... well... important.  If you 
>  look at the moderate and low categories you'll see that they are difficult to 
>  exploit and/or have limited results.  Honestly, I've really not looked at 
>  moderates or lows for closure since we have so many important (and that one, 
>  pesky, critical) CVEs in Fedora/EPEL now. 
So do we go with something like:

** Critical: 3 pings and at least one month before we start non-responsive
** Important: 4 pings and at least two months before we start non-responsive
** Moderate: 6 pings and at least four months before we start non-responsive
** Low: 9 ping and at least nine months before we start non-responsive

With a hard rule that any package with outstanding security issues NOT
be made available for the next Fedora release if the maintainer is
non-responsive.  Possible exception are for low or moderate with no remote?

It's understood that we may not even get to ping Moderate and Low
anytime soon given the load of Critical and Important, but still
important to include those levels in the policy.

>  
> > Can we have a list of volunteer proven packagers that can help
> > us push through criticals/importants when we are having issues with the
> > maintainers.
> >
> > I think the above would help eliminate some of the indecision and
> > dragging on of some of the work.  It get's frustrating pinging someone
> > who never responds for months because it's not clear when you have the
> > authority to say this ends.
>  
>  I think that's a good resource to have.  I know jsmith has offered up his 
>  services but I'm sure there are others.  As far as our "authority" we seem
> to 
>  be operating under the good graces of release engineering.  They care about 
>  security vulnerabilities in their repos and have been very reponsive to 
>  getting packages retired when we've hit the end of our rope.  I think 
>  consistency is important here and we should all be on the same page when it 
>  comes to dealing with the bugs. 
Agreed, would just like to make some resources more clear and have some
policies all agree on so that we can churn through these at a steady
rate vs getting hung-up on a few non-responsive ones.

Cheers,
David

[Matthew Miller]

On Wed, May 27, 2015 at 08:43:14PM -0400, David A. Cafaro wrote:
>  True, but how long do we wait from first contact on a security
> ticket
>  before we start the non-responsive policy?  3 pings on a ticket?  1
>  month after first ping on a ticket?  That's the policy we need to set to
>  trigger a start of the non-responsive package maintainer process. 
If there's an immediate security issue in a case like this, we should
follow the provenpacker process and find someone else to address it.
(And _then_ follow the normal non-responsive process if necessary.)

<https://fedoraproject.org/wiki/Who_is_allowed_to_modify_which_packages>

-- 
Matthew Miller
<mattdm(a)fedoraproject.org&gt;
Fedora Project Leader

[David Cafaro]

On 05/27/2015 08:57 PM, Matthew Miller wrote:
>  On Wed, May 27, 2015 at 08:43:14PM -0400, David A. Cafaro wrote:
> > True, but how long do we wait from first contact on a security ticket
> > before we start the non-responsive policy?  3 pings on a ticket?  1
> > month after first ping on a ticket?  That's the policy we need to set to
> > trigger a start of the non-responsive package maintainer process.
>  
>  If there's an immediate security issue in a case like this, we should
>  follow the provenpacker process and find someone else to address it.
>  (And _then_ follow the normal non-responsive process if necessary.)
>  
>  <https://fedoraproject.org/wiki/Who_is_allowed_to_modify_which_packages> 
I'm all for that, so if critical ticket comes in, and we request a patch
against that ticket we give the packager 24-48 hours to respond?  No
response we follow the provenpacker process, get it addressed, then the
non-responsive process?

What about important tickets?

What I'm looking for is just a hard rule on how much time we give a
packager to respond before we work around them.  I want these things
fixed, but I also don't want to piss off someone who just happened to be
traveling or something when the ticket came in.  If we state clear rules
that we follow then there are less hurt feelings.

Thanks,
David

[P J P]

  Hi,

>  On Thursday, 21 May 2015 8:56 PM, Eric Christensen
> <sparks(a)fedoraproject.org&gt; wrote:
>  > I started this morning's meeting and no one showed up. 
  Yes, sorry about that. I stepped out in the evening thinking I'll be back before our
meeting time, but could not make it in time. :(

>  ** pjp started non-responsive maintainer against
> rubygem-activesupport in  EPEL6
>  Whatever happened with this? 

  -> https://bugzilla.redhat.com/show_bug.cgi?id=1209124#c9

I had contacted the upstream Fedora maintainer about it, and couple of other packages(bugs
from 90-days-challenge), which were also maintained by Michael Stahnke. The Fedora
maintainer has agreed to push updates to EPEL builds too.



>  Anyone have any ideas?  A new meeting time?  Rewards/swag?  Something
> more
>  interesting to do?
>
>  I know this isn't the most fun job in Fedora but I'd like to think
>  we're making a difference.  Perhaps we need to talk more about what we're doing
> in
>  public (or, more in public)? 

  I agree, we are making a difference and an important one. I think more public talking
about it our activities and trying to incorporate security process into our current
package building/review steps should also help. That way folks would know that FST is an
integral part of Fedora package life cycle, just like -qa/-design/-documentation etc.
process. Currently it's perceived to be more of an optional one.


  Secondly I think we need to be think of some services that we could offer to other
Fedora teams and/or contributors, maybe patch reviews, configuration audit/reviews etc.
(just thinking aloud) 


---
Regards
   -P J P
http://feedmug.com