From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id 52ZcLdF9DWZ2pCEAWB0awg (envelope-from ) for ; Wed, 03 Apr 2024 12:03:29 -0400 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=ir1Jv9oY; dkim-atps=neutral Received: by simark.ca (Postfix, from userid 112) id AD3581E0C0; Wed, 3 Apr 2024 12:03:29 -0400 (EDT) Received: from server2.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 ECDSA (prime256v1) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPS id 9E5C31E030 for ; Wed, 3 Apr 2024 12:03:27 -0400 (EDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id BEF62384601E for ; Wed, 3 Apr 2024 16:03:26 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org BEF62384601E DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1712160206; bh=9XhUO+ObQ1ju+jZqP644pGTpYFB1uNF8Zf2C+qJdb9o=; h=Date:To:cc:Subject:In-Reply-To:References:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: From:Reply-To:From; b=ir1Jv9oYG1WHn0oq5T7TleLam/Rp8PavxKrKnN3QMrr4MnRKZs8juon/zoV8k01Fl R4nuRz21K9i3L/iqNf8Elhj3nk76BkL/SRCaIFaMIwHzBoo/w4X/uOCDxUOlYpPk8i GvMiNnAeXOT5IHhZ0I5ca9OQVLwnBwmxfpNc2m8Y= Received: from smtp-out1.suse.de (smtp-out1.suse.de [195.135.223.130]) by sourceware.org (Postfix) with ESMTPS id 531993858401; Wed, 3 Apr 2024 16:02:34 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 531993858401 ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 531993858401 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1712160157; cv=none; b=U7FI8NaCvLB+ipIkgdxLXytArIbStJPVELLbmj31jQUFAObPISAaV8BQSM6wzIw+OJWcqGEZJfMHatqITFJ3/LfAwBMrcy2Hdrdi6KtvMR9L1+jr077RxIh6GmIZQ6ZEJ/bucOQOs82nySldHthXWhETGhW1owFp2lBvBeTQ7HE= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1712160157; c=relaxed/simple; bh=wlRRJtewxq9lmZGNQnYD4gY0DpzHrwpZOqhCPT17t/c=; h=DKIM-Signature:DKIM-Signature:Date:From:To:Subject:Message-ID: MIME-Version; b=IjO9kFVpbpqHZClv/YdpP6H5xkQ/R76KKu/+pv5MXkOVr5otPdv4dGeuPgaBcegCH5pGJ9dCZTeInNnNLLuk7Lg0umL80F85SpWlvfIzfEP342vL9fXr5xafE9e7LkRxEX1GTFQe/H6HDqun3vPQorpRC5556NR99vjHlZJZ/1g= ARC-Authentication-Results: i=1; server2.sourceware.org Received: from knuth.suse.de (unknown [10.168.5.16]) by smtp-out1.suse.de (Postfix) with ESMTP id 300CD37247; Wed, 3 Apr 2024 16:02:32 +0000 (UTC) Received: by knuth.suse.de (Postfix, from userid 10510) id 27ACB34574B; Wed, 3 Apr 2024 18:02:32 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by knuth.suse.de (Postfix) with ESMTP id 1703A34574A; Wed, 3 Apr 2024 18:02:32 +0200 (CEST) Date: Wed, 3 Apr 2024 18:02:31 +0200 (CEST) To: Martin Uecker cc: Ian Lance Taylor , Paul Koning , Paul Eggert , Sandra Loosemore , Mark Wielaard , overseers@sourceware.org, gcc@gcc.gnu.org, binutils@sourceware.org, gdb@sourceware.org, libc-alpha@sourceware.org Subject: Re: Sourceware mitigating and preventing the next xz-backdoor In-Reply-To: Message-ID: <1261f798-175b-961d-b937-f3a9f4246659@suse.de> References: <20240329203909.GS9427@gnu.wildebeest.org> <20240401150617.GF19478@gnu.wildebeest.org> <12215cd2-16db-4ee4-bd98-6a4bcf318592@cs.ucla.edu> <6239192ba9ff8aad0752309a54b633dc75a57c77.camel@tugraz.at> <8e877d2f-01e0-c786-dea5-265edbdc0c07@suse.de> MIME-Version: 1.0 X-Spamd-Result: default: False [-2.20 / 50.00]; BAYES_HAM(-3.00)[100.00%]; CTYPE_MIXED_BOGUS(1.00)[]; NEURAL_HAM_SHORT(-0.20)[-1.000]; MIME_GOOD(-0.10)[multipart/mixed,text/plain]; RCVD_NO_TLS_LAST(0.10)[]; RCPT_COUNT_SEVEN(0.00)[11]; TO_DN_SOME(0.00)[]; MIME_TRACE(0.00)[0:+,1:+]; ARC_NA(0.00)[]; MISSING_XM_UA(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; FREEMAIL_ENVRCPT(0.00)[comcast.net]; FUZZY_BLOCKED(0.00)[rspamd.com]; FROM_HAS_DN(0.00)[]; FREEMAIL_CC(0.00)[golang.org,comcast.net,cs.ucla.edu,baylibre.com,klomp.org,sourceware.org,gcc.gnu.org]; DKIM_SIGNED(0.00)[suse.de:s=susede2_rsa,suse.de:s=susede2_ed25519]; FROM_EQ_ENVFROM(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; DBL_BLOCKED_OPENRESOLVER(0.00)[knuth.suse.de:helo] X-Spam-Score: -2.20 X-Spam-Level: X-Spam-Status: No, score=-3.1 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8BIT X-Content-Filtered-By: Mailman/MimeDel 2.1.30 X-BeenThere: gdb@sourceware.org X-Mailman-Version: 2.1.30 Precedence: list List-Id: Gdb mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , From: Michael Matz via Gdb Reply-To: Michael Matz Errors-To: gdb-bounces+public-inbox=simark.ca@sourceware.org Sender: "Gdb" Hello, On Wed, 3 Apr 2024, Martin Uecker wrote: > The backdoor was hidden in a complicated autoconf script... Which itself had multiple layers and could just as well have been a complicated cmake function. > > (And, FWIW, testing for features isn't "complex". And have you looked at > > other build systems? I have, and none of them are less complex, just > > opaque in different ways from make+autotools). > > I ask a very specific question: To what extend is testing  > for features instead of semantic versions and/or supported > standards still necessary? I can't answer this with absolute certainty, but points to consider: the semantic versions need to be maintained just as well, in some magic way. Because ultimately software depend on features of dependencies not on arbitrary numbers given to them. The numbers encode these features, in the best case, when there are no errors. So, no, version numbers are not a replacement for feature tests, they are a proxy. One that is manually maintained, and hence prone to errors. Now, supported standards: which one? ;-) Or more in earnest: while on this mailing list here we could chose a certain set, POSIX, some languages, Windows, MacOS (versions so-and-so). What about other software relying on other 3rdparty feature providers (libraries or system services)? Without standards? So, without absolute certainty, but with a little bit of it: yes, feature tests are required in general. That doesn't mean that we could not do away with quite some of them for (e.g.) GCC, those that hold true on any platform we support. But we can't get rid of the infrastructure for that, and can't get rid of certain classes of tests. > This seems like a problematic approach that may have been necessary > decades ago, but it seems it may be time to move on. I don't see that. Many aspects of systems remain non-standardized. Ciao, Michael.