Ludovic Courtès writes: > Hello! > > Christopher Baines 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