Re: intrinsic vs extrinsic identifier: toward more robustness?

[Maxim Cournoyer]

Hi Maxime (it's been some time, welcome back!)

Maxime Devos  writes:

[...]

> I think nar stuff should be kept outside SWH.  It doesn't seem
> scalable to me for SWH to support the format of every distribution.
> Likewise, I think that SWH identifiers should _not_ become an
> intrinsic identifier that is recorded in package definitions -- if
> there are other archives that are somewhat SWH-like archives, then
> Guix should support them too even if they don't use SWH identifiers
> for whatever reason, and including the identifier of every single
> archive seems unscalable to me.
>
> I believe I have a solution on how to solve the ‘everyone uses
> different identifiers, how to map between them’ problem, but it will
> take some paragraphs:
>
> At some point in the past, when thinking about downloading source code
> over GNUnet File-sharing (FS), I had the problem that Guix and GNUnet
> uses different intrinsic identifiers -- Guix uses the NAR hash for
> querying substitute servers, whereas FS has a system of its own that's
> more convenient for P2P file-sharing stuff.
>
> The problem then was to somehow map the NAR hash to the FS identifier.
> I couldn't do this the Disarchive way, because the point was to be
> _P2P_ and Disarchive ... isn't.
>
> A straightforward solution would be to just replace the https:// by
> gnunet:// in the origin (like in https://issues.guix.gnu.org/44199,
> except that patch doesn't support fallbacks to other URLs like
> url-fetch does).
>
> The problem was that people demanded that gnunet:// should only be
> supported once there is actually source code on GNUnet and GNUnet is
> stable, but why would people put source code on GNUnet when no
> distribution supports it and how would GNUnet become stable without
> any users?
>
> To work-around these circular demands, I started 'rehash':
> 
> (current location: https://notabug.org/maximed/rehash).  It is a
> (P2P!) GNUnet service that maintains a 'SHA1512<->GNUnet FS URI'
> mapping, or more generally, a 'this hash type<->that hash type'
> mapping.
>
> (It is just a service on top of the DHT, so the same could easily be
> done for BitTorrent or IPFS.)
>
> It's rather incomplete at the moment (there is no verification or
> reputation mechanism at all so the network could be flooded with bogus
> mappings, mappings are only in DHT, not stored on disk, so they are
> lost on reboot, the POC Guix integretation is a bit limited), but the
> basics are there -- the POC successfully downloaded a substitute over
> GNUnet _without_ having to include FS URI in the narinfo (*)!.
>
> I'm writing about substitutes here, but the exact same approach could
> be done for plain source code.
>
> (*) I might have misremembered; I can't find the POC on
> issues.guix.gnu.org again, and I'm not sure if the POC used rehash or
> if it just included the FS URI in the narinfo.
>
> (TBC, I haven't been working on Rehash lately, but rather
> Scheme-GNUnet: a Scheme port of the GNUnet libraries that's less
> limited than Guile-GNUnet.  Idea is to make GNUnet-FS and rehash more
> convenient to use from Scheme, and in particular, in Guix.)

Thanks for sharing your efforts on the P2P in Guix/GNUnet front!  P2P
seems like it'd make substitutes mirroring easy and improve robustness
as the network gets populated.  It's very interesting; it'd definitely
make an interesting summer internship :-).

Keep up the good and inspiring hacks!

-- 
Thanks,
Maxim

Re: The package/inherit trap

[Maxim Cournoyer]

Hi,

Tobias Geerinckx-Rice  writes:

> Hi!
>
> Maxim Cournoyer 写道：
>> Simon Tournier  writes:
>>> It is not clear for me why you choose one over the other.  From my
>>> current understanding, I would be tempted to always use
>>> 'package/inherit' and never plain 'inherit'.
>>
>> I also got confused by that in the past;
>
> Same.  I think it's a rite of passage.  A questionable one.
>
>> The way I process it internally now is this:
>>
>> If the inheritance is for *same-source/same-version* variants of a
>> package, they should use package/inherit, as any security issues
>> found
>> in the parent package should also be applied to that package (since
>> they
>> use the same source).  Otherwise, plain 'inherit' should be used
>> (e.g. for newer version variants).
>
> That about jives with my intuition.
>
> Judging by the (IMO) universal confusion this causes, it is (IMO)
> spectacularly poorly-named.  A docstring doesn't fix that.
>
> Could we rename it to something like ‘package+replacements/inherit’?
> To me, that captures the spirit, without being overly longer.

