OpenStack vulnerability management

From FedoraProject

(Difference between revisions)
Jump to: navigation, search
(Created page with "OpenStack security vulnerabilities are carefully handled by the [http://wiki.openstack.org/VulnerabilityManagement carefully upstream vulnerability management team]. The Fedora ...")
 
 
(6 intermediate revisions by 2 users not shown)
Line 1: Line 1:
OpenStack security vulnerabilities are carefully handled by the [http://wiki.openstack.org/VulnerabilityManagement carefully upstream vulnerability management team].
+
OpenStack security vulnerabilities are carefully handled by the [http://wiki.openstack.org/VulnerabilityManagement upstream vulnerability management team].
  
The Fedora OpenStack package maintainers follow a similarly careful process in order to take respond to the private notification of issue through to making package updates available to users on the public disclosure date:
+
The Fedora OpenStack package maintainers follow a similarly careful process in order to respond to the private notification of issue and make package updates available to users on the public disclosure date:
  
 
* A private notification of a vulnerability is received from upstream
 
* A private notification of a vulnerability is received from upstream
 
* A CVE number is provided some time later
 
* A CVE number is provided some time later
 +
* Send an email with the details to secalert@redhat.com. They will create the bugs as shown indicated below. Note there are scripts for building CVE pages, that only work with bugs created by SRT members.
 
* A tracker bug for this CVE is filed:
 
* A tracker bug for this CVE is filed:
 
  product = Security Response
 
  product = Security Response
Line 12: Line 13:
 
  description: all details from upstream including disclosure date
 
  description: all details from upstream including disclosure date
 
: Note: "Security Sensitive Bug" checkbox is ticked to make sure the information is not yet publicly disclosed.
 
: Note: "Security Sensitive Bug" checkbox is ticked to make sure the information is not yet publicly disclosed.
: Use [https://bugzilla.redhat.com/enter_bug.cgi?product=Security%20Response&component=vulnerability&alias=CVE-2012-XXXX&short_desc=CVE-2012-XXXX%20openstack-foo:%20blaa%20foo%20bar&bit-71=1 this link] to file such a bug.
+
: For illustration, [https://bugzilla.redhat.com/enter_bug.cgi?product=Security%20Response&component=vulnerability&alias=CVE-2012-XXXX&short_desc=CVE-2012-XXXX%20openstack-foo:%20blaa%20foo%20bar&bit-71=1 this link] could be used to file such a bug.
* Package updates are prepared and tested for the affected branches before the disclosure date - e.g. EPEL6, F16, F17, rawhide. The update is decoupled from any other large updates, allowing it to safely go straight through to the updates repo.
+
* Package updates are prepared locally. Note not even scratch builds are allowed on Fedora instructure. The updates are tested for the affected branches before the disclosure date - e.g. EPEL6, F16, F17, rawhide. The update is decoupled from any other large updates, allowing it to safely go straight through to the updates repo.
* On the disclosure date, bugs are filed for each of the affected releases:
+
* On the disclosure date, tracker bugs are filed by SRT members for each of the affected releases:
 
  product = Fedora/Fedora EPEL
 
  product = Fedora/Fedora EPEL
 
  component = $package
 
  component = $package
Line 22: Line 23:
 
  summary: CVE-XXX-XXXX $package: $title [$release]
 
  summary: CVE-XXX-XXXX $package: $title [$release]
 
  description: please see the bug #XXXXXX for more details on this vulnerability
 
  description: please see the bug #XXXXXX for more details on this vulnerability
: Note: at this point, the "Security Sensisitive Bug" flag is unchecked in the original tracker bug
+
: Note: at this point, the "Security Sensitive Bug" flag is unchecked in the original tracker bug
: Use the following links to file these bugs: [https://bugzilla.redhat.com/enter_bug.cgi?product=Fedora%20EPEL&component=openstack-nova&version=el6&keywords=Security,SecurityTracking&blocked=CVE-2012-XXXX&short_desc=CVE-2012-XXXX%20openstack-foo:%20blaa%20foo%20bar%20%5Bepel-6%5D epel-6], [https://bugzilla.redhat.com/enter_bug.cgi?product=Fedora&component=openstack-nova&version=17&keywords=Security,SecurityTracking&blocked=CVE-2012-XXXX&short_desc=CVE-2012-XXXX%20openstack-foo:%20blaa%20foo%20bar%20%5Bfedora-17%5D fedora-17], [https://bugzilla.redhat.com/enter_bug.cgi?product=Fedora&version=16&component=openstack-nova&keywords=Security,SecurityTracking&blocked=CVE-2012-XXXX&short_desc=CVE-2012-XXXX%20openstack-foo:%20blaa%20foo%20bar%20%5Bfedora-16%5D fedora-16]
+
: Note also: a combined [fedora-all] bug may be used rather than one for each Fedora version (EPEL trackers are always separate to Fedora currently). For combined trackers, just set the "auto close bugs" on all Fedora updates, and the first to land wins, with the others being informative.
 +
: For illustration, the following links could be used to file these bugs: [https://bugzilla.redhat.com/enter_bug.cgi?product=Fedora%20EPEL&component=openstack-nova&version=el6&keywords=Security,SecurityTracking&blocked=CVE-2012-XXXX&short_desc=CVE-2012-XXXX%20openstack-foo:%20blaa%20foo%20bar%20%5Bepel-6%5D epel-6], [https://bugzilla.redhat.com/enter_bug.cgi?product=Fedora&component=openstack-nova&version=17&keywords=Security,SecurityTracking&blocked=CVE-2012-XXXX&short_desc=CVE-2012-XXXX%20openstack-foo:%20blaa%20foo%20bar%20%5Bfedora-17%5D fedora-17], [https://bugzilla.redhat.com/enter_bug.cgi?product=Fedora&version=16&component=openstack-nova&keywords=Security,SecurityTracking&blocked=CVE-2012-XXXX&short_desc=CVE-2012-XXXX%20openstack-foo:%20blaa%20foo%20bar%20%5Bfedora-16%5D fedora-16]
 
* The updates are then pushed to fedpkg git, built in koji and filed in bodhi referencing the appropriate bug for that release. Once filed, the packages are tested by others and given karma in order to get it quickly into the updates repo.
 
* The updates are then pushed to fedpkg git, built in koji and filed in bodhi referencing the appropriate bug for that release. Once filed, the packages are tested by others and given karma in order to get it quickly into the updates repo.
  
[[Category:Cloud SIG]]
+
[[Category:OpenStack]]

Latest revision as of 10:18, 31 July 2012

OpenStack security vulnerabilities are carefully handled by the upstream vulnerability management team.

The Fedora OpenStack package maintainers follow a similarly careful process in order to respond to the private notification of issue and make package updates available to users on the public disclosure date:

  • A private notification of a vulnerability is received from upstream
  • A CVE number is provided some time later
  • Send an email with the details to secalert@redhat.com. They will create the bugs as shown indicated below. Note there are scripts for building CVE pages, that only work with bugs created by SRT members.
  • A tracker bug for this CVE is filed:
product = Security Response
component = vulnerability
alias = CVE-XXXX-XXXX
summary: CVE-XXX-XXXX $package: $title
description: all details from upstream including disclosure date
Note: "Security Sensitive Bug" checkbox is ticked to make sure the information is not yet publicly disclosed.
For illustration, this link could be used to file such a bug.
  • Package updates are prepared locally. Note not even scratch builds are allowed on Fedora instructure. The updates are tested for the affected branches before the disclosure date - e.g. EPEL6, F16, F17, rawhide. The update is decoupled from any other large updates, allowing it to safely go straight through to the updates repo.
  • On the disclosure date, tracker bugs are filed by SRT members for each of the affected releases:
product = Fedora/Fedora EPEL
component = $package
version = 16/17/el6
keywords = Security, SecurityTracking
blocks = CVE-XXXX-XXXX
summary: CVE-XXX-XXXX $package: $title [$release]
description: please see the bug #XXXXXX for more details on this vulnerability
Note: at this point, the "Security Sensitive Bug" flag is unchecked in the original tracker bug
Note also: a combined [fedora-all] bug may be used rather than one for each Fedora version (EPEL trackers are always separate to Fedora currently). For combined trackers, just set the "auto close bugs" on all Fedora updates, and the first to land wins, with the others being informative.
For illustration, the following links could be used to file these bugs: epel-6, fedora-17, fedora-16
  • The updates are then pushed to fedpkg git, built in koji and filed in bodhi referencing the appropriate bug for that release. Once filed, the packages are tested by others and given karma in order to get it quickly into the updates repo.