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

[Lonnie Abelbeck <lists@lonnie.abelbeck.com>]

On Dec 7, 2017, at 10:23 PM, Jason A. Donenfeld <Jason@zx2c4.com> wrote:

> Thanks for sending this to the mailing list. Indeed it got lost in the
> fold of disorganized email filters when you sent it to me directly
> twice earlier; sorry about that.

The latest patch is reworked, disabled by default and requires =
WITH_PEERDATA=3Dyes to be enabled.

> I'm not certain this is the right approach -- having wg(8) rely on
> fixed filesystem paths, and splitting peer configuration information
> across three places (original config file, peer data file, kernel).

I'm just trying to find a solution with traction.  My latest patch works =
perfectly fine on our Linux appliance, but alternate approaches could be =
a more general solution.

> I think the way forward for this kind of feature would be what I
> proposed in an earlier thread, of attaching it to the kernel object,
> just like ifalias does or netfilter's comment target. However, the
> question I'm still faced with is -- is this really necessary?

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.

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.

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.

Suggested configuration syntax:

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.

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.

Thanks for your consideration.

Lonnie