Re: [RFC] GCC Security policy

[Arnaud Charlet <charlet@adacore.com>]

[-- Attachment #1: Type: text/plain, Size: 3698 bytes --]

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:  security@debian.org
>       Red Hat: secalert@redhat.com
>       SUSE:    security@suse.de


Can you also please add:

AdaCore:  product-security@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/
>