[Top][All Lists]

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

Re: [GNUnet-developers] Guix + GNUnet at GSoC?

From: Ludovic Courtès
Subject: Re: [GNUnet-developers] Guix + GNUnet at GSoC?
Date: Thu, 05 Mar 2015 23:33:44 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.4 (gnu/linux)

Hello Christian,

Christian Grothoff <address@hidden> 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
“substituter” in Guix parlance–i.e., a back-end queried by the build
daemon to determine whether there are “substitutes” to build results
available out there.  (See

So the way it works is that when the user types ‘guix build emacs’, the
daemon invokes the “substituter” asking whether it has a substitute for
/gnu/store/8hin…-emacs-24.4; the hash here is a hash of all the relevant
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’ll be up to the substituter to authenticate what it downloads, but
Guix already has a PKI for that (also mentioned in the “Substitutes”
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 ‘guix pull’ and not in the substituter mechanism.)  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

> 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 (= Guix root), might
>    delegate source code packaging for GnuPG to
>    Werner (= 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?


reply via email to

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