From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ej1-x632.google.com (mail-ej1-x632.google.com [IPv6:2a00:1450:4864:20::632]) by sourceware.org (Postfix) with ESMTPS id 13DAC3858C66 for ; Fri, 14 Apr 2023 20:46:38 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 13DAC3858C66 Authentication-Results: sourceware.org; dmarc=pass (p=reject dis=none) header.from=google.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=google.com Received: by mail-ej1-x632.google.com with SMTP id dm2so48783554ejc.8 for ; Fri, 14 Apr 2023 13:46:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20221208; t=1681505196; x=1684097196; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=RSmh/vDGDAmCrDJ58bNaj5/gTxYMNKmc3nfBKdkEZHU=; b=IrHz41TW/X8E9ENt8/AOAXgQlryh5K2fNhiFpFzvYd2vH2l4JjkN0CN5Ikx5pMFJ2s bbsS+dWNraaxRSXnLmq6yZY8s9OBSjLEkfRcF2VHAf565Frs2X0VNiIY7WM9crZPtmv+ jN5xsL+LrDwjIQYSH3Vl3LruD/863gOmukUg6K1pHg59tPgKbLU1SFpDJoZ6bNHZt7w2 kymJwAbgJsLkdXBGPlj1umHgh6CJaDwzO4/1x8ZAbgXd1kaAMOnkSbnLwAK+ahjbMZkp R7MXrSZXhFq7m8jkVRIaDnY1IjBXX0QSohWhHo3cfKXw1kLttNKDUe6fng9ud+XAs91U 408g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1681505196; x=1684097196; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=RSmh/vDGDAmCrDJ58bNaj5/gTxYMNKmc3nfBKdkEZHU=; b=YxED13GSxT2109Z0iJZUs3zaYj+1jCWTSNRf8r9yjchUPgTE7k5xeUQtidyzBsj9HN pS7XGM5iwnq8QEWCiAcb80YZXZe9/e/gn10QB1yObQBI1KkogwiGbscPVGTY6hnaIHA5 mANqURS6tB5f21keDA9BrtLG2R2NIDt8zEsP8azl18OR7bl+xnKucl5/k4qv8Xxz/3oU IhzWQEmDVuonPLHz256jSCux6JD+XvurR/vmLEqLFCWuI+4lsTCLvvc3wR5gERl1HSRo ceYPQDFc6utjkQehttjbv2wueZqFJsEALnvbGR/s/XGw6+JOj5w2xpD+7F2up07mINoT pxKg== X-Gm-Message-State: AAQBX9eQjBNI7QEAZS5g3PzzgltVy8LmIlTNw/+JAxDWe+LSQNeeryLa 2eLriXnmYdng3kj3ixHkrutmm3D3yO/xz2tW97S3Jw== X-Google-Smtp-Source: AKy350bpVQikMR6e+Ej0GnKPO0ku37RicxlVAMND9BPv4rXsuFBb6lj6aR3fR+0+K6tsnqgzyTApelmsAK6q0MD/15c= X-Received: by 2002:a17:907:2d8d:b0:94a:2f2f:9a5f with SMTP id gt13-20020a1709072d8d00b0094a2f2f9a5fmr185388ejc.8.1681505196352; Fri, 14 Apr 2023 13:46:36 -0700 (PDT) MIME-Version: 1.0 References: <1c38b926-e003-0e21-e7f1-3d5dbec2aabf@redhat.com> <5d044987-39eb-a060-1b2b-9d07b1515e7d@gotplt.org> <73bc480a-a927-2773-8756-50350f76dfbf@gotplt.org> <4ed86e65-0b7f-11d4-8061-2c5d0b1e147e@foss.arm.com> <7b6b10f8-e480-8efa-fbb8-4fc4bf2cf356@gotplt.org> <0224757b-6b17-f82d-c0bf-c36042489f5e@foss.arm.com> <01e846c0-c6bf-defe-0563-1ed6309b7038@gotplt.org> <2d4c7f13-8a35-3ce5-1f90-ce849a690e66@foss.arm.com> <01b8e177-abfd-549e-768f-1995cab5c81d@gotplt.org> <96e2ec59-11c6-329e-18c4-bf284eb752ac@gotplt.org> <20dbbe16-c7e5-412e-0506-2118dfef5fc2@gotplt.org> In-Reply-To: <20dbbe16-c7e5-412e-0506-2118dfef5fc2@gotplt.org> From: Ian Lance Taylor Date: Fri, 14 Apr 2023 13:46:24 -0700 Message-ID: Subject: Re: RFC: Adding a SECURITY.md document to the Binutils To: Siddhesh Poyarekar Cc: Paul Koning , Richard Earnshaw , Nick Clifton , Binutils , "gdb@sourceware.org" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-14.6 required=5.0 tests=BAYES_00,DKIMWL_WL_MED,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,ENV_AND_HDR_SPF_MATCH,MEDICAL_SUBJECT,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE,USER_IN_DEF_DKIM_WL,USER_IN_DEF_SPF_WL autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On Fri, Apr 14, 2023 at 11:27=E2=80=AFAM Siddhesh Poyarekar 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