[Openvpn-devel] [PATCH applied] Re: Implement optional mtu parameter for mssfix

[Gert Doering]

Acked-by: Gert Doering 

Change makes sense, to take IPv4/IPv6 encap into account.

Code looks reasonable.

Tested with my previous mssfix test setup (and looking very carefully 
at tcpdump-reported "length" values, which one is "packet" and which 
one is "UDP encap" length :-) - that got me confused last time...).

 - BF-CBC, LZ4 (conf), --mssfix 1000 mtu, over IPv4
 v4 TCP -> MSS 890, resulting UDP payload 968, IP size 996 bytes
 v6 TCP -> MSS 870, resulting UDP payload 968, IP size 996 bytes
 (= OK, CBC rounding on 8 byte boundaries)
 - BF-CBC, LZ4 (conf), --mssfix 1000 mtu, over IPv6
 v4 TCP -> MSS 874, resulting UDP payload 952, IP size 1000 bytes
 v6 TCP -> MSS 854, resulting UDP payload 952, IP size 1000 bytes

 - AES256GCM, LZ4, --mssfix 1000 mtu, over IPv4
 v4 TCP -> MSS 907, resulting UDP payload 972, IP size 1000 bytes
 v6 TCP -> MSS 887, resulting UDP payload 972, IP size 1000 bytes
 - AES256GCM, LZ4, --mssfix 1000 mtu, over IPv6
 v4 TCP -> MSS 887, resulting UDP payload 952, IP size 1000 bytes
 v6 TCP -> MSS 867, resulting UDP payload 952, IP size 1000 bytes

"just for completeness" I've re-tested "without 'mtu'" for a few cases

  
 - BF-CBC, LZ4 (conf), --mssfix 1000 mtu, over IPv4
 v4 TCP -> MSS 922, resulting UDP payload 1000, IP size 1028 bytes
 v6 TCP -> MSS 902, resulting UDP payload 1000, IP size 1028 bytes

 - AES256GCM, LZ4, --mssfix 1000, over IPv4
 v4 TCP -> MSS 935, resulting UDP payload 1000, IP size 1028 bytes
 v6 TCP -> MSS 915, resulting UDP payload 1000, IP size 1028 bytes
 - AES256GCM, LZ4, --mssfix 1000, over IPv6
 v4 TCP -> MSS 935, resulting UDP payload 1000, IP size 1048 bytes
 v6 TCP -> MSS 915, resulting UDP payload 1000, IP size 1048 bytes

  (this is "as before", so the previously documented behaviour is not
   broken)


The "if (p[2]..." part of options.c is not perfect (it will check this
even if p[1] was already found to be NULL) but given the calling 
environment, it's well defined as all of p[] is CLEAR()ed on every 
line.

As discussed on IRC, I have adjusted the man page entry somewhat
(1473 was just plain wrong, 1478 is correct math, but I found the
"pass IPv4 packets" text still misleading wrt inside/outside IPv4)


For reference, this was 13/21 in the v1 and v2 series, got feedback
from Frank Lichtenheld.  I have adjusted the commit message according
to this (make the sentence a bit clearer).  The RST formatting comments
have been addressed in v2.

Your patch has been applied to the master branch.

commit 0fcb7cadb225d7f43e29c3ad6a1e9c34abbb8a63
Author: Arne Schwabe
Date:   Sat Jan 1 17:25:23 2022 +0100

 Implement optional mtu parameter for mssfix

 Signed-off-by: Arne Schwabe 
 Acked-by: Gert Doering 
 Message-Id: <20220101162532.2251835-6-a...@rfc2549.org>
 URL: 
https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg23495.html
 Signed-off-by: Gert Doering 


--
kind regards,

Gert Doering



___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

[Openvpn-devel] [PATCH applied] Re: msvc: switch to openssl3

[Gert Doering]

Haven't tested anything.  If you and Antonio say this works, good enough :)

Your patch has been applied to the master branch.

commit 225893ef7d06cdaf145436c54bd1070266a1d1da
Author: Lev Stipakov
Date:   Wed Jan 26 14:35:02 2022 +0200

 msvc: switch to openssl3

 Signed-off-by: Lev Stipakov 
 Acked-by: Antonio Quartulli 
 Message-Id: <20220126123502.403-1-lstipa...@gmail.com>
 URL: 
