From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id UwwxBXm8OWQt7SsAWB0awg (envelope-from ) for ; Fri, 14 Apr 2023 16:50:01 -0400 Received: by simark.ca (Postfix, from userid 112) id 0895F1E221; Fri, 14 Apr 2023 16:50:01 -0400 (EDT) Authentication-Results: simark.ca; dkim=pass (1024-bit key; secure) header.d=sourceware.org header.i=@sourceware.org header.a=rsa-sha256 header.s=default header.b=sA782i8m; dkim-atps=neutral X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-8.0 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,RCVD_IN_DNSWL_HI, URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.6 Received: from sourceware.org (server2.sourceware.org [8.43.85.97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPS id 6156D1E11C for ; Fri, 14 Apr 2023 16:50:00 -0400 (EDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 924E93858414 for ; Fri, 14 Apr 2023 20:49:59 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 924E93858414 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1681505399; bh=hoZfOLlHE27E3+EtiZWJiPh/aTHyqQFeJh39RuvNAhQ=; h=References:In-Reply-To:Date:Subject:To:Cc:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: From:Reply-To:From; b=sA782i8mWFzL7dr9oy3VqVHTRHubjVRj55i8IH1e4MzmTmKnXXjjfL90fNgi6cbxq ALp+K6VltJNNFIwhmMSDBuAzfrIwS8RGsfSpbZ1zMW+2uD3buhZEXrDTNEHHN5zLfX 9uTOEEu9FVcMsLL/s4qL89xJU8uaoNSBa0mAIJjs= Received: from mail-ej1-x629.google.com (mail-ej1-x629.google.com [IPv6:2a00:1450:4864:20::629]) by sourceware.org (Postfix) with ESMTPS id C200A3858C5E for ; Fri, 14 Apr 2023 20:49:32 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org C200A3858C5E Received: by mail-ej1-x629.google.com with SMTP id c9so9825190ejz.1 for ; Fri, 14 Apr 2023 13:49:32 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1681505371; x=1684097371; 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=hoZfOLlHE27E3+EtiZWJiPh/aTHyqQFeJh39RuvNAhQ=; b=G7OcxeWsEPM97jWk1nSDC+4vp7IyiU2FpbX8aNKIwKrNjkGLRaT3QfgvfEt6w5vFp8 PuvfbDXjUJ46ifQV9MfHLXferG7vE3kC/sepD+vz5eAVlmYDgizGjVF4RPmLbQshcIk1 rq4nwxgLfsplyVKh2PA8N1F3NBO6NGE7p0t07dzY9YSQJjX77wePiLvOXsEwxIE6x7Ee xwcs3LhNyd7v4JbixhNWpF8pLDwbIUVfBWYjHIH9gNolsN9PXDiOif4kgGwTNP7XXcvR ICjaWn+GQ5ly/W3hf/Jof1gpzoG753Vxfo/bGr92BhYG5c5iJqZHkOQ0Xu7S7VkioGzr wuEQ== X-Gm-Message-State: AAQBX9fu0k8m2gtaPc5bc9w09gMUCMLBEYdJk+IsWWFdN8fCkspaQ2QD i3CW42mGur0n8J2q1+0Jl8THIl+kHf3iRaoGQSSqecOb4yOl/PiDtlU= X-Google-Smtp-Source: AKy350YPTJNN5VMKUNNR7F6NPxkDVrObiIHTickoHmsdtAPJUVBeilyp83zj69AgYgj4Z0DqwRaU7g2ZdI40lefFTyQ= X-Received: by 2002:a17:906:3850:b0:94a:6cae:701f with SMTP id w16-20020a170906385000b0094a6cae701fmr178836ejc.8.1681505371269; Fri, 14 Apr 2023 13:49:31 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: Date: Fri, 14 Apr 2023 13:49:20 -0700 Message-ID: Subject: Re: RFC: Adding a SECURITY.md document to the Binutils To: DJ Delorie Cc: binutils@sourceware.org, gdb@sourceware.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-BeenThere: gdb@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , From: Ian Lance Taylor via Gdb Reply-To: Ian Lance Taylor Errors-To: gdb-bounces+public-inbox=simark.ca@sourceware.org Sender: "Gdb" On Fri, Apr 14, 2023 at 12:45=E2=80=AFPM DJ Delorie wrote: > > Ian Lance Taylor via Gdb writes: > > Compilers and linkers must behave in a reasonable manner when given > > untrusted input. > > Are we confusing trusted with well-behaved? I mean, if I download a > source tree from the FSF's git server, I trust it, but it may still be > ill-behaved. Meanwhile, sources from a public mailing list may be > well-behaved but not trusted. > > I'm only posting this because Carlos and I had long discussions about > this before we set up the glibc pre-commit CI. This process takes > random patches from the public glibc mailing list, and builds them. > WHOA! That's dangerous! Yes. The patches may produce well-defined > code, but are not trusted. Those builds run in a tight sandbox to > mitigate any attack attempts. Security here is outside the scope of the > build tools. I don't expect gcc to scan for viruses or prevent people > from doing "#include ". I agree that GCC does not have to scan for viruses or strange #include statements. I am saying that you should not need to set up a sandbox merely to build code. Clearly if you want to execute untrusted code, some sort of sandbox is a minimal requirement. I'm only talking about building code (and, for objdump and friends, inspecting code). Ian