Re: "guix potluck", a moveable feast

[Andy Wingo]

Hi :)

Thanks all for review; comments and suggestions very welcome.  Choosing
this message to reply to.

On Sun 02 Apr 2017 01:05, address@hidden (Ludovic Courtès) writes:

> Andy Wingo <address@hidden> 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