From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from crocodile.elm.relay.mailchannels.net (crocodile.elm.relay.mailchannels.net [23.83.212.45]) by sourceware.org (Postfix) with ESMTPS id E5CCA3858C5E; Fri, 14 Apr 2023 21:24:59 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org E5CCA3858C5E Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=gotplt.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gotplt.org X-Sender-Id: dreamhost|x-authsender|siddhesh@gotplt.org Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id B69C2881F42; Fri, 14 Apr 2023 21:24:58 +0000 (UTC) Received: from pdx1-sub0-mail-a305.dreamhost.com (unknown [127.0.0.6]) (Authenticated sender: dreamhost) by relay.mailchannels.net (Postfix) with ESMTPA id 31EDE88181E; Fri, 14 Apr 2023 21:24:58 +0000 (UTC) ARC-Seal: i=1; s=arc-2022; d=mailchannels.net; t=1681507498; a=rsa-sha256; cv=none; b=suie50LVxVq1eo2IHN5rlM7uF7dYlbYuZHyTGMIXOlR9xWJlLuwj+mW/R1ZAMjtXfc5Pii Wf70ez3g3R8Zhne7/r2HZsh0JRApFhulOMU68SnGQ99M+ey2sVPLqMcWKqJAyax1XVCUKR t7mfwpUss2nXl49q4ywgoK7LJfX4rzwaATfpJazcnHqIrMQqnNg+tr+ldlXKNYPj/DXysQ mp0s6fTXS63rZPo6vXHqo8MECnSCeB7yJi6Rr0EiaXef9VFyM9xKN/aV1Y4SVKG2YzANFT NoY1jO0K/RVfudEuLlw5to8w+Qewm3eqUomCdWAyppxTUr3Syh/RvlfGqVBjHg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=mailchannels.net; s=arc-2022; t=1681507498; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=IvkBl/I9Yqaj6P4640R0ftG+Qdobvoc+BpI0kG7YRRo=; b=3azhNHtbjnWO7z8632HD341a29RVBRfykUpY4qRQMKmGb25EzCNYKTnB1aKeylO7jC9nJ0 joTHh2/74NsFtbNCbxcQo+Yww4WLLil4otwnAo/irujvnQzpqTxJK6+GXl7g/p7KgIsKua 7lBXTArJNLSSVpgfWwtu4BuNS/4ZRRQiwxErgapF7LJTYQA/GpOzo+CVpcgGq2IooqFSbB HUSSNcB5Ca7OPAWPqOCRQx3Th28EKXOvqUSCbQvBVdmQJB1LuV7RbzeXO2vBVyhCuJNAcq +ric0HwRGyOaDR/HWhCJ/tkOhu6Opg7H9gnBGusnjYjFEBPK1QL9nkKYGKscRg== ARC-Authentication-Results: i=1; rspamd-7f66b7b68c-dkt2h; auth=pass smtp.auth=dreamhost smtp.mailfrom=siddhesh@gotplt.org X-Sender-Id: dreamhost|x-authsender|siddhesh@gotplt.org X-MC-Relay: Neutral X-MailChannels-SenderId: dreamhost|x-authsender|siddhesh@gotplt.org X-MailChannels-Auth-Id: dreamhost X-Wipe-Fearful: 488cb7b56dc873ef_1681507498541_3629913512 X-MC-Loop-Signature: 1681507498541:1338060430 X-MC-Ingress-Time: 1681507498541 Received: from pdx1-sub0-mail-a305.dreamhost.com (pop.dreamhost.com [64.90.62.162]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384) by 100.127.59.39 (trex/6.7.2); Fri, 14 Apr 2023 21:24:58 +0000 Received: from [192.168.2.12] (bras-vprn-toroon4834w-lp130-09-174-91-45-153.dsl.bell.ca [174.91.45.153]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) (Authenticated sender: siddhesh@gotplt.org) by pdx1-sub0-mail-a305.dreamhost.com (Postfix) with ESMTPSA id 4PyqGd2f39zFW; Fri, 14 Apr 2023 14:24:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gotplt.org; s=dreamhost; t=1681507497; bh=IvkBl/I9Yqaj6P4640R0ftG+Qdobvoc+BpI0kG7YRRo=; h=Date:Subject:To:Cc:From:Content-Type:Content-Transfer-Encoding; b=jb9DodrLHJqPUFXlfcoq7nieyNFtLoGTdavDk1RSTYbapgv4w6TuusPeMS9RzpkfX IfDTYoHbISeOb2NVej0hzIIH9VPX0b8ldlIxrjDcdH+P26YQEf4E1wrsoi9j2lVicg OTn6f5+Fsilwqh1eTs/ftVS+N4dYo1Npf2SPNWIAV7SozBlSnLy/DCffTMubw2I/1I YJad+Ay4s9+xo7nhBrWFivgoqmEQ82MQDFPgKNMPb6lr7BM/FLgk/d56hrOFeruAVf wLMHPk6E0F+ngqj86r9Z7/Zn51VPXq5/B7chKgbJFxM7hbYc5UEPHTNpDh8wYHJdpg G9BplevahuoDQ== Message-ID: Date: Fri, 14 Apr 2023 17:24:56 -0400 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.9.1 Subject: Re: RFC: Adding a SECURITY.md document to the Binutils Content-Language: en-US To: Ian Lance Taylor Cc: Paul Koning , Richard Earnshaw , Nick Clifton , Binutils , "gdb@sourceware.org" References: <1c38b926-e003-0e21-e7f1-3d5dbec2aabf@redhat.com> <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> From: Siddhesh Poyarekar In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-3028.1 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,MEDICAL_SUBJECT,NICE_REPLY_A,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE 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 2023-04-14 16:46, Ian Lance Taylor wrote: > On Fri, Apr 14, 2023 at 11:27 AM 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. I don't disagree with that as an end goal (I even suggested that in that previous thread last year), I think our disagreement is in how we get there in terms of policy, which is a result of that conversation from last year and from exploring how llvm and rust are handling it. >> 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. Sure, they're achievable with adequate resources, but I'm not sure if the binutils project has that; that was in essence the conclusion of last year's conversation FWIW. That of course is a question for the maintainers of the project. Thanks, Sid