[Openvpn-devel] [PATCH applied] Re: dco: turn platform config checks into separate function

Tested this on the Linux / DCO server test rig that found the issue yesterday - the "no root" server now does no longer reject clients on connect, so that problem is fixed. Thanks :-) To verify that the startup function is actually used, I triggered it with - openvpn --mktun --dev tun99 - o

Re: [Openvpn-devel] wolfSSL unit test failures

Hi, On Thu, Aug 18, 2022 at 12:40:09AM +0200, Arne Schwabe wrote: > From 02d4c4d8444188bdf32a054171ea7e20cc7c12ff Mon Sep 17 00:00:00 2001 > From: Arne Schwabe > Date: Thu, 11 Aug 2022 19:27:12 +0200 > Subject: [PATCH] Add wolfSSL to github actions > > I just want to see the world burn a little

Re: [Openvpn-devel] [PATCH v2] push-peer-info: rearrange function generating peer info

HI, On Thu, Aug 18, 2022 at 02:19:05AM +0200, Antonio Quartulli wrote: > This patch is supposed to implement no function change. > The only change in behaviour that can be observed is the IV_/UV_ variables > being printed in different order compared to before applying this patch. I agree with the

Re: [Openvpn-devel] [PATCH] close_tun: print interface type consistently in message

Hi, On Thu, Aug 18, 2022 at 02:13:58AM +0200, Antonio Quartulli wrote: > When closing the tunnel interface we know if we were using DCO or not. > for this reason we can customize the closing message and make it > consistent with the opening one. > > Signed-off-by: Antonio Quartulli > --- > src/

[Openvpn-devel] Possible bug?

Hi, I just moved from Ubuntu 20.04 LTS (where the exact command works fine and does not prompt for pass phrase) to Red Hat Enterprise Linux 9 and installed Easy-RSA via EPEL. When I run ./easyrsa build-ca nopass as root, it still prompts for PEM pass phrase: # ./easyrsa build-ca nopass Using

[Openvpn-devel] [PATCH v2] push-peer-info: rearrange function generating peer info

This patch is supposed to implement no function change. The only change in behaviour that can be observed is the IV_/UV_ variables being printed in different order compared to before applying this patch. However, order does not matter, so we don't need to retain it. What this change really does i

[Openvpn-devel] [PATCH] close_tun: print interface type consistently in message

When closing the tunnel interface we know if we were using DCO or not. for this reason we can customize the closing message and make it consistent with the opening one. Signed-off-by: Antonio Quartulli --- src/openvpn/init.c | 10 +- 1 file changed, 9 insertions(+), 1 deletion(-) diff -

[Openvpn-devel] [PATCH] push-peer-info: rearrange function generating peer info

This patch is supposed to implement no function change. The only change in behaviour that can be observed is the IV_/UV_ variables being printed in different order compared to before applying this patch. However, order does not matter, so we don't need to retain it. What this change really does i

Re: [Openvpn-devel] [PATCH] dco: turn platform config checks into separate function

Hi, On 17/08/2022 23:08, Timo Rothenpieler wrote: All the checks in there are only relevant during startup, and specifically the capability check might cause issues when checking a CCD config later at runtime. So move them to their own function and call it only during startup. simple enough a

[Openvpn-devel] wolfSSL unit test failures

Hey, currently we still have test failures in wolfSSL in EVP_PKEY_CTX_new with clang asan. Github action patch that reproduces this also attached. With the OpenVPN 2.6 release coming up in the next months it would be good if these can be fixed. These look like problems in the upstream wolfSSL

[Openvpn-devel] [PATCH] dco: turn platform config checks into separate function

All the checks in there are only relevant during startup, and specifically the capability check might cause issues when checking a CCD config later at runtime. So move them to their own function and call it only during startup. --- src/openvpn/dco.c | 9 ++--- src/openvpn/dco.h | 18

[Openvpn-devel] [PATCH v2] dco.h: fix return type when DCO is not enabled

From: Lev Stipakov The correct return type for those functions is int, so adjust return type accordingly for the cases when DCO is not defined. Signed-off-by: Lev Stipakov --- v2: also do "return 0" in dco_p2p_add_new_peer() src/openvpn/dco.h | 8 1 file changed, 4 insertions(+), 4

[Openvpn-devel] [PATCH applied] Re: Include DCO status in GLOBAL_STATS status v2 output

