[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Tracking and inspecting how Guix changes over time

From: Christopher Baines
Subject: Re: Tracking and inspecting how Guix changes over time
Date: Tue, 12 Feb 2019 22:05:28 +0000
User-agent: mu4e 1.0; emacs 26.1

Ludovic Courtès <address@hidden> writes:

> Hello!
> Christopher Baines <address@hidden> skribis:
>> In summary, I've started playing around with a new service, I'm
>> currently calling it the "Guix Data Service". The code is here [1], it's
>> based off of Ricardo's excellent Mumi, and at the moment only does one
>> thing, a basic comparison of two different versions (commits) of Guix
>> for the few commits it has data for. I've got it up and running here
>> [2].
>> 1:
>> 2:
> Woow, impressive!  I’m sure this is going to be useful in different
> ways: for patch review, which is your main target, but also for things
> like the hpcguix-web interface, which could provide information about
> package history, or to bisect packaging issues, possibly connected to a
> ‘guix weather’ service.

Thanks :)

>> The following links relate to a couple of patches affecting the Ruby
>> build system.
>> Issue:  
>> Patchwork series: 
>> Laminar job:
>> Git commits:      
>> Comparison:       
> Neat!  With tight integration of all these things, coupled with info
> from ‘guix weather’ and ‘guix lint’ and ‘guix challenge’, for example,
> we’d have an unequaled QA tool!

Yep :) I think one of the next things to do is get the Guix master +
patches data processed automatically, which brings me on to...

>> As far as I can see, guix pull/the channels code directly evaluates some
>> Guile code from the source repository. It would be great if this could
>> somehow be isolated to guard against any malicious patches that try to
>> attack the machine running the Guix Data Service, I haven't thought much
>> about how yet.
>> Similarly, using the inferiors approach to extract out information from
>> Guix requires running a REPL from the target Guix. This could also pose
>> security issues. I was wondering if it was possible to run the REPL
>> within a container, to at least isolate it a bit from the system.
> Yes, we should definitely run that code in a container.  Note that, for
> ‘guix pull’, I think it’s OK to run that code on the user’s machine
> as-is in the sense that the user is going to run code coming from the
> channels they specified anyway.
> For an automated system like this, it’s a bit different, so using a
> container makes a lot of sense.  I’d suggest having an option directly
> in (guix inferior) to allow users to choose whether to run an inferior
> in separate name spaces.  WDYT?

That sounds great, I'm not quite sure how to make it happen though...

So inferior-pipe in (guix inferior) uses open-pipe*. The root of the
Linux container code in Guix looks to be run-container (gnu build

The run-container function uses the clone syscall with the right flags
to isolate the new child process. I've looked at the (ice-9 popen)
module, and the couple of C functions it uses (scm_open_process and
start_child). Calling open-pipe* eventually calls fork, which I think
uses the clone syscall as well.

I can't quite work out how to combine the two though. I'm unsure how to
add the pipe behaviour to run-container, and it seems infeasible to get
open-pipe* to call fork/clone with the right flags.

Any ideas? I included David as he appears to have been involved in the
initial container implementation in case he had any wise suggestions.



Attachment: signature.asc
Description: PGP signature

reply via email to

[Prev in Thread] Current Thread [Next in Thread]