Re: [patch] add support for peer names using a file in userspace

["Jason A. Donenfeld" <Jason@zx2c4.com>]

Hi Lonnie,

On Fri, Dec 8, 2017 at 2:42 PM, Lonnie Abelbeck
<lists@lonnie.abelbeck.com> wrote:
> The latest patch is reworked, disabled by default and requires WITH_PEERDATA=yes to be enabled.

Compile time switches for something that doesn't add a dependency?
Sounds like a bad idea, leading to all sorts of coderot and bloat down
the road.

> Yes, Jason, I think it is necessary.
>
> Consider a GUI showing a list of peers that you can click on to edit, there needs some sort of human-memerable "name" associated with each peer.

In this case, why wouldn't the GUI management logic handle this? Why
does this kind of thing need to be in the tiny building block tool,
wg(8)? This is a great example of a complete system where it perhaps
doesn't make to put it in wg(8).

> Additionally, the "wg show" output is sorted by "handshake time" (a good thing), so remembering your peer config order does not help identifying the peers.

That's a good reason, actually.

> While I would be happy with a compile-time option to support peer-names via a userspace file (per my patch), a kernel object would be better.

Noted, okay.

> 1) Support either [Peer] or [Peer-some_custom_name] in "wg setconf" configurations.
>
> 2) Make "wg showconf" parrot back any [Peer-some_custom_name] context names.

Absolutely not. If something like this lands, it will be called
"Description=" or the like, as another attribute of a peer. There's no
reason to make the section parser more complicated, when this is
essentially just another key value.

> 3) Make "wg show" display either "peer: orQ..." or "peer-some_custom_name: orQ..."
>
> 4) Any spaces in the "some_custom_name" text are ignored and truncated to 64 characters.

Yikes. I'm inclined to make Description or the like follow whatever
other plaintext rules the netfilter comment stuff has, not something
restrictive like "no spaces".

Jason