RFC: Adding a SECURITY.md document to the Binutils

Nick Clifton nickc@redhat.com
Fri Apr 7 08:42:25 GMT 2023


Hi Guys,

   Many open source projects have a SECURITY.md file which explains
   their stance on security related bugs.  So I thought that it would
   be a good idea if we had one too.  The top level file would actually
   just be a placeholder, like this:

------------- ./SECURITY.md ------------------------------------------
For details on the Binutils security process please see
the SECURITY.md file in the binutils sub-directory.

For details on the GDB security process please see
the SECURITY.md file in the gdb sub-directory.
--------------------------------------------------------------------

   So this email is mostly about the wording for the Binutils specific
   version.  Here is my current proposal:

---------------- binutils/SECURITY.md ------------------------------
Binutils Security Process
=========================

What is a binutils security bug?
================================

    A security bug is one that threatens the security of a system or
    network.  In the context of the GNU Binutils this means a bug that
    relates to the creation of corrupt output files from valid, trusted
    inputs.  Even then the bug would only have a security impact if the
    the code invokes undefined behaviour or results in a privilege
    boundary being crossed.

    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 GNU Binutils (eg
    as, ld, gold, objcopy) and the libraries that they use.  Bugs in
    inspection tools (eg readelf, nm objdump) will not be considered
    to be security bugs, since they do not create executable output
    files.  When used on untrusted inputs, these inspection tools
    should be appropriately sandboxed to mitigate potential damage
    due to any malicious input files.

Reporting private security bugs
===============================

   *All bugs reported in the Binutils 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 follow teams have volunteered to handle such
   bugs:

      Debian:  security@debian.org
      Red Hat: secalert@redhat.com
      SUSE:    security@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 Binutils Bugzilla system, thus making
   them public immediately.  The system can be found here:

      https://sourceware.org/bugzilla/

----------------------------------------------------------------------

   Thoughts ?  Comments ?

Cheers
   Nick



More information about the Binutils mailing list