netdev - Re: [PATCH net-next v2 04/22] ovpn: add basic interface creation/destruction/management routines

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <b1b50cad-30dd-4002-8950-0869d636b6a7@lunn.ch>
Date: Fri, 8 Mar 2024 14:13:33 +0100
From: Andrew Lunn <andrew@...n.ch>
To: Antonio Quartulli <antonio@...nvpn.net>
Cc: netdev@...r.kernel.org, Jakub Kicinski <kuba@...nel.org>,
	Sergey Ryazanov <ryazanov.s.a@...il.com>,
	Paolo Abeni <pabeni@...hat.com>, Eric Dumazet <edumazet@...gle.com>
Subject: Re: [PATCH net-next v2 04/22] ovpn: add basic interface
 creation/destruction/management routines

> To be honest we don't have any real concept for the carrier off.
> Especially on a server, I hardly believe it would be any useful.
> 
> However, on a client or on a p2p link, where there is exactly one remote
> host on the other side, it may make sense to turn the carrier off when that
> remote peer is lost.
> 
> There is an extra detail to consider: if the user wants to, the ovpn device
> should remain configured (with all IPs and routes) even if openvpn has fully
> disconnected and it is attempting a reconnection to another server. Reason
> being avoiding data leaks by accidentally removing routes to the tunnel
> (traffic that should go through the tunnel would rather go to the local
> network).
> 
> With all this being said, it may make sense to just keep the carrier on all
> time long.
> 
> Should we come up with something smarter in the future, we can still improve
> this behaviour.

O.K, so..

You already have more patches than recommended for a series, but... I
suggest you make the carrier_on in probe() a patch of its own with a
good commit message based on the above. We then have a clear
explanation in git why the carrier is always on.

	Andrew