FOSS Best Practices recommends that projects have an official Security
policy stated in a SECURITY.md or SECURITY.txt file at the root of the
repository. GLIBC and Binutils have added such documents.
Appended is a prototype for a Security policy file for GCC based on the
Binutils document because GCC seems to have more affinity with Binutils as
a tool. Do the runtime libraries distributed with GCC, especially libgcc,
require additional security policies?
[ ] Is it appropriate to use the Binutils SECURITY.txt as the starting
point or should GCC use GLIBC SECURITY.md as the starting point for the GCC
Security policy?
[ ] Does GCC, or some components of GCC, require additional care because of
runtime libraries like libgcc and libstdc++, and because of gcov and
profile-directed feedback?
Thoughts?
Thanks, David
GCC Security Process
====================
What is a GCC security bug?
===========================
A security bug is one that threatens the security of a system or
network, or might compromise the security of data stored on it.
In the context of GCC there are two ways in which such
bugs might occur. In the first, the programs themselves might be
tricked into a direct compromise of security. In the second, the
tools might introduce a vulnerability in the generated output that
was not already present in the files used as input.
Other than that, all other bugs will be treated as non-security
issues. This does not mean that they will be ignored, just that
they will not be given the priority that is given to security bugs.
This stance applies to the creation tools in the GCC (e.g.,
gcc, g++, gfortran, gccgo, gccrs, gnat, cpp, gcov, etc.) and the
libraries that they use.
Notes:
======
None of the programs in GCC need elevated privileges to operate and
it is recommended that users do not use them from accounts where such
privileges are automatically available.
Reporting private security bugs
========================
*All bugs reported in the GCC Bugzilla are public.*
In order to report a private security bug that is not immediately
public, please contact one of the downstream distributions with
security teams. The following teams have volunteered to handle
such bugs:
Debian: secur...@debian.org
Red Hat: secal...@redhat.com
SUSE: secur...@suse.de
Please report the bug to just one of these teams. It will be shared
with other teams as necessary.
The team contacted will take care of details such as vulnerability
rating and CVE assignment (http://cve.mitre.org/about/). It is likely
that the team will ask to file a public bug because the issue is
sufficiently minor and does not warrant an embargo. An embargo is not
a requirement for being credited with the discovery of a security
vulnerability.
Reporting public security bugs
==============================
It is expected that critical security bugs will be rare, and that most
security bugs can be reported in GCC, thus making
them public immediately. The system can be found here:
https://gcc.gnu.org/bugzilla/
