Hi :) Thanks all for review; comments and suggestions very welcome. Choosing this message to reply to.
On Sun 02 Apr 2017 01:05, l...@gnu.org (Ludovic Courtès) writes: > Andy Wingo <wi...@igalia.com> skribis: > >> (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 “dishes”, right? Yes I think so: a union of all potluck "dishes" with the Guix package set as well. Christopher Webber asks about breakage due to version skew between peer channels and channels and Guix itself. I think I would like to just ignore this problem for now: if you add channels and things break somehow due to an update in Guix or an update in some channel, then the workaround is to disable channels until developers fix things. > 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)) I think the strategy here would be to avoid making a sandbox binding set that is "unsafe". Having source-module-closure in that binding set would seem to make it unsafe. > 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’s what > you were describing when you talk about rewriting potluck.scm files > so? Yes I think this is a good idea. Incidentally I am now thinking that all the potluck stuff should be in a potluck dir; you run "guix potluck init" and it makes potluck/README.md potluck/mypackage.scm and the .scm files should evaluate to a single package, like: (import-packages ...) (package ...) The rewrite would create files like: gnu/packages/potluck/gitlab-com-wingo-foo-master/mypackage.scm gnu/packages/potluck/gitlab-com-wingo-foo-master/mypackage2.scm These files would look like: (define-module (gnu packages potluck gitlab-com-wingo-foo-master mypackage) #:pure ;; The sandbox. We've already verified that the user code works in ;; this sandbox when we rewrite the package, so this allows us to ;; provide a stable language for sandbox packages #:use-module (guix potluck environment) ;; The individual module imports, resolved by channel manager. #:use-module ((gnu packages guile) #:select (guile)) ... #:export (mypackage)) (define mypackage (package ....)) You can compile files from the channel, so guix startup time will be only minimally affected. >> 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’s the problem anyway? The build environment is a “sandbox” so it’s > not a problem if staged code attempts to do nasty things. I guess so, yeah. Andy
