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 iAIoIKS1AWR+IwAAbAwnHQ (envelope-from ) for ; Fri, 03 Mar 2023 09:53:56 +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 ACo5H6S1AWR5UQAAG6o9tA (envelope-from ) for ; Fri, 03 Mar 2023 09:53:56 +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 29FA7F8F6 for ; Fri, 3 Mar 2023 09:53:56 +0100 (CET) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pY19L-0008KL-2s; Fri, 03 Mar 2023 03:52:23 -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 1pY19A-0007zb-MF for guix-devel@gnu.org; Fri, 03 Mar 2023 03:52:14 -0500 Received: from mail-wr1-x42d.google.com ([2a00:1450:4864:20::42d]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1pY196-0004fO-O2 for guix-devel@gnu.org; Fri, 03 Mar 2023 03:52:11 -0500 Received: by mail-wr1-x42d.google.com with SMTP id h14so1517955wru.4 for ; Fri, 03 Mar 2023 00:52:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; t=1677833527; h=content-transfer-encoding:mime-version:message-id:date:references :in-reply-to:subject:cc:to:from:from:to:cc:subject:date:message-id :reply-to; bh=gtM03dVD+ctZlnzriXATEZsZJ/zICdVGhpjE8/BewtQ=; b=NkkVbW+4M0kHaqjkxY6zJd72s65dZokp3tnnWhRLUmhMxhVkD+RSj+KxUa6xw33F+O hH+qmqu51V8gggnEFbHSTGOhffVvuJN10xlxhX/NF4CcM94+kjo/qcTOHloBkJuus8n7 XEoNewt6ern5Zknyj/WUulXUCUC0ic03zwlZY6uizcmsonWy74ToS4lNwwlTiHhnSY1K vtQ+fMVrMq7m7xj8CuMnB3CTbTRm7THcxFi6HhK9BRVyeTt4Lj0XSJ08tIA9CKUOQs4u R9TIjFwRIcA94YiNe2zkMkmGA1lX8toNNppamtIUvTRCljoLBs44wwEIRrwzaGaqXDnM KALg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1677833527; h=content-transfer-encoding:mime-version:message-id:date:references :in-reply-to:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=gtM03dVD+ctZlnzriXATEZsZJ/zICdVGhpjE8/BewtQ=; b=Fcmz2ONn6Rd+qwcT0x5Zchp0heUFovjaZn3v94VEMBN5tMr5Gzcr4QcAbwOEvhPXju /r+Aoem85nBDTRXUPQnhWclCLYwrZLWkQ1arwX59m2juzwK2aXRyg5fp4xfQJZB3ciKa inZqWLRGWVJj7EHNjiIECYv/jfiL35iLPZj0s4V8bzRMl4HvGf6cqbs6xb5bjrhfeCMH WZLnfVagso/GYSii4ZDrEeVrSEgUrJlsGJi+SqAUyH444RxxXIfT1le8ax7QKHmuz4sa CNGNwyS+lt8yV1NElWl9aUllZ8YnDaqgQUTz++v5yD/vwYc8OfrnLMJjHhfhiUsKfu5j VdRQ== X-Gm-Message-State: AO0yUKXtSeFcfw4OWbfcWMsZk6oTGB6fPb3V2ZjvEWJzfOL+kZMI6vfB wK1O7gfGgTDTEbvW5JuqO0o= X-Google-Smtp-Source: AK7set/4cJPoLotLCmMcBJuatjHevHjhPbajTjvlVsBiJz8fhZSKE1NkHEKrnpbvPvCUJ6ZzUsS9Lw== X-Received: by 2002:a5d:4e87:0:b0:2cb:3b68:3c1d with SMTP id e7-20020a5d4e87000000b002cb3b683c1dmr734345wru.4.1677833526649; Fri, 03 Mar 2023 00:52:06 -0800 (PST) Received: from lili ([2a01:e0a:59b:9120:65d2:2476:f637:db1e]) by smtp.gmail.com with ESMTPSA id u16-20020a5d5150000000b002c559843748sm1592174wrt.10.2023.03.03.00.52.05 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 03 Mar 2023 00:52:06 -0800 (PST) From: Simon Tournier To: Jonathan Frederickson , guix-devel@gnu.org, Josselin Poiret Cc: christine@spritely.institute Subject: Re: Guix, Nix flakes, and object capabilities In-Reply-To: <871qm986fp.fsf@terracrypt.net> References: <871qm986fp.fsf@terracrypt.net> Date: Fri, 03 Mar 2023 02:12:48 +0100 Message-ID: <864jr2eiy7.fsf@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Received-SPF: pass client-ip=2a00:1450:4864:20::42d; envelope-from=zimon.toutoune@gmail.com; helo=mail-wr1-x42d.google.com X-Spam_score_int: -5 X-Spam_score: -0.6 X-Spam_bar: / X-Spam_report: (-0.6 / 5.0 requ) BAYES_00=-1.9, DATE_IN_PAST_06_12=1.543, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=no 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=1677833636; a=rsa-sha256; cv=none; b=Oxxz/tz099/3IbJE7fnXFZgkdaw7smZdPbhlEdTnrocpgJosNNzFpglHvi3BREJpAt3Rgw SQQFb925QsPFggs/zo8FyKEHQLj7hN4pr2PL488y3hHLh5QWob+/ST76gT68Y8lPxP37xR XXefYlSqRWCXWwOeDF1dMnWJBJ8jU/8yjbDlFkDUB2a9whU0BpWyjljc2kflzbC7k+ET0G gd3P4dI39aZ2qDxDEslAiYVEoqnRffS1nfCg2/yF0MvUFrUGkj08ZyMhlndYyPFaP7ITGx mCFNAbAsMphSJ89o8AKMlT+PrCbgxTlEnfN5otRmn577uvTl/rBDsm5V0mFOfg== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=NkkVbW+4; 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=pass (policy=none) header.from=gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1677833636; 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=gtM03dVD+ctZlnzriXATEZsZJ/zICdVGhpjE8/BewtQ=; b=dp1622Wo1QCOhT0kWsgMP+4/+OilAs+mT/T4F3jb06Zewg73/xmLtGKFHWR738pf0186DG PQDYiBjQtnXTREUeF9ByFJ6SlL6x+YNGJ+GCJAPCauj9W4/wZ6NUML19HJVz54RHmyRZ+U yLgoE8oOpGd1qEhXZno/30y4m0R66DXwvFpi04oivmGSEpkrNdidgmv7x1hN6VpQbxutbM LVCx4EsNKLEzaCdmK0DGiGLjCTBTWanWQwQk+3eDyThf6yaZH3/RIFjMhnB4YE9zlFsrQ7 8+aojEh4/HnI4T9ZtcUfa3oSA7kDVO9m1PzDPUrdGLBpTPPaMT7aUhlKlG9kIg== X-Migadu-Scanner: scn1.migadu.com X-Migadu-Spam-Score: -4.92 X-Spam-Score: -4.92 X-Migadu-Queue-Id: 29FA7F8F6 Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=NkkVbW+4; 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=pass (policy=none) header.from=gmail.com X-TUID: Ganjcg8dqUeY Hi, On Tue, 28 Feb 2023 at 22:13, Jonathan Frederickson wrote: > 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. Well, even after several readings of Nix documentation about Flakes, I am still not sure to understand how the concept would apply for Guix. :-) > 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. That=E2=80=99s why =E2=80=9Cguix time-machine=E2=80=9D is really cool! :-) Basically, I have my current Guix revision and I run =E2=80=9Cguix pull=E2= =80=9D every=E2=80=A6 indecent duration. However, I run many many =E2=80=9Cguix time-machine=E2= =80=9D, well each time I am working on a project, so daily. Even, I only run =E2=80=9Cguix pull=E2=80=9D against the default Savannah G= uix channel. Then, depending on the projects, they can require the channels guix-science, guix-cran or others. The graph I need for a specific project is controlled by the file channels.scm and I run, from the directory of that project: guix time-machine -C channels.scm -- shell This channels.scm file can be part of the Git repository of that project. And sometimes, I have several files for testing revision variants. On the top of that, for some cases, I have specific packages for one project. Therefore, I have a folder, say guix/extra containing one or more files which define new or variant packages. Somehow, my typical line looks like: guix time-machine -C state-1.scm -- shell -L guix/extra -m manifest-A.scm guix time-machine -C state-2.scm -- shell -L guix/extra -f guix-B.scm etc. (Although, I should admit that I barely use the option -f. ;-)) > 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. >From my understanding, what I describe above seems providing these Nix flakes, no? Or could you explain on a concrete example what you can do with Nix flakes that you cannot do with Guix? Well, UI and how easy to use can also be considered part of =E2=80=9Ccan do=E2=80=9D. :-) I mean, maybe the current Guix way could be improved on the light of the Nix flakes. > 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 am not sure to understand this sandbox part. For instance, guix time-machine -C channels.scm -- shell --container provides you an isolated environment where you can run untrusted packages coming from untrusted channels. Even, the option =E2=80=99-F, --emulate-fhs=E2=80=99 combined with the option =E2=80=99-C, --container=E2= =80=99 allow to run untrusted binaries coming from elsewhere (not built by Guix); you need some care with the options -E and --expose though. Do you think something is missing? What could we improve in this area? Do you mean evaluate the Guile files provided by the untrusted channels in a sandbox? > 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. Hum, I should have missed some details =E2=80=93 since I am not familiar wi= th =E2=80=9Cobject capability=E2=80=9D. Thanks for the pointer. Is it another way to view =E2=80=9Ccontract=E2=80=9D [a]? a: > 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 >From my understanding, Guix and guix-daemon already works that way, no? Do you mean evaluate the user-side Guile part of =E2=80=9Cguix foo -f file.= scm=E2=80=9D inside a sandboxed environment? On Wed, 01 Mar 2023 at 10:56, Josselin Poiret wrote: > Now my personal opinion: you should note that it's a very bad idea in > general to rely on specific versions of dependencies. Downstream > consumers of your software should be able to use it with up-to-date > dependencies, because they can provide security benefits, bugfixes, > etc. Having version pinning like in go leads to dependency hell, and > should be frowned upon. Well, it depends on what you want, IMHO. :-) Sometimes, you want to reproduce the exact same computational environment, including all the defects. >From my personal opinion, channels.scm and manifests.scm, probably considering also transformations, these features allow =E2=80=93 putting mo= re than less efforts =E2=80=93 to achieve a fine control with flexibility. Cheers, simon