From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp12.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms9.migadu.com with LMTPS id KOLzKRcxBmSrZwEASxT56A (envelope-from ) for ; Mon, 06 Mar 2023 19:29:43 +0100 Received: from aspmx1.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp12.migadu.com with LMTPS id 2H7jKRcxBmSjKAAAauVa8A (envelope-from ) for ; Mon, 06 Mar 2023 19:29:43 +0100 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 874B829570 for ; Mon, 6 Mar 2023 19:29:43 +0100 (CET) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pZFaF-0005KH-JP; Mon, 06 Mar 2023 13:29:15 -0500 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 1pZFaE-0005Iq-4a for guix-devel@gnu.org; Mon, 06 Mar 2023 13:29:14 -0500 Received: from mailout2.hostsharing.net ([83.223.78.233]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pZFaB-0000si-NO for guix-devel@gnu.org; Mon, 06 Mar 2023 13:29:13 -0500 Received: from h20.hostsharing.net (h20.hostsharing.net [IPv6:2a01:37:1000::53df:5fec:0]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "*.hostsharing.net", Issuer "RapidSSL Global TLS RSA4096 SHA256 2022 CA1" (verified OK)) by mailout2.hostsharing.net (Postfix) with ESMTPS id 6D47510089053 for ; Mon, 6 Mar 2023 19:29:06 +0100 (CET) Received: from anna.fritz.box (unknown [195.52.23.87]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by h20.hostsharing.net (Postfix) with ESMTPSA id 40E5396DC8 for ; Mon, 6 Mar 2023 19:29:06 +0100 (CET) Message-ID: Subject: Re: Guix, Nix flakes, and object capabilities From: Tobias Platen To: guix-devel@gnu.org Date: Mon, 06 Mar 2023 19:29:05 +0100 In-Reply-To: <871qm986fp.fsf@terracrypt.net> References: <871qm986fp.fsf@terracrypt.net> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.46.4-1 MIME-Version: 1.0 Received-SPF: none client-ip=83.223.78.233; envelope-from=guix@platen-software.de; helo=mailout2.hostsharing.net X-Spam_score_int: -25 X-Spam_score: -2.6 X-Spam_bar: -- X-Spam_report: (-2.6 / 5.0 requ) BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_NONE=0.001 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-TUID: Fx4H4jJQaXQS I recently saw that the SlimeVR server[1] has nix flakes, is there a way to convert this for guix?=20 On Tue, 2023-02-28 at 22:13 -0500, Jonathan Frederickson wrote: > Hello Guix, >=20 > I recently had a discussion in #spritely on Libera.Chat about Guix > and > Nix, and in particular a (relatively) new feature of Nix called > flakes > that Guix doesn't currently have an analogue for. >=20 > I've been a Guix user for a while, but I've only recently started > looking at using Guix for development via ~guix shell~ as in this > blog > post by David Thompson[0]. The Guile port of Spritely has been using > it, > so I've been trying it out for one of my own projects as a result. > And > it seems pretty nice; you're using the same package definitions you > might use when contributing a package upstream to Guix, which feels > pretty natural as someone already pretty familiar with Guix as a > user. >=20 > However, I noticed something about the resulting dependency graph > that > feels somewhat unsatisfying. When you define a package, the > dependencies you provide in e.g. ~inputs~ are references to > packages. And the way you get those is, of course, by importing > modules containing those packages. >=20 > But the package you end up with each time you do that... depends on > which revision of Guix you're running when you run ~guix shell~! So > if > I point someone to a project with a ~guix.scm~ file, they might not > be > able to use it if their Guix revision is too old. (Or too new, if > packages have been renamed or removed.) More generally, it means that > they do not end up with the same dependency graph that I do. This > makes troubleshooting potentially tricky, because if something breaks > you have to check the resulting profile to see which versions of your > package's dependencies (and transitive dependencies) are actually > installed. >=20 > For those who haven't used Nix, it has a solution to this called > flakes. Flakes let you specify git repositories explicitly as inputs > for > your project[1]. (It also maintains a flake.lock file so you can lock > to > a specific revision automatically while still using a named branch in > your inputs directly, but I believe you could in theory refer to a > specific rev in your inputs.) Effectively, the channels you're using > for > dependencies are specified by the project you're building, not > whatever > happens to be configured on your local machine. >=20 > I think something like this would be useful for Guix for many of the > same reasons it's useful in Nix. But there's a bit of a security > conundrum here. Loading Guix package definitions involves code > execution, which as far as I can tell isn't currently sandboxed at > all! > And that's a problem. When you load package definitions from a > channel > that you've configured on your system, you've explicitly trusted that > channel's maintainers. But with a flake-like system... even if you > might > be okay depending on someone else's code, that doesn't necessarily > mean > you fully trust them. You might ultimately choose to sandbox the > resulting binary, but that's moot if you can't fetch its dependencies > without running arbitrary code with all of your user's authority. >=20 > I think there is a solution to this, though. Right now when you > evaluate Guix package definitions, you're basically running arbitrary > Guile code. This of course can do anything you can do. But it doesn't > have to! If you're familiar with Christine Lemmer-Webber's work on > Spritely, you'll probably know what I'm getting at here: I think > using > object capabilities[2] would fix this. I recommend reading the linked > blog post for a good explainer on what object capabilities are, as I > won't do it justice here, but to perhaps oversimplify: code in a > capability system only has access to the things you give it, and no > more. It's like lexical scope, but taken very seriously. >=20 > If you think about what a typical package definition needs to be able > to > do to your system directly, I think it's not actually that much? My > (admittedly basic, possibly flawed) understanding of how Guix works > is > that most of the heavy lifting is done by ~guix-daemon~, which itself > is > pretty heavily sandboxed, and that most of what the ~guix~ > subcommands > are doing is building derivations which instruct ~guix-daemon~ to > perform build actions. So while you're building these derivations, > unless I'm misunderstanding: >=20 > - You don't need network access > - You don't need (much) filesystem access >=20 > I think object capabilities provide a good answer to this > problem. Rather than evaluating package definitions from a channel as > you would normally run Guile code, evaluate them in a restricted > environment that only has access to things you've passed in. In > JavaScript, this might look like this (taken from this blog post[3] > about the event-stream incident): >=20 > #+BEGIN_SRC javascript > =C2=A0 const addHeader =3D require('./addHeader', {fs, https}); > #+END_SRC >=20 > This way, you could import modules including packages you'd like to > use as dependencies, and if you don't pass those modules access to > the > rest of your filesystem they won't have it, and can't do things like > cryptolocker your home directory. (At least not until you run some > software installed from it, but that's a separate issue!) >=20 > Of course, easier said than done. Guile's import system doesn't work > like this. But I believe the Spritely project has a module system > like > this planned for Guile, which could enable things like this. I'm sure > such a thing would be a lot of work, but I hope this plants a seed in > your minds as to what might be possible. >=20 > [0] https://dthompson.us/guix-for-development.html > [1] https://nixos.wiki/wiki/Flakes#Introduction > [2] http://habitatchronicles.com/2017/05/what-are-capabilities/ > [3] > https://medium.com/agoric/pola-would-have-prevented-the-event-stream-inci= dent-45653ecbda99 >=20