This sets the flag if the OpenVPN server should create authentication
tokens on-the-fly on successful --auth-user-pass-verify or --plugin with
OPENVPN_PLUGIN_AUTH_USER_PASS_VERIFY processing.
If an OpenVPN server is running without this option, it should behave
as before. Next patches will implem
This sets the flag if the OpenVPN server should create authentication
tokens on-the-fly on successful --auth-user-pass-verify or --plugin with
OPENVPN_PLUGIN_AUTH_USER_PASS_VERIFY processing.
If an OpenVPN server is running without this option, it should behave
as before. Next patches will implem
If --auth-gen-token has been enabled and a token has been generated,
ensure this token is pushed to the client using the 'auth-token' option.
This patch will also remove the logging of auth-token values being
pushed, unless --verb level is 7 or higher.
v2 - Don't exceed 80 chars line length
On a server with --auth-gen-token enabled, the server will have created
a random token and pushed it to the client. When the client needs to
renegotiate the connection or otherwise reconnect, it will at this point
use the auth-token as password.
Here we check if we have a token generated and that
This is an updated patch-set of the --auth-gen-token feature. A couple
of patches have already been sent to the previous mail thread [1], but I
thought it would be easier to do the final ACK round when everything was
collected into the same thread.
As the previous PATCH 1/5 got ACKed and is alrea
When --auth-gen-token is used a random token key is generated for
each client after a successful user/password authentication. This
token is expected to be returned in the password field on the
following authentications.
The token is 256 bits long and BASE64 encoded before it is stored.
v2 - F
Hi,
On Fri, Oct 28, 2016 at 6:27 AM, Jan Just Keijser wrote:
> ---
> src/openvpn/options.c | 9 -
> 1 file changed, 8 insertions(+), 1 deletion(-)
>
>
As Arne pointed out the utility of allowing setenv opt in push is
questionable. "setenv opt bad-option" in config file logs a warning an
Hi
This series is a direct outcome of the incident with my previous
patch. I've taken on struct argv and related functions and made
them like I please.
For a more detailed description what's happening see the
comments in the individual patches:
[PATCH 1/7] put argv_* functions into own file, add
With the private gc_arena we do not have to allocate the strings
found during parsing again, since we know the arena they are
allocated in is valid as long as the argv vector is.
Signed-off-by: Heiko Hund
---
src/openvpn/argv.c | 37 ++--
src/ope
Move functionality to parse command strings into argv_parse_cmd().
That is a preparation for the upcoming refactoring of argv_printf().
Signed-off-by: Heiko Hund
---
src/openvpn/argv.c | 47 +---
src/openvpn/argv.h | 1 +
src/o
The previous implementation had the problem that it was not fully
compatible with printf() and could only detect % format directives
following a space character (0x20).
It modifies the format string and inserts marks to separate groups
before passing it to the regular printf in libc. The marks are
Signed-off-by: Heiko Hund
---
src/openvpn/argv.c | 86 --
src/openvpn/argv.h | 1 -
2 files changed, 87 deletions(-)
diff --git a/src/openvpn/argv.c b/src/openvpn/argv.c
index 89c9b14..a279a40 100644
--- a/src/openvpn/argv.c
+++ b/src/openvpn/
Prevent the re-allocations of memory when the internal argv grows
beyond 2 and 4 arguments by initially allocating argv to hold up to
7 (+ trailing NULL) pointers.
While at it rename argv_reset to argv_free to actually express
what's going on. Redo the argv_reset functionality so that it can
be us
Signed-off-by: Heiko Hund
---
src/openvpn/argv.c| 53 +++
src/openvpn/argv.h| 6 -
src/openvpn/console_systemd.c | 3 +--
src/openvpn/route.c | 12 --
src/openvpn/tun.c | 42 +++
misc.c is too crowded with different things to perform any
sane unit testing due to its dependencies. So, in order to re-write
the #ifdef'ed tests for the argv_* family of functions into unit
tests I moved them into a dedicated file.
Signed-off-by: Heiko Hund
---
configure.ac
Lets try again. The script really managed to misinterpret something
really badly this time.
commit ffe508e1082000531c9dc3a60abb9b6ba448f519 master
>> Author: Arne Schwabe
>> Date: Fri Oct 21 16:42:37 2016 +0200
>>
>> Make Changes.rst nicer for 2.4 release
>>
>> Acked-by: David Somm
This patch refactors the CRL handling to rely more on the implementation
of the crypto library. It will insert the CRL at the correct time to keep
it up to date, but all additional verification logic is removed from
ssl_verify_.c. "Less code of our own, less bugs of our own."
In practice, this m
On 28/10/16 15:15, David Sommerseth wrote:
> ACK.
>
> Your patch has been applied to the branch
This was applied to the master branch.
> commit fe621610ff300a299b232956056ffdf0833a9b45
> Author: Arne Schwabe
> Date: Fri Oct 21 16:42:37 2016 +0200
>
> Make Changes.rst nicer for 2.4 relea
On 28/10/16 15:16, David Sommerseth wrote:
> ACK.
>
> Your patch has been applied to the dev/pre-push-hook branch
This was pushed to the master branch.
> commit 752caece99a61e516386f94823e82ddf13fcbcab
> Author: Steffan Karger
> Date: Fri Oct 28 13:57:01 2016 +0200
>
> Limit --reneg-byte
On 28/10/16 15:16, David Sommerseth wrote:
> ACK.
>
> Your patch has been applied to the branch
This was pushed to the release/2.3 branch.
> commit a91ddc99a524014ec79560d873721e8fa81a5631
> Author: Steffan Karger
> Date: Fri Oct 28 14:10:07 2016 +0200
>
> Limit --reneg-bytes to 64MB w
That should be the master branch. My scripts obviously needs some more
enhancements.
On 28/10/16 15:15, David Sommerseth wrote:
> Your patch has been applied to the dev/pre-push-hook branch
>
> commit a64d76e246042fde40189033b87b126627db5b6b
> Author: Steffan Karger
> Date: Wed Oct 26 21:29:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
ACK.
Your patch has been applied to the branch
commit a91ddc99a524014ec79560d873721e8fa81a5631
Author: Steffan Karger
Date: Fri Oct 28 14:10:07 2016 +0200
Limit --reneg-bytes to 64MB when using small block ciphers
Signed-off-by: Steffa
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
ACK.
Your patch has been applied to the dev/pre-push-hook branch
commit 752caece99a61e516386f94823e82ddf13fcbcab
Author: Steffan Karger
Date: Fri Oct 28 13:57:01 2016 +0200
Limit --reneg-bytes to 64MB when using small block ciphers
Sign
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
ACK.
Your patch has been applied to the branch
commit fe621610ff300a299b232956056ffdf0833a9b45
Author: Arne Schwabe
Date: Fri Oct 21 16:42:37 2016 +0200
Make Changes.rst nicer for 2.4 release
Acked-by: David Sommerseth
Message-Id
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Your patch has been applied to the dev/pre-push-hook branch
commit a64d76e246042fde40189033b87b126627db5b6b
Author: Steffan Karger
Date: Wed Oct 26 21:29:19 2016 +0200
Add a revoked cert to the sample keys
Signed-off-by: Steffan Karger
ACK. Great idea to test stuff and if it is only as a documentation
example (aka look in the script how to revoke)
Am 26.10.16 um 21:29 schrieb Steffan Karger:
> Allows for easier testing of the revocation functionality.
>
>
---
Following the earlier warning about small block ciphers, now limit the
--reneg-bytes value when using a cipher that susceptible to SWEET32-like
attacks. The 64 MB value has been selected with the researchers who
published the SWEET32 paper.
Note that this will not change a user-set --reneg-bytes
Following the earlier warning about small block ciphers, now limit the
--reneg-bytes value when using a cipher that susceptible to SWEET32-like
attacks. The 64 MB value has been selected with the researchers who
published the SWEET32 paper.
Note that this will not change a user-set --reneg-bytes
Hi,
On 19 October 2016 at 23:12, David Sommerseth
wrote:
> On 19/10/16 22:12, Steffan Karger wrote:
>> On 13-10-16 21:59, David Sommerseth wrote:
>>> On a server with --auth-gen-token enabled, the server will have created
>>> a random token and pushed it to the client. When the client needs to
>
Hi Arne,
On 28/10/16 13:08, Arne Schwabe wrote:
> Hm,
>
>
> I would like to see a rationale why this is needed. The client will
> already only warn on unsupported options. Your patch would make push
> "setenv opt unsupported" similar to "push unsupported".
the rationale behind this is based on an
Hm,
I would like to see a rationale why this is needed. The client will
already only warn on unsupported options. Your patch would make push
"setenv opt unsupported" similar to "push unsupported".
Arne
--
The Command L
---
src/openvpn/options.c | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/src/openvpn/options.c b/src/openvpn/options.c
index 281ef0b..dbb926d 100644
--- a/src/openvpn/options.c
+++ b/src/openvpn/options.c
@@ -5616,7 +5616,14 @@ add_option (struct options *options,
32 matches
Mail list logo