Re: Tracking and inspecting how Guix changes over time

[Christopher Baines]

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: https://git.cbaines.net/guix/data-service/
>> 2: https://prototype-guix-data-service.cbaines.net/
>
> 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:            https://issues.guix.info/issue/34385
>> Patchwork series: 
>> https://patchwork.cbaines.net/project/guix-patches/list/?series=535
>> Laminar job:      https://laminar.cbaines.net/jobs/patchwork-test-series/889
>> Git commits:      
>> https://git.cbaines.net/guix/patches/log/?h=series-535-version-1&qt=range&q=base-for-series-535-version-1..series-535-version-1
>> Comparison:       
>> https://prototype-guix-data-service.cbaines.net/compare?base_commit=6fd72f7094885dc3dbb10431996c445251094915&target_commit=7d70e05d7064f31a8de60b04d22ac16c1953b7a9
>
> 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
linux-container).

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.

Thanks,

Chris

signature.asc
Description: PGP signature