https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg23662.html
 Signed-off-by: Gert Doering 


--
kind regards,

Gert Doering



___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] [PATCH 1/2] crypto: move validation logic from cipher_get to cipher_valid

[David Sommerseth]

On 26/01/2022 17:28, Antonio Quartulli wrote:

With cipher validation performed in cipher_get(), a cipher is never
returned in any case if some check fails.

This prevents OpenVPN from operating on all ciphers provided by the SSL
library, like printing them to the user.

Move the validation logic to cipher_valid() so that checks are performed
only when OpenVPN really want to know if a cipher is usable or not.

Fixes: ce2954a0 ("Remove cipher_kt_t and change type to const char* in API")
Cc: Arne Schwabe 
Signed-off-by: Antonio Quartulli 
---

NOTE: mbedtls already follows this approach and did not require
any change.

  src/openvpn/crypto_openssl.c | 30 +++---
  1 file changed, 11 insertions(+), 19 deletions(-)

diff --git a/src/openvpn/crypto_openssl.c b/src/openvpn/crypto_openssl.c
index a725306c..ea0147db 100644
--- a/src/openvpn/crypto_openssl.c
+++ b/src/openvpn/crypto_openssl.c
@@ -565,16 +565,19 @@ rand_bytes(uint8_t *output, int len)
  static evp_cipher_type *
  cipher_get(const char *ciphername)
  {
-evp_cipher_type *cipher = NULL;
-
  ASSERT(ciphername);
  
  ciphername = translate_cipher_name_from_openvpn(ciphername);

-cipher = EVP_CIPHER_fetch(NULL, ciphername, NULL);
+return EVP_CIPHER_fetch(NULL, ciphername, NULL);
+}
  
-if (NULL == cipher)

+bool cipher_valid(const char *ciphername)


Nitpick - function return 'bool' should be on a line on its own.

[...]


@@ -585,7 +588,7 @@ cipher_get(const char *ciphername)
  {
  msg(D_LOW, "Cipher algorithm '%s' is known by OpenSSL library but "
  "currently disabled by running in FIPS mode.", 
ciphername);
-return NULL;
+return false;


It's missing an EVP_CIPHER_free(cipher) here.


  }
  #endif
  if (EVP_CIPHER_key_length(cipher) > MAX_CIPHER_KEY_LENGTH)
@@ -594,22 +597,11 @@ cipher_get(const char *ciphername)
  "which is larger than " PACKAGE_NAME "'s current maximum key size 
"
  "(%d bytes)", ciphername, EVP_CIPHER_key_length(cipher),
  MAX_CIPHER_KEY_LENGTH);
-return NULL;
+return false;


Missing EVP_CIPHER_free(cipher) here as well.


  }
  
-return cipher;

-}
-
-bool cipher_valid(const char *ciphername)
-{
-evp_cipher_type *cipher = cipher_get(ciphername);
-bool valid = (cipher != NULL);
-if (!valid)
-{
-crypto_msg(D_LOW, "Cipher algorithm '%s' not found", ciphername);
-}
  EVP_CIPHER_free(cipher);
-return valid;
+return true;


Maybe it would be better to have a 'bool ret = true' defined in the 
beginning and have an 'exit' label above the EVP_CIPHER_free() and at 
those two failure locations just set ret = false and goto exit?




--
kind regards,

David Sommerseth
OpenVPN Inc



OpenPGP_signature
Description: OpenPGP digital signature
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] [PATCH v2 2/2] msvc: switch to openssl3

[Antonio Quartulli]

Hi,

On 26/01/2022 13:35, Lev Stipakov wrote:

From: Lev Stipakov 

Add openssl3 vcpkg port, which is slightly modified version of
openssl1.1.1 port from official vcpkg repo.

Signed-off-by: Lev Stipakov 


Built this branch using GH actions and it worked for all archs.
I also smoke tested the x64 build on Win11 and it worked as expected.
Reported openssl version is 3.0.1, as expected.

I could establish a connection and have a working tunnel.

FWIW:

Acked-by: Antonio Quartulli 


--
Antonio Quartulli


OpenPGP_signature
Description: OpenPGP digital signature
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

[Openvpn-devel] [PATCH applied] Re: Fix datagram_overhead and assorted functions

[Gert Doering]

Acked-by: Gert Doering 

