Hi,
On Thu, Nov 11, 2021 at 04:26:17PM -0500, Selva Nair wrote:
> I'm supposing that we do not want --provider to become a M_FATAL error
> in mbedTLS builds.
For "generic OpenVPN" I'm not sure this makes a real difference - you
know what your build uses, and if you need --provider, you know that
On Thu, Nov 11, 2021 at 4:09 PM Gert Doering wrote:
>
> Hi,
>
> On Thu, Nov 11, 2021 at 08:20:51PM +0100, Arne Schwabe wrote:
> > diff --git a/src/openvpn/options.c b/src/openvpn/options.c
> > index b5d65d293..b1f9473dc 100644
> > --- a/src/openvpn/options.c
> > +++ b/src/openvpn/options.c
> > @@
Hi,
On Thu, Nov 11, 2021 at 08:20:51PM +0100, Arne Schwabe wrote:
> diff --git a/src/openvpn/options.c b/src/openvpn/options.c
> index b5d65d293..b1f9473dc 100644
> --- a/src/openvpn/options.c
> +++ b/src/openvpn/options.c
> @@ -8157,6 +8158,13 @@ add_option(struct options *options,
>
Am 11.11.2021 um 21:04 schrieb Selva Nair:
Quoting from meeting log:
(15:50:52) cron2: and the ERR_BUF_SIZE (21/21) is missing as well...
This is not really a missing piece in the OpenSSl 3.0/deprecation
patch set as the buffer size increase is not a necessity yet. The need
for a larger buff
Quoting from meeting log:
> (15:50:52) cron2: and the ERR_BUF_SIZE (21/21) is missing as well...
This is not really a missing piece in the OpenSSl 3.0/deprecation
patch set as the buffer size increase is not a necessity yet. The need
for a larger buffer arises when we start sending undigested mes
Hi,
On Thu, Nov 11, 2021 at 2:21 PM Arne Schwabe wrote:
> This allows OpenVPN to load non-default providers. This is mainly
> useful for loading the legacy provider with --providers legacy default
>
> Patch v4: use spaces to seperate providers, unload providers.
> Patch v5: General cleanup, rena
This allows OpenVPN to load non-default providers. This is mainly
useful for loading the legacy provider with --providers legacy default
Patch v4: use spaces to seperate providers, unload providers.
Patch v5: General cleanup, rename option to --providers, add
option to usage() and add an
Hi,
Looks good except for some documentation errors and some nits
On Thu, Nov 11, 2021 at 8:01 AM Arne Schwabe wrote:
> This allows OpenVPN to load non-default providers. This is mainly
> useful for loading the legacy provider with --provider legacy default
>
> Patch v4: use spaces to seperate
Hi
On Thu, Nov 11, 2021 at 4:41 AM Lev Stipakov wrote:
> From: Lev Stipakov
>
> This is the rebase of original Selva Nair's patch
> which hasn't been merged:
>
> https://sourceforge.net/p/openvpn/mailman/message/34674818/
Yes, something I wanted 5 years ago
>
> and documentation change to
Hi,
On Tue, Nov 09, 2021 at 03:59:27AM +0200, Lev Stipakov wrote:
> For subnet topology use "offset 0" as default for
> calculating DHCP server address, which makes it equal
> to the network address.
I assume this has been tested across all windows platforms, including
Windows 7?
On the patch it
When evaluating authentication plugins, stop further evaluation
once the first failure is detected.
implementation notes: refactoring from a switch-case to an
if-else block allows the break statement to break out of the
outer for loop without additional control variables. Also,
moving the pr->n s
Hi,
On Thu, Nov 11, 2021 at 03:34:19PM +0100, Antonio Quartulli wrote:
> In any case, I'd suggest fixing git-send-email as copy/paste may
> introduce all kind of formatting bugs and may make the patch unusable.
Indeed. Line wraps, tab/space issues, "helpful mail clients", so
git-send-email is r
Hi,
On 11/11/2021 15:26, Pete Nelson wrote:
Should that have shown up as a separate entry in patchworks? I'm having
to cut/paste the results of git format-patch as I can't git send-email
from my dev box, and it looks like I may have missed editing the subject
line.
It shows up when it is de
Should that have shown up as a separate entry in patchworks? I'm having to
cut/paste the results of git format-patch as I can't git send-email from my
dev box, and it looks like I may have missed editing the subject line.
-- Pete
On Thu, Nov 11, 2021 at 1:34 PM Gert Doering wrote:
> Hi,
>
> On
When evaluating authentication plugins, stop further evaluation
once the first failure is detected.
implementation note: refactoring from a switch-case to an
if-else block allows the break statement to break out of the
outer for loop without additional control variables.
v2: add check for auth pl
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
One tiny typo:
Sent with ProtonMail Secure Email.
‐‐‐ Original Message ‐‐‐
On Thursday, November 11th, 2021 at 13:00, Arne Schwabe
wrote:
> This allows OpenVPN to load non-default providers. This is mainly
>
> useful for loading the leg
Hi,
On Thu, Nov 11, 2021 at 01:23:43PM +, Pete Nelson wrote:
> Thank you, Frank. Amended patch so it applies only to auth attempts.
>
> Not sure how patchwork handles this.. my intent is this amended patch
> overwrites the patch from the OP.
> -- Pete
The best way to do that is to send the
Thank you, Frank. Amended patch so it applies only to auth attempts.
Not sure how patchwork handles this.. my intent is this amended patch
overwrites the patch from the OP.
-- Pete
---
src/openvpn/plugin.c | 28 +---
1 file changed, 13 insertions(+), 15 deletions(-)
dif
This allows OpenVPN to load non-default providers. This is mainly
useful for loading the legacy provider with --provider legacy default
Patch v4: use spaces to seperate providers, unload providers.
Signed-off-by: Arne Schwabe
---
doc/man-sections/generic-options.rst | 10 ++
src/openvpn
From: Lev Stipakov
This is the rebase of original Selva Nair's patch
which hasn't been merged:
https://sourceforge.net/p/openvpn/mailman/message/34674818/
and documentation change to reflect code changes, which
is basically a revert of another Selva's patch (which got merged):
https://www.
Hi Jason,
On 09/11/21 09:37, Jason Haar wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
How about ditching the NTLM and adding HTTPS proxy support instead? ;-)
Does the privacy aspect of talking to proxies "properly" of course (Basic
is fine over HTTPS)
(and accidentally makes openvpn-o
Hi,
> Why not just use 0 offset always? Perpetuating this dance of 0 offset in some
> cases, -1 otherwise is not a way forward. Also see my patch from 2015 that
> never got any traction. I have lost touch with the context, so, I'm not sure
> whether this addresses the same (apart from code chan
22 matches
Mail list logo
