From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: ludo@gnu.org (Ludovic =?utf-8?Q?Court=C3=A8s?=) Newsgroups: gmane.lisp.guile.devel,gmane.comp.gnu.guix.devel Subject: Re: "guix potluck", a moveable feast Date: Sun, 02 Apr 2017 01:05:15 +0200 Message-ID: <87o9wfenkk.fsf@gnu.org> References: <87d1cxh5f0.fsf@igalia.com> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Trace: blaine.gmane.org 1491087933 29788 195.159.176.226 (1 Apr 2017 23:05:33 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sat, 1 Apr 2017 23:05:33 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1 (gnu/linux) Cc: guix-devel@gnu.org, guile-devel@gnu.org To: Andy Wingo Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Sun Apr 02 01:05:28 2017 Return-path: Envelope-to: guile-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cuS5I-00072a-7u for guile-devel@m.gmane.org; Sun, 02 Apr 2017 01:05:28 +0200 Original-Received: from localhost ([::1]:53069 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cuS5L-0004Xu-1k for guile-devel@m.gmane.org; Sat, 01 Apr 2017 19:05:31 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:35318) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cuS5C-0004Xc-7b for guile-devel@gnu.org; Sat, 01 Apr 2017 19:05:23 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cuS59-0005e2-21 for guile-devel@gnu.org; Sat, 01 Apr 2017 19:05:22 -0400 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:52580) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cuS58-0005dq-VD; Sat, 01 Apr 2017 19:05:18 -0400 Original-Received: from reverse-83.fdn.fr ([80.67.176.83]:59958 helo=ribbon) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1cuS58-0002t8-9Y; Sat, 01 Apr 2017 19:05:18 -0400 X-URL: http://www.fdn.fr/~lcourtes/ X-Revolutionary-Date: 13 Germinal an 225 de la =?utf-8?Q?R=C3=A9volution?= X-PGP-Key-ID: 0x090B11993D9AEBB5 X-PGP-Key: http://www.fdn.fr/~lcourtes/ludovic.asc X-PGP-Fingerprint: 3CE4 6455 8A84 FDC6 9DB4 0CFB 090B 1199 3D9A EBB5 X-OS: x86_64-unknown-linux-gnu In-Reply-To: <87d1cxh5f0.fsf@igalia.com> (Andy Wingo's message of "Fri, 31 Mar 2017 16:44:35 +0200") X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Developers list for Guile, the GNU extensibility library" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Original-Sender: "guile-devel" Xref: news.gmane.org gmane.lisp.guile.devel:19085 gmane.comp.gnu.guix.devel:36734 Archived-At: Hello! Andy Wingo skribis: > As an interlude, here is how a user would enter an environment that has > a potluck package "foo" using Guix (using a pack is also possible). We > start with setup steps: > > (1) Install Guix as a user. (This needs to be easier.) > (2) guix channel add potluck https://gitlab.com/potluck/potluck master > (3) guix channel enable potluck So users would see the union of independent potluck =E2=80=9Cdishes=E2=80= =9D, right? > A packaging language for stability and security > ----------------------------------------------- > > So how do packages enter the potluck channel? Good question, fictional > reader! This is the tricky bit. There are some concerns here: > > (1) The Guix API is not stable and has no plans to be stable. This > works great for now because all packages are in one atomic > repository and people work on making the whole thing make sense > together. One of the goals of the potluck effort is to > decentralize things a bit, so we have an impedance mismatch > between potluck packages and Guix itself. > > (2) Potluck package definitions will live in many different git > repositories across the internet, and anyone should be able to > make a potluck package. Some potluck package authors will be > malicious. They could: > > 1. Damage the server that manages the potluck channel > > 2. Damage the users that run Guix commands with the potluck > channel enabled > > 3. Damage the users that install potluck packages > > I think we need to forget about 3, for now at least. (Flatpak > solves this, more or less; Guix has ongoing work to do here I > think.) > > Both of these large issues point to the need for careful design of the > language that potluck packages are written in. The language that Guix > packages are written in is inappropriate because of (1). In particular > we should not depend on which module a package comes from, and what > identifier binds any given package. For (2), packages are currently > written in full Scheme, staged between the Guix command itself and the > sandbox that runs inside guix-daemon. Full Scheme might be OK in the > daemon but it's not OK in the Guix command itself. > > Concretely I would propose that the language that potluck files are > written in is like this: > > (1) It's code, not inert data. > > (2) It's a subset of Scheme, like core Guix packages. > > (3) The general structure looks like this: > > (import-guix-packages ((guile "guile@2.0") > (glibc "glibc"))) > (import-potluck-packages ((foo "foo"))) > > (define bar > (package > (name "guile-bar") > (version "1.0.0") > (build-system gnu-build-system) > (inputs `(("guile" ,guile)) > ....))) That makes sense to me. The sandbox would have transitive access to a lot of modules; I wonder if this might somehow make it easier to escape the sandbox, by increasing the attack surface. For instance, (source-module-closure '((guix packages)) #:select? (const #t)) contains (system foreign). That=E2=80=99s probably more of a topic for guile-devel though. Beside, related to Chris=E2=80=99 comment, I=E2=80=99m a bit concerned abou= t versioning in such a widely distributed repo. The package graph in Guix has zero degrees of liberty: every package is connected to other packages; every Guix user sees the exact same graph. Here, we=E2=80=99d have to be more flexible and allow potluck.scm files to = just say =E2=80=9Cimport guile=E2=80=9D or =E2=80=9Cimport guile@2.0=E2=80=9D; = =E2=80=9Cimport guile=E2=80=9D might provide 2.0 on a machine running an older Guix, and it might give 2.2.9 on an up-to-date machine. IOW, we=E2=80=99re no longer describing one specific graph, but instead describing a family of graphs with some constraints. The benefits are decentralization, but the main drawback is non-reproducibility: the result would depend on the user machine=E2=80=99s initial state. To work around that, I think the server should resolve package specifications when the potluck.scm file is submitted, and insert each package in the Guix package graph of the moment. Does that make sense? Maybe that=E2=80=99s what you were describing when you talk about rewriting potluck.scm files so? > There is a particular concern about staging: there is staged Scheme code > in these modules that runs inside build processes in guix-daemon. I > don't have any nice solution here. What=E2=80=99s the problem anyway? The build environment is a =E2=80=9Csan= dbox=E2=80=9D so it=E2=80=99s not a problem if staged code attempts to do nasty things. > A potluck channel manager > ------------------------- > > The "guix potluck manage-channel" command manages a registry of sources > of potluck definitions and turns them into a git branch of package > files. This is the web service. > > The idea is that as a developer, you should be able to do: > > guix potluck add https://gitlab.com/wingo/foo master > > This causes the client to make a request to some web service, say > running on potluck.guixsd.org, to register that git branch. Souds good. Thanks for getting it started! Ludo=E2=80=99.