For reference, this was 12/21 in the first patch series, and got an
ACK from Frank Lichtenheld there.

Stared at the code.  Looks bigger than it really is :-) - what it
really does is pass on the socket address family down the call
chain to the "datagram_overhead()" function, which will then know
if it's v4 or v6.  

Should we ever support SCTP, we'll only have to adjust a single
function here, no mixture of functions and tables... :-)

Tested client and server side.  P2P NCP is still broken (waiting for 
13/14), Rest works.

Your patch has been applied to the master branch.

commit a63a727b020ef42c475bd861b960200686359b2d
Author: Arne Schwabe
Date:   Sat Jan 1 17:25:22 2022 +0100

 Fix datagram_overhead and assorted functions

 Signed-off-by: Arne Schwabe 
 Acked-by: Frank Lichtenheld 
 Acked-by: Gert Doering 
 Message-Id: <20220101162532.2251835-5-a...@rfc2549.org>
 URL: 
https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg23504.html
 Signed-off-by: Gert Doering 


--
kind regards,

Gert Doering



___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

[Openvpn-devel] [PATCH applied] Re: Change buffer allocation calculation and checks to be more static

[Gert Doering]

Acked-by: Gert Doering 

Tested on client and server side, all "regular" stuff works, but
it breaks my TCP/P2P/P2P-NCP test case for big packets, namely...

2022-02-02 12:57:19 TCP/UDP packet too large on write to 
[AF_INET6]2001:608:0:814::f000:11:51204 (tried=1520,max=1499)

(expected result: oversized packet, fragment/segment on outer layer)

After discussion on IRC, decided to go forward anyway, as this is only
one specific corner case (P2P NCP), and it gets fixed for good in 13/14 
- removing EXPANDED_SIZE() in forward.c, replacing it with just 
"buf.payload_size", which always has "sufficient headroom" - tested,
fixes this corner case, doesn't break anything else.


(For reference, this was 10/21 in v1 of the patchset, 03/14 in v3, and
standalone patches v4+v5 - but neither of the previous ones got an ACK
or NAK, just MaxF finding ways to crash v3 and v4 ;-) )

Your patch has been applied to the master branch.

commit 65a21eb14f4afd80864e88ff425f5d9ef8d8fdec
Author: Arne Schwabe
Date:   Mon Jan 24 03:54:59 2022 +0100

 Change buffer allocation calculation and checks to be more static

 Signed-off-by: Arne Schwabe 
 Acked-by: Gert Doering 
 Message-Id: <20220124025459.1042317-1-a...@rfc2549.org>
 URL: 
https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg23638.html
 Signed-off-by: Gert Doering 


--
kind regards,

Gert Doering



___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

[Openvpn-devel] [PATCH applied] Re: Change buffer allocation calculation and checks to be more static

[Gert Doering]

Acked-by: Gert Doering 

Tested on client and server side, all "regular" stuff works, but
it breaks my TCP/P2P/P2P-NCP test case for big packets, namely...

2022-02-02 12:57:19 TCP/UDP packet too large on write to 
[AF_INET6]2001:608:0:814::f000:11:51204 (tried=1520,max=1499)

(expected result: oversized packet, fragment/segment on outer layer)

After discussion on IRC, decided to go forward anyway, as this is only
one specific corner case (P2P NCP), and it gets fixed for good in 13/14 
- removing EXPANDED_SIZE() in forward.c, replacing it with just 
"buf.payload_size", which always has "sufficient headroom" - tested,
fixes this corner case, doesn't break anything else.


(For reference, this was 10/21 in v1 of the patchset, 03/14 in v3, and
standalone patches v4+v5 - but neither of the previous ones got an ACK
or NAK, just MaxF finding ways to crash v3 and v4 ;-) )

Your patch has been applied to the master branch.

commit 65a21eb14f4afd80864e88ff425f5d9ef8d8fdec
Author: Arne Schwabe
Date:   Mon Jan 24 03:54:59 2022 +0100

 Change buffer allocation calculation and checks to be more static

 Signed-off-by: Arne Schwabe 
 Acked-by: Gert Doering 
 Message-Id: <20220124025459.1042317-1-a...@rfc2549.org>
 URL: 
https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg23638.html
 Signed-off-by: Gert Doering 


--
kind regards,

Gert Doering



___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] [PATCH v5] Change buffer allocation calculation and checks to be more static