I have lightly tested it, by sending SIGUSR2 as Lev has suggested. It's not visible in the client GLOBAL_STATS (unsurprisingly, since added to multi_print_status()... but maybe a followup patch?) but on the servers it nicely shows... Aug 17 21:31:59 ubuntu2004 tap-udp-p2mp[2183229]: GLOBAL_STATS

[Openvpn-devel] [PATCH applied] Re: dco: don't pass VPN IPs to NEW_PEER API in P2P mode

Acked-by: Gert Doering This goes hand in hand with commit 383a897a5cb040d065689 in the ovpn-dco repo ("require peer VPN IPs only in multipoint mode"). If the kernel does no longer want this from us, no need to have it here. Also, the kernel change fixes the edge case I found (ipv4-only without

Re: [Openvpn-devel] [PATCH applied] Re: dco: disable DCO if --user specified but unable to retain capabilities

Hi, On Wed, Aug 17, 2022 at 04:18:39PM +0200, Gert Doering wrote: > Acked-by: Gert Doering > > Thanks. Bernhard has already tested this on his Debian/NM testing > environment and confirms it fixes the issues seen in > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1017379 > > I've adde

Re: [Openvpn-devel] [PATCH applied] Re: platform: Retain CAP_NET_ADMIN when dropping privileges

Hi, On Mon, Aug 15, 2022 at 11:54:21AM +0200, Gert Doering wrote: > [..] > > commit 2e359a088226ab1e5ee41fbab27d38d8a8d192ac > > Author: Timo Rothenpieler > > Date: Sat May 14 12:37:17 2022 +0200 > > > > platform: Retain CAP_NET_ADMIN when dropping privileges > > Unfortunately, it seems t

Re: [Openvpn-devel] [PATCH] dco_p2p_add_new_peer: do not warn about missing default gw

Hi, On Wed, Aug 10, 2022 at 11:46:05AM +0200, Frank Lichtenheld wrote: > Currently we issue a message when using --ifconfig but > not specifying a default gateway. This seems to be misleading, > the setup will still work fine since in P2P we now send > all traffic to the peer anyway. Or it might b

Re: [Openvpn-devel] [PATCH] dco.h: fix return type when DCO is not enabled

Hi, On Wed, Aug 17, 2022 at 01:03:19PM +0200, Lev Stipakov wrote: > From: Lev Stipakov > > The correct return type for those functions is int, > so adjust return type accordingly for the cases > when DCO is not defined. The change is fine, but you only go halfway... > --- > src/openvpn/dco.h

[Openvpn-devel] [PATCH applied] Re: Rename OPT_P_IPWIN32 to OPT_P_DHCPDNS and include --dns in it

Acked-by: Gert Doering Looks like a reasonable change (so, feature-ACK), and stare-at-code agrees. Basically, this renames OPT_P_IPWIN32 to OPT_P_DHCPDNS and mechanically changes this in all the code, adds "DNS" to the --route-nopull help text, and changes the "dns" permissions from DEFAULT to

[Openvpn-devel] [PATCH applied] Re: Fix IV_PLAT_VER and UV_ variables sent without push-peer-info

I have not tested this, but it's obvious enough from the changes in said commit. Your patch has been applied to the master branch. commit e0dbe5c4e290c0c24a26a9e5c19957ebaca09543 Author: Arne Schwabe Date: Wed Aug 17 15:53:48 2022 +0200 Fix IV_PLAT_VER and UV_ variables sent without push-

Re: [Openvpn-devel] [PATCH v2] Fix IV_PLAT_VER and UV_ variables sent without push-peer-info

Hi, On 17/08/2022 15:53, Arne Schwabe wrote: Commit 8c72d7981 changed the push_peer_info_detail to have an additional level for P2P NCP and shifting most of the other levels with 1. The check for UV_ and IV_PLAT_VER was not changed accordingly. Fixes: 8c72d7981 ("Support NCP in pure P2P VPN set

[Openvpn-devel] [PATCH applied] Re: dco: disable DCO if --user specified but unable to retain capabilities

Acked-by: Gert Doering Thanks. Bernhard has already tested this on his Debian/NM testing environment and confirms it fixes the issues seen in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1017379 I've added a bit of explanatory text to the commit message (quite a bit of blurb, actually,

[Openvpn-devel] [PATCH applied] Re: Github Actions: update used actions

Applied :-) - had a look, looks as discused, GHA has to do the testing. Your patch has been applied to the master branch. commit 9b17fed14bc534353d9a5e2d90d902bb093df3c2 Author: Timo Rothenpieler Date: Wed Aug 17 15:23:02 2022 +0200 Github Actions: update used actions Acked-by: Arne

[Openvpn-devel] [PATCH v2] Fix IV_PLAT_VER and UV_ variables sent without push-peer-info

Commit 8c72d7981 changed the push_peer_info_detail to have an additional level for P2P NCP and shifting most of the other levels with 1. The check for UV_ and IV_PLAT_VER was not changed accordingly. Fixes: 8c72d7981 ("Support NCP in pure P2P VPN setups") Signed-off-by: Arne Schwabe --- src/open

Re: [Openvpn-devel] [PATCH v2] Github Actions: update used actions

Am 17.08.22 um 15:23 schrieb Timo Rothenpieler: In the case of the Microsoft action, this fixes security relevant issues according to their release notes: https://github.com/microsoft/setup-msbuild/releases Unfortunately they don't appear to be following the usual scheme of v1 referring to all

[Openvpn-devel] [PATCH v2] Github Actions: update used actions

In the case of the Microsoft action, this fixes security relevant issues according to their release notes: https://github.com/microsoft/setup-msbuild/releases Unfortunately they don't appear to be following the usual scheme of v1 referring to all v1.x.x, but instead v1 just points to v1.0.0. Th

Re: [Openvpn-devel] [PATCH] Github Actions: update used actions

On 17/08/2022 15:12, Arne Schwabe wrote: Hey, newest and greatest is always nice but could you give a bit more rationale why we should update? The commit message is unfortunately not giving any details. In the case of the Microsoft action, it actually fixes security relevant issues accordin

[Openvpn-devel] [PATCH] dco: disable DCO if --user specified but unable to retain capabilities

--- src/openvpn/dco.c | 26 ++ 1 file changed, 26 insertions(+) diff --git a/src/openvpn/dco.c b/src/openvpn/dco.c index caa4ce32..b7db23f4 100644 --- a/src/openvpn/dco.c +++ b/src/openvpn/dco.c @@ -44,6 +44,10 @@ #include "ssl_ncp.h" #include "tun.h" +#ifdef HAVE_LIBC

Re: [Openvpn-devel] [PATCH] Github Actions: update used actions

Hey, newest and greatest is always nice but could you give a bit more rationale why we should update? The commit message is unfortunately not giving any details. Arne ___ Openvpn-devel mailing list Openvpn-devel@lists.sourceforge.net https://lists

[Openvpn-devel] [PATCH] Github Actions: update used actions

--- .github/workflows/build.yaml | 24 1 file changed, 12 insertions(+), 12 deletions(-) diff --git a/.github/workflows/build.yaml b/.github/workflows/build.yaml index c89d3c8c..49b7d6d1 100644 --- a/.github/workflows/build.yaml +++ b/.github/workflows/build.yaml @@ -13,7

Re: [Openvpn-devel] Fix IV_PLAT_VER and UV_ variables sent without push-peer-info

Patch is easy and by looking at the "breaking" commit it is easy to understand what happened: peer-info-detail levels have been shifted by one and what was "2" before is now "3". So the check that decides to append the extra info should check for ">= 3" (or "> 2") now. This patch makes this

[Openvpn-devel] [PATCH] dco.h: fix return type when DCO is not enabled

From: Lev Stipakov The correct return type for those functions is int, so adjust return type accordingly for the cases when DCO is not defined. Signed-off-by: Lev Stipakov --- src/openvpn/dco.h | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/src/openvpn/dco.h b/src/op

[Openvpn-devel] Summary of the community meeting (17th August 2022)

Hi, Here's the summary of the IRC meeting. --- COMMUNITY MEETING Place: #openvpn-meeting on libera.chat Date: Wed 17th August 2022 Time: 10:30 CEST (9:30 UTC) Planned meeting topics for this meeting were here: Your local meeting

[Openvpn-devel] [PATCH] Rename OPT_P_IPWIN32 to OPT_P_DHCPDNS and include --dns in it

The dns options are very similar to dhcp-option and should fall under the same option mask. For that rename the OPT_P_IPWIN32 mask to OPT_P_DHCPDNS and include dns in it. This effects currently route-nopull which block all host side network/dns configuration but did not block the new dns option. -