From mboxrd@z Thu Jan 1 00:00:00 1970 From: Christopher Baines Subject: Re: Tracking and inspecting how Guix changes over time Date: Tue, 12 Feb 2019 22:05:28 +0000 Message-ID: <87zhr0u0gn.fsf@cbaines.net> References: <87k1ia5sd4.fsf@cbaines.net> <87bm3lrnwm.fsf@gnu.org> Mime-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" Return-path: Received: from eggs.gnu.org ([209.51.188.92]:45834) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gtgBU-0005zC-76 for guix-devel@gnu.org; Tue, 12 Feb 2019 17:05:45 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gtgBL-0002lr-IQ for guix-devel@gnu.org; Tue, 12 Feb 2019 17:05:36 -0500 In-reply-to: <87bm3lrnwm.fsf@gnu.org> List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org Sender: "Guix-devel" To: Ludovic =?utf-8?Q?Court=C3=A8s?= , Thompson@localhost, David Cc: guix-devel@gnu.org --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Ludovic Court=C3=A8s 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=E2=80=99m sure this is going to be useful in differe= nt > 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 > =E2=80=98guix weather=E2=80=99 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/lis= t/?series=3D535 >> Laminar job: https://laminar.cbaines.net/jobs/patchwork-test-series= /889 >> Git commits: https://git.cbaines.net/guix/patches/log/?h=3Dseries-5= 35-version-1&qt=3Drange&q=3Dbase-for-series-535-version-1..series-535-versi= on-1 >> Comparison: https://prototype-guix-data-service.cbaines.net/compar= e?base_commit=3D6fd72f7094885dc3dbb10431996c445251094915&target_commit=3D7d= 70e05d7064f31a8de60b04d22ac16c1953b7a9 > > Neat! With tight integration of all these things, coupled with info > from =E2=80=98guix weather=E2=80=99 and =E2=80=98guix lint=E2=80=99 and = =E2=80=98guix challenge=E2=80=99, for example, > we=E2=80=99d 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 > =E2=80=98guix pull=E2=80=99, I think it=E2=80=99s OK to run that code on = the user=E2=80=99s 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=E2=80=99s a bit different, so using= a > container makes a lot of sense. I=E2=80=99d suggest having an option dir= ectly > 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 --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQKTBAEBCgB9FiEEPonu50WOcg2XVOCyXiijOwuE9XcFAlxjQyhfFIAAAAAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldDNF ODlFRUU3NDU4RTcyMEQ5NzU0RTBCMjVFMjhBMzNCMEI4NEY1NzcACgkQXiijOwuE 9Xe8VQ/+PmIj8IaPay0H33ra6HsFg+N2YOXTyeBM5z8r7M9yqjrnRy6RmNY1RZU5 Fhzo0V92L4qqI3Zs4+CAIDNUzc8NDE9Yo8nm1pqa0KNoVOom0IC3bXfcXYYyrhJB Uuw3ShKwNXku8kyLm6QEhV4IRTHnfFDTLGXhGxHb/RmiSuAbb+E+Wdp2Lu9LneMV LR6mGGNH8XXextdx7Abcx6+Uu52Desfjq2m3/hm26RzHt1CsDk3sa3QrTnU/82L3 GcxAZcsLC3FinTgbUrEKFwsQd5rFOTaPC43R6LXHEN1uWRv1Ijj/81rMFoNkpBbk kW+P6XnM7evjiG2Kirc5pA9it0xx4ptVk5WNRSTlPjtPiLG7llCPkkdQjO3pHeib ripHviNvai8SnveSXr/58ROb3V7rBD085BX4ip4Zw2gxdCqX7mgKF8P68J+vC9uD U5wDbWsmhSWu88WPYXmO3X6G9z/9JwP1cq64ZqyW18SiCykyJU4l2i4wO2MhqzKG Lz7AFiElU/tN6yuEiYDDqK3qeWjff9ZRmVc2lffpOYxg5FCRgEgn5qE97dro9dzZ od0vefgVQyBu6U+7rHU5cebyxdbeyz0vuyTen1boZj7uzrgJLb60/YwChBRE48Yv nMY4DgX/StllKTtLEm56CXz0H9h96b5xCkOLrg0D7F+IeNdA+S8= =j882 -----END PGP SIGNATURE----- --=-=-=--