That'd be better, I think.  The more verbose name at least wouldn't let
one think, 'oh, some questionable syntax sugar for the lazy', like I did
in the past :-).

-- 
Thanks,
Maxim

Re: [PATCH] Cuirass: Complete IPv6 support

[Leo Famulari]

On Wed, Mar 01, 2023 at 12:34:08AM -0800, Ryan Sundberg wrote:
> Hello Guix hackers,
> 
> I have implemented IPv6 support for Cuirass in the attached patchset.
> This has been tested on a multi-node cluster running Cuirass over IPv6
> with some real builds. It should maintain full backwards compatibility
> with the default IPv4, only enabling IPv6 when given the arguments to
> bind to IPv6 addresses. See the commit log for full details!

Thanks, this is great! Can you send the patches to
, so that we can use qa.guix.gnu.org for testing?

To send a multi-patch series, you'll need to first send an introductory
message to , and then send the patches to the
special ticket-number email address that it gives you in response.

Re: intrinsic vs extrinsic identifier: toward more robustness?

[Maxime Devos]

Op 03-03-2023 om 19:07 schreef Simon Tournier:

Hi,

I would like to open a discussion about how we identify the source
origin (fixed output).  It is of vitally importance for being robust on
the long-term (say 3-5 years).  It matters in Reproducible Research
context, but not only.

# First thing first
===

## What is an intrinsic identifier or an extrinsic one?
===

  - extrinsic: use a register to keep the correspondence between the
identifier and the object; say label version as Git tag.

  - intrinsic: intimately bound to the designated object itself; say hash
as Git blob or tree and at some extent commit.

>
> [... some reordering for convenience of replying ...]
>
> Please note that the identification and the integrity is not the same.
> Since intrinsic identifier often uses cryptographic hash functions and
> integrity too, it is often confusing.

To my understanding, there is only one 'real' identifier in Guix: the 
(sha256sum (base32 ...)) (*).  Those other identifiers like the URL in 
url-fetch and git-fetch are just hints on where to find the object -- 
very important hints without which finding the object is much more 
likely to fail, but just hints nonetheless.


While identification and integrity might be different concepts, 
content-based identifiers like (sha256 (base32 ...)) accomplish both at 
the same time.


(*) FWIW, I would like to point out that Guix theoretically supports 
some other hashes as well, though they aren't used for any in-tree packages.



The register must be a trusted authority and it resolves by mapping the
key identifier to the object.  Having the object at hand does not give
any clue about the key identifier.  And collisions are very frequent;
two key identifiers resolve to the same content – hopefully! we call
that mirrors. ;-)


I first thought you where writing about 'extrinsic -> intrinsic (e.g. 
hash-based)' registers, so I was confused by your comment about 
collisions -- to my understanding, no sha256sum collisions are known. 
Going by your comment about mirrors, I think you meant an 'intrinsic -> 
extrinsic' map instead, e.g. 'sha256 -> a bunch of appropriate URLs'.



Intrinsic identifier also relies on a (trusted) map but collisions are
avoided as much as possible.  Somehow it strongly reduces the power of
the authority and it is often more robust.


Who is 'the authority' here, how does the absence of collision reduces 
the power of the authority, and what is your point about reducing the 
power of the authority?  I was thinking of ‘the authority=Guix package 
definition’, but then only the 'more robust' part of your conclusion 
makes sense to me.  Also, as you used 'but' instead of 'and', it appears 
you consider relying on a trusted map to be a bad thing, but that 
appears basic security and patch review to me.



Whatever the intrinsic identifier we consider – even ones based on very
weak cryptographic hash function as MD5, or based on non-crytographic
hash function as Pearson hashing, etc. – the integrity check is
currently done by SHA256.


How about using the hash of the integrity check as an intrinsic 
identifier, like is done currently?  I mean, we hash it anyway with 
sha256 for the integrity check anyway, might as reuse it.



