From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp0.migadu.com ([2001:41d0:403:58f0::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms1.migadu.com with LMTPS id cPnfGhdcX2aE5QAAqHPOHw:P1 (envelope-from ) for ; Tue, 04 Jun 2024 20:25:27 +0200 Received: from aspmx1.migadu.com ([2001:41d0:403:58f0::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp0.migadu.com with LMTPS id cPnfGhdcX2aE5QAAqHPOHw (envelope-from ) for ; Tue, 04 Jun 2024 20:25:27 +0200 X-Envelope-To: larch@yhetil.org Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=dismail.de header.s=20190914 header.b=f0LoJW5U; dmarc=pass (policy=reject) header.from=dismail.de; spf=pass (aspmx1.migadu.com: domain of "guix-devel-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="guix-devel-bounces+larch=yhetil.org@gnu.org" ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1717525527; h=from:from:sender:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:list-id:list-help: list-unsubscribe:list-subscribe:list-post:dkim-signature; bh=VpBWPWvgFPNXm4I0ZBcilrVy9/QvqxybAbZ4XN9Wt/I=; b=Tkpoin3C6+bJzMEILqfGN32YPhQs25zRuvAYQgfTH4IlCCRy1hGMgwhNOVy+acapqX6uti ucTPyWeAQ1LKVMJznMHXp6+1jRJEf162KAIb/vyQq5BMlPQZJf6N379GZN4/m9QV7fqIZT H2j/XreefsMHbPUuc8kC5q7setbNZWwGS7jDVTC6RoVQmdHHKh4qU74WwtkTLReCBSqqL2 s3UjeidBVx9EQ7UzACp+qo/0DHKuvXCREPUUOWddyykMWJqXviv2N4WFJzqltfciDeuhkw Nz5r7UPA6zJ2/uF+Q+XgQ9gYb6p8a35UH/dB4yZojMRigKLa7IoRGmwX6BEVTQ== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1717525527; a=rsa-sha256; cv=none; b=M270sWeFQlaJDbV3J2ayXHolz59w2vaSt/fGQyz+8EiWhwJkuKoJh7ab2KA8JTZK5VT6xK Mp+dLPxmJHmJtt2qhLCdWTcQvtKhDbvcWSaO4jKK4KPwJRy/PnHo4jJfrKWAyN7M5MTkqL +oulRtTdrWSYsLJFv3VwjnUXVXG/9BH3lCkE6N3CkvUlqA+o5zRDUah2KCiLj82Wya64l+ do07ZpvbU6V/Gxz0VAMPztwpk9avYZYRJ2m15d2fybHi1zQpJJ5HVktFVcKRvmw/jX+sTo f1zZZMnnzSUoMyLxiRIED9RFlznwhJUBg0Kfe4nUW0RVs/Mc4MF9dCU34KBqWw== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=pass header.d=dismail.de header.s=20190914 header.b=f0LoJW5U; dmarc=pass (policy=reject) header.from=dismail.de; spf=pass (aspmx1.migadu.com: domain of "guix-devel-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="guix-devel-bounces+larch=yhetil.org@gnu.org" Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by aspmx1.migadu.com (Postfix) with ESMTPS id D89307C336 for ; Tue, 04 Jun 2024 20:25:26 +0200 (CEST) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1sEYpl-0007i4-JK; Tue, 04 Jun 2024 14:24:33 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1sEYpj-0007hp-QA for guix-devel@gnu.org; Tue, 04 Jun 2024 14:24:31 -0400 Received: from mx1.dismail.de ([78.46.223.134]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1sEYpc-00022X-He for guix-devel@gnu.org; Tue, 04 Jun 2024 14:24:30 -0400 Received: from mx1.dismail.de (localhost [127.0.0.1]) by mx1.dismail.de (OpenSMTPD) with ESMTP id 96403f62; Tue, 4 Jun 2024 20:24:17 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed; d=dismail.de; h= mime-version:date:content-type:content-transfer-encoding:from :message-id:subject:to:cc:in-reply-to:references; s=20190914; bh=isATi+WWySU5OrPhEm9LJP6M1wHAfu52XOAjMU7CosE=; b=f0LoJW5U/n3+ YpBB8zK2511+1aFHjgIdCTckHZPwLNWJ3IlcdvrLCzYyOExP2WpgGP8/PHccvuBA A44WEGxOu1vxAdX0VMYEcC/E9B3meQxvqpCKj/reJnjiRuxL7beIdd0Dq3X+8018 0UuM7qFjkjRVSJSKwjl9KtIYrBZDaOoIuPzp4JD1lxyK4d1aVlBE0P1u7A9m6BUk e/ip15LRgJdhInyDI/BCMVCQiBKqkvzzT5NTmmcqWzZN2u1rsJJz3pufKoF4xVqg 3NDRzhzncaheu1PPJs55LKaTq/9QOAq1jgnpA+IqLAYAgeU2ajDIBHKBZ9D+BB6N 6L2Zf0As4w== Received: from smtp1.dismail.de ( [10.240.26.11]) by mx1.dismail.de (OpenSMTPD) with ESMTP id 6079591f; Tue, 4 Jun 2024 20:24:16 +0200 (CEST) Received: from smtp1.dismail.de (localhost [127.0.0.1]) by smtp1.dismail.de (OpenSMTPD) with ESMTP id 88b22ce9; Tue, 4 Jun 2024 20:24:16 +0200 (CEST) Received: by dismail.de (OpenSMTPD) with ESMTPSA id 369db3d8 (TLSv1.3:TLS_AES_256_GCM_SHA384:256:NO); Tue, 4 Jun 2024 20:24:16 +0200 (CEST) MIME-Version: 1.0 Date: Tue, 04 Jun 2024 18:24:15 +0000 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: jbranso@dismail.de Message-ID: <789fe3fd0ffc13369420d16ecc2f9ad2eafe1d42@dismail.de> TLS-Required: No Subject: Re: Autodafe is "production" ready To: esr@thyrsus.com Cc: guix-devel@gnu.org In-Reply-To: References: <9101aa92b331d50f3e70be1e676f7cafa1c1851f@dismail.de> Received-SPF: pass client-ip=78.46.223.134; envelope-from=jbranso@dismail.de; helo=mx1.dismail.de X-Spam_score_int: -27 X-Spam_score: -2.8 X-Spam_bar: -- X-Spam_report: (-2.8 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: guix-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+larch=yhetil.org@gnu.org Sender: guix-devel-bounces+larch=yhetil.org@gnu.org X-Migadu-Flow: FLOW_IN X-Migadu-Country: US X-Migadu-Spam-Score: -6.40 X-Spam-Score: -6.40 X-Migadu-Queue-Id: D89307C336 X-Migadu-Scanner: mx11.migadu.com X-TUID: yNCVyTPDkrXh June 2, 2024 at 5:39 PM, "Eric S. Raymond" wrote: >=20 >=20jbranso@dismail.de : >=20 >=20>=20 >=20> Hey Guix! > >=20 >=20>=20=20 >=20>=20 >=20> Have you heard about autodafe? I just did today. > >=20 >=20>=20=20 >=20>=20 >=20> So it looks like autodafe (1) converts autotools into=20 >=20>=20 >=20> simple makefiles. Quoting from it's hacker's guide (2):=C2=A0=C2= =A0 > >=20 >=20> "The proximate goal of this project is to eliminate autotools's > >=20 >=20> piles of intermediate products and scripts that create a=20 >=20>=20 >=20> jungle in which exploits like the xz crack of 2024 can hide. > >=20 >=20> =C2=A0The wider goal is to abolish the festering complexity sink= =20 >=20>=20 >=20> that autotools recipes have become."=C2=A0 Sounds like a fairly co= ol > >=20 >=20> goal eh? > >=20 >=20 > I should emphasize that the project was *directly* motivated by the xz >=20 >=20Trojan. That's what, in my mind, moved autotools from "chronic >=20 >=20irritation" to "Someone should kill it with fire, *now*, and I guess >=20 >=20that will be me". Took me eight weeks of balls-to-the-wall hacking. >=20 >=20The demand for some solution to supply-chain attacks through autotool= s >=20 >=20is urgent. I've been getting a particular earful about it from a >=20 >=20friend who is on the Gentoo packager lists; they want to be able to >=20 >=20throw out autotools *yesterday*. I have no doubt similar conversation= s >=20 >=20are going on within other packaging groups. >=20 >=20>=20 >=20> I know that guix has wanted to create a "guile based build=20 >=20>=20 >=20> system" to replace autotools (autodafe is written in=20 >=20>=20 >=20> python 3).=C2=A0 It sounds like Eric's work is moving to=20 >=20>=20 >=20> supplant and/or fix or repace autotools.=C2=A0 Eric is there > >=20 >=20> anything Guix can do for you to help you with your goal? > >=20 >=20> We do love our guile, so we will probably encourage you > >=20 >=20> to use some scheme code.=C2=A0 :) > >=20 >=20 > I looked into using Guile embedded in Make as an engine; >=20 >=20I'm a fan of Scheme myself. There are two reasons I didn't >=20 >=20go that route: >=20 >=201. Practical: Guile support is normally disablled in the packaged >=20 >=20versions of gmake on Debian, Ubuntu, Red Hat, etc. >=20 >=20That means that for my purpose of fielding a prompt replacement for >=20 >=20autotools, Guile might as well not be there at all. The demand for a >=20 >=20usable drop-in replacement for autotools won't wait for the number of >=20 >=20packaging cycles it would take to get all the distributions on board >=20 >=20with enabling embedded Guile-in-make and then deploying it. >=20 >=202. Architectural: I have a promary goal of making the build >=20 >=20flow in the replacement for autotools more auditable, with fewer >=20 >=20places an attacker can hide exploit components. >=20 >=20As much as I personally like Scheme, it would be a move in the wrong >=20 >=20direction from an audiability perspective even if it were >=20 >=20available. Too few people can read Scheme, or want to be able to. >=20 >=20What Scheme might have done if it were actually available I have >=20 >=20managed to cover with 661 lines of standalone Python 3. Under >=20 >=20the requirements, that is in every way a better solution, >=20 >=20even if not having an excuse to hack some Lisp makes me >=20 >=20a little wistful. >=20 >=20>=20 >=20> Richard do you have any advice for Eric in how to "fix or > >=20 >=20> replace" autotools? > >=20 >=20>=20=20 >=20>=20 >=20> Ludo, does guix need to do anything to get ready for some > >=20 >=20> software wanting to use autodafe=C2=A0 ?=C2=A0 Is there a way we= =20 >=20>=20 >=20> could use autodafe to help us get started on a guile based > >=20 >=20> build tool? > >=20 >=20 > You'll make a better decision about that if you understand >=20 >=20what I've actually done. >=20 >=20There are three tools in the autodafe suite. Two of them are one-time >=20 >=20transition aids; the third replaces autotools configure and is meant >=20 >=20to be checked into project repositories and shipped with them. >=20 >=20deconfig analyzes a code tree, removes guards abound POSIX features, >=20 >=20and reports a minimal set of guard symbols for non-POSIX >=20 >=20extensions. On a typical large old project, assuming POSIX reduces th= e >=20 >=20complexity of the configuration about an order of magnitude - you go >=20 >=20from hundreds of goard symbols to dozens. >=20 >=20Yes, this does mean you risk losing back-portability to big-iron >=20 >=20Unixes from the last century. One of the design premises of autodafe >=20 >=20is that in 2024 this is an acceptable trade for a huge >=20 >=20reduction in the complexity and obscurity of the build recipe. >=20 >=20makemake takes a Makefuke generated by autotools and tries to rurn it >=20 >=20into a standalone Makefile that can be read and modifies by humans - >=20 >=20removing unused boilerplate and rearranging parts so the control >=20 >=20variables of the build are easy to modify. >=20 >=20These are two transion aids. They aren't needed onece you have your >=20 >=20nuild conversion done. >=20 >=20autodafe configure replaces the autotools generated configure script, >=20 >=20but is much, *much* smaller and easier to read than those are. It >=20 >=20reads magic comments in your Makefile (which you add during the >=20 >=20conversion process - deconfig will typically generates most of them >=20 >=20for you) to know which testrs to do to discover the capabilities of >=20 >=20your host ststem. Here's what the example from the documentation >=20 >=20looks like: >=20 >=20# CHECK_ENABLE(ipv6) >=20 >=20# CHECK_DECL(sys/socket.h, netinet/in.h, netinet/tcp.h, TCP_KEEPCNT) >=20 >=20# CHECK_DECL(sys/socket.h, netinet/in.h, netinet/tcp.h, TCP_KEEPIDLE) >=20 >=20# CHECK_DECL(sys/socket.h, netinet/in.h, netinet/tcp.h, TCP_KEEPINTVL= ) >=20 >=20# CHECK_HAVE(getopt.h, getopt_long) >=20 >=20# CHECK_HAVE(_GNU_SOURCE, unistd.h, getresuid) >=20 >=20# CHECK_LIB(m) REQUIRED >=20 >=20# CHECK_LIB(nsl) >=20 >=20# CHECK_LIB(resolv) >=20 >=20# CHECK_LIB(rt) >=20 >=20# CHECK_HAVE(linux/if/tun.h) >=20 >=20# CHECK_HAVE(linux/ipv6.h) >=20 >=20# CHECK_HAVE(_GNU_SOURCE, string.h, memrchr) >=20 >=20# CHECK_HAVE(_GNU_SOURCE, unistd.h, setresuid) >=20 >=20# CHECK_SIZEOF(int) >=20 >=20# CHECK_SIZEOF(int *) >=20 >=20# CHECK_SIZEOF(long) >=20 >=20# CHECK_SIZEOF(long long) >=20 >=20# CHECK_SIZEOF(sys/types.h, off_t) >=20 >=20# CHECK_SIZEOF(pthread.h, pthread_t) >=20 >=20# CHECK_SIZEOF(stddef.h, size_t) >=20 >=20The effect is that the Makefile becomes the single point >=20 >=20of truth for the build, repl;acing configure.ac. >=20 >=20The entire transition process is described in detail here: >=20 >=20https://gitlab.com/esr/autodafe/-/blob/master/configure.adoc?ref_type= =3Dheads >=20 >=20>=20 >=20> Thanks, > >=20 >=20>=20=20 >=20>=20 >=20> Joshua > >=20 >=20>=20=20 >=20>=20 >=20>=20=20 >=20>=20 >=20> 1)=C2=A0https://www.phoronix.com/news/Autodafe-1.0-Released=20 >=20>=20 >=20>=20=20 >=20>=20 >=20> 2)=C2=A0https://gitlab.com/esr/autodafe/-/blob/master/hacking.adoc > >=20 >=20 > --=20 >=20 >=20 Eric http://www.catb.org/~es= r/%22%3EEric S. Raymond > Eric thanks for the super quick response! I really enjoyed reading your previous email. Thanks for explaining the decisions that you made when you wrote autodafe. I suppose autodafe doesn't have a logo yet.=20=20 If=20there are any good guix artists out there, then you could probably help Eric by creating a logo for autodafe! Eric would you mind if I=20 took=20your previous email and turn it into a blog post on https://gnucode.me ? Thanks, Joshua P.S. The Cathedral and the Bazaar was a really fun read for me!