From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp10.migadu.com ([2001:41d0:2:bcc0::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms5.migadu.com with LMTPS id 0NXGHrPO/mNp7AAAbAwnHQ (envelope-from ) for ; Wed, 01 Mar 2023 05:04:03 +0100 Received: from aspmx1.migadu.com ([2001:41d0:2:bcc0::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp10.migadu.com with LMTPS id MMhTHbPO/mPpaQAAG6o9tA (envelope-from ) for ; Wed, 01 Mar 2023 05:04:03 +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 2589439DA3 for ; Wed, 1 Mar 2023 05:04:03 +0100 (CET) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pXDgd-0005nP-Gn; Tue, 28 Feb 2023 23:03:27 -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 1pXDgb-0005n4-HG for guix-devel@gnu.org; Tue, 28 Feb 2023 23:03:25 -0500 Received: from wout5-smtp.messagingengine.com ([64.147.123.21]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pXDgZ-0001qF-3i for guix-devel@gnu.org; Tue, 28 Feb 2023 23:03:25 -0500 Received: from compute2.internal (compute2.nyi.internal [10.202.2.46]) by mailout.west.internal (Postfix) with ESMTP id 492F93200935; Tue, 28 Feb 2023 23:03:19 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute2.internal (MEProxy); Tue, 28 Feb 2023 23:03:19 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=terracrypt.net; h=cc:cc:content-type:date:date:from:from:in-reply-to:message-id :mime-version:reply-to:sender:subject:subject:to:to; s=fm2; t= 1677643398; x=1677729798; bh=XCQmXGjFw5GLlMZB9cbT+h4iKc9h0Aa0uDY MvQwwC8E=; b=XzaGfHkyobatqnKvn9hK7RLCifsFt0HvH+Icz7m7WaM2vm7PbBn tnFrui6fqMgLmBRDwNP0vb9B7J9GkOBiZTxBVKc8uVIL0gS7HOg/nfYDkbuAmisz T5QpzT/5YpjdCNl2Bqv9Ea7byRcPnAb64eVNmpLEClf6L1CGlvNCa0Rww5DFHjKj /3PmwjGOD9pEaGZcRr1MuWCyXkeJc8TfjjRBxdEretWnKZxFm/5ZBwvWy5lUXuEZ 6ZgQof7RS1B4CJ7EJTJcEb66wPK0SgrqcpxBf3JQgwVPJTq6tzWzsxz23eWbIdhA SyYFCI5JQ1Nvxs6fYcD4Ezoh8cU5fWr3Ngg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-type:date:date:feedback-id :feedback-id:from:from:in-reply-to:message-id:mime-version :reply-to:sender:subject:subject:to:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm1; t=1677643398; x= 1677729798; bh=XCQmXGjFw5GLlMZB9cbT+h4iKc9h0Aa0uDYMvQwwC8E=; b=d mKM3/oaltYcLsruWyjA73C4UQIXLWKrbMMla5s9v81/WmTklDNI1SQ3OzmufnIzs 4g1XDiVwjIamcOJNWYGt7TOS7t+BulmHk2GEl00DFnF3o1ZJY6WWKAAM6r7yeeXm mvVvPd/CYN/aBCHEgZfGzjrOD15T+w2xH1Bhsikt/+rrmwTBQub2whqgTjqFdEHS ObsPkmn2N6/auRPUnWErKfXQHp3ZgvWCi03OygTu+N5jFK0zhuggN9woXh0fgqG4 PupBjXbL1H0wlgq+8z4KF/xBVJ8Pb75xEjHFc5K8jiIvc5QaMbes6fQMieqhAaLy RokZXzLIzSG98PFwrLUXQ== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvhedrudelgedgieduucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpegfhffvvefufffkgggtsehttdertd dtredtnecuhfhrohhmpeflohhnrghthhgrnhcuhfhrvgguvghrihgtkhhsohhnuceojhho nhgrthhhrghnsehtvghrrhgrtghrhihpthdrnhgvtheqnecuggftrfgrthhtvghrnhepvd dtvdduieegkedvjeejveffleeiudekleeuheffvdeludekffehuddtkeetffehnecuffho mhgrihhnpeguthhhohhmphhsohhnrdhushdpnhhigihoshdrfihikhhipdhhrggsihhtrg httghhrhhonhhitghlvghsrdgtohhmpdhmvgguihhumhdrtghomhenucevlhhushhtvghr ufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehjohhnrghthhgrnhesthgvrh hrrggtrhihphhtrdhnvght X-ME-Proxy: Feedback-ID: if4194509:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Tue, 28 Feb 2023 23:03:18 -0500 (EST) User-agent: mu4e 1.8.13; emacs 28.2 From: Jonathan Frederickson To: guix-devel@gnu.org Cc: christine@spritely.institute Subject: Guix, Nix flakes, and object capabilities Date: Tue, 28 Feb 2023 22:13:24 -0500 Message-ID: <871qm986fp.fsf@terracrypt.net> MIME-Version: 1.0 Content-Type: text/plain Received-SPF: pass client-ip=64.147.123.21; envelope-from=jonathan@terracrypt.net; helo=wout5-smtp.messagingengine.com 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_PASS=-0.001, SPF_PASS=-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-Migadu-Country: US X-Migadu-Flow: FLOW_IN ARC-Seal: i=1; s=key1; d=yhetil.org; t=1677643443; a=rsa-sha256; cv=none; b=JrVmquhN/oQ9d+59Tff2ckBiUteFHB/waliccVtnJkynl7gsD1G7ugopqFSsLdKEar3xdd KfCGIliscQTTaojm16YF6dnBCn+fuh9gjGiW85wOblrEqewFkxBRxgn6dDIgzVnyMQMezc EV4ACcPFM3jJKlYwDiiiJsD+24jHtqFWOG3L8GGRWK/tk+vD8aZo5x2FevMrYeZCrrG//Y h9/R3vTKYbL1MzCMzWprUAUBJq6LzFb1bchoR0WnDauJ8y1UvGxQZ91tzz5KeTRNrvn65D QyjHwWVq2w/7g71mOIkB+3a2DFi5WdBAE22CMpukwBHYbYXCqCFgllSm6Nk+6g== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=fail ("headers rsa verify failed") header.d=terracrypt.net header.s=fm2 header.b=XzaGfHky; dkim=fail ("headers rsa verify failed") header.d=messagingengine.com header.s=fm1 header.b="d mKM3/o"; 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"; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1677643443; 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:list-id:list-help:list-unsubscribe: list-subscribe:list-post:dkim-signature; bh=XCQmXGjFw5GLlMZB9cbT+h4iKc9h0Aa0uDYMvQwwC8E=; b=gA6qiA2uetyvgyNJ0Vm3TNbe66rOdBcxdrR14VIOlhjB1luNyFVK9QL9JdhqvtqkD3xb3V MYjL+THHTpxsUvH5Dr3rD6o5gLzSR+xVIYuW42lth387N/lXxrpWOUP0QBPNydmhatciOA NKfrkGMYPbYUaaA2EwAENEC86K87LLCQ/P7d0lqCd4qWL8rlBpdgKsy2f6HD5SYv0+RznO WuwxzCos3U9FX5agtKxdtjv1TWhgWU6P0ijku/rybtP9JvqmJ9t2DkRdxHLju5nRmC1que m3/F8wO3dkfUiMoAi5cD4mtVfVGH9sLj2Q/DpEg79mX5nfPYcl6uO0U7xojijQ== X-Migadu-Scanner: scn1.migadu.com X-Migadu-Spam-Score: -0.59 X-Spam-Score: -0.59 X-Migadu-Queue-Id: 2589439DA3 Authentication-Results: aspmx1.migadu.com; dkim=fail ("headers rsa verify failed") header.d=terracrypt.net header.s=fm2 header.b=XzaGfHky; dkim=fail ("headers rsa verify failed") header.d=messagingengine.com header.s=fm1 header.b="d mKM3/o"; 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"; dmarc=none X-TUID: An1nUsoB5RKF Hello Guix, 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. 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. 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. 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. 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. 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. 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. 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: - You don't need network access - You don't need (much) filesystem access 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): #+BEGIN_SRC javascript const addHeader = require('./addHeader', {fs, https}); #+END_SRC 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!) 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. [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-incident-45653ecbda99 -- Jonathan Frederickson