User:Chkr/Drafts/Security/TrackingBugs

From FedoraProject

< User:Chkr(Difference between revisions)
Jump to: navigation, search
Line 11: Line 11:
 
* Parent bug is ''publicly viewable''
 
* Parent bug is ''publicly viewable''
 
* Parent bug has an alias=''CVE''
 
* Parent bug has an alias=''CVE''
* Parent bug is assigned to the ''Fedora Security Response'' team
+
* Parent bug is assigned to the ''Redhat Security Response'' team
 
* Parent bug has a Security keyword set
 
* Parent bug has a Security keyword set
  
Line 18: Line 18:
 
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.
 
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 belongs to ''Fedora Project Contributors'' group
+
* Tracking bug is depended on by / blocks the ''Parent bug''
* Tracking bug is depended on by 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 developer
+
* Tracking bug is assigned to the default owner of the bug reports ofr 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 keyword set
+
* Tracking bug has a Security and the SecurityTracking keyword set
  
 
The situation then looks like this:
 
The situation then looks like this:
 
<pre>
 
<pre>
 
(public, alias=CVE-2007-9999)
 
(public, alias=CVE-2007-9999)
|- #222222: CVE-2007-4631 Yoyodine stack overflow via a long do_nothing() argument [FC7]  
+
|- #111111: CVE-2007-4631 Yoyodine stack overflow via a long do_nothing() argument [rawhide]  
 
|  (group Fedora Project Contributors, component=yoyodine)
 
|  (group Fedora Project Contributors, component=yoyodine)
|- #333333: CVE-2007-4631 Yoyodine stack overflow via a long do_nothing() argument [F8]  
+
|- #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)
 
|  (group Fedora Project Contributors, component=yoyodine)
 
|- #444444: CVE-2007-4631 Yoyodine stack overflow via a long do_nothing() argument [EPEL5]  
 
|- #444444: CVE-2007-4631 Yoyodine stack overflow via a long do_nothing() argument [EPEL5]  
Line 36: Line 37:
 
</pre>
 
</pre>
  
== Handling tracking bugs in Bodhi ==
+
== Handling CVE bugs by maintainers ==
  
=== The procedure ===
+
for each tracking bug (refers to a single branch):
 +
# if the version in this branch is not affected, close this particular tracking bug
 +
# otherwise commit the fixes and create a new build
 +
# create a new update request in bodhi
 +
#* refer to bug the parent *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
  
The maintainer commits the fixes, builds packages and creates an update request. He refers to both parent bug and tracking bug. Bodhi is able to identify that the 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.
+
That's all. The rest will happen automatically.
  
=== Proposed changes to Bodhi ===
+
== Handling Tracking bugs in bodhi ==
'''These proposed changes have been implemented.  -lmacken'''
+
  
This might include things that are already implemented in Bodhi that I am not aware of.
+
* Bodhi is able to identify if a bug is a tracking bug and doesn't include it in the new package announce mail.
* Bodhi shouldn't include the bug belonging to ''Fedora Project Contributors'' in the mail (Note: Wouldn't it be better to identify a tracking bug with a dedicated keyword rather than group membership?)
+
* Bodhi closes the tracking bug, and in case all other bugs that Parent depends on it also closes the Parent.
* Bodhi should close the bug only in case all bugs it depends on are closed and it is not in NEW state
+
* To keep track, Bodhi adds comments to both Parent and Tracking bug.
* There is no need to refer to CVE from Bodhi, security bugzillas allways refer to CVE themselves
+
* Bodhi includes the bug belonging to ''Fedora Project Contributors'' in the mail.
* Bodhi should include the Summary of the bugzillas rather than just the number, so that reference to CVE is visible 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 should add comments to the bugs when the update is created, and pushed to testing, not just when it gets live. (This would save the SRT from unnecessary pings to developers and keep users updated)
+
* 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.
  
This would change the ''References'' section in update announce mails from:
+
The ''References'' section in update announce mails looks like:
<pre>
+
References:
+
 
+
[ 1 ]  Bug #284511
+
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=284511
+
[ 2 ]  CVE-2007-4727
+
http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-4727
+
</pre>
+
to:
+
 
<pre>
 
<pre>
 
References:
 
References:
Line 68: Line 66:
 
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=284511
 
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=284511
 
</pre>
 
</pre>
 
 
[[Category:Security]]
 

Revision as of 20:21, 15 March 2011

Contents

Using Tracking Bugs

Handling tracking bugs in Bugzilla

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

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 ofr 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)

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 bug the parent *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.

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