From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Richard Stallman Newsgroups: gmane.emacs.devel Subject: Re: [PROPOSAL] Builder, a build system integration for Emacs Date: Sun, 28 May 2023 17:48:38 -0400 Message-ID: References: <95980ffc-86e7-ad54-4a20-539d8c6ea5d0@mailo.com> <3f68f4bc-d426-0bcc-1329-674c12b29386@mailo.com> <76e12f7c-335f-476b-ffb3-fd8e8e4ab5d0@mailo.com> <87pm6rx4ea.fsf@yahoo.com> <87wn0ytefw.fsf@gmail.com> <83h6s0n95y.fsf@gnu.org> <83edn4myz4.fsf@gnu.org> <83a5xsmuc0.fsf@gnu.org> <3a315ddd3a25a56c8d6a@heytings.org> Reply-To: rms@gnu.org Content-Type: text/plain; charset=Utf-8 Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="39926"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-devel@gnu.org To: Gregory Heytings Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sun May 28 23:49:16 2023 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1q3OGK-000ACF-BY for ged-emacs-devel@m.gmane-mx.org; Sun, 28 May 2023 23:49:16 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1q3OFp-0006e8-6f; Sun, 28 May 2023 17:48:45 -0400 Original-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 1q3OFj-0006an-8C for emacs-devel@gnu.org; Sun, 28 May 2023 17:48:39 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1q3OFj-00014H-0H; Sun, 28 May 2023 17:48:39 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=Date:References:Subject:In-Reply-To:To:From: mime-version; bh=ezmdk9C0yL27nEVzioEj+o/M+LgEX477MRWl5GEi9ho=; b=Sw0ZVlZAnsCS /gkm/PbiaZZcg9ZbZeIrZCUd8CIJILcgJLs4sNxpyN5R3bwRNwzIFTkIbKlSKIBtLtjjQTUBQhgYR KTNH4390muxli8J5TvqHJ+ZIYnwCcLWUQy/oWBV7F0yWn8iRzjtRkS8PU2223eaYPM4I/4Ab2M+vj vUv/K0r0vvhjNyNEhAYd3uSGtm6JaNgbcFGYn4/McrwN9dE9e29Yof5NHk4u4KtSpRAdNdTIBjZWy 9EJl1g1OwFsdgjIN/AoJ2p+BhmTQbEBZE6CwbPddacXRoqxK4NREB8HLR6z1OurHwBH9EPoQPx1pf PmzGjPNmU/a7Y0i4Ygq/ew==; Original-Received: from rms by fencepost.gnu.org with local (Exim 4.90_1) (envelope-from ) id 1q3OFi-0000hj-Jp; Sun, 28 May 2023 17:48:38 -0400 In-Reply-To: <3a315ddd3a25a56c8d6a@heytings.org> (message from Gregory Heytings on Sat, 27 May 2023 00:26:13 +0000) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.devel:306380 Archived-At: [[[ To any NSA and FBI agents reading my email: please consider ]]] [[[ whether defending the US Constitution against all enemies, ]]] [[[ foreign or domestic, requires you to follow Snowden's example. ]]] You've told me a lot of pertinent info about how Cargo works. Thank you for going to that effort. I think that due to your help I now understand the issue enough to reach tentative conclusions. The conclusions say that we have a problem. The reasoning is explained below. > > Where does cargo get the list of libraries to consider using? > > > The dependencies of a Rust program/library are specified (manually) by the > author of that program/library, in a (structured) text file. The source > code of the libraries on which the program/library depends are downloaded > (by Cargo) from the crates.io registry, and kept in a local cache > (CARGO_HOME, by default $HOME/.cargo). I expected it was something like this, but I didn't know. Now I know. Thanks. > No, some libraries/programs in the crates.io registry are non-free I was worried about that. So if you build a Rust program Foo, its dependencies will cause some libraries to be loaded from crates.io, and their dependencies will cause other libraries to be loaded from crates.io, and so on recursively. Is that right? And if any of those libraries specifies a nonfree dependency, that nonfree code will get compiled into the program Foo -- right? If so, that puts freedom at risk. It means that any time you build a Rust program that you have not thoroughly studied, you don't know whether it will incorporate nonfree software. Have I made any mistake in this reasoning? If it is correct so far, I think that implies that the standard version of Cargo is unacceptable in a free system. With the standard version of Cargo, all the packages in crates.io are virtually include in the system distro. If crates.io contains any nonfree package, then any system distro that includes Cargo virtually includes that nonfree package, so it is not a free distro. Our distros must be free -- so I think it follows that our distros cannot include unmodified Cargo. Have I made any mistake in this reasoning? > Since a registry is just a git repository hosted > online or locally, you can fork the crates.io repository, and then you > are free to modify it as you see fit, such as filtering out unsuitable > libraries (e.g., those who transitively depend on any non-libre > libraries). Maybe we need to make such a fork of crates.io, delete all nonfree packages, and modify our version of Cargo to use that. How do packages get approved for inclusion in crates.io? There are both freedom issues and security issues. I think we should move this to gnu-prog-disc. -- Dr Richard Stallman (https://stallman.org) Chief GNUisance of the GNU Project (https://gnu.org) Founder, Free Software Foundation (https://fsf.org) Internet Hall-of-Famer (https://internethalloffame.org)