Triaging/Security Classification & redhat-config-nfs; was Re: Fwd: Re: releasing updates-testing packages without VERIFY...

David Eisenstein deisenst at gtw.net
Fri Sep 30 06:38:51 UTC 2005


On Wed, 28 Sep 2005, Eric Rostetter wrote:

> <snip>
> We have a nfs-config package held up for a similar reason.  It was in QA with
> the upstream patch, and it fixes the problem as well as any other patch.
> But a rare case was found where it doesn't fix the problem.  Well, why not
> release it like every other vendor did (maybe even document the new case
> it doesn't address).  Then go back and fix the new bug, and release again.

There are right now redhat-config-nfs packages (Bug #152787) that, to be
published then released, need source-level ("publish") QA.  I've done
publish QA for the FC1 package.  Eric, how about you do the RH9 publish QA
and I'll do the FC2 QA so this puppy can move forward and be put to bed?

> I hate seeing a perfectly good patch go through QA and then be put on hold
> or held back while we try to patch additional bugs.  Release a version for
> each bug if we need to, so that people are protected from each bug as soon
> as possible.

I would rather agree, IF it were feasible.  Our QA process seems to be
rather slow sometimes.  While time is elapsing waiting for people to do
QA, new issues do arise, especially for things like kernels or web
browsers.  Because we seem to be so low on man-hours lately to even get
the first QA step done in many instances, asking to release a new package
version for each bug may unduly tie up a lot of those man hours building
new packages for release to updates and writing release notes for each of
those releases.

But you know what?  I think we have an even bigger problem.  We don't have 
effective bug triaging in place.

We need effective bug triaging in order to make clear decisions as to what
really matters to be worked on quickly, and what can be put off.  Good
triaging and bug classification will help inform our decisions as to
whether or not we've fixed enough bugs in a given package in Bugzilla, so
we can complete the QA and release it ("have we covered all the critical
CVEs?").  Other moderate- or low-impact bugs that have shown up in the
meantime we can choose to relegate to a new Bugzilla ticket on that 
package.

Another problem is ownership.  Since so much is done by committee and
consensus (not that I am knocking consensus), many times bugs just
languish in Bugzilla because no one steps forward with a tack to take, or
saying, "Let's get moving on this."

Maybe we need to review how bugs are assigned and start assigning them to
individuals ("bug chairs"?) who then own those bugs and who will take
personal responsibility for seeing them through to completion (including
taking time to advocate their bug(s) here on the list)?  Bugs that are
assigned to <bugs AT fedoralegacy.org> seem to have no owner at all, which
means no one in particular has incentive to see those bugs through.

Returning to the subject of triaging -- I have found the RedHat Security
Response Team's webpage "Classification of Security Issues" an excellent
read, at
	<http://www.redhat.com/security/updates/classification/>.

IMHO, it would be helpful to classify each and every bug currently in the
queue according to some system like this, so we can all be made aware of
what bugs matter most to be fixed most quickly.  As long as we *know* the
severity of the CVE issues for a given software package "in the shop" at
Bugzilla, we could then more clearly assess whether or not to hold up
releasing it.  Or whether or not to release without full VERIFY (or *any*
verify).

At this time, AFAIK, we have at least one bug out there that RH Security
has classified as Critical Impact (Mozilla).  There may be others.

	-David

ps: It is interesting to note that, although our redhat-config-nfs bug
(#152787) has packages to QA, they haven't been looked at since July,
except for the lone FC1 Publish vote I gave the other day.  Even more
interesting -- although we offered John Dalbec's patch to Red Hat in their
comparable bug report to better fix their reopened redhat-config-nfs bug
(#107997, for RHEL 3), they have not jumped on it.




More information about the fedora-legacy-list mailing list