User:Chkr/Drafts/Security/TrackingBugs

From FedoraProject

< User:Chkr(Difference between revisions)
Jump to: navigation, search
 
Line 20: Line 20:
 
* Tracking bug is depended on by / blocks the ''Parent bug''
 
* Tracking bug is depended on by / blocks the ''Parent bug''
 
* Tracking bug is entered into respective Product/Component/Version where the flaw needs to be addresed
 
* Tracking bug is entered into respective Product/Component/Version where the flaw needs to be addresed
* Tracking bug is assigned to the default owner of the bug reports ofr a certain component
+
* Tracking bug is assigned to the default owner of the bug reports for a certain component
 
* The description of the tracking bug doesn't contain information about the flaw, but rather refers to the Parent bug and describes how to handle the flaw
 
* The description of the tracking bug doesn't contain information about the flaw, but rather refers to the Parent bug and describes how to handle the flaw
 
* Tracking bug has a Security and the SecurityTracking keyword set
 
* Tracking bug has a Security and the SecurityTracking keyword set

Latest revision as of 21:27, 15 March 2011

Contents

[edit] Using Tracking Bugs

[edit] Handling tracking bugs in Bugzilla

[edit] Parent Bug

Let's imagine a situation where a security flaw was found in yoyodine package. A member of Fedora Security Response team enters it in bugzilla under Security Response Team. Then he requests a CVE identifier for the issue. As he found the mention of the bug while reading a public mailing list, he creates a public bug. When he gets the CVE for the bug, he adds it to the begining of the Summary line and sets an appropriate alias=CVE number.

  • Parent bug is entered in the Security Response product
  • Parent bug's subject begins with the CVE
  • Parent bug is publicly viewable
  • Parent bug has an alias=CVE
  • Parent bug is assigned to the Redhat Security Response team
  • Parent bug has a Security keyword set

[edit] Tracking Bugs

As the bug obviously affects yoyodine package, he triages it and finds that it affects all supported Fedora releases, and also EPEL. He creates appropriate tracking bugs (with a script). Later it is found out that the vulnerable code is reused in foobar package that is present in EPEL5 (common situation with xpdf code). He adds appropriate tracking bug.

  • Tracking bug is depended on by / blocks the Parent bug
  • Tracking bug is entered into respective Product/Component/Version where the flaw needs to be addresed
  • Tracking bug is assigned to the default owner of the bug reports for a certain component
  • The description of the tracking bug doesn't contain information about the flaw, but rather refers to the Parent bug and describes how to handle the flaw
  • Tracking bug has a Security and the SecurityTracking keyword set

The situation then looks like this:

(public, alias=CVE-2007-9999)
|- #111111: CVE-2007-4631 Yoyodine stack overflow via a long do_nothing() argument [rawhide] 
|  (group Fedora Project Contributors, component=yoyodine)
|- #222222: CVE-2007-4631 Yoyodine stack overflow via a long do_nothing() argument [F15] 
|  (group Fedora Project Contributors, component=yoyodine)
|- #333333: CVE-2007-4631 Yoyodine stack overflow via a long do_nothing() argument [F14] 
|  (group Fedora Project Contributors, component=yoyodine)
|- #444444: CVE-2007-4631 Yoyodine stack overflow via a long do_nothing() argument [EPEL5] 
|  (group Fedora Project Contributors, component=foobar)

[edit] Handling CVE bugs by maintainers

for each tracking bug (refers to a single branch):

  1. if the version in this branch is not affected, close this particular tracking bug
  2. otherwise commit the fixes and create a new build
  3. create a new update request in bodhi
    • refer to the Parent bug and the Tracking bug
    • select Close bugs when update is stable
    • don't explicitly refer to the CVE from in the notes text box, the reference is implicit created by referring both bugs

That's all. The rest will happen automatically.

[edit] Handling Tracking bugs in bodhi

  • Bodhi is able to identify if a bug is a tracking bug and doesn't include it in the new package announce mail.
  • 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.
  • Bodhi includes the bug belonging to Fedora Project Contributors in the mail.
  • Bodhi closes the bug only in case all bugs it depends on are closed and it is not in NEW state.
  • Bodhi includes the Summary of the bugzillas rather than just the number, so that reference to CVE is visible in the mail.
  • Bodhi adds comments to the bugs when the update is created, and pushed to testing, not just when it gets live.

The References section in update announce mails looks like:

References:

[ 1 ]  CVE-2007-4727 FastCGI header overrun in lighttpd's mod_fastcgi
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=284511