[Gert Doering]

Hi,

On Mon, Jan 24, 2022 at 03:54:59AM +0100, Arne Schwabe wrote:
> Currently we use half dynamic buffer sizes where we use have a fixed
> overhead for crypto (crypto_max_overhead) but use a dynamic overhead
> for the the other small header sizes.
> 
> Patch v3: rebase
> Patch v4: add size of ack array to control channel frame size
> Patch v5: fix calculation of compression overhead calculated over 0 instead
>   of payload size

Generally this looks okayish, and *most* t_client / t_server tests work
beautifully.

It does break --tls-client --proto tcp for me, for big packets, though...

The client is called like this:

openvpn --ca ... --cert ... --key ... --comp-lzo --verb 3 --tls-client --dev 
tap --proto tcp-client --remote gentoo.ov.greenie.net 51204 --ifconfig 
10.204.9.2 255.255.255.0 --comp-lzo --tun-ipv6 --ifconfig-ipv6 
fd00:abcd:204:9::2/64 fd00:abcd:204:9::1 --route 10.204.0.0 255.255.0.0 
10.204.9.1 --route-ipv6 fd00:abcd:204::/48 --data-ciphers BF-CBC

and will do

2022-02-02 12:56:52 peer info: IV_CIPHERS=BF-CBC:AES-256-GCM:AES-128-GCM
2022-02-02 12:56:52 peer info: IV_PROTO=42
2022-02-02 12:56:52 WARNING: 'tun-mtu' is used inconsistently, local='tun-mtu 
1500', remote='tun-mtu 1532'
2022-02-02 12:56:52 P2P mode NCP negotiation result: TLS_export=1, DATA_v2=1, 
peer-id 897556, cipher=BF-CBC
2022-02-02 12:56:52 Control Channel: TLSv1.3, cipher TLSv1.3 
TLS_AES_256_GCM_SHA384, peer certificate: 2048 bit RSA, signature: RSA-SHA1
2022-02-02 12:56:52 [server] Peer Connection Initiated with 
[AF_INET6]2001:608:0:814::f000:11:51204
2022-02-02 12:56:53 OPTIONS IMPORT: adjusting link_mtu to 1579
2022-02-02 12:56:53 Outgoing Data Channel: Cipher 'BF-CBC' initialized with 128 
bit key
2022-02-02 12:56:53 Outgoing Data Channel: Using 160 bit message hash 'SHA1' 
for HMAC authentication


when sending 1440 byte pings (t_client test) it will complain

2022-02-02 12:56:15 TCP/UDP packet too large on write to 
[AF_INET6]2001:608:0:814::f000:11:51204 (tried=1520,max=1499)
2022-02-02 12:56:15 TCP/UDP packet too large on write to 
[AF_INET6]2001:608:0:814::f000:11:51204 (tried=1520,max=1499)
2022-02-02 12:56:15 TCP/UDP packet too large on write to 
[AF_INET6]2001:608:0:814::f000:11:51204 (tried=1520,max=1499)


soo...  is this something that "should be fixed" by a later patch in the
series, or do we need a v6 of this one?


The same test works correctly with master as of right now (5b3c8ca86976).

gert
-- 
"If was one thing all people took for granted, was conviction that if you 
 feed honest figures into a computer, honest figures come out. Never doubted 
 it myself till I met a computer with a sense of humor."
 Robert A. Heinlein, The Moon is a Harsh Mistress

Gert Doering - Munich, Germany g...@greenie.muc.de


signature.asc
Description: PGP signature
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

[Openvpn-devel] [PATCH applied] Re: Fix mssfix and frame calculation in CBC mode

[Gert Doering]

Acked-by: Gert Doering 

This came out of discussions on the "last" mssfix patch (d4458eed0c3,
"Decouple MSS fix calculation") where I discovered that sometimes we'd 
still see too-big payloads for BF-CBC - this was a rounding issue, and 
also an interpretation issue on "which parts of the frame are considered 
'plaintext' or 'header', depending on CBC vs. AEAD mode".  See this:

https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg23481.html

Stared at code, scratched my head, tested client and server side
("normal packet tests" - everything passes) and explicitly tested 
combinations for resulting packet size.

