Hello Christian,
Christian Grothoff <groth...@gnunet.org> 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’.
