public inbox for binutils@sourceware.org
 help / color / mirror / Atom feed
From: Ian Lance Taylor <iant@google.com>
To: Siddhesh Poyarekar <siddhesh@gotplt.org>
Cc: Paul Koning <paulkoning@comcast.net>,
	 Richard Earnshaw <Richard.Earnshaw@foss.arm.com>,
	Nick Clifton <nickc@redhat.com>,
	 Binutils <binutils@sourceware.org>,
	"gdb@sourceware.org" <gdb@sourceware.org>
Subject: Re: RFC: Adding a SECURITY.md document to the Binutils
Date: Fri, 14 Apr 2023 13:46:24 -0700	[thread overview]
Message-ID: <CAKOQZ8x4KOfVhdGrf+mgkRJ9QkDn36jUJcWWXU=NG1E3g6BDyg@mail.gmail.com> (raw)
In-Reply-To: <20dbbe16-c7e5-412e-0506-2118dfef5fc2@gotplt.org>

On Fri, Apr 14, 2023 at 11:27 AM Siddhesh Poyarekar <siddhesh@gotplt.org> wrote:
>
> A compiler crash, core dump, etc. is definitely a serious bug and we
> consider them as P1/P2 in almost all cases.  However to be considered a
> security issue, the input has to be crafted and that's where the user
> comes in; their responsibility is to ensure that they don't build
> untrusted code (e.g. when they're trying to study malware or virus
> sources or binaries) outside of sandboxes.

I believe I understand what you are saying, and I don't agree.

We live in a time where free software has succeeded.  People routinely
rely on gigantic libraries provided as source code by people across
the Internet.  10% of the projects on GitHub are written at least
partially in C++.  To argue that people should not even compile
untrusted code is to speak about a world that simply does not exist
today.  Very few people working on application level code can trust
their entire software supply chain.

This means that software development must be secure at every level.
We must not rely on the single layer of defense of trusting source
code, a defense that very few people can maintain.  We must defend at
other levels.

The binutils developers must play their own small part in this, which
is to assemble and link code correctly, and to not make the assembler,
linker, and related tools themselves into vectors for security issues.


> If as a project we decide to treat untrusted input as a valid use case,
> it is going to shift the goalposts for binutils (and gcc, if we take the
> same stand there). I suppose golang does try to adhere to these higher
> standards somewhat but I am not well versed with their formal position
> on this.  I've seen them consider bugs due to untrusted regex inputs as
> security issues whereas even glibc currently doesn't, except for some
> very specific conditions.

Yes, the Go project does aim to adhere to these higher standards,
because, in my opinion, they are the correct standards.

And, honestly, these are not standards that are unusually difficult to
meet.  Don't dump core, don't use up all of memory, don't have buffer
overflows.  Treat failures of this sort as security bugs to be fixed
ASAP in minor releases.  These are achievable goals.

Ian

  reply	other threads:[~2023-04-14 20:46 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
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 [this message]
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='CAKOQZ8x4KOfVhdGrf+mgkRJ9QkDn36jUJcWWXU=NG1E3g6BDyg@mail.gmail.com' \
    --to=iant@google.com \
    --cc=Richard.Earnshaw@foss.arm.com \
    --cc=binutils@sourceware.org \
    --cc=gdb@sourceware.org \
    --cc=nickc@redhat.com \
    --cc=paulkoning@comcast.net \
    --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).