From: Andy Wingo <wingo@pobox.com>
To: "Ludovic Courtès" <ludo@gnu.org>
Cc: guix-devel@gnu.org, guile-devel@gnu.org
Subject: Re: "guix potluck", a moveable feast
Date: Sun, 02 Apr 2017 12:52:39 +0200 [thread overview]
Message-ID: <87y3vj84js.fsf@pobox.com> (raw)
In-Reply-To: <87o9wfenkk.fsf@gnu.org> ("Ludovic Courtès"'s message of "Sun, 02 Apr 2017 01:05:15 +0200")
Hi :)
Thanks all for review; comments and suggestions very welcome. Choosing
this message to reply to.
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.
> 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
next prev parent reply other threads:[~2017-04-02 10:52 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-03-31 14:44 "guix potluck", a moveable feast Andy Wingo
2017-04-01 14:50 ` Christopher Allan Webber
2017-04-01 16:01 ` ng0
2017-04-01 23:05 ` Ludovic Courtès
2017-04-02 2:20 ` Chris Marusich
2017-04-02 9:24 ` Ludovic Courtès
2017-04-04 2:20 ` Chris Marusich
2017-04-02 10:52 ` Andy Wingo [this message]
2017-04-02 14:45 ` Christopher Allan Webber
2017-04-04 12:01 ` Ludovic Courtès
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://guix.gnu.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87y3vj84js.fsf@pobox.com \
--to=wingo@pobox.com \
--cc=guile-devel@gnu.org \
--cc=guix-devel@gnu.org \
--cc=ludo@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/guix.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).