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

[Ludovic Courtès]

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
<https://www.gnu.org/software/guix/manual/guix.html#Substitutes>.)

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
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 (= 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?

Thanks,
Ludo’.