Re: [Openvpn-devel] [PATCH 1/1] Rework mbedtls CRL handling

2021-04-07 Thread Antonio Quartulli
Hi Max,

On 07/04/2021 21:15, Max Fillinger wrote:
> This commit fixes the following two issues:
> 
> The config belonging to a mbedtls_ssl_ctx struct is not supposed to be
> changed after mbedtls_ssl_setup() has been called. Previously, we
> modified the CRL structure in place when a new CRL was loaded, but a
> pointer to this struct appears in configs that are currently in use.
> 
> This commit uses reference counting to ensure that CRLs remain in memory
> while the mbedtls_ssl_ctx struct and config remain.
> 

To fix this issue, wouldn't be enough to reload the CRL *before* calling
mbedtls_ssl_setup()?
This way we know that a new ssl_ctx is always initialized with the
latest CRL, rather than having the old one still around?

I have attached a proposal for your review. Please let me know what you
think about it.

As a side note: how did you notice this issue?

> The other issue fixed by this commit is that, if OpenVPN failed to read
> the CRL in init_ssl(), but succeeded in reading it later, it would not
> actually use that CRL.

Mh... I have tried to reproduce this issue, but I was not able to.
Would you be able to provide me with the exact steps to hit this situation?

What I tried was:
1) create empty file crl.pem;
2) start server with --crl-verify crl.pem;
3) connect with client -> connection denied due to verification issue
(VERIFY ERROR: CRL not loaded);
4) I overwrote crl.pem with a real CRL (without restarting the server);
5) I connected with my client and it worked;
6) I connected with a certificate in the CRL -> connection denied.


Btw, Signed-off-by line is missing - a patch submitted for inclusion
should always have one.



Regards,


-- 
Antonio Quartulli
diff --git a/src/openvpn/ssl.c b/src/openvpn/ssl.c
index d8662d00..eda7fae1 100644
--- a/src/openvpn/ssl.c
+++ b/src/openvpn/ssl.c
@@ -899,6 +899,17 @@ key_state_init(struct tls_session *session, struct key_state *ks)
 
 CLEAR(*ks);
 
+/*
+ * Attempt CRL reload before any TLS operation. Won't be performed if
+ * the file was not modified since the last reload
+ */
+if (session->opt->crl_file
+&& !(session->opt->ssl_flags & SSLF_CRL_VERIFY_DIR))
+{
+tls_ctx_reload_crl(>opt->ssl_ctx, session->opt->crl_file,
+   session->opt->crl_file_inline);
+}
+
 /*
  * Build TLS object that reads/writes ciphertext
  * to/from memory BIOs.
@@ -2728,17 +2739,6 @@ tls_process(struct tls_multi *multi,
 ks->state = S_START;
 state_change = true;
 
-/*
- * Attempt CRL reload before TLS negotiation. Won't be performed if
- * the file was not modified since the last reload
- */
-if (session->opt->crl_file
-&& !(session->opt->ssl_flags & SSLF_CRL_VERIFY_DIR))
-{
-tls_ctx_reload_crl(>opt->ssl_ctx,
-   session->opt->crl_file, session->opt->crl_file_inline);
-}
-
 /* New connection, remove any old X509 env variables */
 tls_x509_clear_env(session->opt->es);
 
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel


[Openvpn-devel] [PATCH 0/1] CRL issues with mbedtls

2021-04-07 Thread Max Fillinger
This patch fixes the bug I wrote about earlier[0] where the mbedtls
version of OpenVPN might not properly reload a CRL when running in a
chroot. I've submitted a somewhat hacky patch for it[1].

While looking into it further, I also noticed another unrelated problem:

The mbedtls documentation states that the config struct for a
mbedtls_ssl_context is not supposed to be modified after calling
mbedtls_ssl_setup(). However, the config contains a pointer to the CRL,
and we're currently modifying the CRL in place when we reload it.

I figured that by reworking the way CRLs are handled, I could fix the
CRL reloading bug in a less hacky manner and also make sure that we
don't modify the configs of active mbedtls_ssl_contexts.

