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