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
| ||
|
Message-ID: <875zipihhk.fsf@toke.dk> 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
Powered by blists - more mailing lists