[0] https://sourceforge.net/p/openvpn/mailman/message/37254045/
[1] https://sourceforge.net/p/openvpn/mailman/message/37254048/

Max Fillinger (1):
  Rework mbedtls CRL handling

 src/openvpn/ssl.c|   8 +++
 src/openvpn/ssl_mbedtls.c| 103 ++-
 src/openvpn/ssl_mbedtls.h|  25 +-
 src/openvpn/ssl_verify_mbedtls.c |   2 +-
 4 files changed, 125 insertions(+), 13 deletions(-)

-- 
2.11.0



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


[Openvpn-devel] [PATCH 1/1] Rework mbedtls CRL handling

2021-04-07 Thread Max Fillinger
This commit fixes the following two issues:

The config belonging to a mbedtls_ssl_ctx struct is not supposed to be
changed after mbedtls_ssl_setup() has been called. Previously, we
modified the CRL structure in place when a new CRL was loaded, but a
pointer to this struct appears in configs that are currently in use.

This commit uses reference counting to ensure that CRLs remain in memory
while the mbedtls_ssl_ctx struct and config remain.

The other issue fixed by this commit is that, if OpenVPN failed to read
the CRL in init_ssl(), but succeeded in reading it later, it would not
actually use that CRL.
---
 src/openvpn/ssl.c|   8 +++
 src/openvpn/ssl_mbedtls.c| 103 ++-
 src/openvpn/ssl_mbedtls.h|  25 +-
 src/openvpn/ssl_verify_mbedtls.c |   2 +-
 4 files changed, 125 insertions(+), 13 deletions(-)