Thus, tested:

 - BF-CBC, LZ4 (pushed), --mssfix 1000, over IPv4
 v4 TCP -> MSS 923, resulting UDP payload <= 1008 bytes
 v6 TCP -> MSS 903, resulting UDP payload <= 1008 bytes
 - BF-CBC, LZ4 (pushed), --mssfix 1000, over IPv6
 v4 TCP -> MSS 923, resulting UDP payload <= 1008 bytes
 v6 TCP -> MSS 903, resulting UDP payload <= 1008 bytes
 [so this is clearly wrong, but see below]

 - BF-CBC, comp no, --mssfix 1000, over IPv4
 v4 TCP -> MSS 923, resulting UDP payload <= 1000 bytes
 [OK]

 - AES256GCM, LZ4, --mssfix 1000, over IPv4
 v4 TCP -> MSS 935, resulting UDP payload <= 1000 bytes
 v6 TCP -> MSS 915, resulting UDP payload <= 1000 bytes
 - AES256GCM, LZ4, --mssfix 1000, over IPv6
 v4 TCP -> MSS 935, resulting UDP payload <= 1000 bytes
 v6 TCP -> MSS 915, resulting UDP payload <= 1000 bytes

 - AES256GCM, comp no, --mssfix 1000, over IPv4
 v4 TCP -> MSS 936, resulting UDP payload <= 1000 bytes

--> so it looks as if the CBC code is not handling the compression
framing and then rounding up and down and sideways correctly...

I've discussed this with Arne, and the result of that was "it's due
to option recalculation wackiness if cipher does not change, but
other options do".

So, the failing test above has no compression setting in the client
config *but* permits pushed LZ4.  If I change that towards
"client has compress lz4", the result changes:

 - BF-CBC, LZ4 (config), --mssfix 1000, over IPv4
 v4 TCP -> MSS 922 (from 923), resulting UDP payload <= 1000 bytes
 v6 TCP -> MSS 902 (from 903), resulting UDP payload <= 1000 bytes

so the resulting packets are correct.  The fix for the underlying issue
comes later in the patch series.


Given that these corner cases have been wrong all the time, it makes
sense to merge this patch as it is (nothing is getting worse), and 
re-test when the dewackyfying patch is in.


I have fixed one comment in mss.c

Your patch has been applied to the master branch.

commit 5b3c8ca869766de2c94eb7dd4450b0d9ab1c75fc
Author: Arne Schwabe
Date:   Sat Jan 1 17:25:20 2022 +0100

 Fix mssfix and frame calculation in CBC mode

 Signed-off-by: Arne Schwabe 
 Acked-by: Gert Doering 
 Message-Id: <20220101162532.2251835-3-a...@rfc2549.org>
 URL: 
https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg23494.html
 Signed-off-by: Gert Doering 


--
kind regards,

Gert Doering



___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

[Openvpn-devel] Summary of the community meeting (2nd February 2022)

[Samuli Seppänen]

Hi,

Here's the summary of the IRC meeting.

---

COMMUNITY MEETING

Place: #openvpn-meeting on libera.chat
Date: Wed 2nd February 2022
Time: 10:30 CET (9:30 UTC)

Planned meeting topics for this meeting were here:



Your local meeting time is easy to check from services such as



SUMMARY

cron2, dazo, lev, mattock, novaflash, ordex and plaisthos participated 
in this meeting.


---

Novaflash will have OpenVPN Inc ("corp") tickets in Trac reviewed.

---

Talked about OpenSSL 3 and easyrsa3. According to wiscii the changes 
required are minor, so we should be able to continue using easyrsa3. The 
fix could even be applied on the fly as a patch.


---

Agreed that we should release 2.4.12 after completing mattock's ongoing 
tasks. In particular:


- Windows EC2 buildbot worker (requires a small fix + buildbot glue)
- ovpn-dco packaging (not started)

---

Talked about OpenVPN 2.6 release. There are plenty of patches to review 
and test. For the gory details refer to the full chatlog.


---

Noted that OpenSSL 3.0.0 (bundled with Fedora 36 right now) should work 
with OpenVPN just fine, even though you might encounter some deprecation 
warnings if using it.


---

Note that there's no progress on the community IPv6 front.

---

The new community Buildbot is now in production and is tracking almost 
all openvpn projects worth building. TheWindows EC2 buildbot worker is 
almost done. The new community VPN server is available for real people 
and buildbot workers alike. Cron2 will try to get one of this buildbot 
workers connected to buildmaster before the next meeting.


