[Top][All Lists]

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

[bug#41803] [PATCH] Yggdrasil package and accompanying shepherd service

From: Julien Lepiller
Subject: [bug#41803] [PATCH] Yggdrasil package and accompanying shepherd service (mesh network)
Date: Sun, 12 Jul 2020 00:12:06 +0200

Le Thu, 11 Jun 2020 15:56:56 +0200,
raingloom <> a écrit :

> from:
> "Yggdrasil is an early-stage implementation of a fully end-to-end
> encrypted IPv6 network."
> I spent the last few days packaging it and now it's in a state where I
> think it's usable.
> The configuration can include private keys, so that part should NOT go
> in the operating system config, because it would get stored in the
> world-readable Guix store. Nix works around this by merging the
> generated config with a JSON file and sending it to yggdrasil over its
> stdin.
> I chose not to do that because I couldn't figure out how to open a
> service's stdin and because I think the way I did it is much more
> elegant in the long run.
> The package is lightly patched to take not one but two config files,
> and it simply merges them internally. The patch is completely
> backwards compatible and unobtrusive. It took me about an hour to
> write and debug and most of that was just figuring out Go's syntax
> and type system. I will try to get upstream to accept it, or
> implement similar functionality.
> Still TODO:
> documenting the service as an info page.
> The gist of using it is:
> 1. look at example operating system
> 2. see yggdrasil -genconf -json for config options
> (3.) optional: save output as /etc/yggdrasil-secret.conf
> (4.) chmod 600 /etc/yggdrasil-secret.conf
> (5.) delete everything but the signing and encryption keys
> 6. add peers as needed, or set autoconf? to #t to connect through a
> local peer
> It seems to work fine. I could connect to open peers from one
> machine and another one could auto-configure itself to connect through
> the first one over the LAN. It's pretty nifty.


this is more of a quick review.

First patch LGTM.

You should split every package you add in the second patch in separate
patches. Also the commit message should say "new variable", no need to
say it's public.

You left a comment about the license for go-github-com-gologme-log.
Have you contacted upstream to tell them about that, what was their
reaction? I think the fact that the readme says bsd implies the
intention is that it is free software, but better safe than sorry.

Otherwise, these packages lgtm.

In the third patch again, the commit message should say "new variable".
You should not use the past tense either, so "Add it".

Is the licenes lgpl3, or lgpl3+?

Not a go programmer, so I'm not reading the patch, but I'm trusting you
that it works :)

For the fourth patch, I don't think you need to list new private
variables in the commit message, nor new dependencies. Only list public
variables, as "New variables".

As you noted, could you add something about it to the manual?

In the system example, should Yggdrasil really be installed in the
system profile? If so, I think you can add a profile-service-type
extension to the service so the package is automatically available. Then
you don't need to specify the package in the os configuration, and it
ensures you install the same package (declared in the service
configuration) for the service and in the system.

Thanks for working on this!

reply via email to

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