From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-yb1-f169.google.com (mail-yb1-f169.google.com [209.85.219.169]) by sourceware.org (Postfix) with ESMTPS id 2D76C3858401; Wed, 3 Apr 2024 16:26:21 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 2D76C3858401 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=rtems.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 2D76C3858401 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=209.85.219.169 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1712161583; cv=none; b=rGAdRBaA5vI1IMX3gZ0fz2+9HZXnEGZbxE/LobtwX7MjDVcceSAm6l5hnvy9KSR/GKWI5AFhb09VbQpMkMnjFzpIzk2yST32cABnsKhpDw4h/ULNyacVL6u+NWTI6v68P/9EwCRmfF//eOQVzwzTGZ3GssQjFMlS/MaAyF5OglI= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1712161583; c=relaxed/simple; bh=R98+caECY5aUFBnhsg7TscXx2Gyo+7nXp936BRiFbfU=; h=MIME-Version:From:Date:Message-ID:Subject:To; b=C8b8N3oIfgEbyzHcKdwVV7fNcCR4Gmnls4laMSPAUXKBlI2KYxJ11d4GSRAhkGzRmsiJ9MgimPT9+RkDtXD8VRRjBc5ZO86cKMbK+Df3dr7dbo12wetP2P0z9DvnXN/Yf8YqizSvLLgOFzq8BV8uRuf+ZV4fTPFqPUZEiBJ/knU= ARC-Authentication-Results: i=1; server2.sourceware.org Received: by mail-yb1-f169.google.com with SMTP id 3f1490d57ef6-dc6d8bd612dso71454276.1; Wed, 03 Apr 2024 09:26:21 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1712161580; x=1712766380; h=cc:to:subject:message-id:date:from:reply-to:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=Ej+eIt5zIwKTUnntpKWCnefcm35hOhuHGH8efcJXehc=; b=KVgJU2GaYJ1Aw2u1SnkVGELmDgM1PGUu6BAy7W9qiJ23QVqdjKvVfXnUhCgauysHV/ O6Z+Ufq9Yex03UZMObk/c99yWF9lieY9sr2wDGDrdK/lJnZD/zy2Tqexxkjc4/qJGfPs ZIIbgX9GwWB9Lvg0cDEo/J1Lt8O8q0Z/BjsbqaGHw3T42vSLZSgbl9KBERKvldg6EuJf t2XwPEX4ZCQlzsxrSnLKV1p1nPMu+jfO/5LzEe7uAwNv1pyyFoyR6F7qqI75eUf/QxXH HjjOj45ace5m2RjMeEY71itDJ4McOZ++//WLBW9JXeUYqFWNq2QOzlZbMhAdu9sJ3YQD JSZg== X-Forwarded-Encrypted: i=1; AJvYcCWiipeM77wS567DV9nlyOSDtmXv0QBx6vTXUc5R9BjGQ9wqPyPbUviIIkwSIlGZKGVKAvg963Nx5styUFLLG7qMgHm8HPaQCWk/xxmn7ulUBSODvm+IGswo8l3vd0R3WSLgW7I0uEekp6PZZQHs/R7Tct8R1XuJzd+ncs8z9fceYaNvkld5Zl/amjhv6TeWD1Y= X-Gm-Message-State: AOJu0YzdptQ53Lyvt212xecrhK44q6vd6LYblFLtwbSxAH4k/fJz/taX pNefJImtQX0JUA9IIQFPXg2fvNeECySbgcQAOyv61yMvihCsBDCcSdR/pn8A59A= X-Google-Smtp-Source: AGHT+IH7eekMw4UQh0JEnKmsD86F9bQavySp/hQmPQQlIigiUb1X3Rbk5tU/nDnC5wi3p074RnOtyg== X-Received: by 2002:a25:b90e:0:b0:dc2:5674:b408 with SMTP id x14-20020a25b90e000000b00dc25674b408mr13966594ybj.57.1712161580094; Wed, 03 Apr 2024 09:26:20 -0700 (PDT) Received: from mail-yb1-f173.google.com (mail-yb1-f173.google.com. [209.85.219.173]) by smtp.gmail.com with ESMTPSA id v10-20020a2583ca000000b00dcc620f4139sm3023416ybm.14.2024.04.03.09.26.19 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 03 Apr 2024 09:26:19 -0700 (PDT) Received: by mail-yb1-f173.google.com with SMTP id 3f1490d57ef6-dc745927098so56672276.3; Wed, 03 Apr 2024 09:26:19 -0700 (PDT) X-Forwarded-Encrypted: i=1; AJvYcCVjN/pTGTDDZfehIF5MfSaug7Zsjb1ueHShNpPoKAB+cXUddRSlrtwIohKq8EZqMc7wo3sxz+eQIoP5wFtiaT8ZfZLCm2D636whEDPxqs/Z+Wzs9XFa4neihV3tIoPtiVqJ7lMlHXfqLoEyAPN/jRN1CEJCJaGC+KWI9EBCAIzyYIjGA5L1WvNV0obu52KsJ0s= X-Received: by 2002:a25:18c3:0:b0:dcb:b41c:77ef with SMTP id 186-20020a2518c3000000b00dcbb41c77efmr13420518yby.24.1712161579007; Wed, 03 Apr 2024 09:26:19 -0700 (PDT) MIME-Version: 1.0 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> <1261f798-175b-961d-b937-f3a9f4246659@suse.de> In-Reply-To: <1261f798-175b-961d-b937-f3a9f4246659@suse.de> Reply-To: joel@rtems.org From: Joel Sherrill Date: Wed, 3 Apr 2024 11:26:07 -0500 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: Sourceware mitigating and preventing the next xz-backdoor To: Michael Matz Cc: Martin Uecker , 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 Content-Type: multipart/alternative; boundary="000000000000b70fb7061533aeca" X-Spam-Status: No, score=-3031.3 required=5.0 tests=BAYES_00,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM,HEADER_FROM_DIFFERENT_DOMAINS,HTML_MESSAGE,KAM_DMARC_STATUS,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_PASS,TXREP 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: --000000000000b70fb7061533aeca Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Apr 3, 2024 at 11:03=E2=80=AFAM Michael Matz via Gdb wrote: > 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. > Even assuming a set of standards still leaves issues like supporting a wide range of OS versions which may evolve to support different versions of the same standard. And then there is the case of standards having deliberately implementation defined behavior. Last week, I had to double check what malloc(0) and free(NULL) are supposed to do per POSIX. Guess what -- implementation defined behavior options. And worse, POSIX doesn't define the default attributes for pthreads and the associated synchronization objects. These vary widely across OSes. Then there are the broken things autoconf checks for. Somehow the "broken sed from Solaris" check sticks in my head. Or needing to use GNU sed instead of FreeBSD sed to build a mips embedded target. And this ignores issues like word size issues. 32 vs 64 bits for one, Or weird CPUs where nothing is byte addressable (TI C3x/4x is one example). > > 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. > Again from pthreads, manipulating affinity on multi-core systems and having names for pthreads are non-standard but commonly available with varying APIs. And the standards have plenty of wiggle room in them. Undefined areas or deliberately implementation defined. --joel > > > Ciao, > Michael. > --000000000000b70fb7061533aeca--