Re: "guix potluck", a moveable feast

[ludo@gnu.org (Ludovic Courtès)]

Hey!

Andy Wingo <wingo@pobox.com> skribis:

> On Sun 02 Apr 2017 01:05, ludo@gnu.org (Ludovic Courtès) writes:
>
>> Andy Wingo <wingo@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’.