--

Full chatlog attached(11.31.25) mattock: hello
(11.32.19) cron2: meow
(11.33.23) lev__: hellow
(11.33.42) dazo: Yo!
(11.36.21) mattock: https://community.openvpn.net/openvpn/wiki/Topics-2022-02-02
(11.36.41) cron2 ha scelto come argomento: 
https://community.openvpn.net/openvpn/wiki/Topics-2022-02-02
(11.37.12) cron2: that agenda looks messy
(11.37.41) mattock: I cannot be blamed because it's not my doing!
(11.39.16) cron2: fixed
(11.39.32) novaflash [~novafl...@185-227-75-241.dsl.cambrium.nl] è entrato 
nella stanza.
(11.39.58) cron2: updated
(11.40.56) dazo: lets kick off with 2 and throw novaflash under the bus! ;-)
(11.41.12) novaflash: that's where i belong
(11.43.29) cron2: so... #2 can be handled fairly quickly... can we revive the 
activities regarding corp products in community trac again, please?  thanks :-)
(11.44.08) dazo: novaflash: can you follow up on that? ^^^
(11.44.15) novaflash: yeah.. i'll see what can be done
(11.44.24) cron2: thanks!
(11.44.40) cron2: #1 is "what can we do about easyrsa3 with openssl3"
(11.45.01) cron2: wiscii says "it just works, with a small bugfix", if I 
understood that right (over in #openvpn-devel)
(11.47.12) cron2: consequence of that: we should be able to ship 2.6 with 3.0.1
(11.47.37) dazo: What does "small bugfix" imply?
(11.48.09) cron2: either it gets fixed upstream or we patch at build time 
("like we do for pkcs11-helper, etc.")
(11.48.37) dazo: fine ... but how small is that fix?
(11.49.14) novaflash: 2 inches
(11.49.35) cron2: he did not say... backlog in #openvpn-devel of today around 
2am
(11.54.53) dazo: If an updated easy-rsa could be made available soonish, we're 
all good.  That would also indicate how small and intrusive the change is.
(11.56.14) mattock: +1
(11.57.00) mattock: sync up?
(11.57.59) cron2: I can live with having the patch available just fine
(11.58.44) cron2: getting the patch merged could be complicated, if there is no 
active maintainer
(11.58.58) dazo: We should probably get 2.4 into that list  do we have 
anything in the pipe for 2.4?  Just to do the last release before switching to 
old-stable
(11.59.25) dazo: cron2: I'll try to reach out to ecrist and check the situation
(11.59.34) ordex: hi hi
(11.59.35) cron2: 2.4 has some minor bugfixes
(11.59.36) ordex: sorry for being late
(11.59.59) dazo: Does 2.4 have any unreviewed changes we want to include?
(12.00.08) cron2: not that I'm aware
(12.00.28) dazo: so, basically we can do a 2.4 release as soon as mattock is 
ready for it then ...
(12.00.59) mattock: I suggest "after windows EC2 buildbot worker and after 
ovpn-dco packaging"
(12.01.19) mattock: the former is lacking a small fix (authorization issue) + 
buildbot glue
(12.01.27) dazo: https://termbin.com/zcmq   shortlog 2.4.11 to release/2.4
(12.01.31) mattock: the latter I did not start doing, but ordex may be on it
(12.02.36) dazo: Agreed ... lets complete on-going tasks, then do the 2.4.12
(12.03.08) d12fk ha abbandonato la stanza (quit: Remote host closed the 
connection).
(12.03.20) d12fk [~he...@exit0.net] è entrato nella stanza.
(12.04.55) mattock: 2.6?
(12.05.04) mattock: Windows builds + openssl?
(12.05.27) lev__: there are few patches waiting for review
(12.05.35) lev__: related to ossl3
(12.05.36) cron2: I managed to get one buffer pa

[Openvpn-devel] Community meetings in February 2022

[Samuli Seppänen]

Hi,

Next community meetings have been scheduled to

- Wed 2nd February 2022 at 10:30 CET (ongoing)

- Wed 9th February 2022 at 10:30 CET

- Wed 16th February 2022 at 10:30 CET

- Wed 23rd February 2022 at 10:30 CET


The place is #openvpn-meeting IRC channel at libera.chat Meeting agendas
and summaries are in here:



Samuli




___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel