Re: Security Tracking Bugs
Hi Christian!
On Tue, 15 Mar 2011 22:29:11 +0100 Christian Krause wrote:
https://fedoraproject.org/wiki/Security/TrackingBugs
From a maintainer's point of view this page needs some improvements:
The page is fairly outdated and can definitely benefit from some
improvement.
- the page lacks of the description of the very specific tasks for
the
maintainers
The fixing process for maintainer should not really differ from
the normal bug fixing process, hence this part did not get much
attention previously. I agree that it may be good to explicitly
document "add that extra bug to bodhi update request, everything else
is what already know quite well".
- some information is outdated and/or wrong - e.g. the description
how
many tracking bugs are created
More on that below.
I took the opportunity to clarify some parts of this page and I also
added a section with step-by-step instructions for the maintainers:
https://fedoraproject.org/wiki/User:Chkr/Drafts/Security/TrackingBugs
Few comments on the things that changed:
- "don't explicitly refer to the CVE from in the notes text box, the
reference is implicit created by referring both bugs"
I think is based on old "There is no need to refer to CVE from Bodhi,
security bugzillas allways refer to CVE themselves", which was about
a bit different thing. Bodhi used to have an extra "CVE list"
field. That field was obsoleted by a CVE listed inferred from CVE
mentioned in the linked bugzillas. It's OK to mention CVE, upstream
advisory id, upstream announcement, or any other useful info in the
update Description.
- "Bodhi is able to identify if a bug is a tracking bug and doesn't
include it in the new package announce mail."
I don't think that's true. See e.g.:
https://lwn.net/Articles/431813/
which links BZ#638428.
- "Bodhi closes the tracking bug, and in case all other bugs that
Parent depends on it also closes the Parent."
"To keep track, Bodhi adds comments to both Parent and Tracking bug."
That's broken currently and Bodhi does not update Security Response
bugs at all:
https://fedorahosted.org/bodhi/ticket/485
For the unchanged text, there's no really much guarantee that CVE is
assigned before update is pushed to stable. There's also problem with
Bodhi caching, so BZ summary changes done after the bug was added to
Bodhi are usually not picked up. That's where CVE in the Description
has some benefits.
I find the idea of having multiple tracking bugs quite helpful since
it really simplifies the maintainer's job: He can make full use of
bodhi's feature to close the bug reports automatically.
Not all maintainers view it the same. For some, it's sufficient to get
CC on SR bug and frown upon having one extra fedora-all bug filed.
Based on the past experience, there's attempt to file less bugs rather
than more (fedora-all/epel-all if all versions affected, fedora-X if
only some). That's even more nasty if you file lot of tracking bugs
incorrectly (e.g. you've missed already built updates in koji, or the
fact that some issue is not compiled in).
If we want to go back to an old "separate bug for each affected
version", we probably want to have it discussed on devel and/or
reviewed by FESCo.
a) the security engineer (who opens the security bugs) checks, which
Fedora branches are affected and creates the appropriate tracking bugs
or
b) the step-by-step section could contain the explicit suggestion that
the maintainer could (or should?) create the appropriate number of
tracking bugs for each release himself
We should think of a way to mark SR bugs as needing further triage. RH
SRT folks may not always have time to look in detail on all Fedora /
EPEL branches for every issue. So it may be better to note that based
on the available info, this should affect certain Fedora and EPEL
versions and ask for another pair of eyes to double-check before
annoying someone with lot of incorrect bugs.
Thank you for your feedback and asking about your concerns!
--
Tomas Hoger / Red Hat Security Response Team