When entering an embargoed issue in the Red Hat Bugzilla, please check the "Security Sensitive Bug" checkbox to ensure that the information being entered is not publically viewable until the embargo date passes. These bugs will only be viewable by certain Red Hat employees, the reporter, and anyone in the CC field.

When entering an embargoed issue in the Red Hat Bugzilla, please check the "Security Sensitive Bug" checkbox to ensure that the information being entered is not publically viewable until the embargo date passes. These bugs will only be viewable by certain Red Hat employees, the reporter, and anyone in the CC field.

+

+

{{Admon/important |

+

While a security bug is under embargo, you should not push your fixes to Fedora GIT repository (or upstream version control repositories) because that would disclose details about the bug prematurely. But you are welcome to prepare a patch fixing the issues, and attach it to the Bugzilla bug.

Revision as of 09:57, 20 December 2012

Contents

Reporting Security Issues

Fedora includes a large number of security features to mitigate and prevent potential security issues. However new security flaws are continously found in thousands of software packages we include in the Fedora repository. Reporting these security issues and exploits will help the project fix these issues and release updates that resolve the problem. Read on to understand how to deal with these problems effectively.

Understanding Security Issues

When filing security bugs, care may need to be taken regarding the information being placed in public view. We are in support of the full public disclosure of security issues, but it should be done so in a responsible manner. This primarily applies to embargoed issues.

Embargoed Security Issues

An embargoed security issue is one which is not publically known, and its existence is to be reported to responsible organizations. Often when a researcher discovers a security issue, they will contact an organization such as vendor sec or the project's upstream developers. If the issue is of great severity, it is wise to give the upstream project, various distribution vendors, and the researcher some time to produce patches and advisories for the issue. That means setting a date sometime in the future which all parties can agree upon.

When entering an embargoed issue in the Red Hat Bugzilla, please check the "Security Sensitive Bug" checkbox to ensure that the information being entered is not publically viewable until the embargo date passes. These bugs will only be viewable by certain Red Hat employees, the reporter, and anyone in the CC field.

While a security bug is under embargo, you should not push your fixes to Fedora GIT repository (or upstream version control repositories) because that would disclose details about the bug prematurely. But you are welcome to prepare a patch fixing the issues, and attach it to the Bugzilla bug.

Setting Keywords

Make sure you set the bug keywords to "security". These bugs receive special attention compared to other normal bug reports.

Providing Proper Information

When entering a security bug in bugzilla, it is important to ensure the information is accurate and clear. If the issue discovered is triggered by a bad file, please be sure to attach the file to the bug report. A testcase that can be reproduced is best so the security team can verify the issues exists, and to verify that the fix is complete. Additionally, if you know which bits of code are incorrect and are triggering the issue, this information will help speed the time needed to research the issue.

Read the Security Classifications page and if you believe that a bug you are entering is a security issue, please add JoshBressers (bressers@redhat.com) to the CC list. Additionally, if the issue is not public and you wish to keep it under embargo, please check the "Security Sensitive Bug" checkbox to prevent the information from being viewable by the general public.