diff --git a/src/openvpn/ssl.c b/src/openvpn/ssl.c
index d8662d00..0f2cb62d 100644
--- a/src/openvpn/ssl.c
+++ b/src/openvpn/ssl.c
@@ -2737,6 +2737,14 @@ tls_process(struct tls_multi *multi,
 {
 tls_ctx_reload_crl(>opt->ssl_ctx,
session->opt->crl_file, 
session->opt->crl_file_inline);
+
+#ifdef ENABLE_CRYPTO_MBEDTLS
+/* With mbedtls, the new CRL doesn't end up in the key_state
+ * automatically, so we need to put it there and recreate the
+ * mbedtls_ssl_context. */
+update_key_state_crl(>ks_ssl, >opt->ssl_ctx);
+#endif
+
 }
 
 /* New connection, remove any old X509 env variables */
diff --git a/src/openvpn/ssl_mbedtls.c b/src/openvpn/ssl_mbedtls.c
index 8917fb18..87a4b8df 100644
--- a/src/openvpn/ssl_mbedtls.c
+++ b/src/openvpn/ssl_mbedtls.c
@@ -105,6 +105,45 @@ tls_clear_error(void)
 {
 }
 
+/* Functions to handle reference counting for CRLs.
+ *
+ * The config of an mbedtls_ssl_context is not supposed to be changed
+ * after mbedtls_ssl_setup() has been called. Therefore, we need to
+ * leave previous CRLs in memory. They will be freed when they are no
+ * longer needed.
+ */
+static struct refcounted_crl *
+init_refcounted_crl(void)
+{
+struct refcounted_crl *ref_crl;
+ALLOC_OBJ(ref_crl, struct refcounted_crl);
+mbedtls_x509_crl_init(_crl->crl);
+ref_crl->refcount = 1;
+
+return ref_crl;
+}
+
+static struct refcounted_crl *
+get_refcounted_crl(struct refcounted_crl *ref_crl)
+{
+ASSERT(ref_crl->refcount < SIZE_MAX);
+ref_crl->refcount += 1;
+return ref_crl;
+}
+
+static void
+release_refcounted_crl(struct refcounted_crl *ref_crl)
+{
+if (ref_crl != NULL) {
+ASSERT(ref_crl->refcount > 0);
+if (--ref_crl->refcount == 0)
+{
+mbedtls_x509_crl_free(_crl->crl);
+free(ref_crl);
+}
+}
+}
+
 void
 tls_ctx_server_new(struct tls_root_ctx *ctx)
 {
@@ -149,8 +188,7 @@ tls_ctx_free(struct tls_root_ctx *ctx)
 mbedtls_dhm_free(ctx->dhm_ctx);
 free(ctx->dhm_ctx);
 
-mbedtls_x509_crl_free(ctx->crl);
-free(ctx->crl);
+release_refcounted_crl(ctx->ref_crl);
 
 #if defined(ENABLE_PKCS11)
 pkcs11h_certificate_freeCertificate(ctx->pkcs11_cert);
@@ -1013,15 +1051,12 @@ backend_tls_ctx_reload_crl(struct tls_root_ctx *ctx, 
const char *crl_file,
 {
 ASSERT(crl_file);
 
-if (ctx->crl == NULL)
-{
-ALLOC_OBJ_CLEAR(ctx->crl, mbedtls_x509_crl);
-}
-mbedtls_x509_crl_free(ctx->crl);
+release_refcounted_crl(ctx->ref_crl);
+ctx->ref_crl = init_refcounted_crl();
 
 if (crl_inline)
 {
-if (!mbed_ok(mbedtls_x509_crl_parse(ctx->crl,
+if (!mbed_ok(mbedtls_x509_crl_parse(>ref_crl->crl,
 (const unsigned char *)crl_file,
 strlen(crl_file) + 1)))
 {
@@ -1031,7 +1066,7 @@ backend_tls_ctx_reload_crl(struct tls_root_ctx *ctx, 
const char *crl_file,
 }
 else
 {
-if (!mbed_ok(mbedtls_x509_crl_parse_file(ctx->crl, crl_file)))
+if (!mbed_ok(mbedtls_x509_crl_parse_file(>ref_crl->crl, 
crl_file)))
 {
 msg(M_WARN, "CRL: cannot read CRL from file %s", crl_file);
 goto err;
@@ -1040,7 +1075,9 @@ backend_tls_ctx_reload_crl(struct tls_root_ctx *ctx, 
const char *crl_file,
 return;
 
 err:
-mbedtls_x509_crl_free(ctx->crl);
+/* Leaving the CRL in the freed state causes all connection attempts to
+ * be rejected. */
+mbedtls_x509_crl_free(>ref_crl->crl);
 }
 
 void
@@ -1121,8 +1158,17 @@ key_state_ssl_init(struct key_state_ssl *ks_ssl,
 }
 mbedtls_ssl_conf_verify(ks_ssl->ssl_config, verify_callback, session);
 
+if (ssl_ctx->ref_crl)
+{
+ks_ssl->ref_crl = get_refcounted_crl(ssl_ctx->ref_crl);
+}
+else
+{
+ks_ssl->ref_crl = NULL;
+}
+
 /* TODO: mbed TLS does not currently support sending the CA chain to the 
client */

[Openvpn-devel] [PATCH v6] Implement deferred auth for scripts

2021-04-07 Thread Arne Schwabe
This patch also refactors the if condition that checks the result of
the authentication since that has become quite unreadable. It renames
s1/s2 and extracts some parts of the condition into individual variables
to make the condition better understandle

Patch v2: add refactoring of the if condition
Patch v4: fix documentation not mentioning method as 2nd line
Patch v5: fix deferred auth used by both plugin and script not working
Patch v6: Add missing async inotify for script deferred auth

Signed-off-by: Arne Schwabe 
---
 Changes.rst |  10 +++
 doc/man-sections/script-options.rst |  14 +++-
 src/openvpn/multi.c |   6 ++
 src/openvpn/ssl.c   |   1 +
 src/openvpn/ssl_common.h|   1 +
 src/openvpn/ssl_verify.c| 105 
 6 files changed, 106 insertions(+), 31 deletions(-)

diff --git a/Changes.rst b/Changes.rst
index 457dfc07e..9185b55f7 100644
--- a/Changes.rst
+++ b/Changes.rst
@@ -30,6 +30,16 @@ TLS mode with self-signed certificates
 become optional. This allows for small OpenVPN setups without setting up
 a PKI with Easy-RSA or similar software.
 
+Deferred auth support for scripts
+The ``--auth-user-pass-verify`` script supports now deferred 
authentication.
+
+Pending auth support for plugins and scripts
+Both auth plugin and script can now signal pending authentication to
+the client when using deferred authentication. The new 
``client-crresponse``
+script option and ``OPENVPN_PLUGIN_CLIENT_CRRESPONSE`` plugin function can
+be used to parse a client response to a ``CR_TEXT`` two factor challenge.
+
+See ``sample/sample-scripts/totpauth.py`` for an example.
 
 Deprecated features
 ---
diff --git a/doc/man-sections/script-options.rst 
b/doc/man-sections/script-options.rst
index 03b3dd77b..22990f4f4 100644
--- a/doc/man-sections/script-options.rst
+++ b/doc/man-sections/script-options.rst
@@ -90,7 +90,19 @@ SCRIPT HOOKS
 
   The script should examine the username and password, returning a success
   exit code (:code:`0`) if the client's authentication request is to be
-  accepted, or a failure code (:code:`1`) to reject the client.
+  accepted, a failure code (:code:`1`) to reject the client, or a that
+  the authentication is deferred (:code:`2`). If the authentication is
+  deferred, the script must fork/start a background or another non-blocking
+  operation to continue the authentication in the background. When finshing
+  the authentication, a :code:`1` or :code:`0` must be written to the
+  file specified by the :code:`auth_control_file`.
+
+  When deferred authentication is in use, the script can also request
+  pending authentication by writing to the file specified by the
+  :code:`auth_pending_file`. The first line must be the timeout in
+  seconds, the required method on the second line (e.g. crtext) and
+  third line must be the EXTRA as documented in the
+  ``client-pending-auth`` section of `doc/management.txt`.
 
   This directive is designed to enable a plugin-style interface for
   extending OpenVPN's authentication capabilities.
diff --git a/src/openvpn/multi.c b/src/openvpn/multi.c
index 7c9500f3e..e5e466631 100644
--- a/src/openvpn/multi.c
+++ b/src/openvpn/multi.c
@@ -2990,6 +2990,12 @@ multi_process_post(struct multi_context *m, struct 
multi_instance *mi, const uns
 add_inotify_file_watch(m, mi, m->top.c2.inotify_fd,
ks->plugin_auth.auth_control_file);
 }
+if (ks && ks->script_auth.auth_control_file && was_unauthenticated
+&& (ks->authenticated == KS_AUTH_DEFERRED))
+{
+add_inotify_file_watch(m, mi, m->top.c2.inotify_fd,
+   ks->script_auth.auth_control_file);
+}
 #endif
 
 if (!IS_SIG(>context))
diff --git a/src/openvpn/ssl.c b/src/openvpn/ssl.c
index d8662d000..b27a78b3d 100644
--- a/src/openvpn/ssl.c
+++ b/src/openvpn/ssl.c
@@ -994,6 +994,7 @@ key_state_free(struct key_state *ks, bool clear)
 packet_id_free(>crypto_options.packet_id);
 
 key_state_rm_auth_control_files(>plugin_auth);
+key_state_rm_auth_control_files(>script_auth);
 
 if (clear)
 {
diff --git a/src/openvpn/ssl_common.h b/src/openvpn/ssl_common.h
index b2fa44e56..acb815955 100644
--- a/src/openvpn/ssl_common.h
+++ b/src/openvpn/ssl_common.h
@@ -222,6 +222,7 @@ struct key_state
 time_t acf_last_mod;
 
 struct auth_deferred_status plugin_auth;
+struct auth_deferred_status script_auth;
 };
 
 /** Control channel wrapping (--tls-auth/--tls-crypt) context */
diff --git a/src/openvpn/ssl_verify.c b/src/openvpn/ssl_verify.c
index 7608155cd..7c02d46ce 100644
--- a/src/openvpn/ssl_verify.c
+++ b/src/openvpn/ssl_verify.c
@@ -1102,20 +1102,25 @@ tls_authentication_status(struct tls_multi *multi, 
const int latency)
 }
 else
 {
-unsigned int s1 = 

Re: [Openvpn-devel] [PATCH] Remove --no-replay

2021-04-07 Thread Antonio Quartulli
Hi,

On 26/07/2020 15:31, Arne Schwabe wrote:
> Am 26.07.20 um 02:01 schrieb Arne Schwabe:
>> Am 17.07.20 um 19:10 schrieb David Sommerseth:
>>> The --no-replay feature is considered to be a security weakness, which
>>> was also highlighed during the OpenVPN 2.4 security audit [0].  This
>>> option was added to the DeprecatedOptions[1] list and has been reported
>>> as deprecated since OpenVPN 2.4.
>>
>> As a side note, removing this feature weakens the ability to use OpenVPN
>> is a pure tunnel without crypto (--auth none, --cipher none and
>> no-replay) since this removes the ability to disable replay proctection
>> when no authentication is enabled. (replay protection without auth is
>> silly as a attacker can just fake the replay id too.)
>>
>> Acked-By: Arne Schwabe
> 
> I given that a bit of a thought. But we need to decide if we to support
> unencrypted transport only session or not in future. If we do not want
> to support them, then applying this patch is fine, otherwise we should
> restrict disabling no-replay to --auth none and also --auth none to
> --cipher none basically:
> 
> --cipher != none => auth none and no-replay forbidden
> 
> --cipher == none => allows auth none and also no-replay
> 
> --cipher none and auth none, warn if no-replay is used that it does not
> prevent replay attacks. But do not fail since we would break a lot of
> setups.

I work for the ministry of oversimplification and I think that removing
user knobs is simply a good thing.

Following the logic provided by Arne, how about removing the --no-reply
knob and making this mechanism automatic?

* if cipher != none -> replay prevention is always enabled;
* if cipher == none && auth == none -> replay prevention is disabled.


[allowing or disabling auth=none should be tackled saparately imho]

Regards,

-- 
Antonio Quartulli


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


Re: [Openvpn-devel] [PATCH 5/5] Remove OpenSSL configure checks

2021-04-07 Thread Antonio Quartulli
Hi,

On 06/04/2021 23:01, Antonio Quartulli wrote:
> 
> I like the new approach a lot.
> It definitely helps keeping track of "what compat code do we need? and
> for which version?"
> 
> Just one suggestion:
> I think it would still be useful to add a comment on the #endif line to
> explicitly say what if we are closing.
> 
> i.e:
> 
> #endif /* OPENSSL_VERSION_NUMBER < 0x10101000L &&
> !defined(ENABLE_CRYPTO_WOLFSSL) */
> 
> That helps your brain when the corresponding #if is far away or you have
> more than one nearby.
> 
> Other than that, it compiles on openssl-1.1.1, 1.1.0 and 1.0.2.
> Test on Linux and Windows (openssl-1.1.1 only in this case).

Since Gert has volunteered to fix this comment on the fly, I am fine
with this version of the patch.

Acked-by: Antonio Quartulli 


-- 
Antonio Quartulli


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


[Openvpn-devel] [PATCH applied] Re: Use EVP_CTRL_AEAD_* instead EVP_CTRL_GCM_*

2021-04-07 Thread Gert Doering
Lightly client-side tested with OpenSSL 1.0.2 and 1.1.1

Your patch has been applied to the master branch.

commit 3fbeeda5cd3cbd0cbb4c039b469685e2a6254daf
Author: Arne Schwabe
Date:   Tue Apr 6 18:25:17 2021 +0200

 Use EVP_CTRL_AEAD_* instead EVP_CTRL_GCM_*

 Signed-off-by: Arne Schwabe 
 Acked-by: Antonio Quartulli 
 Message-Id: <20210406162518.4075-4-a...@rfc2549.org>
 URL: 
https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg22050.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: ssl: remove unneeded if block

2021-04-07 Thread Gert Doering
Acked-by: Gert Doering 

*Such* a pretty patch!

Your patch has been applied to the master branch.

commit 8af7c6b2d79b63ef5587ef1bc4ec81834905698e
Author: Antonio Quartulli
Date:   Mon Apr 5 14:28:27 2021 +0200

 ssl: remove unneeded if block

 Signed-off-by: Antonio Quartulli 
 Acked-by: Gert Doering 
 Message-Id: <20210405122827.16836-...@unstable.cc>
 URL: 
https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg22045.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 (7th April 2021)

2021-04-07 Thread Samuli Seppänen

Hi,

Here's the summary of the IRC meeting.

---

COMMUNITY MEETING

Place: #openvpn-meeting on irc.freenode.net
Date: Wed 7th April 2021
Time: 11:30 CET (10: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, d12fk, lev, mattock, novaflash, ordex and plaisthos 
participated in this meeting.


--

Decided to postpone OpenVPN 2.5.2 and 2.4.11 releases to April 20th / 
21st due to Access Server-related challenges.


--

Decided not to release OpenVPN Windows installers before 2.5.2 and 
2.4.11 as the latest OpenSSL issues affect only Windows acting as an 
OpenVPN server and because there are ways to mitigate the issue while 
waiting for the new releases.


--

Noted that mattock will be able to start working on upgrading buildbots 
after 19th April once he's off the hook from ops work.


Also noted that MacOS buildslave is shown "offline". Mattock restarted 
the buildmaster as the slave had been restarted several times already.


--

Decided to reschedule the meetings to 14:00 CET/CEST. Everyone agreed 
that works better as it does not conflict with lunch time. It won't 
affect Americans as they're all asleep and generally not present in the 
meetings anyways.


--

Talked about removing OCC warnings completely. It was agreed that the 
feature is partially broken in modern client<->server setups. In p2p 
static key context it works better, but we're getting rid of that, so 
that point is moot. Did not decide anything on this topic, but noted 
that cleanups are needed before we can move forward with this.


--

Talked about LibreSSL support. We can perhaps drop support for older 
OpenBSDs if needed, but in general we want to avoid breaking LibreSSL 
support in OpenVPN	.


---

Full chatlog attached
(12:26:22) cron2: I am here!
(12:26:30) cron2: EARLIER THAN NEEDED! HAH!
(12:27:49) mattock: hi
(12:30:17) cron2: we have no topic and no agenda...
(12:30:47) mattock: of course, turn of the month catches mattock by surprise 
every month :)
(12:30:54) mattock: let's make something up then
(12:31:19) cron2: damn cloudflare messing up my links again
(12:31:54) lev__: hello
(12:32:39) cron2: ah, call interferes
(12:32:41) cron2: 5 min
(12:32:44) mattock: https://community.openvpn.net/openvpn/wiki/Topics-2021-04-07
(12:33:46) d12fk: hi and back in 3 -> coffee
(12:34:40) mattock: I have 26 minutes then I'll have to start multitasking due 
to a meeting
(12:37:35) cron2: let's go :)
(12:37:41) mattock: +1
(12:37:43) mattock: 2.5.2?
(12:38:32) dazo: so  yet another delay due to the Easter eggs ...
(12:38:48) cron2: I have updated the agenda page
(12:39:08) novaflash [b9e34...@185-227-75-241.dsl.cambrium.nl] è entrato nella 
stanza.
(12:39:23) cron2: AS has arm-twisted us into not releasing today, and I am very 
busy next week... so we compromised on a joint release in 2 weeks (April 20, 
April 21)
(12:39:36) cron2: we'll do a 2.5.2 and 2.4.11 release
(12:39:53) mattock: +1
(12:40:09) novaflash: so sorry about that :-)  but it's not good to do a 
release on a friday and that's what it would have amounted to. so thanks for 
agreeing to delay it.
(12:40:36) cron2: in corona times, all the days blur...
(12:40:57) d12fk: not if you have a wine cellar =)
(12:41:08) novaflash: with a wine cellar, EVERYTHING blurs
(12:41:11) cron2: the 2.5.2 release is actually all finished and in mattock's 
repo :-) - but will be overwritten when I push the next change to 2.5
(12:41:18) cron2: novaflash: I was about to say that
(12:41:37) novaflash: but yeah i would like to try to keep the weekend, well, 
the weekend
(12:41:47) cron2: but I have the 3+1 patches all ready, so for me it's not very 
much work to do
(12:41:48) plaisthos: With wine cellar I am surprised you are still alive 
during Covid
(12:41:53) novaflash: haha
(12:41:55) cron2: (unless plaisthos discovers new easter eggs)
(12:42:01) dazo: yeah, keeping releases to mon-wed is reasonable
(12:42:13) novaflash: oh is that what we're calling this vulnerability? the 
easter egg?
(12:42:34) dazo: it seems plaisthos and ordex was bored this easter :-P
(12:42:48) cron2: I think the last patch needed to fix all avenues is now 
called "the easter egg" because it came to novaflash as a surprise :)
(12:43:02) dazo: :-D
(12:43:20) dazo: So, anything else blocking the 2.5.2/2.4.11 releases?
(12:43:34) cron2: so - there remains the question whether "we" (*cough* 
mattock) wants to do a 2.5.1-I602 with updated OpenSSL interim...
(12:44:34) cron2: dazo: no blockers from my side.  My test infra needs a bit 
work to do a full server side test for 2.4 (because all the instances test 
"something of the new 2.5 stuff" nowadays, so 2.4 doesn't even start with these 
configs...)
(12:44:50) dazo: plaisthos: how critical would you classify the latest OpenSSL 
CVEs in OpenVPN context?
(12:45:07) plaisthos: 

[Openvpn-devel] Community meetings in April 2021

2021-04-07 Thread Samuli Seppänen

Hi,

Next community meetings have been scheduled to

- Wed 14th April 2021 at 14:00 CET
- Wed 21st April 2021 at 14:00 CET
- Wed 28th April 2021 at 14:00 CET

Please note the change of time (11:30 -> 14:00).

The place is #openvpn-meeting IRC channel at Freenode. 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


[Openvpn-devel] [PATCH applied] Re: Remove check for socket functions and Win XP compatbility code

2021-04-07 Thread Gert Doering
Acked-by: Gert Doering 

Since Antonio did all the testing, I can take the blame :-) - we dropped
support for Windows XP quite a while ago, and I think also for Vista -
the "give me IPv6 routing info!" code new in 2.4 is not available on
older Windows versions, but since they are all out of support anyway,
we decided to "not care".

I have not *tested* the resulting MinGW-built Windows binary, but from
looking at the actual changes I do not expect runtime errors - either
it blows up at compilation/link time, or works.

Your patch has been applied to the master branch.

commit 17f91332069b4adc317bf11cb4d710b00ee139c5
Author: Arne Schwabe
Date:   Tue Apr 6 18:25:14 2021 +0200

 Remove check for socket functions and Win XP compatbility code

 Signed-off-by: Arne Schwabe 
 Acked-by: Gert Doering 
 Message-Id: <20210406162518.4075-1-a...@rfc2549.org>
 URL: 
https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg22052.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: Remove checks for uint* types that are part of C99

2021-04-07 Thread Gert Doering
Your patch has been applied to the master branch.

I have stared at the patch a bit, and pushed it ot all the buildbots,
which are "all green".  So that's the oldest stuff I care about...
(and since we require a C99 compiler anyway, expecting C99 headers
should be reasonable nowadays)

commit 6287538039e2ba787c096272c65ec067e667d773
Author: Arne Schwabe
Date:   Tue Apr 6 18:25:15 2021 +0200

 Remove checks for uint* types that are part of C99

 Signed-off-by: Arne Schwabe 
 Acked-by: Antonio Quartulli 
 Message-Id: <20210406162518.4075-2-a...@rfc2549.org>
 URL: 
https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg22049.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: Remove a number of checks for functions/headers that are always present

2021-04-07 Thread Gert Doering
Acked-by: Gert Doering 

I find these very reasonable changes (like, what,  or ,
these have been around since K day 1...).  

And Eurephia definitely needs dropping!

The buildbot army agrees that these changes are fine :-)

Your patch has been applied to the master branch.

commit b8510baa25b9b6fad0fa373d414a4bbf1565acd0
Author: Arne Schwabe
Date:   Tue Apr 6 18:25:16 2021 +0200

 Remove a number of checks for functions/headers that are always present

 Signed-off-by: Arne Schwabe 
 Acked-by: Gert Doering 
 Message-Id: <20210406162518.4075-3-a...@rfc2549.org>
 URL: 
https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg22053.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