From mboxrd@z Thu Jan 1 00:00:00 1970 From: ludo@gnu.org (Ludovic =?utf-8?Q?Court=C3=A8s?=) Subject: Re: [GNUnet-developers] Guix + GNUnet at GSoC? Date: Thu, 05 Mar 2015 23:33:44 +0100 Message-ID: <87r3t3axbr.fsf@gnu.org> References: <87oao8a2mn.fsf@gnu.org> <54F85EC1.7090101@gnunet.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:40046) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YTeL5-0006Wu-Gl for guix-devel@gnu.org; Thu, 05 Mar 2015 17:33:56 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YTeL1-00037G-Ej for guix-devel@gnu.org; Thu, 05 Mar 2015 17:33:55 -0500 In-Reply-To: <54F85EC1.7090101@gnunet.org> (Christian Grothoff's message of "Thu, 05 Mar 2015 14:48:49 +0100") 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-bounces+gcggd-guix-devel=m.gmane.org@gnu.org To: Christian Grothoff Cc: guix-devel@gnu.org, gnunet-developers@gnu.org Hello Christian, Christian Grothoff skribis: > Yes, I think we should. MESH (now CADET) is much further along and the > API is stable. I also don't see any other significant roadblocks. OK. I gather from a recent Mumble meeting report that a new release is in the works, right? > 1) Transfer of source code (with signatures / integrity checking / > build rules) > 2) Transfer of binary packages (with signatures / integrity checking), > which also requires > - specification of platforms (what is binary-compatible) > - specification of platform-independent resources > ("noarch"/"all"/"data") I should mention that the GNUnet-based mechanism would become a =E2=80=9Csubstituter=E2=80=9D in Guix parlance=E2=80=93i.e., a back-end que= ried by the build daemon to determine whether there are =E2=80=9Csubstitutes=E2=80=9D to buil= d results available out there. (See .) So the way it works is that when the user types =E2=80=98guix build emacs= =E2=80=99, the daemon invokes the =E2=80=9Csubstituter=E2=80=9D asking whether it has a su= bstitute for /gnu/store/8hin=E2=80=A6-emacs-24.4; the hash here is a hash of all the rel= evant info, including the architecture, etc. The GNUnet-based substituter would typically go find a list of peers that provide it, and fetch it from them. It=E2=80=99ll be up to the substituter to authenticate what it downloads, b= ut Guix already has a PKI for that (also mentioned in the =E2=80=9CSubstitutes= =E2=80=9D section above.) > 3) Incremental updates > - to source (i.e. "diff") > - to binaries (funky binary-diff) Definitely. (Content-based addressing comes to mind.) > 4) Notification about available updates to sources (to individual > packages or full distribution by distribution authority), or > signed messages asserting no updates are available (also important > to avoid adversary preventing upgrade) Definitely important, but technically different (it would have to be hooked up in =E2=80=98guix pull=E2=80=99 and not in the substituter mechani= sm.) I would not make it part of the GSoC. > 5) Notification about available updates to binaries (including > signatures of binary package builders arriving at the same > (or different!?) deterministic build hash) Binaries are immutable. However, being able to know which peers arrive at a given hash for a given /gnu/store item would be a nice bonus indeed. > 6) A trust graph / metric / WoT-like construction to determine > how many (and which) binary package builders are needed before > we trust third-party binaries (instead of building ourselves > from source) Interesting, but beyond GSoC IMO. > 7) Automatically offering packages the local system has build to > others (or not) That would have to be done so we can at least test the system. :-) > 8) Delegation of build authority (i.e. Ludo (=3D Guix root), might > delegate source code packaging for GnuPG to > Werner (=3D GnuPG maintainer)); this creates questions of how > to handle/specify/allow/prohibit transitive delegations > (subpackages (KDE, Kedit), related packages (GnuPG/Enigmail) Beyond GSoC IMO. I think getting the basic functionality of the substituter in place as well as a tool to public local binaries would be a great achievement. Who would like to (co-)mentor it? Thanks, Ludo=E2=80=99.