gnunet-developers
[Top][All Lists]
Advanced

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

[GNUnet-developers] [GSoC] Guix + GNUnet: what’s next


From: Rémi Birot-Delrue
Subject: [GNUnet-developers] [GSoC] Guix + GNUnet: what’s next
Date: Thu, 02 Jul 2015 13:30:35 +0200

Hello GNUnet! Here’s a little update on what’s coming for this project.

The current binary package distribution (through HTTP) is based on two
components: a substituer that retrieves packages, and a publisher to
make them available. The current plan is to start with adapting the
publisher for GNUnet before attacking the substituer; this work will be
started once I’ll have successfully bound the download and publish
operations.

Here’s an overview of how these components will work:

After a call to `guix package -i foo`, the GNUnet substituer will search
GNUnet for a specific build of the `foo` package and if it finds one, it
will download it and install it (as if it had been downloaded through
HTTP).

An interesting point is handling of metadata: in Guix (and Nix), each
binary package’s metadata (size, signature, compression method…) is
downloaded separatedly, before its archive. In the HTTP substituer, that
means you have to download two files: one for the metadata, one for the
archive. In the GNUnet substituer, we take advantage of the functionning
of GNUnet and ship an archive’s metadata along with the search result,
using.

In order to make this work, the publisher will basically inline an
archive’s metadata file in the archive’s metadata using a specific
libextractor type.

On the security side, Guix uses a list of authorized public keys to
determine if its safe to download a specific binary (based, thus, on its
author). I’m currently wondering if it would be better to use a peer’s
key or a namespace’s; what do you think?

As usual, feel free to contact me for any question, suggestion, advice,
critic or idea.
-- 
Rémi Birot-Delrue



reply via email to

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