From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx-2023-1.gwdg.de (mx-2023-1.gwdg.de [134.76.10.21]) by sourceware.org (Postfix) with ESMTPS id A5A053858401; Wed, 3 Apr 2024 16:32:16 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org A5A053858401 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gwdg.de Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gwdg.de ARC-Filter: OpenARC Filter v1.0.0 sourceware.org A5A053858401 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=134.76.10.21 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1712161939; cv=none; b=Y30lJxei/ijsVs8pn72xvSjLO0dUTAE8+ebUZVkWt802LLpiBkzOZU7cx2DjWGT5I2EKNYZVOXqwebglWEO+N9cCyok/rXMMK1p85iOilGzb8LVjhSGEe/mPUopktGv/Kzza+5HSgChbF2VctkbMaUl+M2g9bcj4liV7bzNhhq8= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1712161939; c=relaxed/simple; bh=Ka2L5Koh2MxZwGlv8U1XKnpHN20MpCsW10nwUMpEFjY=; h=DKIM-Signature:Message-ID:Subject:From:To:Date:MIME-Version; b=UehPZ/TOvbQ5FAd0/eD0cK4SBnKxIWzoc13cpHQKWhtQUuD+snRZyXFa+Lc6YI2b468vOKOx6wekucTyQYAn+yGJFb1dCopE3SifCoy4unS/nhU+D49gfKiSDhdDH64Djshho3ANcgwrVhMGnfVyCE3SlHgQewZD+eRF7w1umhg= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gwdg.de; s=2023-rsa; h=MIME-Version:Content-Transfer-Encoding:Content-Type:References: In-Reply-To:Date:CC:To:From:Subject:Message-ID:Sender:Reply-To:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=iCYT2KSuTnKuy7kP/8u37t9PzCklWCB7DvihDooyRas=; b=ozbJrXS938HaS4AJcpsFCHYgma HmUASzSc3yPh52nu7V7d0L2Vfi/pU30te9wLXqw1wt+j/XwBekg3wjnBpK6g+F9gn3fc+uK4DATDA VmTLJcUAb2bLoJ9yjyWyQzh7pjLDcq732BMFDwLlP5qK8kRE6nmBiVTjyK3DpcNKHNlR7XLFZmf/9 km5sdAUU/ytDeFYrubwhTwHChOG9Tiw2qX4JtD0pEhQDtjcbOc7kvE7xNUrcH2bl/OGBHz5joW0/D 7faxRr/OCyq/gmqcwJoZxJwAjdyI/ctbLkazcDWyWPNDqeHmd2dLpwzMRkCe5JiriS1JbCumE6Q9Q k4CcevCQ==; Received: from xmailer.gwdg.de ([134.76.10.29]:44341) by mailer.gwdg.de with esmtp (GWDG Mailer) (envelope-from ) id 1rs3X1-005wol-2M; Wed, 03 Apr 2024 18:32:11 +0200 Received: from excmbx-29.um.gwdg.de ([134.76.9.204] helo=email.gwdg.de) by mailer.gwdg.de with esmtp (GWDG Mailer) (envelope-from ) id 1rs3X1-0002Rn-1X; Wed, 03 Apr 2024 18:32:11 +0200 Received: from vra-168-178.tugraz.at (10.250.9.199) by EXCMBX-29.um.gwdg.de (134.76.9.204) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.37; Wed, 3 Apr 2024 18:32:11 +0200 Message-ID: <10275adf764d87d40c1f29375ca029dd00634412.camel@gwdg.de> Subject: Re: Sourceware mitigating and preventing the next xz-backdoor From: Martin Uecker To: Michael Matz CC: Ian Lance Taylor , Paul Koning , Paul Eggert , "Sandra Loosemore" , Mark Wielaard , , , , , Date: Wed, 3 Apr 2024 18:32:10 +0200 In-Reply-To: <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> <1261f798-175b-961d-b937-f3a9f4246659@suse.de> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.46.4-2 MIME-Version: 1.0 X-Originating-IP: [10.250.9.199] X-ClientProxiedBy: MBX19-GWD-06.um.gwdg.de (10.108.142.59) To EXCMBX-29.um.gwdg.de (134.76.9.204) X-Virus-Scanned: (clean) by clamav X-Spam-Status: No, score=-2.2 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 List-Id: Am Mittwoch, dem 03.04.2024 um 18:02 +0200 schrieb Michael Matz: > Hello, >=20 > On Wed, 3 Apr 2024, Martin Uecker wrote: >=20 > > The backdoor was hidden in a complicated autoconf script... >=20 > Which itself had multiple layers and could just as well have been a=20 > complicated cmake function. Don't me wrong, cmake is no way better. Another problem was=C2=A0 actually hidden in a cmake test in upstream git in plain sight: https://git.tukaani.org/?p=3Dxz.git;a=3Dcommitdiff;h=3Df9cf4c05edd14dedfe63= 833f8ccbe41b55823b00;hp=3Daf071ef7702debef4f1d324616a0137a5001c14c >=20 > > > (And, FWIW, testing for features isn't "complex". And have you looke= d at=20 > > > other build systems? I have, and none of them are less complex, just= =20 > > > opaque in different ways from make+autotools). > >=20 > > I ask a very specific question: To what extend is testing=C2=A0 > > for features instead of semantic versions and/or supported > > standards still necessary? >=20 > I can't answer this with absolute certainty, but points to consider: the= =20 > semantic versions need to be maintained just as well, in some magic way. = =20 It would certainly need to be maintained just like now autoconf configuration needs to be maintained. > Because ultimately software depend on features of dependencies not on=20 > arbitrary numbers given to them. The numbers encode these features, in= =20 > the best case, when there are no errors. So, no, version numbers are not= =20 > a replacement for feature tests, they are a proxy. One that is manually= =20 > maintained, and hence prone to errors. Tests are also prone to errors and - as the example above shows - also very fragile and susceptible to manipulation. >=20 > Now, supported standards: which one? ;-) Or more in earnest: while on= =20 > this mailing list here we could chose a certain set, POSIX, some=20 > languages, Windows, MacOS (versions so-and-so). What about other=20 > software relying on other 3rdparty feature providers (libraries or system= =20 > services)? Without standards? >=20 > So, without absolute certainty, but with a little bit of it: yes, feature= =20 > tests are required in general. That doesn't mean that we could not=20 > do away with quite some of them for (e.g.) GCC, those that hold true on= =20 > any platform we support. But we can't get rid of the infrastructure for= =20 > that, and can't get rid of certain classes of tests. >=20 > > This seems like a problematic approach that may have been necessary=20 > > decades ago, but it seems it may be time to move on. >=20 > I don't see that. Many aspects of systems remain non-standardized. This is just part of the problem. Martin >=20 >=20 > Ciao, > Michael.