This is a great initiative I think. See reference to AdaCore's security email below (among Debian, Red Hat, SUSE)
On Mon, Aug 7, 2023 at 7:30 PM David Edelsohn via Gcc-patches < gcc-patches@gcc.gnu.org> wrote: > 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 Can you also please add: AdaCore: product-secur...@adacore.com > > 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/ >
