From: Nick Clifton <nickc@redhat.com>
To: Binutils <binutils@sourceware.org>
Cc: siddhesh@gotplt.org, "gdb@sourceware.org" <gdb@sourceware.org>
Subject: Re: RFC: Adding a SECURITY.md document to the Binutils
Date: Thu, 20 Apr 2023 16:56:08 +0100 [thread overview]
Message-ID: <cebb4d49-a4b5-07f1-6c45-e7e0740525d1@redhat.com> (raw)
In-Reply-To: <32b08080-f174-4a22-802a-a6b94fdd7b0d@FreeBSD.org>
Hi Guys,
Right, I have gone ahead and applied a patch to add the SECURITY.txt
files to the sources. I realise that we may not have reached a final
agreement on the exact wording, but I wanted to get the files in
place now so that there is at least something there for others to see.
Cheers
Nick
PS. The text of the binutils/SECURITY.txt file that I checked in looks
like this:
Binutils Security Process
=========================
What is a binutils 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 GNU Binutils 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 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.
Notes:
======
None of the programs in the GNU Binutils suite need elevated
privileges to operate and it is recommended that users do not use
them from accounts where such privileges are automatically
available.
The inspection tools are intended to be robust but nevertheless
they should be appropriately sandboxed if they are used to examine
malicious or potentially 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 following 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/
next prev parent reply other threads:[~2023-04-20 15:56 UTC|newest]
Thread overview: 56+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-04-07 8:42 Nick Clifton
2023-04-07 10:36 ` Eli Zaretskii
2023-04-11 13:29 ` Nick Clifton
2023-04-11 14:23 ` Simon Marchi
2023-04-11 15:00 ` Eli Zaretskii
2023-04-11 16:22 ` Nick Clifton
2023-04-11 16:32 ` Matt Rice
2023-04-11 18:18 ` J.W. Jagersma
2023-04-12 8:43 ` Nick Clifton
2023-04-08 6:30 ` Jan Beulich
2023-04-10 18:30 ` John Baldwin
2023-04-20 15:56 ` Nick Clifton [this message]
2023-04-11 19:45 ` Ian Lance Taylor
2023-04-12 16:02 ` Richard Earnshaw
2023-04-12 16:26 ` Siddhesh Poyarekar
2023-04-12 16:52 ` Richard Earnshaw
2023-04-12 16:58 ` Paul Koning
2023-04-12 17:10 ` Siddhesh Poyarekar
2023-04-13 3:51 ` Alan Modra
2023-04-13 4:25 ` Siddhesh Poyarekar
2023-04-13 5:16 ` Alan Modra
2023-04-13 12:00 ` Siddhesh Poyarekar
2023-04-13 10:25 ` Richard Earnshaw
2023-04-13 11:53 ` Siddhesh Poyarekar
2023-04-13 12:37 ` Richard Earnshaw
2023-04-13 12:54 ` Siddhesh Poyarekar
2023-04-13 13:11 ` Richard Earnshaw
2023-04-13 13:35 ` Siddhesh Poyarekar
2023-04-13 13:40 ` Richard Earnshaw
2023-04-13 13:56 ` Siddhesh Poyarekar
2023-04-13 14:50 ` Richard Earnshaw
2023-04-13 15:02 ` Siddhesh Poyarekar
2023-04-13 15:05 ` Richard Earnshaw
2023-04-13 16:42 ` Siddhesh Poyarekar
2023-04-14 9:52 ` Richard Earnshaw
2023-04-14 12:43 ` Siddhesh Poyarekar
2023-04-14 12:49 ` Richard Earnshaw
2023-04-14 13:13 ` Siddhesh Poyarekar
2023-04-13 15:08 ` Paul Koning
2023-04-13 16:02 ` Siddhesh Poyarekar
2023-04-13 16:49 ` Paul Koning
2023-04-13 17:00 ` Siddhesh Poyarekar
2023-04-13 17:05 ` Paul Koning
2023-04-13 17:29 ` Siddhesh Poyarekar
2023-04-13 17:37 ` Paul Koning
2023-04-13 18:16 ` Siddhesh Poyarekar
2023-04-14 17:37 ` Ian Lance Taylor
2023-04-14 18:27 ` Siddhesh Poyarekar
2023-04-14 20:46 ` Ian Lance Taylor
2023-04-14 21:24 ` Siddhesh Poyarekar
2023-04-17 15:31 ` Michael Matz
2023-04-17 19:55 ` Ian Lance Taylor
2023-04-14 19:45 ` DJ Delorie
2023-04-14 20:49 ` Ian Lance Taylor
2023-04-15 6:41 ` Xi Ruoyao
2023-04-13 16:06 ` Richard Earnshaw
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=cebb4d49-a4b5-07f1-6c45-e7e0740525d1@redhat.com \
--to=nickc@redhat.com \
--cc=binutils@sourceware.org \
--cc=gdb@sourceware.org \
--cc=siddhesh@gotplt.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).