From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp-out2.suse.de (smtp-out2.suse.de [IPv6:2001:67c:2178:6::1d]) by sourceware.org (Postfix) with ESMTPS id 6E5C93858C50; Mon, 17 Apr 2023 15:31:16 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 6E5C93858C50 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=suse.de Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=suse.de Received: from relay2.suse.de (relay2.suse.de [149.44.160.134]) by smtp-out2.suse.de (Postfix) with ESMTP id B8FA71F86C; Mon, 17 Apr 2023 15:31:13 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa; t=1681745473; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=VnnzSBV3bvcSJ6TPa/4yqLleVFiMIjb0WNI8+WxVwq4=; b=W8RD7lLv7AuOgXLsKpR1Ml3e23HgioYmjWYUPPl7W/Q5B8/EDhgSe1ukEs/jMTP1kDOP5R buAwV/3N7wAbp0iwPftWm87IR+RafzN38L+9ghOuzuHGagU9MnaDmEVjTWdJ0diilygxNQ pw4dYdHFSu51xgOdDWuc074R4oi9Nd8= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_ed25519; t=1681745473; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=VnnzSBV3bvcSJ6TPa/4yqLleVFiMIjb0WNI8+WxVwq4=; b=cToiUwnMyOnX7ZRynGe0R+NEesr6I//QFn8rMrVT6IOius4OdC7j7XGIrxOIM+6C5XuAS0 bUZaU90maO18WAAQ== Received: from wotan.suse.de (wotan.suse.de [10.160.0.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by relay2.suse.de (Postfix) with ESMTPS id 5D9212C141; Mon, 17 Apr 2023 15:31:13 +0000 (UTC) Received: by wotan.suse.de (Postfix, from userid 10510) id 1D7E2644B; Mon, 17 Apr 2023 15:31:13 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by wotan.suse.de (Postfix) with ESMTP id 1B0A46424; Mon, 17 Apr 2023 15:31:13 +0000 (UTC) Date: Mon, 17 Apr 2023 15:31:13 +0000 (UTC) From: Michael Matz To: Binutils cc: Ian Lance Taylor , Siddhesh Poyarekar , Paul Koning , Richard Earnshaw , Nick Clifton , "gdb@sourceware.org" Subject: Re: RFC: Adding a SECURITY.md document to the Binutils In-Reply-To: Message-ID: 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> User-Agent: Alpine 2.20 (LSU 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-Spam-Status: No, score=-1.2 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,MEDICAL_SUBJECT,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: Hello, On Fri, 14 Apr 2023, Ian Lance Taylor via Binutils wrote: > 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. These are all noble goals to reach for. But the fact is that all the crap CVE entries from script-kiddies with their fuzzers are mainly fixed by Alan with his seemingly endless patience. Downstream they are the cause of endless worries (as customers blindly _demand_ that all CVEs be fixed by checking tickmarks on an endless list of entries they've downloaded last week from mitre; just by virtue of the entry having a CVE number and hence "be a serious security problem"). All of these are bugs to be fixed eventually. Literally _none_ of them are in any way a serious bug demanding an immediate fix. Next release is completely fine for that. The endless trouble is in either (a) disputing the CVE with mitre, or (b) discussing each of the entries with the customer of why it's harmless and so on or (c) to backport zillions of useless patches to multiple codestreams and (d) to rebuild all stuff with the new patched binutils. And _then_ multiply this by the overwhelming feeling of wasting lifetime on completely irrelevant, unrealistic and stupid problems that noone in a realistic world will hit. Fixing the (e.g. buffer overflow) bug is good. Fixing it "right now because I'm important" is not. Essentially fuzzers have destroyed any value of the CVE database (they are wonderful as bug hunters, don't get me wrong on that; but CVEs are meanwhile used as "I'm important, fix my bug right now!!!"). We as downstream for instance, since a long time, essentially defer all binutiles "CVEs" resulting from fuzzing to the next release of binutils (even though updating to new releases in old codestreams brings its own problems, they are just a lot easier to deal with than backporting 100 "CVE" fixes, where each of them poses the danger of introducing an actual bug). If it were me my SECURITY.md text would read "If you get a CVE from a fuzzed input we ignore you. Report it as normal bug and stop hunting for a CVE-entry ranking record.", but I can see why that might be a bit too blunt :) Sorry for the rant :) Ciao, Michael.