Hey! Andy Wingo <wi...@pobox.com> skribis:
> 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. OK, that sounds reasonable. >> 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. Sorry, I used ‘source-module-closure’ just to show that (system foreign) is being pulled, and (system foreign) is “sudo”. :-) So I think we’d have to make sure the sandbox cannot access (system foreign) transitively. >> 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. Sounds good! Ludo’.
