netdev - Re: organization of wireguard linux kernel repos moving forward

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:   Mon, 09 Dec 2019 17:36:07 +0100
From:   Toke Høiland-Jørgensen <toke@...e.dk>
To:     David Ahern <dsahern@...il.com>,
        "Jason A. Donenfeld" <Jason@...c4.com>
Cc:     WireGuard mailing list <wireguard@...ts.zx2c4.com>,
        Netdev <netdev@...r.kernel.org>,
        Stephen Hemminger <stephen@...workplumber.org>
Subject: Re: organization of wireguard linux kernel repos moving forward

David Ahern <dsahern@...il.com> writes:

> On 12/9/19 5:49 AM, Jason A. Donenfeld wrote:
>> I'd definitely be interested in this. Back in 2015, that was the plan.
>> Then it took a long time to get to where we are now, and since then
>> wg(8) has really evolved into its own useful thing. The easiest thing
>> would be to move wg(8) wholesale into iproute2 like you suggested;
>> that'd allow people to continue using their infrastructure and whatnot
>> they've used for a long time now. A more nuanced approach would be
>> coming up with a _parallel_ iproute2 tool with mostly the same syntax
>> as wg(8) but as a subcommand of ip(8). Originally the latter appealed
>> to me, but at this point maybe the former is better after all. I
>> suppose something to consider is that wg(8) is actually a
>> cross-platform tool now, with a unified syntax across a whole bunch of
>> operating systems. But it's also just boring C.
>
> If wg is to move into iproute2, it needs to align with the other
> commands and leverage the generic facilities where possible. ie., any
> functionality that overlaps with existing iproute2 code to be converted
> to use iproute2 code.

Thought that might be the case :)

That means a re-implementation, then. In which case the question becomes
whether it's better to do it as an 'ip' subcommand (or even just new
parameters to 'ip link'), or a new top-level utility striving for
compatibility with 'wg'. But that's mostly a UI issue...

-Toke