## For example, consider this source origin,
==

 (source (origin
   (method url-fetch)
   (uri (string-append "mirror://gnu/hello/hello-" version
   ".tar.gz"))
   (sha256
(base32
 "086vqwk2wl8zfs47sq2xpjc9k066ilmb8z6dn0q6ymwjzlm196cd"

where ’mirror://gnu’ is resolved by Guix itself.  Or this one,

 (source
  (origin
(method git-fetch)
(uri (git-reference
  (url "https://github.com/FluxML/Zygote.jl;)
  (commit (string-append "v" version
(file-name (git-file-name name version))
(sha256
 (base32 "02bgj6m1j25sm3pa5sgmds706qpxk1qsbm0s2j3rjlrz9xn7glgk"

where Guix clones then checks out at the specification of the field
’commit’.

Here both are extrinsic identifiers.  For the first example, the register
is defined by ’%mirrors’.  For the second example, the register is the
folder ’.git/’.

Intrinsic identifier could be plain hash or hashed serialized data.
Using Guix b8f6ead:

--8<---cut here---start->8---
$ guix hash -S none -H sha256 -f nix-base32 -x $(guix build hello -S)
086vqwk2wl8zfs47sq2xpjc9k066ilmb8z6dn0q6ymwjzlm196cd

$ guix hash -S git -H sha256 -f nix-base32 -x $(guix build hello -S)
11kaw6m19rdj3d55y4cygk6k9zv6sn2iz4gpimx0j99ps87ij29l

$ guix hash -S nar -H sha256 -f nix-base32 -x 
/gnu/store/3dq55rw99wdc4g4wblz7xikc8a2jy7a3-hello-2.12.1.tar.gz
1lvqpbk2k1sb39z8jfxixf7p7v8sj4z6mmpa44nnmff3w1y6h8lh
--8<---cut here---end--->8---

Or some Git-like tree md5 of the 

The package/inherit trap (was: gnu: stellarium: Enable ShowMySky.)

[Tobias Geerinckx-Rice]

Hi!

Maxim Cournoyer 写道：

Simon Tournier  writes:
It is not clear for me why you choose one over the other.  From 
my

current understanding, I would be tempted to always use
'package/inherit' and never plain 'inherit'.


I also got confused by that in the past;


Same.  I think it's a rite of passage.  A questionable one.


The way I process it internally now is this:

If the inheritance is for *same-source/same-version* variants of 
a
package, they should use package/inherit, as any security issues 
found
in the parent package should also be applied to that package 
(since they

use the same source).  Otherwise, plain 'inherit' should be used
(e.g. for newer version variants).


That about jives with my intuition.

Judging by the (IMO) universal confusion this causes, it is (IMO) 
spectacularly poorly-named.  A docstring doesn't fix that.


Could we rename it to something like 
‘package+replacements/inherit’?  To me, that captures the spirit, 
without being overly longer.


But I'll gladly judge other bikesheds if they lead to a less 
misleading name.


Kind regards,

T G-R


signature.asc
Description: PGP signature

intrinsic vs extrinsic identifier: toward more robustness?

[Simon Tournier]

Hi,

I would like to open a discussion about how we identify the source
origin (fixed output).  It is of vitally importance for being robust on
the long-term (say 3-5 years).  It matters in Reproducible Research
context, but not only.

# First thing first
===

## What is an intrinsic identifier or an extrinsic one?
===

 - extrinsic: use a register to keep the correspondence between the
   identifier and the object; say label version as Git tag.

 - intrinsic: intimately bound to the designated object itself; say hash
   as Git blob or tree and at some extent commit.

The register must be a trusted authority and it resolves by mapping the
key identifier to the object.  Having the object at hand does not give
any clue about the key identifier.  And collisions are very frequent;
two key identifiers resolve to the same content – hopefully! we call
that mirrors. ;-)

Intrinsic identifier also relies on a (trusted) map but collisions are
avoided as much as possible.  Somehow it strongly reduces the power of
the authority and it is often more robust.

Please note that the identification and the integrity is not the same.
Since intrinsic identifier often uses cryptographic hash functions and
integrity too, it is often confusing.

Whatever the intrinsic identifier we consider – even ones based on very
weak cryptographic hash function as MD5, or based on non-crytographic
hash function as Pearson hashing, etc. – the integrity check is
currently done by SHA256.

## For example, consider this source origin,
==

(source (origin
  (method url-fetch)
  (uri (string-append "mirror://gnu/hello/hello-" version
  ".tar.gz"))
  (sha256
   (base32
"086vqwk2wl8zfs47sq2xpjc9k066ilmb8z6dn0q6ymwjzlm196cd"

where ’mirror://gnu’ is resolved by Guix itself.  Or this one,

(source
 (origin
   (method git-fetch)
   (uri (git-reference
 (url "https://github.com/FluxML/Zygote.jl;)
 (commit (string-append "v" version
   (file-name (git-file-name name version))
   (sha256
(base32 "02bgj6m1j25sm3pa5sgmds706qpxk1qsbm0s2j3rjlrz9xn7glgk"

where Guix clones then checks out at the specification of the field
’commit’.

Here both are extrinsic identifiers.  For the first example, the register
is defined by ’%mirrors’.  For the second example, the register is the
folder ’.git/’.

Intrinsic identifier could be plain hash or hashed serialized data.
Using Guix b8f6ead:

--8<---cut here---start->8---
$ guix hash -S none -H sha256 -f nix-base32 -x $(guix build hello -S)
086vqwk2wl8zfs47sq2xpjc9k066ilmb8z6dn0q6ymwjzlm196cd

$ guix hash -S git -H sha256 -f nix-base32 -x $(guix build hello -S)
11kaw6m19rdj3d55y4cygk6k9zv6sn2iz4gpimx0j99ps87ij29l

$ guix hash -S nar -H sha256 -f nix-base32 -x 
/gnu/store/3dq55rw99wdc4g4wblz7xikc8a2jy7a3-hello-2.12.1.tar.gz
1lvqpbk2k1sb39z8jfxixf7p7v8sj4z6mmpa44nnmff3w1y6h8lh
--8<---cut here---end--->8---

Or some Git-like tree md5 of the decompressed data, e.g.,

--8<---cut here---start->8---
$ guix hash -S git -H md5 -f hex -x hello-2.12.1
3db60bcfecf17a5dd81e3fb5bfb1c191
--8<---cut here---end--->8---

Or some others.

--8<---cut here---start->8---
$ git clone https://github.com/FluxML/Zygote.jl
$ git -C Zygote.jl checkout v0.6.41

$ guix hash -S nar -H sha256 -f nix-base32 -x Zygote.jl
02bgj6m1j25sm3pa5sgmds706qpxk1qsbm0s2j3rjlrz9xn7glgk

$ guix hash -S git -H sha1 -f hex -x Zygote.jl
3cfdb31b517eec4173584fba2b1aa65daad46e09
--8<---cut here---end--->8---


# Second thing second
=

All that’s said, Guix uses extrinsic identifiers for almost all origins,
if not all.  Even for ’git-fetch’ method.

Consider that GitHub disappears and the default build farms ci.guix and
bordeaux.guix are unreachable for whatever reason.  Then Guix will
fallback to Software Heritage and will exploits its resolver.

--8<---cut here---start->8---
Initialized empty Git repository in 
/gnu/store/ns1f3b4wm5n470bczd2k5li6xpgbqkz7-julia-zygote-0.6.41-checkout/.git/
fatal: unable to access 'https://github.com/FluxML/Zygote.jl/': Could not 
resolve host: github.com
Failed to do a shallow fetch; retrying a full fetch...
fatal: unable to access 'https://github.com/FluxML/Zygote.jl/': Could not 
resolve host: github.com
git-fetch: 
'/gnu/store/55ba5ragbd5sd4r45n0q24vrxx9rigrm-git-minimal-2.39.1/bin/git fetch 
origin' failed with exit code 128
Trying content-addressed mirror at berlin.guix.gnu.org...
Trying content-addressed mirror at berlin.guix.gnu.org...
Trying to download from Software Heritage...
SWH: found revision 

Re: Fwd: [gnu-soc] GNU Guix Project: Decentralized substitute distribution

[Csepp]

Shivam Madlani  writes:

> -- Forwarded message -
> From: Shivam Madlani 
> Date: Fri, 3 Mar 2023 at 12:42
> Subject: [gnu-soc] GNU Guix Project: Decentralized substitute distribution
> To: 
>
> Hello all,
> My name is Shivam Madlani aiming for GSoC'23, and I am particularly
> interested in The Guix project. I took a look at the project idea and
> installed a fresh version of Guix on a VM and started playing around in it.
> I have a few questions regarding the project which I think you guys can
> help me with:
>
> 1) The project title states "decentralized"... which i don't get. How
> exactly is it decentralized? Similar to a P2P file sharing tech or
> something else (BitTorrent)?
> 2) As per the project idea I interpreted that the technologies involved
> would be c/c++, shell and a bit of networking. Is this correct or am I
> missing something?
> 3) What would be the duration of the project? (175hrs/350hrs).
>
> Thank you all and I hope to hear from you soon. :)
>
> Regards

Moving this to guix-devel, since this is more a development focused
question, not a user support one.

See this issue for some related code:
https://issues.guix.gnu.org/52555

As for languages, you would definitely need to write Guile Scheme on the
Guix side, but it would probably make use of libraries written in other
languages, which would likely include C and C++, but also quite possibly
Rust and Go, since a lot of newer decentralized file distribution
protocols have implementations written in them.

As for other details, I CC'd Pukkamustard, who will be the mentor for
this project if I'm not mistaken, and should be able to fill in the
blanks.

ps.: Personally I'd really love to see NDN based substitutes, but NDN is
not even packaged in Guix yet, so my guess is that at first it's best if
you added support for something that already works on Guix System, like
IPFS.

Re: Projects for the Google Summer of Code

[Simon Tournier]

Hi,

On Fri, 3 Mar 2023 at 01:51, Kyle Andrews  wrote:

> > Do you mean ’guix.install()’ from r-guix-install?
> >
> > https://cran.rstudio.com/web/packages/guix.install/index.html
> >
> > How do you install Python packages from the Python REPL?
>
> With the reticulate package in R, a python environment can be readily
> instantiated using R code like `use_condaenv`.
>
> https://rstudio.github.io/reticulate/articles/versions.html

IIUC, this install Python packages from R REPL and not from Python
REPL.  Maybe I am missing something but I think 'guix.install' already
does that.

> In my dreams there would be a `use_guix()` command as well. Of course,
> right now that R code is limited to setting up python-specific
> environments and conda environments (and installing python packages into
> them). However, it still might be valuable to get the name recognition
> for Guix in this limited context.

Again, maybe I am missing a point but, IMHO, 'guix.install' is the
'use_guix' you are describing.

> While guix would be responsible for just the python environment in the
> context of the reticulate package, that isn't the only possible use
> case. It would be nice to write that integration for reticulate by
> having them use another R package with deeper integrations built out for
> managing guix itself from R. That's why I brought up RcppGuile as a path
> for how R could interface directly with the Guix scheme libraries. Such
> an interface might be useful for other interactive scientific
> environments like python as well. The goal would be to make Guix seem
> less exotic to researchers in typical scientific languages. If it's part
> of their "home" computing environment, then they might be much more
> interested in trying it out. This reflects a bigger scope than just
> being a replacement for install.packages.

>From my understanding, the path would be 'guix.install', but maybe I
am missing details.  And I am not following the point of RcppGuile,
instead I would go via some 'emulate-fhs' as "guix shell" provides.

Anyway, in all cases, it could nice to fix these bugs related to Conda
on the top of Guix:

https://issues.guix.gnu.org/issue/59776
https://issues.guix.gnu.org/issue/59775
https://issues.guix.gnu.org/issue/59774
https://issues.guix.gnu.org/issue/59772


> Later in that conversation you made the point that the purpose of the
> guix-past channel was to make things like this possible. I added my
> voice to this (GSOC Project) thread because I thought it would be useful
> to place a fresh pair of eyes at tackling the combinatorial
> configuration problems which still stand in the way of curating a large
> Guix package repository with the breadth of scientific package versions
> that a platform like conda provides... even if it cheats a lot by not
> doing that reproducibly. Whatever they learn might also help elsewhere
> in the project, such as potentially helping to curate large collections
> of packages in other languages like those in Go, Rust, or even
> JavaScript.

I agree that working around Conda could pay off for Reproducible
Research.  For example, you might be interested by the thread starting
here:

https://lists.gnu.org/archive/html/guix-science/2022-11/msg9.html

continuing there:

https://lists.gnu.org/archive/html/guix-science/2022-12/msg0.html

Last, Thibault launched a Git repository with CI trying to find after
which weeks or months or years? a Conda environment as you described
earlier breaks, see:

https://framagit.org/tlestang/conda-python-example/-/pipelines

The current CI tests the resolver part of Conda as discussed in the
thread above and that's cool!  :-)

Other tests could be added, as changing the "base" computational
environment (image) [1].  What happens if the Docker image
'continuumio/miniconda3:4.12.0' is lost?  For example, it could also
be tested with other 'continuumio/miniconda3' images.  Or even install
Conda on the top of say various Debian or other "base" image.  Well,
using a simple example (numpy+matplotlib) and try to run it on various
computational environments management by Conda; mimicking what we do
most of the time as scientific researchers.

1: 
https://framagit.org/tlestang/conda-python-example/-/blob/main/.gitlab-ci.yml#L1

Well, for what it is worth, I am trying to do these kind of tests for
Guix -- rebuild an old computational environment from 2020 using
current state of the world -- as reported here:

https://lists.gnu.org/archive/html/guix-devel/2023-02/msg00398.html
https://lists.gnu.org/archive/html/guix-devel/2023-03/msg7.html

And I also proposed to work on that as GSoC:
https://libreplanet.org/wiki/Group:Guix/GSoC-2023
Feel free to add you as co-mentor. :-)

Cheers,
simon

Re: Guix, Nix flakes, and object capabilities

[Simon Tournier]

Hi,

On Tue, 28 Feb 2023 at 22:13, Jonathan Frederickson  
wrote:

> I recently had a discussion in #spritely on Libera.Chat about Guix and
> Nix, and in particular a (relatively) new feature of Nix called flakes
> that Guix doesn't currently have an analogue for.

Well, even after several readings of Nix documentation about Flakes, I
am still not sure to understand how the concept would apply for Guix. :-)


> But the package you end up with each time you do that... depends on
> which revision of Guix you're running when you run ~guix shell~! So if
> I point someone to a project with a ~guix.scm~ file, they might not be
> able to use it if their Guix revision is too old. (Or too new, if
> packages have been renamed or removed.) More generally, it means that
> they do not end up with the same dependency graph that I do. This
> makes troubleshooting potentially tricky, because if something breaks
> you have to check the resulting profile to see which versions of your
> package's dependencies (and transitive dependencies) are actually
> installed.

That’s why “guix time-machine” is really cool! :-)

Basically, I have my current Guix revision and I run “guix pull” every…
indecent duration.  However, I run many many “guix time-machine”, well
each time I am working on a project, so daily.

Even, I only run “guix pull” against the default Savannah Guix channel.
Then, depending on the projects, they can require the channels
guix-science, guix-cran or others.

The graph I need for a specific project is controlled by the file
channels.scm and I run, from the directory of that project:

guix time-machine -C channels.scm -- shell

This channels.scm file can be part of the Git repository of that
project.  And sometimes, I have several files for testing revision
variants.

On the top of that, for some cases, I have specific packages for one
project.  Therefore, I have a folder, say guix/extra containing one or
more files which define new or variant packages.

Somehow, my typical line looks like:

  guix time-machine -C state-1.scm -- shell -L guix/extra -m manifest-A.scm
  guix time-machine -C state-2.scm -- shell -L guix/extra -f guix-B.scm

etc.

(Although, I should admit that I barely use the option -f. ;-))

> For those who haven't used Nix, it has a solution to this called
> flakes. Flakes let you specify git repositories explicitly as inputs for
> your project[1]. (It also maintains a flake.lock file so you can lock to
> a specific revision automatically while still using a named branch in
> your inputs directly, but I believe you could in theory refer to a
> specific rev in your inputs.) Effectively, the channels you're using for
> dependencies are specified by the project you're building, not whatever
> happens to be configured on your local machine.

>From my understanding, what I describe above seems providing these
Nix flakes, no?

Or could you explain on a concrete example what you can do with Nix
flakes that you cannot do with Guix?

Well, UI and how easy to use can also be considered part of “can
do”. :-) I mean, maybe the current Guix way could be improved on the
light of the Nix flakes.


> I think something like this would be useful for Guix for many of the
> same reasons it's useful in Nix. But there's a bit of a security
> conundrum here. Loading Guix package definitions involves code
> execution, which as far as I can tell isn't currently sandboxed at all!
> And that's a problem. When you load package definitions from a channel
> that you've configured on your system, you've explicitly trusted that
> channel's maintainers. But with a flake-like system... even if you might
> be okay depending on someone else's code, that doesn't necessarily mean
> you fully trust them. You might ultimately choose to sandbox the
> resulting binary, but that's moot if you can't fetch its dependencies
> without running arbitrary code with all of your user's authority.

I am not sure to understand this sandbox part.  For instance,

guix time-machine -C channels.scm -- shell --container

provides you an isolated environment where you can run untrusted
packages coming from untrusted channels.  Even, the option ’-F,
--emulate-fhs’ combined with the option ’-C, --container’ allow to run
untrusted binaries coming from elsewhere (not built by Guix); you need
some care with the options -E and --expose though.

Do you think something is missing?  What could we improve in this area?

Do you mean evaluate the Guile files provided by the untrusted channels
in a sandbox?


> I think there is a solution to this, though. Right now when you
> evaluate Guix package definitions, you're basically running arbitrary
> Guile code. This of course can do anything you can do. But it doesn't
> have to! If you're familiar with Christine Lemmer-Webber's work on
> Spritely, you'll probably know what I'm getting at here: I think using
> object capabilities[2] would fix this. I recommend reading the linked
> blog post for a good explainer on