Re: [Openvpn-devel] [PATCH] src/openvpn/dco_freebsd.c: handle malloc failure

[Илья Шипицин]

чт, 18 мая 2023 г. в 09:10, Илья Шипицин :

>
>
> чт, 18 мая 2023 г. в 08:47, Gert Doering :
>
>> Hi,
>>
>> On Wed, May 17, 2023 at 04:43:01PM -0400, Kristof Provost wrote:
>> > Fwiw: I usually don???t bother handling malloc failure in userspace,
>> > because modern systems all overallocate anyway, so the first thing
>> > you know about lack of memory is the out-of-memory killer terminating
>> > you. It???s a policy choice for the project, so I don???t object
>> > to handling it either.
>>
>> In OpenVPN, we do check malloc() returns :-) - and there's cases where
>> it actually hit, like running with too low ulimits and --mlock.
>>
>> If a malloc fail is not recoverable, we have check_malloc_return(p),
>> which will do
>>
>> void
>> out_of_memory(void)
>> {
>> fprintf(stderr, PACKAGE_NAME ": Out of Memory\n");
>> exit(1);
>> }
>> static inline void
>> check_malloc_return(const void *p)
>> {
>> if (!p)
>> {
>> out_of_memory();
>> }
>> }
>>
>> so it depends a bit on the context if "return an error upstream, and
>> wait for the next allocation to fail" or "abort right away" is the best
>> choice.  In low level functions, "return error" might lead to a better
>> error message from upstream (or not).
>>
>
> this one is recoverable.
> if malloc fails, dco fails, but openvpn still able to function
>

maybe we should add something like "data channel offload failed due to ..."


>
>
>>
>> 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
>>
>
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] [PATCH] src/openvpn/dco_freebsd.c: handle malloc failure

[Илья Шипицин]

чт, 18 мая 2023 г. в 08:47, Gert Doering :

> Hi,
>
> On Wed, May 17, 2023 at 04:43:01PM -0400, Kristof Provost wrote:
> > Fwiw: I usually don???t bother handling malloc failure in userspace,
> > because modern systems all overallocate anyway, so the first thing
> > you know about lack of memory is the out-of-memory killer terminating
> > you. It???s a policy choice for the project, so I don???t object
> > to handling it either.
>
> In OpenVPN, we do check malloc() returns :-) - and there's cases where
> it actually hit, like running with too low ulimits and --mlock.
>
> If a malloc fail is not recoverable, we have check_malloc_return(p),
> which will do
>
> void
> out_of_memory(void)
> {
> fprintf(stderr, PACKAGE_NAME ": Out of Memory\n");
> exit(1);
> }
> static inline void
> check_malloc_return(const void *p)
> {
> if (!p)
> {
> out_of_memory();
> }
> }
>
> so it depends a bit on the context if "return an error upstream, and
> wait for the next allocation to fail" or "abort right away" is the best
> choice.  In low level functions, "return error" might lead to a better
> error message from upstream (or not).
>

this one is recoverable.
if malloc fails, dco fails, but openvpn still able to function


>
> 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
>
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] [PATCH] src/openvpn/dco_freebsd.c: handle malloc failure

[Илья Шипицин]

ср, 17 мая 2023 г. в 23:04, Kristof Provost :

> On 17 May 2023, at 16:58, Илья Шипицин wrote:
> > ср, 17 мая 2023 г. в 22:43, Kristof Provost :
> >
> >> On 17 May 2023, at 16:01, Ilya Shipitsin wrote:
> >>> malloc was not checked against NULL, I was able
> >>> to get core dump in case of failure
> >>>
> >>> Signed-off-by: Ilya Shipitsin 
> >>> ---
> >>>  src/openvpn/dco_freebsd.c | 5 +
> >>>  1 file changed, 5 insertions(+)
> >>>
> >>> diff --git a/src/openvpn/dco_freebsd.c b/src/openvpn/dco_freebsd.c
> >>> index abeb..adbd1120 100644
> >>> --- a/src/openvpn/dco_freebsd.c
> >>> +++ b/src/openvpn/dco_freebsd.c
> >>> @@ -594,6 +594,11 @@ dco_available(int msglevel)
> >>>  }
> >>>
> >>>  buf = malloc(ifcr.ifcr_total * IFNAMSIZ);
> >>> +if (buf == NULL)
> >>> +{
> >>
> >> I’d ‘goto out;’ instead, because that’s how we handle other errors in
> this
> >> function.
> >> (free(NULL) is guaranteed to be safe, so we can just do that.)
> >>
> >
> > on "goto out" we'll end with "return available;"
> >
> ‘available’ defaults to ‘false’, so that seems fine to me.
>

looks fragile :)

I do not see benefits of such an approach. But it will work indeed


>
> Best regards,
> Kristof
>
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] [PATCH] src/openvpn/dco_freebsd.c: handle malloc failure

[Илья Шипицин]

ср, 17 мая 2023 г. в 22:47, Antonio Quartulli :

> Hi,
>
> On 17/05/2023 22:01, Ilya Shipitsin wrote:
> > malloc was not checked against NULL, I was able
> > to get core dump in case of failure
> >
> > Signed-off-by: Ilya Shipitsin 
> > ---
> >   src/openvpn/dco_freebsd.c | 5 +
> >   1 file changed, 5 insertions(+)
> >
> > diff --git a/src/openvpn/dco_freebsd.c b/src/openvpn/dco_freebsd.c
> > index abeb..adbd1120 100644
> > --- a/src/openvpn/dco_freebsd.c
> > +++ b/src/openvpn/dco_freebsd.c
> > @@ -594,6 +594,11 @@ dco_available(int msglevel)
> >   }
> >
> >   buf = malloc(ifcr.ifcr_total * IFNAMSIZ);
> > +if (buf == NULL)
>
> as style guideline, we wanted to go for if (!A) rather than if (A ==
> NULL). Although I am not sure if the whole codebase was cleaned up yet
> or not.
>

I'm fine with either :)


>
> Cheers,
>
> > +{
> > +close(fd);
> > +return false;
> > +}
> >
> >   ifcr.ifcr_count = ifcr.ifcr_total;
> >   ifcr.ifcr_buffer = buf;
>
> --
> Antonio Quartulli
>
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] [PATCH] src/openvpn/dco_freebsd.c: handle malloc failure

[Илья Шипицин]

ср, 17 мая 2023 г. в 22:43, Kristof Provost :

> On 17 May 2023, at 16:01, Ilya Shipitsin wrote:
> > malloc was not checked against NULL, I was able
> > to get core dump in case of failure
> >
> > Signed-off-by: Ilya Shipitsin 
> > ---
> >  src/openvpn/dco_freebsd.c | 5 +
> >  1 file changed, 5 insertions(+)
> >
> > diff --git a/src/openvpn/dco_freebsd.c b/src/openvpn/dco_freebsd.c
> > index abeb..adbd1120 100644
> > --- a/src/openvpn/dco_freebsd.c
> > +++ b/src/openvpn/dco_freebsd.c
> > @@ -594,6 +594,11 @@ dco_available(int msglevel)
> >  }
> >
> >  buf = malloc(ifcr.ifcr_total * IFNAMSIZ);
> > +if (buf == NULL)
> > +{
>
> I’d ‘goto out;’ instead, because that’s how we handle other errors in this
> function.
> (free(NULL) is guaranteed to be safe, so we can just do that.)
>

on "goto out" we'll end with "return available;"


>
> Fwiw: I usually don’t bother handling malloc failure in userspace, because
> modern systems all overallocate anyway, so the first thing you know about
> lack of memory is the out-of-memory killer terminating you. It’s a policy
> choice for the project, so I don’t object to handling it either.
>

I agree it's a highly unlikely condition.


>
> Best regards,
> Kristof
>
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] Amend OpenVPN license to allow continued mbed TLS support (allow mbed TLS 3.x linking)

[Илья Шипицин]

вс, 15 янв. 2023 г. в 22:29, Gert Doering :

> HI,
>
> On Sun, Jan 15, 2023 at 10:12:03PM +0600,  ?? wrote:
> > 1) distributing openssl dll for windows installer is illegal
> > 2) distributing openssl/libressl with tunnelblick is illegal
>
> Neither, because we do have an exception for OpenSSL.
>

that expection is for "system" openssl variant only, not for 3rd parties
openssl ?


>
> But distributing with mbedTLS is what we have been told is problematic.
>
> 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
>
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] Amend OpenVPN license to allow continued mbed TLS support (allow mbed TLS 3.x linking)

[Илья Шипицин]

that means

1) distributing openssl dll for windows installer is illegal
2) distributing openssl/libressl with tunnelblick is illegal

?

вс, 15 янв. 2023 г. в 22:09, Arne Schwabe :

> Am 15.01.23 um 17:07 schrieb Илья Шипицин:
> > just curious, is linking against LibreSSL allowed ? os x Tunnelblick is
> > shipped with both LibreSSL and OpenSSL builds, but neither of them is
> > "system" lib as far as I know.
>
> LibreSSL counts as modification of OpenSSL.
>
> Arne
>
>
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] Amend OpenVPN license to allow continued mbed TLS support (allow mbed TLS 3.x linking)

[Илья Шипицин]

just curious, is linking against LibreSSL allowed ? os x Tunnelblick is
shipped with both LibreSSL and OpenSSL builds, but neither of them is
"system" lib as far as I know.

вс, 15 янв. 2023 г. в 21:35, Arne Schwabe :

> Am 15.01.23 um 16:22 schrieb James Bottomley:
> > On Sun, 2023-01-15 at 15:22 +0100, Arne Schwabe wrote:
> >>
> >>> If that's the source of this issue, then I think there's a
> >>> misunderstanding about the problem the OpenSSL exception is
> >>> addressing. The problem was that the OpenSSL licence required
> >>> additional conditions be imposed on the binary as a whole, even
> >>> though openssl itself was a system library.
> >>>
> >>> https://spdx.org/licenses/OpenSSL.html
> >>>
> >>> Specifically the advertising and redistribution clauses.  The
> >>> OpenSSL exception is to make GPLv2 compatible with the OpenSSL
> >>> licence's additional restrictions, not the other way around.  There
> >>> is still a considerable body of opinion that thinks the system
> >>> exception covers this case as well, but just in case, people added
> >>> the OpenSSL compatibility exception to GPLv2.
> >>>
> >>> The goal of changing OpenSSL to Apache-2 was to remove those
> >>> additional restrictions and make the library behave like a normal
> >>> linked library from a licensing point of view.  The Apache-2
> >>> licence imposes no additional restrictions on the binary as a
> >>> whole, which is why no exception is necessary.  Specifically the
> >>> patent retaliation and indemnity clauses which some people think
> >>> cause the cut and paste incompatibility don't apply to the binary
> >>> as a whole, only to the Apache2 pieces.
> >>
> >>
> >> Yes. That is my understanding as well. But I think where we have been
> >> told
> >
> > Who told you?  Because I'd like to tackle this misinformation at source
> > before it spreads further than openvpn.
> >
> >>   and see the problem different is that the GPL2 covers the whole
> >> binary and also the Apache2 licensed parts.
> >
> > It does under section 2 for any component that can't be classified as a
> > system library, yes.  But the system library exception is the way you
> > avoid this for linking with most libraries.
>
> So we have the same interpretation and just disagree if mbed TLS and
> OpenSSL can be seen as system library on non-Linux/non-BSD systems.
>
> >>   And then the restrictions become a problem.
> >
> > Only if the library you're linking with isn't a system library, which I
> > think we can all agree in not the case on every Linux distribution
> > because they all ship both openssl and mbedtls as part of the
> > distribution.
> >
> >>   So you are right in the sense that the Apache2 is just
> >> a normal library to link for most purposes, the GPL licenses are
> >> special in the way that they want to cover the whole source
> >> code/binary. Sometimes this feature of the GPL is called viral by
> >> opponents of the license.
> >
> > Not for system libraries ... that's what the system library exception
> > is all about.
>
> Yes but neither mbed TLS nor OpenSSL is a system library on Windows or
> macOS. And even mbed TLS is sketchy as many distributions do not have in
> their base system. So just assume, at least for the sake of argument
> that they are not. In that case I think we need this exception. So I am
> asking if you are willing to allow this exception to the license even
> though you think it is unnecessary to make the people that think that it
> is needed happy?
>
> Arne
>
>
>
>
> ___
> Openvpn-devel mailing list
> Openvpn-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/openvpn-devel
>
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] Amend OpenVPN license to allow continued mbed TLS support (allow mbed TLS 3.x linking)

[Илья Шипицин]

вс, 15 янв. 2023 г. в 19:09, Arne Schwabe :

> Am 15.01.23 um 13:52 schrieb Илья Шипицин:
> > subject says "allow mbed TLS 3.x linking".
> > is OpenSSL currently restrictive as well ?
> >
>
> Yes that is what the subject says but OpenSSL 3 also uses Apache 2.
>
> In laymen terms, the Apache 2 license contains additional protections
> for users using the source code that GPLv2 does not. While these
> additional protection are in the spirit of the GPL (the GPL3 includes
> the same protections), they are not in the letter of GPL2 and GPL2 does
> not allow additional restriction (like these protections).
>
> So it would be nice if you could just agree to allow the special
> exception, so we can continue using mbed TLS and OpenSSL with OpenVPN.
>

I agree with moving toward Apache license (or some kind of exception), also
I'm fine with dropping mbed TLS for good.


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

Re: [Openvpn-devel] Amend OpenVPN license to allow continued mbed TLS support (allow mbed TLS 3.x linking)

[Илья Шипицин]

subject says "allow mbed TLS 3.x linking".
is OpenSSL currently restrictive as well ?

вс, 15 янв. 2023 г. в 18:24, Arne Schwabe :

> Am 15.01.23 um 13:21 schrieb Илья Шипицин:
> > I am fine with dropping MBED TLS for good
> >
>
> Please read the full mail. This also affects OpenSSL. We would like to
> reaffirm that contributors are still okay linking with OpenSSL even
> after OpenSSL changed its license to Apache2.
>
> Arne
>
>
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] Amend OpenVPN license to allow continued mbed TLS support (allow mbed TLS 3.x linking)

[Илья Шипицин]

I am fine with dropping MBED TLS for good

On Sat, Jan 14, 2023, 11:30 PM Arne Schwabe  wrote:

> Hey,
>
> This is the first round and will be only to the openvpn-devel list.
> After that I will also write to individuals email addresses but I want
> to start with sending this to the devel list.
>
> We are writing to you since you are or were a contributor in past to
> OpenVPN and we would like to  ask for your permission to amend the
> license of OpenVPN.
>
> OpenVPN 2.x is licensed under the GPL v2. This license has served us
> well in the past and we are not trying to change that. However, changes
> in licenses of our dependencies make this change necessary.
>
> Both mbed TLS and OpenSSL nowadays use the Apache 2.x license. For the
> OpenSSL library we have a special exception that allows us linking with
> it. For newer mbed TLS version, we cannot do this any more.
> Compatibility of Apache 2.x and GPL 2.x has to our knowledge never been
> tested in court and even FSF and ASF disagree about the issue
> (https://www.apache.org/licenses/GPL-compatibility.html)
>
> We would like to be able to continue to build/ship OpenVPN with mbed
> TLS. We want all contributors to ask if they agree to license change
> that adds explicit permission to link with Apache 2 licensed libraries:
>
>
> Special exception for linking OpenVPN with Apache 2 licensed libraries:
>
>In addition, as a special exception, OpenVPN Inc and contributors
>give permission to link the code of this program to libraries with the
>"APACHE LICENSE, VERSION 2.0", and distribute linked combination
>including the two.  You must obey the GNU General Public License in
>all respects for all of the code used other than these libraries.  If
>you modify this file, you may extend this exception to your version of
>the file, but you are not obligated to do so.  If you do not wish to
>do so, delete this exception statement from your version.
>
>
> You might wonder why we are going for a generic Apache 2 exception
> rather than one targeted at mbed TLS specifically. We believe that a
> generic exemption is better since it also implicitly allows forks of
> mbed TLS and even if a SSL library might emerge in the future we do not
> have to discuss if it is a fork or not. Also granting an explicit
> exception for Apache 2 style licenses reaffirms the linking to OpenSSL.
>
> We also considered going for a change from GPL2 to GPL2+ but we think
> that GPL3 would hurt the ability to distribute OpenVPN as part of router
> or other embedded devices as the GPL3 has been explicitly developed (at
> least in part) to make this use case harder/impossible
> (https://en.wikipedia.org/wiki/Tivoization)
>
> If you are okay with this, please reply to this mail and confirm that.
> Otherwise we might be forced to remove and/or rewrite your code.
>
>
> As a reminder, the The current OpenSSL exception reads as follows
> (COPYING). We don't intend to change or remote it:
>
>Special exception for linking OpenVPN with OpenSSL:
>
>In addition, as a special exception, OpenVPN Inc gives
>permission to link the code of this program with the OpenSSL
>library (or with modified versions of OpenSSL that use the same
>license as OpenSSL), and distribute linked combinations including
>the two.  You must obey the GNU General Public License in all
>respects for all of the code used other than OpenSSL.  If you modify
>this file, you may extend this exception to your version of the
>file, but you are not obligated to do so.  If you do not wish to
>do so, delete this exception statement from your version.
>
>
>
> ___
> Openvpn-devel mailing list
> Openvpn-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/openvpn-devel
>
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] Multiple Openvpn servers using same port + Nginx

[Илья Шипицин]

I apologise for suggesting unmaintaned project.

сб, 1 окт. 2022 г. в 14:43, Daniel Lando :

> Seems the project is unmaintained BTW.
>
> Any other suggestions?
>
> ---
>
> *Daniel*
>
> On 1 Oct 2022, at 06:07, Илья Шипицин  wrote:
>
> 
> there's brilliant piece of software:
> https://github.com/StreisandEffect/streisand
>
> among other ideas, there's openvpn port sharing.
>
> пт, 30 сент. 2022 г. в 20:22, Daniel Lando :
>
>> Hi everyone,
>>
>> As described in this
>> <https://github.com/OpenVPN/openvpn/pull/166#issuecomment-1263600751>
>> comment, what I would like to know is if it's possible (and how) I could
>> proxy requests using nginx to multiple openvpn servers. I'm actually using
>> docker-compose to start the openvpn servers and also nginx is running in a
>> docker container.
>>
>> The possible solutions I have in mind could be by using subdomains or sni
>> but cannot find a way to make them working as sni support is only available
>> on openvpn 3.
>>
>> There is also a webserver that should share the same port
>>
>> Any suggestions? Thanks in advance
>>
>> --
>> --
>> *Daniel Lando*
>> ___
>> Openvpn-devel mailing list
>> Openvpn-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/openvpn-devel
>>
>
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] Multiple Openvpn servers using same port + Nginx

[Илья Шипицин]

there's brilliant piece of software:
https://github.com/StreisandEffect/streisand

among other ideas, there's openvpn port sharing.

пт, 30 сент. 2022 г. в 20:22, Daniel Lando :

> Hi everyone,
>
> As described in this
> 
> comment, what I would like to know is if it's possible (and how) I could
> proxy requests using nginx to multiple openvpn servers. I'm actually using
> docker-compose to start the openvpn servers and also nginx is running in a
> docker container.
>
> The possible solutions I have in mind could be by using subdomains or sni
> but cannot find a way to make them working as sni support is only available
> on openvpn 3.
>
> There is also a webserver that should share the same port
>
> Any suggestions? Thanks in advance
>
> --
> --
> *Daniel Lando*
> ___
> Openvpn-devel mailing list
> Openvpn-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/openvpn-devel
>
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] [PATCH] Add OpenSSL 3.0 to mingw build

[Илья Шипицин]

I am fine with adding lib64 to 1.1.1

On Wed, Aug 24, 2022, 6:01 PM Arne Schwabe  wrote:

> Am 24.08.22 um 14:36 schrieb Илья Шипицин:
> > It reverts 3.0 behaviour to 1.1.1
> > However --libdir is available for 1.1.1 as well
>
> I understand. What I am missing is *why* reverting to 1.1.1 is a good
> idea. I think we should rather use the new default. I can see arguments
> that we add --libdir=lib64 to openSSL 1.1.1 to adjust it to OpenSSL 3.0
> but not the other way round.
>
> Arne
>
>
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] [PATCH] Add OpenSSL 3.0 to mingw build

[Илья Шипицин]

It reverts 3.0 behaviour to 1.1.1
However --libdir is available for 1.1.1 as well

On Wed, Aug 24, 2022, 5:27 PM Arne Schwabe  wrote:

> Am 24.08.22 um 13:26 schrieb Илья Шипицин:
> > if this is not too late, can we add --libdir=mingw/opt/lib to keep
> > current behaviour ?
> >
> >
> > +  # OpenSSL 3.0.5 installs itself into mingw/opt/lib64 instead of
> > +  # mingw/opt/lib, so we include both dirs in the following steps
> > +  # (pkcs11-helper and OpenVPN) so the libraries will be found
> >
>
> We could but I am not sure why we should force it to be in the other
> directory and deviate from the default of how the libraries are build.
>
> Arne
>
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] [PATCH] Add OpenSSL 3.0 to mingw build

[Илья Шипицин]

if this is not too late, can we add --libdir=mingw/opt/lib to keep current
behaviour ?


+  # OpenSSL 3.0.5 installs itself into mingw/opt/lib64 instead of
+  # mingw/opt/lib, so we include both dirs in the following steps
+  # (pkcs11-helper and OpenVPN) so the libraries will be found

ср, 24 авг. 2022 г. в 15:55, Arne Schwabe :

> This also updates the host system to ubuntu 22.04 and remove the
> ovpn-dco-win
> checkout as we now include the required headers in our own repository.
>
> Signed-off-by: Arne Schwabe 
> ---
>  .github/workflows/build.yaml | 31 ++-
>  1 file changed, 14 insertions(+), 17 deletions(-)
>
> diff --git a/.github/workflows/build.yaml b/.github/workflows/build.yaml
> index b0f67a785..f2472fdcf 100644
> --- a/.github/workflows/build.yaml
> +++ b/.github/workflows/build.yaml
> @@ -39,31 +39,25 @@ jobs:
>  strategy:
>fail-fast: false
>matrix:
> +osslver: [1.1.1q, 3.0.5]
> +target: [mingw64, mingw]
>  include:
>- target: mingw64
>  chost: x86_64-w64-mingw32
>- target: mingw
>  chost: i686-w64-mingw32
>
> -name: "gcc-mingw - ${{matrix.target}}"
> -
> -runs-on: ubuntu-20.04
> +name: "gcc-mingw - ${{matrix.target}} - OSSL ${{ matrix.osslver }}"
> +runs-on: ubuntu-22.04
>  env:
>MAKEFLAGS: -j3
>LZO_VERSION: "2.10"
>PKCS11_HELPER_VERSION: "1.29.0"
> -  OPENSSL_VERSION: "1.1.1n"
> +  OPENSSL_VERSION: "${{ matrix.osslver }}"
>TAP_WINDOWS_VERSION: "9.23.3"
> -  CHOST: ${{ matrix.chost }}
> -  TARGET: ${{ matrix.target }}
>  steps:
>- name: Install dependencies
>  run: sudo apt update && sudo apt install -y mingw-w64 libtool
> automake autoconf man2html unzip
> -  - name: Checkout ovpn-dco-win
> -uses: actions/checkout@v3
> -with:
> -  repository: OpenVPN/ovpn-dco-win
> -  path: ovpn-dco-win
>- name: Checkout OpenVPN
>  uses: actions/checkout@v3
>  with:
> @@ -78,7 +72,7 @@ jobs:
>  uses: actions/cache@v3
>  with:
>path: '~/mingw/'
> -  key: ${{ matrix.target }}-mingw-${{ env.OPENSSL_VERSION }}-${{
> env.LZO_VERSION }}-${{ env.PKCS11_HELPER_VERSION }}-${{
> env.TAP_WINDOWS_VERSION }}
> +  key: ${{ matrix.target }}-mingw-${{ matrix.osslver }}-${{
> env.LZO_VERSION }}-${{ env.PKCS11_HELPER_VERSION }}-${{
> env.TAP_WINDOWS_VERSION }}
>
># Repeating  if: steps.cache.outputs.cache-hit != 'true'
># on every step for building dependencies is ugly but
> @@ -90,15 +84,15 @@ jobs:
>wget -c -P download-cache/ "
> https://build.openvpn.net/downloads/releases/tap-windows-${TAP_WINDOWS_VERSION}.zip
> "
>wget -c -P download-cache/ "
> https://www.oberhumer.com/opensource/lzo/download/lzo-${LZO_VERSION}.tar.gz
> "
>wget -c -P download-cache/ "
> https://github.com/OpenSC/pkcs11-helper/releases/download/pkcs11-helper-${PKCS11_HELPER_VERSION}/pkcs11-helper-${PKCS11_HELPER_VERSION}.tar.bz2
> "
> -  wget -c -P download-cache/ "
> https://www.openssl.org/source/openssl-${OPENSSL_VERSION}.tar.gz;
>tar jxf
> "download-cache/pkcs11-helper-${PKCS11_HELPER_VERSION}.tar.bz2"
> +  wget -c -P download-cache/ "
> https://www.openssl.org/source/old/1.1.1/openssl-${OPENSSL_VERSION}.tar.gz;
> || wget -c -P download-cache/ "
> https://www.openssl.org/source/openssl-${OPENSSL_VERSION}.tar.gz;
>tar zxf "download-cache/openssl-${OPENSSL_VERSION}.tar.gz"
>tar zxf "download-cache/lzo-${LZO_VERSION}.tar.gz"
>unzip download-cache/tap-windows-${TAP_WINDOWS_VERSION}.zip
>
>- name: Configure OpenSSL
>  if: steps.cache.outputs.cache-hit != 'true'
> -run: ./Configure --cross-compile-prefix=${CHOST}- shared ${{
> matrix.target }} no-capieng --prefix="${HOME}/mingw/opt"
> --openssldir="${HOME}/mingw/opt" -static-libgcc
> +run: ./Configure --cross-compile-prefix=${{ matrix.chost }}-
> shared ${{ matrix.target }} no-capieng --prefix="${HOME}/mingw/opt"
> --openssldir="${HOME}/mingw/opt" -static-libgcc
>  working-directory: "./openssl-${{ env.OPENSSL_VERSION }}"
>
>- name: Build OpenSSL
> @@ -106,6 +100,9 @@ jobs:
>  run: make
>  working-directory: "./openssl-${{ env.OPENSSL_VERSION }}"
>
> +  # OpenSSL 3.0.5 installs itself into mingw/opt/lib64 instead of
> +  # mingw/opt/lib, so we include both dirs in the following steps
> +  # (pkcs11-helper and OpenVPN) so the libraries will be found
>- name: Install OpenSSL
>  if: steps.cache.outputs.cache-hit != 'true'
>  run: make install
> @@ -118,7 +115,7 @@ jobs:
>
>- name: configure pkcs11-helper
>  if: steps.cache.outputs.cache-hit != 'true'
> -run: OPENSSL_LIBS="-L${HOME}/mingw/opt/lib -lssl -lcrypto"
> OPENSSL_CFLAGS=-I$HOME/mingw/opt/include

Re: [Openvpn-devel] [PATCH] fix GitHub workflow working directories in MinGW builds

[Илья Шипицин]

I recall that link "
https://www.openssl.org/source/openssl-${OPENSSL_VERSION}.tar.gz; becomes
broken as soon as new version is released.
that is the way how openssl warns you to update.

"old" links are immutable.

пн, 25 апр. 2022 г. в 00:27, Marc Becker :

> replace hardcoded directory names with env variable version info
> bump pkcs11-helper version to 1.29.0
> bump OpenSSL version to 1.1.1n
> add OpenSSL version to cache key
> use release file for pkcs11-helper archive
> use OpenSSL URL endpoint with all/current versions
>
> Signed-off-by: Marc Becker 
> ---
>  .github/workflows/build.yaml | 36 ++--
>  1 file changed, 18 insertions(+), 18 deletions(-)
>
> diff --git a/.github/workflows/build.yaml b/.github/workflows/build.yaml
> index fa99e12b..34a9d9b9 100644
> --- a/.github/workflows/build.yaml
> +++ b/.github/workflows/build.yaml
> @@ -19,8 +19,8 @@ jobs:
>  env:
>MAKEFLAGS: -j3
>LZO_VERSION: "2.10"
> -  PKCS11_HELPER_VERSION: "1.26"
> -  OPENSSL_VERSION: "1.1.1j"
> +  PKCS11_HELPER_VERSION: "1.29.0"
> +  OPENSSL_VERSION: "1.1.1n"
>TAP_WINDOWS_VERSION: "9.23.3"
>CHOST: ${{ matrix.chost }}
>TARGET: ${{ matrix.target }}
> @@ -46,20 +46,20 @@ jobs:
>  uses: actions/cache@v2
>  with:
>path: '~/mingw/'
> -  key: ${{ matrix.target }}-mingw-${{ env.LZO_VERSION }}-${{
> env.PKCS11_HELPER_VERSION }}-${{ env.TAP_WINDOWS_VERSION }}
> +  key: ${{ matrix.target }}-mingw-${{ env.OPENSSL_VERSION }}-${{
> env.LZO_VERSION }}-${{ env.PKCS11_HELPER_VERSION }}-${{
> env.TAP_WINDOWS_VERSION }}
>
># Repeating  if: steps.cache.outputs.cache-hit != 'true'
># on every step for building dependencies is ugly but
># I haven't found a better solution so far.
>
> -  - name: Download mingw depnendencies
> +  - name: Download mingw dependencies
>  if: steps.cache.outputs.cache-hit != 'true'
>  run: |
>wget -c -P download-cache/ "
> https://build.openvpn.net/downloads/releases/tap-windows-${TAP_WINDOWS_VERSION}.zip
> "
>wget -c -P download-cache/ "
> https://www.oberhumer.com/opensource/lzo/download/lzo-${LZO_VERSION}.tar.gz
> "
> -  wget -c -P download-cache/ "
> https://github.com/OpenSC/pkcs11-helper/archive/pkcs11-helper-${PKCS11_HELPER_VERSION}.tar.gz
> "
> -  wget -c -P download-cache/ "
> https://www.openssl.org/source/old/1.1.1/openssl-${OPENSSL_VERSION}.tar.gz
> "
> -  tar zxf
> "download-cache/pkcs11-helper-${PKCS11_HELPER_VERSION}.tar.gz"
> +  wget -c -P download-cache/ "
> https://github.com/OpenSC/pkcs11-helper/releases/download/pkcs11-helper-${PKCS11_HELPER_VERSION}/pkcs11-helper-${PKCS11_HELPER_VERSION}.tar.bz2
> "
> +  wget -c -P download-cache/ "
> https://www.openssl.org/source/openssl-${OPENSSL_VERSION}.tar.gz;
> +  tar jxf
> "download-cache/pkcs11-helper-${PKCS11_HELPER_VERSION}.tar.bz2"
>tar zxf "download-cache/openssl-${OPENSSL_VERSION}.tar.gz"
>tar zxf "download-cache/lzo-${LZO_VERSION}.tar.gz"
>unzip download-cache/tap-windows-${TAP_WINDOWS_VERSION}.zip
> @@ -67,56 +67,56 @@ jobs:
>- name: Configure OpenSSL
>  if: steps.cache.outputs.cache-hit != 'true'
>  run: ./Configure --cross-compile-prefix=${CHOST}- shared ${{
> matrix.target }} no-capieng --prefix="${HOME}/mingw/opt"
> --openssldir="${HOME}/mingw/opt" -static-libgcc
> -working-directory: "./openssl-1.1.1j"
> +working-directory: "./openssl-${{ env.OPENSSL_VERSION }}"
>
>- name: Build OpenSSL
>  if: steps.cache.outputs.cache-hit != 'true'
>  run: make
> -working-directory: "./openssl-1.1.1j/"
> +working-directory: "./openssl-${{ env.OPENSSL_VERSION }}"
>
>- name: Install OpenSSL
>  if: steps.cache.outputs.cache-hit != 'true'
>  run: make install
> -working-directory: "./openssl-1.1.1j/"
> +working-directory: "./openssl-${{ env.OPENSSL_VERSION }}"
>
>- name: autoreconf pkcs11-helper
>  if: steps.cache.outputs.cache-hit != 'true'
>  run: autoreconf -iv
> -working-directory: "./pkcs11-helper-pkcs11-helper-1.26"
> +working-directory: "./pkcs11-helper-${{ env.PKCS11_HELPER_VERSION
> }}"
>
>- name: configure pkcs11-helper
>  if: steps.cache.outputs.cache-hit != 'true'
>  run: OPENSSL_LIBS="-L${HOME}/mingw/opt/lib -lssl -lcrypto"
> OPENSSL_CFLAGS=-I$HOME/mingw/opt/include
> PKG_CONFIG_PATH=${HOME}/mingw/opt/lib/pkgconfig ./configure --host=${CHOST}
> --program-prefix='' --libdir=${HOME}/mingw/opt/lib
> --prefix=${HOME}/mingw/opt --build=x86_64-pc-linux-gnu
> --disable-crypto-engine-gnutls --disable-crypto-engine-nss
> --disable-crypto-engine-polarssl --disable-crypto-engine-mbedtls
> -working-directory: "./pkcs11-helper-pkcs11-helper-1.26"
> +working-directory: 

Re: [Openvpn-devel] [PATCH 2.5] msvc: adjust build options to harden binaries

[Илья Шипицин]

sorry, it does not look like "2 new threads".
also, I'm not sure patchwork will be able to pick 2 ack from 1 thread.

I'm not motivated to run in circles from you to Gert and back.
if you can find someone more motivated, I'll appreciate that.

пн, 21 февр. 2022 г. в 17:02, Lev Stipakov :

> Reply to both of them with the line (remove ">"):
>
> > Acked-by: Ilya Shipitsin 
>
> if you think that you could ack both of those patches.
>
> ma 21. helmik. 2022 klo 13.17 Илья Шипицин (chipits...@gmail.com)
> kirjoitti:
> >
> > Lev, I see two new messages in this thread. Please clarify what do you
> want me to do?
> >
> > пн, 21 февр. 2022 г. в 13:59, Lev Stipakov :
> >>
> >> Let's start from the beginning.
> >>
> >> I'll start two new threads (master and 2.5) and Ilya could ack them.
> >>
> >> Ilya, to ack please reply on those threads with following line:
> >>
> >> Acked-by: Firstname Lastname 
> >>
> >> su 20. helmik. 2022 klo 19.31 Gert Doering (g...@greenie.muc.de)
> kirjoitti:
> >> >
> >> > Hi,
> >> >
> >> > On Sun, Feb 20, 2022 at 07:53:56PM +0500,  ??
> wrote:
> >> > > There is ack from me earlier in this thread.
> >> >
> >> > "ACK in this thread" is not really helpful, as it is not clear for
> >> > which patch exactly this is.
> >> >
> >> > (You basically ACKed in response to v1 of the 2.5 patch, while we
> >> > have v2 for the master + 2.5 patch out)
> >> >
> >> > For me, to make clear which version of which patches an ACK refers
> >> > to, it is important that the reply is to the correct e-mail - you can
> >> > see in patchwork if your ACK has been recorded or not.
> >> >
> >> > https://patchwork.openvpn.net/project/openvpn2/list/
> >> >
> >> > 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
> >>
> >>
> >>
> >> --
> >> -Lev
>
>
>
> --
> -Lev
>
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] [PATCH 2.5] msvc: adjust build options to harden binaries

[Илья Шипицин]

Lev, I see two new messages in this thread. Please clarify what do you want
me to do?

пн, 21 февр. 2022 г. в 13:59, Lev Stipakov :

> Let's start from the beginning.
>
> I'll start two new threads (master and 2.5) and Ilya could ack them.
>
> Ilya, to ack please reply on those threads with following line:
>
> Acked-by: Firstname Lastname 
>
> su 20. helmik. 2022 klo 19.31 Gert Doering (g...@greenie.muc.de)
> kirjoitti:
> >
> > Hi,
> >
> > On Sun, Feb 20, 2022 at 07:53:56PM +0500,  ?? wrote:
> > > There is ack from me earlier in this thread.
> >
> > "ACK in this thread" is not really helpful, as it is not clear for
> > which patch exactly this is.
> >
> > (You basically ACKed in response to v1 of the 2.5 patch, while we
> > have v2 for the master + 2.5 patch out)
> >
> > For me, to make clear which version of which patches an ACK refers
> > to, it is important that the reply is to the correct e-mail - you can
> > see in patchwork if your ACK has been recorded or not.
> >
> > https://patchwork.openvpn.net/project/openvpn2/list/
> >
> > 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
>
>
>
> --
> -Lev
>
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] [PATCH 2.5] msvc: adjust build options to harden binaries

[Илья Шипицин]

There is ack from me earlier in this thread.

Lev, I did all things you asked me to do. Please follow up. I do not catch
what else left

On Sun, Feb 20, 2022, 7:38 PM Gert Doering  wrote:

> Hi,
>
> On Sun, Feb 20, 2022 at 07:29:24PM +0500,  ?? wrote:
> > Lev, I'm lost here. Can you please follow up?
>
> Please test and ACK *this* patch:
>
>   https://patchwork.openvpn.net/patch/2296/
>
> this is the "v2 for master" patch.
>
> When that is done, we can talk about release/2.5 application.
>
> 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
>
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] [PATCH 2.5] msvc: adjust build options to harden binaries

[Илья Шипицин]

Lev, I'm lost here. Can you please follow up?

On Sun, Feb 20, 2022, 7:18 PM Gert Doering  wrote:

> Hi,
>
> On Sun, Feb 20, 2022 at 07:15:33PM +0500,  ?? wrote:
> > It is applied to master.
>
> The "adjust build options to harden binaries" has no ACK for master.
>
> This is needed so the 2.5 patch can go into 2.5
>
> 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
>
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] [PATCH 2.5] msvc: adjust build options to harden binaries

[Илья Шипицин]

It is applied to master.

git id:
https://github.com/OpenVPN/openvpn/commit/9da733751ce80b2226ef19923365bd3102cfbd47

On Sun, Feb 20, 2022, 7:10 PM Gert Doering  wrote:

> Hi,
>
> On Sun, Feb 20, 2022 at 07:07:15PM +0500,  ?? wrote:
> > pdb patch
>
> Whatever that is... a commit ID in master would be much easier for
> me to cherrypick.
>
> (In any case, *this* patch can't go into 2.5 before the *master* patch
> has an ACK - for patches for "master + 2.5", master always comes first,
> then release branch)
>
> 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
>
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] [PATCH 2.5] msvc: adjust build options to harden binaries

[Илья Шипицин]

pdb patch

On Sun, Feb 20, 2022, 7:04 PM Gert Doering  wrote:

> Hi,
>
> On Thu, Feb 17, 2022 at 01:55:35PM +0200, Lev Stipakov wrote:
> > > can you please apply "pdb" patch to your branch ?
> > > CI: github actions: keep "pdb" in artifacts · OpenVPN/openvpn@9da7337
> >
> > Done! https://github.com/lstipakov/openvpn/actions/runs/1858390624
> >
> > > BinSkim uses pdb for analysis.
> > >
> > > probably, it makes sense to apply this patch to release/2.5 branch as
> well
> >
> > I agree. /me looks at Gert.
>
> I'm a bit confused on what exactly you want applied where now.
>
> What is "this patch"?  This one, or "the pdb patch", or yet something
> else mentioned in this thread?
>
> 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
>
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] [PATCH 2.5] msvc: adjust build options to harden binaries

[Илья Шипицин]

Ack from me.

чт, 17 февр. 2022 г. в 16:55, Lev Stipakov :

> Hi,
>
> > can you please apply "pdb" patch to your branch ?
> > CI: github actions: keep "pdb" in artifacts · OpenVPN/openvpn@9da7337
>
> Done! https://github.com/lstipakov/openvpn/actions/runs/1858390624
>
> > BinSkim uses pdb for analysis.
> >
> > probably, it makes sense to apply this patch to release/2.5 branch as
> well
>
> I agree. /me looks at Gert.
>
> --
> -Lev
>
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] [PATCH 2.5] msvc: adjust build options to harden binaries

[Илья Шипицин]

чт, 17 февр. 2022 г. в 13:53, Lev Stipakov :

> Hi,
>
> Thanks for testing.
>
> > original patch does not apply
>
> Indeed it doesn't apply anymore since recent changes to vcxproj files.
> I have rebased it.
>
> > minor build issues still there: test · chipitsine/openvpn@eeff765 (
> github.com)
>
> Those are likely because this was not applied
>
> https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg21774.html
> to your 2.5 branch.
> I have mentioned it in the patch email, but not in a commit message.
>
> > also, I have a question on true, in your patch it
> is not applied to all configurations, but to few of them. is it on purpose ?
>
> For some reasons I missed debug configurations in some projects, I'll add
> those.
>
> Here are my GHa builds:
>
> master: https://github.com/lstipakov/openvpn/actions/runs/1857589993
> release/2.5
> :
> https://github.com/lstipakov/openvpn/actions/runs/1857547158


can you please apply "pdb" patch to your branch ?
CI: github actions: keep "pdb" in artifacts · OpenVPN/openvpn@9da7337


BinSkim uses pdb for analysis.

probably, it makes sense to apply this patch to release/2.5 branch as well



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

Re: [Openvpn-devel] [PATCH v2 release/2.5] msvc: adjust build options to harden binaries

[Илья Шипицин]

I've missed that patch [Openvpn-devel] [PATCH v2 4/5] tapctl: Resolve MSVC
C4996 warnings (mail-archive.com)


I'll test updated patch soon.

чт, 17 февр. 2022 г. в 14:03, Lev Stipakov :

> From: Lev Stipakov 
>
>  - enable hardware-enforced stack protection on
> compatible hardware/software (/CETCOMPAT linker option)
>
>  - hash object files with SHA256 (/ZH:SHA_256 compiler option)
>
>  - enable SDL. The required to add
>
> _CRT_NONSTDC_NO_DEPRECATE
> _CRT_SECURE_NO_WARNINGS
> _WINSOCK_DEPRECATED_NO_WARNINGS
>
> preprocessor definitions. I don't feel like replacing strdup (which is
> correct POSIX function) and inet_ntoa (we always pass IPv4 address to
> it, inet_ntop will make code more complex)
>
> Above issues were discovered by bitskim.
>
> Before applying this patch, this one must be applied from master:
>
>
> https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg21774.html
>
>
> Signed-off-by: Lev Stipakov 
> ---
>  v2:
>- rebase on top of latest release/2.5
>- add SDL checks to all configurations
>
>  src/openvpn/auth_token.c  |  1 +
>  src/openvpn/openvpn.vcxproj   | 38 +--
>  src/openvpnmsica/openvpnmsica.vcxproj | 48 
>  src/openvpnserv/openvpnserv.vcxproj   | 26 ++---
>  src/tapctl/tapctl.vcxproj | 54 ---
>  5 files changed, 143 insertions(+), 24 deletions(-)
>
> diff --git a/src/openvpn/auth_token.c b/src/openvpn/auth_token.c
> index ca7e5a4d..37af6605 100644
> --- a/src/openvpn/auth_token.c
> +++ b/src/openvpn/auth_token.c
> @@ -87,6 +87,7 @@ add_session_token_env(struct tls_session *session,
> struct tls_multi *multi,
>
>  default:
>  /* Silence compiler warning, all four possible
> combinations are covered */
> +state = NULL;
>  ASSERT(0);
>  }
>  }
> diff --git a/src/openvpn/openvpn.vcxproj b/src/openvpn/openvpn.vcxproj
> index 91d5ebbe..05c63b03 100644
> --- a/src/openvpn/openvpn.vcxproj
> +++ b/src/openvpn/openvpn.vcxproj
> @@ -147,11 +147,13 @@
>
> Condition="'$(Configuration)|$(Platform)'=='Debug|Win32'">
>  
> -
> _CONSOLE;%(PreprocessorDefinitions)
> +
> _CRT_NONSTDC_NO_DEPRECATE;_CRT_SECURE_NO_WARNINGS;_WINSOCK_DEPRECATED_NO_WARNINGS;_CONSOLE;%(PreprocessorDefinitions)
>
>  
> %(UndefinePreprocessorDefinitions)
> -  Level2
>true
>
>  
> ..\compat;%(AdditionalIncludeDirectories)
> +  Level2
> +  /ZH:SHA_256
> %(AdditionalOptions)
> +  true
>  
>  
>  
> @@ -162,11 +164,13 @@
>
> Condition="'$(Configuration)|$(Platform)'=='Debug|x64'">
>  
> -
> _CONSOLE;%(PreprocessorDefinitions)
> +
> _CRT_NONSTDC_NO_DEPRECATE;_CRT_SECURE_NO_WARNINGS;_WINSOCK_DEPRECATED_NO_WARNINGS;_CONSOLE;%(PreprocessorDefinitions)
>
>  
> %(UndefinePreprocessorDefinitions)
> -  Level2
>true
>
>  
> ..\compat;%(AdditionalIncludeDirectories)
> +  Level2
> +  /ZH:SHA_256
> %(AdditionalOptions)
> +  true
>  
>  
>  
> @@ -177,11 +181,13 @@
>
> Condition="'$(Configuration)|$(Platform)'=='Debug|ARM64'">
>  
> -
> _CONSOLE;%(PreprocessorDefinitions)
> +
> _CRT_NONSTDC_NO_DEPRECATE;_CRT_SECURE_NO_WARNINGS;_WINSOCK_DEPRECATED_NO_WARNINGS;_CONSOLE;%(PreprocessorDefinitions)
>
>  
> %(UndefinePreprocessorDefinitions)
> -  Level2
>true
>
>  
> ..\compat;%(AdditionalIncludeDirectories)
> +  Level2
> +  /ZH:SHA_256
> %(AdditionalOptions)
> +  true
>  
>  
>  
> @@ -192,44 +198,52 @@
>
> Condition="'$(Configuration)|$(Platform)'=='Release|Win32'">
>  
> -
> _CONSOLE;%(PreprocessorDefinitions)
> +
> _CRT_NONSTDC_NO_DEPRECATE;_CRT_SECURE_NO_WARNINGS;_WINSOCK_DEPRECATED_NO_WARNINGS;_CONSOLE;%(PreprocessorDefinitions)
>
>  
> %(UndefinePreprocessorDefinitions)
> -  Level2
>true
>
>  
> ..\compat;%(AdditionalIncludeDirectories)
>Guard
> +  Level2
> +  /ZH:SHA_256
> %(AdditionalOptions)
> +  true
>  
>  
>  
>
>  
> Ncrypt.lib;gdi32.lib;ws2_32.lib;wininet.lib;crypt32.lib;iphlpapi.lib;winmm.lib;Fwpuclnt.lib;Rpcrt4.lib;setupapi.lib;Advapi32.lib
>
>  
> $(OPENSSL_HOME)/lib;$(LZO_HOME)/lib;$(PKCS11H_HOME)/lib;%(AdditionalLibraryDirectories)
>Console
> +  true
>  
>
> Condition="'$(Configuration)|$(Platform)'=='Release|x64'">
>  
> -
> _CONSOLE;%(PreprocessorDefinitions)
> +
> _CRT_NONSTDC_NO_DEPRECATE;_CRT_SECURE_NO_WARNINGS;_WINSOCK_DEPRECATED_NO_WARNINGS;_CONSOLE;%(PreprocessorDefinitions)
>
>  
> %(UndefinePreprocessorDefinitions)
> -  Level2
>true
>
>  
> ..\compat;%(AdditionalIncludeDirectories)
>Guard
> +  true
> +  Level2
> +  /ZH:SHA_256
> %(AdditionalOptions)
>  
>  
>  
>
>  
> 

Re: [Openvpn-devel] [PATCH 2.5] msvc: adjust build options to harden binaries

[Илья Шипицин]

original patch does not apply

C:\i\openvpn-chipitsine-2.5>"C:\Program Files\Git\usr\bin\patch.exe" -p1 <
c:\users\ilia\Downloads\Openvpn-devel-2.5-msvc-adjust-build-options-to-harden-binaries.diff
patching file src/openvpn/openvpn.vcxproj
Hunk #1 FAILED at 147.
Hunk #2 FAILED at 162.
Hunk #3 FAILED at 177.
Hunk #4 FAILED at 192.
4 out of 4 hunks FAILED -- saving rejects to file
src/openvpn/openvpn.vcxproj.rej
patching file src/openvpnmsica/openvpnmsica.vcxproj
patching file src/openvpnserv/openvpnserv.vcxproj
patching file src/tapctl/tapctl.vcxproj


I tried to apply manually: test · chipitsine/openvpn@eeff765 (github.com)
<https://github.com/chipitsine/openvpn/commit/eeff76551238b0194e72953b916c4481aab5f303>

minor build issues still there: test · chipitsine/openvpn@eeff765
(github.com)
<https://github.com/chipitsine/openvpn/runs/5226889392?check_suite_focus=true>


also, I have a question on true, in your patch it is
not applied to all configurations, but to few of them. is it on purpose ?



ср, 9 февр. 2022 г. в 15:16, Илья Шипицин :

> Sorry, I did not catch that you have been waiting for me.
> I'll have a look in couple of days
>
> ср, 9 февр. 2022 г. в 15:07, Lev Stipakov :
>
>> Hi Ilja,
>>
>> Is there any chance you could have a look at this patch?
>>
>>
>> pe 7. tammik. 2022 klo 16.54 Lev Stipakov (lstipa...@gmail.com)
>> kirjoitti:
>> >
>> > From: Lev Stipakov 
>> >
>> >  - enable hardware-enforced stack protection on
>> > compatible hardware/software (/CETCOMPAT linker option)
>> >
>> >  - hash object files with SHA256 (/ZH:SHA_256 compiler option)
>> >
>> >  - enable SDL. The required to add
>> >
>> > _CRT_NONSTDC_NO_DEPRECATE
>> > _CRT_SECURE_NO_WARNINGS
>> > _WINSOCK_DEPRECATED_NO_WARNINGS
>> >
>> > preprocessor definitions. I don't feel like replacing strdup (which is
>> > correct POSIX function) and inet_ntoa (we always pass IPv4 address to
>> > it, inet_ntop will make code more complex)
>> >
>> > Above issues were discovered by bitskim.
>> >
>> > Signed-off-by: Lev Stipakov 
>> > ---
>> >
>> >  Note that one needs to cherry-pick commit
>> >
>> >  "e5e9a07" (tapctl: Resolve MSVC C4996 warnings)
>> >
>> >  before applying this patch.
>> >
>> >  src/openvpn/openvpn.vcxproj   | 35 +++--
>> >  src/openvpnmsica/openvpnmsica.vcxproj | 43 +
>> >  src/openvpnserv/openvpnserv.vcxproj   | 26 ++---
>> >  src/tapctl/tapctl.vcxproj | 54 ---
>> >  4 files changed, 134 insertions(+), 24 deletions(-)
>> >
>> > diff --git a/src/openvpn/openvpn.vcxproj b/src/openvpn/openvpn.vcxproj
>> > index 33b8f19a..a540ec22 100644
>> > --- a/src/openvpn/openvpn.vcxproj
>> > +++ b/src/openvpn/openvpn.vcxproj
>> > @@ -147,11 +147,12 @@
>> >
>> >> Condition="'$(Configuration)|$(Platform)'=='Debug|Win32'">
>> >  
>> > -
>> _CONSOLE;%(PreprocessorDefinitions)
>> > +
>> _CRT_NONSTDC_NO_DEPRECATE;_CRT_SECURE_NO_WARNINGS;_WINSOCK_DEPRECATED_NO_WARNINGS;_CONSOLE;%(PreprocessorDefinitions)
>> >
>> %(UndefinePreprocessorDefinitions)
>> > -  Level2
>> >true
>> >
>> ..\compat;$(SolutionDir);%(AdditionalIncludeDirectories)
>> > +  Level2
>> > +  /ZH:SHA_256
>> %(AdditionalOptions)
>> >  
>> >  
>> >  
>> > @@ -162,11 +163,12 @@
>> >
>> >> Condition="'$(Configuration)|$(Platform)'=='Debug|x64'">
>> >  
>> > -
>> _CONSOLE;%(PreprocessorDefinitions)
>> > +
>> _CRT_NONSTDC_NO_DEPRECATE;_CRT_SECURE_NO_WARNINGS;_WINSOCK_DEPRECATED_NO_WARNINGS;_CONSOLE;%(PreprocessorDefinitions)
>> >
>> %(UndefinePreprocessorDefinitions)
>> > -  Level2
>> >true
>> >
>> ..\compat;$(SolutionDir)include;$(SolutionDir);%(AdditionalIncludeDirectories)
>> > +  Level2
>> > +  /ZH:SHA_256
>> %(AdditionalOptions)
>> >  
>> >  
>> >  
>> > @@ -177,11 +179,12 @@
>> >
>> >> Condition="'$(Configuration)|$(Platform)'=='Debug|ARM64'">
>> >  
>> > -
>> _CONSOLE;%(PreprocessorDefinitions)
>> > +
>> _CRT_NONSTDC_NO_DEPRECATE;_CRT_SECURE_NO_WARNINGS;_WINSOCK_DEPRECATED_NO_WARNINGS;_CONSOLE;%(PreprocessorD

Re: [Openvpn-devel] [PATCH] Add warning about mbed TLS licensing problem

[Илья Шипицин]

+Support for mbed TLS is likely to be removed in OpenVPN 2.17.

2.7 ?

ср, 16 февр. 2022 г. в 19:13, Max Fillinger <
maximilian.fillin...@foxcrypto.com>:

> Signed-off-by: Max Fillinger 
> ---
>  README.mbedtls | 17 +
>  1 file changed, 17 insertions(+)
>
> diff --git a/README.mbedtls b/README.mbedtls
> index 4875822d..b5604bb8 100644
> --- a/README.mbedtls
> +++ b/README.mbedtls
> @@ -11,6 +11,23 @@ This version depends on mbed TLS 2.0 (and requires at
> least 2.0.0).
>
>  *
>
> +Warning:
> +
> +As of version 2.17, mbed TLS can be licensed *only* under the Apache v2.0
> +license. That license is incompatible with OpenVPN's GPLv2.
> +
> +If you wish to distribute OpenVPN linked with mbed TLS, there are two
> options:
> +
> + * Ensure that your case falls under the system library exception in
> GPLv2, or
> +
> + * Use an earlier version of mbed TLS. Version 2.16.12 is the last release
> +   that may be licensed under GPLv2. Unfortunately, this version is
> +   unsupported and won't receive any more updates.
> +
> +Support for mbed TLS is likely to be removed in OpenVPN 2.17.
> +
> +*
> +
>  Due to limitations in the mbed TLS library, the following features are
> missing
>  in the mbed TLS version of OpenVPN:
>
> --
> 2.20.1
>
>
>
> ___
> Openvpn-devel mailing list
> Openvpn-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/openvpn-devel
>
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] [PATCH 2.5] msvc: adjust build options to harden binaries

[Илья Шипицин]

Sorry, I did not catch that you have been waiting for me.
I'll have a look in couple of days

ср, 9 февр. 2022 г. в 15:07, Lev Stipakov :

> Hi Ilja,
>
> Is there any chance you could have a look at this patch?
>
>
> pe 7. tammik. 2022 klo 16.54 Lev Stipakov (lstipa...@gmail.com) kirjoitti:
> >
> > From: Lev Stipakov 
> >
> >  - enable hardware-enforced stack protection on
> > compatible hardware/software (/CETCOMPAT linker option)
> >
> >  - hash object files with SHA256 (/ZH:SHA_256 compiler option)
> >
> >  - enable SDL. The required to add
> >
> > _CRT_NONSTDC_NO_DEPRECATE
> > _CRT_SECURE_NO_WARNINGS
> > _WINSOCK_DEPRECATED_NO_WARNINGS
> >
> > preprocessor definitions. I don't feel like replacing strdup (which is
> > correct POSIX function) and inet_ntoa (we always pass IPv4 address to
> > it, inet_ntop will make code more complex)
> >
> > Above issues were discovered by bitskim.
> >
> > Signed-off-by: Lev Stipakov 
> > ---
> >
> >  Note that one needs to cherry-pick commit
> >
> >  "e5e9a07" (tapctl: Resolve MSVC C4996 warnings)
> >
> >  before applying this patch.
> >
> >  src/openvpn/openvpn.vcxproj   | 35 +++--
> >  src/openvpnmsica/openvpnmsica.vcxproj | 43 +
> >  src/openvpnserv/openvpnserv.vcxproj   | 26 ++---
> >  src/tapctl/tapctl.vcxproj | 54 ---
> >  4 files changed, 134 insertions(+), 24 deletions(-)
> >
> > diff --git a/src/openvpn/openvpn.vcxproj b/src/openvpn/openvpn.vcxproj
> > index 33b8f19a..a540ec22 100644
> > --- a/src/openvpn/openvpn.vcxproj
> > +++ b/src/openvpn/openvpn.vcxproj
> > @@ -147,11 +147,12 @@
> >
> > Condition="'$(Configuration)|$(Platform)'=='Debug|Win32'">
> >  
> > -
> _CONSOLE;%(PreprocessorDefinitions)
> > +
> _CRT_NONSTDC_NO_DEPRECATE;_CRT_SECURE_NO_WARNINGS;_WINSOCK_DEPRECATED_NO_WARNINGS;_CONSOLE;%(PreprocessorDefinitions)
> >
> %(UndefinePreprocessorDefinitions)
> > -  Level2
> >true
> >
> ..\compat;$(SolutionDir);%(AdditionalIncludeDirectories)
> > +  Level2
> > +  /ZH:SHA_256
> %(AdditionalOptions)
> >  
> >  
> >  
> > @@ -162,11 +163,12 @@
> >
> > Condition="'$(Configuration)|$(Platform)'=='Debug|x64'">
> >  
> > -
> _CONSOLE;%(PreprocessorDefinitions)
> > +
> _CRT_NONSTDC_NO_DEPRECATE;_CRT_SECURE_NO_WARNINGS;_WINSOCK_DEPRECATED_NO_WARNINGS;_CONSOLE;%(PreprocessorDefinitions)
> >
> %(UndefinePreprocessorDefinitions)
> > -  Level2
> >true
> >
> ..\compat;$(SolutionDir)include;$(SolutionDir);%(AdditionalIncludeDirectories)
> > +  Level2
> > +  /ZH:SHA_256
> %(AdditionalOptions)
> >  
> >  
> >  
> > @@ -177,11 +179,12 @@
> >
> > Condition="'$(Configuration)|$(Platform)'=='Debug|ARM64'">
> >  
> > -
> _CONSOLE;%(PreprocessorDefinitions)
> > +
> _CRT_NONSTDC_NO_DEPRECATE;_CRT_SECURE_NO_WARNINGS;_WINSOCK_DEPRECATED_NO_WARNINGS;_CONSOLE;%(PreprocessorDefinitions)
> >
> %(UndefinePreprocessorDefinitions)
> > -  Level2
> >true
> >
> ..\compat;$(SolutionDir);%(AdditionalIncludeDirectories)
> > +  Level2
> > +  /ZH:SHA_256
> %(AdditionalOptions)
> >  
> >  
> >  
> > @@ -192,44 +195,52 @@
> >
> > Condition="'$(Configuration)|$(Platform)'=='Release|Win32'">
> >  
> > -
> _CONSOLE;%(PreprocessorDefinitions)
> > +
> _CRT_NONSTDC_NO_DEPRECATE;_CRT_SECURE_NO_WARNINGS;_WINSOCK_DEPRECATED_NO_WARNINGS;_CONSOLE;%(PreprocessorDefinitions)
> >
> %(UndefinePreprocessorDefinitions)
> > -  Level2
> >true
> >
> ..\compat;$(SolutionDir);%(AdditionalIncludeDirectories)
> >Guard
> > +  Level2
> > +  /ZH:SHA_256
> %(AdditionalOptions)
> > +  true
> >  
> >  
> >  
> >
> Ncrypt.lib;gdi32.lib;ws2_32.lib;wininet.lib;crypt32.lib;iphlpapi.lib;winmm.lib;Fwpuclnt.lib;Rpcrt4.lib;setupapi.lib;Advapi32.lib
> >
> $(OPENSSL_HOME)/lib;$(LZO_HOME)/lib;$(PKCS11H_HOME)/lib;%(AdditionalLibraryDirectories)
> >Console
> > +  true
> >  
> >
> > Condition="'$(Configuration)|$(Platform)'=='Release|x64'">
> >  
> > -
> _CONSOLE;%(PreprocessorDefinitions)
> > +
> _CRT_NONSTDC_NO_DEPRECATE;_CRT_SECURE_NO_WARNINGS;_WINSOCK_DEPRECATED_NO_WARNINGS;_CONSOLE;%(PreprocessorDefinitions)
> >
> %(UndefinePreprocessorDefinitions)
> > -  Level2
> >true
> >
> ..\compat;$(SolutionDir);%(AdditionalIncludeDirectories)
> >Guard
> > +  true
> > +  Level2
> > +  /ZH:SHA_256
> %(AdditionalOptions)
> >  
> >  
> >  
> >
> Ncrypt.lib;gdi32.lib;ws2_32.lib;wininet.lib;crypt32.lib;iphlpapi.lib;winmm.lib;Fwpuclnt.lib;Rpcrt4.lib;setupapi.lib;Advapi32.lib
> >
> $(OPENSSL_HOME)/lib;$(LZO_HOME)/lib;$(PKCS11H_HOME)/lib;%(AdditionalLibraryDirectories)
> >Console
> > +  true
> >  
> >
> > Condition="'$(Configuration)|$(Platform)'=='Release|ARM64'">
> >  
> > -
> _CONSOLE;%(PreprocessorDefinitions)
> > +
> 

Re: [Openvpn-devel] [PATCH] BUILD: MSVC: enable the Control-flow Enforcement Technology (CET) Shadow Stack mitigation

[Илья Шипицин]

For the record
https://github.com/microsoft/binskim/issues/508

On Fri, Dec 31, 2021, 8:35 PM Илья Шипицин  wrote:

> CETCOMPAT is not supported for ARM.
> Regarding other arch I do not have particular opinion, I'm fine with
> either props or vcxproj approach
>
> On Fri, Dec 31, 2021, 5:09 PM Lev Stipakov  wrote:
>
>> Hi,
>>
>> Sorry for the delay.
>>
>>  1) Was it really necessary to modify .props? I enabled this via
>> Linker->Advanced->CET Shadow Stack Compatible and only .vcxproj files
>> got modified.
>>
>>  2) I think we could enable it for all binaries
>> (openvpn/openvpnmsica/openvpnserv/tapctl) for ARM64/WIn32/x64 Release
>> configurations.
>>
>> -Lev
>>
>> ma 27. jouluk. 2021 klo 11.09 Илья Шипицин (chipits...@gmail.com)
>> kirjoitti:
>> >
>> > gentle ping
>> >
>> >
>> > сб, 16 окт. 2021 г. в 19:15, Ilya Shipitsin :
>> >>
>> >> found by BinSkim, more details:
>> >>
>> https://docs.microsoft.com/en-us/cpp/build/reference/cetcompat?view=msvc-160
>> >>
>> >> Signed-off-by: Ilya Shipitsin 
>> >> ---
>> >>  src/compat/Debug.props  | 10 ++
>> >>  src/compat/Release.props| 10 ++
>> >>  src/openvpn/openvpn.vcxproj |  4 
>> >>  src/openvpnmsica/openvpnmsica-Debug.props   | 10 ++
>> >>  src/openvpnmsica/openvpnmsica-Release.props | 10 ++
>> >>  src/openvpnserv/openvpnserv.vcxproj |  4 
>> >>  6 files changed, 48 insertions(+)
>> >>
>> >> diff --git a/src/compat/Debug.props b/src/compat/Debug.props
>> >> index 31bb9d91..14d7a1f7 100644
>> >> --- a/src/compat/Debug.props
>> >> +++ b/src/compat/Debug.props
>> >> @@ -17,5 +17,15 @@
>> >>EditAndContinue
>> >>  
>> >>
>> >> +  > Condition="'$(Configuration)|$(Platform)'=='Debug|Win32'">
>> >> +
>> >> +  true
>> >> +
>> >> +  
>> >> +  > Condition="'$(Configuration)|$(Platform)'=='Debug|x64'">
>> >> +
>> >> +  true
>> >> +
>> >> +  
>> >>
>> >>  
>> >> \ No newline at end of file
>> >> diff --git a/src/compat/Release.props b/src/compat/Release.props
>> >> index 50eaa8de..df04ddf2 100644
>> >> --- a/src/compat/Release.props
>> >> +++ b/src/compat/Release.props
>> >> @@ -22,5 +22,15 @@
>> >>true
>> >>  
>> >>
>> >> +  > Condition="'$(Configuration)|$(Platform)'=='Release|Win32'">
>> >> +
>> >> +  true
>> >> +
>> >> +  
>> >> +  > Condition="'$(Configuration)|$(Platform)'=='Release|x64'">
>> >> +
>> >> +  true
>> >> +
>> >> +  
>> >>
>> >>  
>> >> \ No newline at end of file
>> >> diff --git a/src/openvpn/openvpn.vcxproj b/src/openvpn/openvpn.vcxproj
>> >> index 65ee6839..38dd22de 100644
>> >> --- a/src/openvpn/openvpn.vcxproj
>> >> +++ b/src/openvpn/openvpn.vcxproj
>> >> @@ -158,6 +158,7 @@
>> >>
>> Ncrypt.lib;gdi32.lib;ws2_32.lib;wininet.lib;crypt32.lib;iphlpapi.lib;winmm.lib;Fwpuclnt.lib;Rpcrt4.lib;setupapi.lib;Advapi32.lib
>> >>
>> $(OPENSSL_HOME)/lib;$(LZO_HOME)/lib;$(PKCS11H_HOME)/lib;%(AdditionalLibraryDirectories)
>> >>Console
>> >> +  true
>> >>  
>> >>
>> >>> Condition="'$(Configuration)|$(Platform)'=='Debug|x64'">
>> >> @@ -173,6 +174,7 @@
>> >>
>> Ncrypt.lib;gdi32.lib;ws2_32.lib;wininet.lib;crypt32.lib;iphlpapi.lib;winmm.lib;Fwpuclnt.lib;Rpcrt4.lib;setupapi.lib;Advapi32.lib
>> >>
>> $(OPENSSL_HOME)/lib;$(LZO_HOME)/lib;$(PKCS11H_HOME)/lib;%(AdditionalLibraryDirectories)
>> >>Console
>> >> +  true
>> >>  
>> >>
>> >>> Condition="'$(Configuration)|$(Platform)'=='Debug|ARM64'">
>> >> @@ -204,6 +206,7 @@
>> >>
>> Ncrypt.lib;gdi32.lib;ws2_32.lib;wininet.lib;crypt32.lib;iphlpapi.lib;winmm.lib;Fwpuclnt.lib;Rpcrt4.lib;setupapi.lib;Advapi32.lib
>> >>
>> $(OPENSSL_HOME)/lib;$(LZO_HOME)/lib;$

Re: [Openvpn-devel] [PATCH] BUILD: MSVC: enable the Control-flow Enforcement Technology (CET) Shadow Stack mitigation

[Илья Шипицин]

CETCOMPAT is not supported for ARM.
Regarding other arch I do not have particular opinion, I'm fine with either
props or vcxproj approach

On Fri, Dec 31, 2021, 5:09 PM Lev Stipakov  wrote:

> Hi,
>
> Sorry for the delay.
>
>  1) Was it really necessary to modify .props? I enabled this via
> Linker->Advanced->CET Shadow Stack Compatible and only .vcxproj files
> got modified.
>
>  2) I think we could enable it for all binaries
> (openvpn/openvpnmsica/openvpnserv/tapctl) for ARM64/WIn32/x64 Release
> configurations.
>
> -Lev
>
> ma 27. jouluk. 2021 klo 11.09 Илья Шипицин (chipits...@gmail.com)
> kirjoitti:
> >
> > gentle ping
> >
> >
> > сб, 16 окт. 2021 г. в 19:15, Ilya Shipitsin :
> >>
> >> found by BinSkim, more details:
> >>
> https://docs.microsoft.com/en-us/cpp/build/reference/cetcompat?view=msvc-160
> >>
> >> Signed-off-by: Ilya Shipitsin 
> >> ---
> >>  src/compat/Debug.props  | 10 ++
> >>  src/compat/Release.props| 10 ++
> >>  src/openvpn/openvpn.vcxproj |  4 
> >>  src/openvpnmsica/openvpnmsica-Debug.props   | 10 ++
> >>  src/openvpnmsica/openvpnmsica-Release.props | 10 ++
> >>  src/openvpnserv/openvpnserv.vcxproj |  4 
> >>  6 files changed, 48 insertions(+)
> >>
> >> diff --git a/src/compat/Debug.props b/src/compat/Debug.props
> >> index 31bb9d91..14d7a1f7 100644
> >> --- a/src/compat/Debug.props
> >> +++ b/src/compat/Debug.props
> >> @@ -17,5 +17,15 @@
> >>EditAndContinue
> >>  
> >>
> >> +   Condition="'$(Configuration)|$(Platform)'=='Debug|Win32'">
> >> +
> >> +  true
> >> +
> >> +  
> >> +   Condition="'$(Configuration)|$(Platform)'=='Debug|x64'">
> >> +
> >> +  true
> >> +
> >> +  
> >>
> >>  
> >> \ No newline at end of file
> >> diff --git a/src/compat/Release.props b/src/compat/Release.props
> >> index 50eaa8de..df04ddf2 100644
> >> --- a/src/compat/Release.props
> >> +++ b/src/compat/Release.props
> >> @@ -22,5 +22,15 @@
> >>true
> >>  
> >>
> >> +   Condition="'$(Configuration)|$(Platform)'=='Release|Win32'">
> >> +
> >> +  true
> >> +
> >> +  
> >> +   Condition="'$(Configuration)|$(Platform)'=='Release|x64'">
> >> +
> >> +  true
> >> +
> >> +  
> >>
> >>  
> >> \ No newline at end of file
> >> diff --git a/src/openvpn/openvpn.vcxproj b/src/openvpn/openvpn.vcxproj
> >> index 65ee6839..38dd22de 100644
> >> --- a/src/openvpn/openvpn.vcxproj
> >> +++ b/src/openvpn/openvpn.vcxproj
> >> @@ -158,6 +158,7 @@
> >>
> Ncrypt.lib;gdi32.lib;ws2_32.lib;wininet.lib;crypt32.lib;iphlpapi.lib;winmm.lib;Fwpuclnt.lib;Rpcrt4.lib;setupapi.lib;Advapi32.lib
> >>
> $(OPENSSL_HOME)/lib;$(LZO_HOME)/lib;$(PKCS11H_HOME)/lib;%(AdditionalLibraryDirectories)
> >>Console
> >> +  true
> >>  
> >>
> >> Condition="'$(Configuration)|$(Platform)'=='Debug|x64'">
> >> @@ -173,6 +174,7 @@
> >>
> Ncrypt.lib;gdi32.lib;ws2_32.lib;wininet.lib;crypt32.lib;iphlpapi.lib;winmm.lib;Fwpuclnt.lib;Rpcrt4.lib;setupapi.lib;Advapi32.lib
> >>
> $(OPENSSL_HOME)/lib;$(LZO_HOME)/lib;$(PKCS11H_HOME)/lib;%(AdditionalLibraryDirectories)
> >>Console
> >> +  true
> >>  
> >>
> >> Condition="'$(Configuration)|$(Platform)'=='Debug|ARM64'">
> >> @@ -204,6 +206,7 @@
> >>
> Ncrypt.lib;gdi32.lib;ws2_32.lib;wininet.lib;crypt32.lib;iphlpapi.lib;winmm.lib;Fwpuclnt.lib;Rpcrt4.lib;setupapi.lib;Advapi32.lib
> >>
> $(OPENSSL_HOME)/lib;$(LZO_HOME)/lib;$(PKCS11H_HOME)/lib;%(AdditionalLibraryDirectories)
> >>Console
> >> +  true
> >>  
> >>
> >> Condition="'$(Configuration)|$(Platform)'=='Release|x64'">
> >> @@ -220,6 +223,7 @@
> >>
> Ncrypt.lib;gdi32.lib;ws2_32.lib;wininet.lib;crypt32.lib;iphlpapi.lib;winmm.lib;Fwpuclnt.lib;Rpcrt4.lib;setupapi.lib;Advapi32.lib
> >>
> $(OPENSSL_HOME)/lib;$(LZO_HOME)/lib;$(PKCS11H_HOME)/lib;%(AdditionalLibraryDirectories)
> >>Console
> >> +  true
> >>  
> &g

Re: [Openvpn-devel] [PATCH] BUILD: MSVC: enable the Control-flow Enforcement Technology (CET) Shadow Stack mitigation

[Илья Шипицин]

gentle ping


сб, 16 окт. 2021 г. в 19:15, Ilya Shipitsin :

> found by BinSkim, more details:
>
> https://docs.microsoft.com/en-us/cpp/build/reference/cetcompat?view=msvc-160
>
> Signed-off-by: Ilya Shipitsin 
> ---
>  src/compat/Debug.props  | 10 ++
>  src/compat/Release.props| 10 ++
>  src/openvpn/openvpn.vcxproj |  4 
>  src/openvpnmsica/openvpnmsica-Debug.props   | 10 ++
>  src/openvpnmsica/openvpnmsica-Release.props | 10 ++
>  src/openvpnserv/openvpnserv.vcxproj |  4 
>  6 files changed, 48 insertions(+)
>
> diff --git a/src/compat/Debug.props b/src/compat/Debug.props
> index 31bb9d91..14d7a1f7 100644
> --- a/src/compat/Debug.props
> +++ b/src/compat/Debug.props
> @@ -17,5 +17,15 @@
>EditAndContinue
>  
>
> +   Condition="'$(Configuration)|$(Platform)'=='Debug|Win32'">
> +
> +  true
> +
> +  
> +   Condition="'$(Configuration)|$(Platform)'=='Debug|x64'">
> +
> +  true
> +
> +  
>
>  
> \ No newline at end of file
> diff --git a/src/compat/Release.props b/src/compat/Release.props
> index 50eaa8de..df04ddf2 100644
> --- a/src/compat/Release.props
> +++ b/src/compat/Release.props
> @@ -22,5 +22,15 @@
>true
>  
>
> +   Condition="'$(Configuration)|$(Platform)'=='Release|Win32'">
> +
> +  true
> +
> +  
> +   Condition="'$(Configuration)|$(Platform)'=='Release|x64'">
> +
> +  true
> +
> +  
>
>  
> \ No newline at end of file
> diff --git a/src/openvpn/openvpn.vcxproj b/src/openvpn/openvpn.vcxproj
> index 65ee6839..38dd22de 100644
> --- a/src/openvpn/openvpn.vcxproj
> +++ b/src/openvpn/openvpn.vcxproj
> @@ -158,6 +158,7 @@
>
>  
> Ncrypt.lib;gdi32.lib;ws2_32.lib;wininet.lib;crypt32.lib;iphlpapi.lib;winmm.lib;Fwpuclnt.lib;Rpcrt4.lib;setupapi.lib;Advapi32.lib
>
>  
> $(OPENSSL_HOME)/lib;$(LZO_HOME)/lib;$(PKCS11H_HOME)/lib;%(AdditionalLibraryDirectories)
>Console
> +  true
>  
>
> Condition="'$(Configuration)|$(Platform)'=='Debug|x64'">
> @@ -173,6 +174,7 @@
>
>  
> Ncrypt.lib;gdi32.lib;ws2_32.lib;wininet.lib;crypt32.lib;iphlpapi.lib;winmm.lib;Fwpuclnt.lib;Rpcrt4.lib;setupapi.lib;Advapi32.lib
>
>  
> $(OPENSSL_HOME)/lib;$(LZO_HOME)/lib;$(PKCS11H_HOME)/lib;%(AdditionalLibraryDirectories)
>Console
> +  true
>  
>
> Condition="'$(Configuration)|$(Platform)'=='Debug|ARM64'">
> @@ -204,6 +206,7 @@
>
>  
> Ncrypt.lib;gdi32.lib;ws2_32.lib;wininet.lib;crypt32.lib;iphlpapi.lib;winmm.lib;Fwpuclnt.lib;Rpcrt4.lib;setupapi.lib;Advapi32.lib
>
>  
> $(OPENSSL_HOME)/lib;$(LZO_HOME)/lib;$(PKCS11H_HOME)/lib;%(AdditionalLibraryDirectories)
>Console
> +  true
>  
>
> Condition="'$(Configuration)|$(Platform)'=='Release|x64'">
> @@ -220,6 +223,7 @@
>
>  
> Ncrypt.lib;gdi32.lib;ws2_32.lib;wininet.lib;crypt32.lib;iphlpapi.lib;winmm.lib;Fwpuclnt.lib;Rpcrt4.lib;setupapi.lib;Advapi32.lib
>
>  
> $(OPENSSL_HOME)/lib;$(LZO_HOME)/lib;$(PKCS11H_HOME)/lib;%(AdditionalLibraryDirectories)
>Console
> +  true
>  
>
> Condition="'$(Configuration)|$(Platform)'=='Release|ARM64'">
> diff --git a/src/openvpnmsica/openvpnmsica-Debug.props
> b/src/openvpnmsica/openvpnmsica-Debug.props
> index 43532cfe..c99346af 100644
> --- a/src/openvpnmsica/openvpnmsica-Debug.props
> +++ b/src/openvpnmsica/openvpnmsica-Debug.props
> @@ -10,5 +10,15 @@
>MultiThreadedDebug
>  
>
> +   Condition="'$(Configuration)|$(Platform)'=='Debug|Win32'">
> +
> +  true
> +
> +  
> +   Condition="'$(Configuration)|$(Platform)'=='Debug|x64'">
> +
> +  true
> +
> +  
>
>  
> \ No newline at end of file
> diff --git a/src/openvpnmsica/openvpnmsica-Release.props
> b/src/openvpnmsica/openvpnmsica-Release.props
> index 47727b35..70f82713 100644
> --- a/src/openvpnmsica/openvpnmsica-Release.props
> +++ b/src/openvpnmsica/openvpnmsica-Release.props
> @@ -11,5 +11,15 @@
>Guard
>  
>
> +   Condition="'$(Configuration)|$(Platform)'=='Release|Win32'">
> +
> +  true
> +
> +  
> +   Condition="'$(Configuration)|$(Platform)'=='Release|x64'">
> +
> +  true
> +
> +  
>
>  
> \ No newline at end of file
> diff --git a/src/openvpnserv/openvpnserv.vcxproj
> b/src/openvpnserv/openvpnserv.vcxproj
> index 5fd7d60b..65d03e3b 100644
> --- a/src/openvpnserv/openvpnserv.vcxproj
> +++ b/src/openvpnserv/openvpnserv.vcxproj
> @@ -130,6 +130,7 @@
>  
>
>  
> Userenv.lib;Iphlpapi.lib;ntdll.lib;Fwpuclnt.lib;Netapi32.lib;Shlwapi.lib;%(AdditionalDependencies)
>Console
> +  true
>  
>
> Condition="'$(Configuration)|$(Platform)'=='Debug|x64'">
> @@ -141,6 +142,7 @@
>  
>
>  
> legacy_stdio_definitions.lib;Userenv.lib;Iphlpapi.lib;ntdll.lib;Fwpuclnt.lib;Netapi32.lib;Shlwapi.lib;%(AdditionalDependencies)
>Console
> +  true
>  
>
> Condition="'$(Configuration)|$(Platform)'=='Debug|ARM64'">
> @@ 

Re: [Openvpn-devel] [PATCH v2] BUILD: enable CFG and Spectre mitigation for MSVC

[Илья Шипицин]

Performance report was delayed due to oversize. It was only delivered to
Lev and Gert.

Thank you Lev for bringing this up:)


Performance was captured by WPT. I'd like to make some similar
investigation if needed (to compare other perf impact)

On Wed, Nov 24, 2021, 7:21 PM Lev Stipakov  wrote:

> Since we're preparing the next 2.5 release, let's take this in. The
> performance numbers, reported in different thread, look good.
>
> ma 27. syysk. 2021 klo 13.06 Илья Шипицин (chipits...@gmail.com)
> kirjoitti:
> >
> > I'll setup test stand similar to this one
> https://community.openvpn.net/openvpn/wiki/PerformanceTestingOpenVPN
> > hopefully in next 1-2 weeks
> >
> > I also believe that spectre mitigation is neglectable, but it is good to
> have numbers
> >
> > пн, 27 сент. 2021 г. в 12:58, Lev Stipakov :
> >>
> >> I didn't, but here
> >>
> >> https://devblogs.microsoft.com/cppblog/spectre-mitigations-in-msvc/
> >>
> >> it says that
> >>
> >> "On the MSVC team, we’ve reviewed information in detail and conducted
> >> extensive tests, which showed the performance impact of the new
> >> /Qspectre switch to be negligible."
> >> --
> >> -Lev
>
>
>
> --
> -Lev
>
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] [PATCH v2] BUILD: enable CFG and Spectre mitigation for MSVC

[Илья Шипицин]

I'll setup test stand similar to this one
https://community.openvpn.net/openvpn/wiki/PerformanceTestingOpenVPN
hopefully in next 1-2 weeks

I also believe that spectre mitigation is neglectable, but it is good to
have numbers

пн, 27 сент. 2021 г. в 12:58, Lev Stipakov :

> I didn't, but here
>
> https://devblogs.microsoft.com/cppblog/spectre-mitigations-in-msvc/
>
> it says that
>
> "On the MSVC team, we’ve reviewed information in detail and conducted
> extensive tests, which showed the performance impact of the new
> /Qspectre switch to be negligible."
> --
> -Lev
>
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] [PATCH] BUILD: enable CFG and Spectre mitigation for MSVC

[Илья Шипицин]

thanks,

I'll recheck and will send v2 soon

вт, 21 сент. 2021 г. в 16:49, Lev Stipakov :

> Hi,
>
> Sorry for the delay.
>
> I got "command line error D8016: '/ZI' and '/guard:cf' command-line
> options are incompatible" errors for Debug configuration,
> Release works fine. Looks like "Debug Information Format: Program
> Database for Edit and Continue" is not compatible with Control Flow
> Guard:
>
>
> https://docs.microsoft.com/en-us/cpp/build/reference/guard-enable-control-flow-guard?view=msvc-160
>
> Let's apply those changes to Release configurations only.
>
> ke 15. syysk. 2021 klo 15.27 Ilya Shipitsin (chipits...@gmail.com)
> kirjoitti:
> >
> > found by BinSkim
> >
> > Signed-off-by: Ilya Shipitsin 
> > ---
> >  src/compat/Debug.props|  1 +
> >  src/compat/Release.props  |  1 +
> >  src/compat/compat.vcxproj |  6 ++
> >  src/openvpn/openvpn.vcxproj   | 12 
> >  src/openvpnmsica/openvpnmsica.props   |  1 +
> >  src/openvpnmsica/openvpnmsica.vcxproj |  6 ++
> >  src/openvpnserv/openvpnserv.vcxproj   |  6 ++
> >  src/tapctl/tapctl.vcxproj |  6 ++
> >  8 files changed, 39 insertions(+)
> >
> > diff --git a/src/compat/Debug.props b/src/compat/Debug.props
> > index 31bb9d91..810609bf 100644
> > --- a/src/compat/Debug.props
> > +++ b/src/compat/Debug.props
> > @@ -15,6 +15,7 @@
> >
> _DEBUG;%(PreprocessorDefinitions)
> >MultiThreadedDebugDLL
> >EditAndContinue
> > +  Guard
> >  
> >
> >
> > diff --git a/src/compat/Release.props b/src/compat/Release.props
> > index 63828b79..50eaa8de 100644
> > --- a/src/compat/Release.props
> > +++ b/src/compat/Release.props
> > @@ -15,6 +15,7 @@
> >MultiThreadedDLL
> >ProgramDatabase
> >
> NDEBUG;%(PreprocessorDefinitions)
> > +  Guard
> >  
> >  
> >true
> > diff --git a/src/compat/compat.vcxproj b/src/compat/compat.vcxproj
> > index 49824783..fe03a51a 100644
> > --- a/src/compat/compat.vcxproj
> > +++ b/src/compat/compat.vcxproj
> > @@ -38,33 +38,39 @@
> >  MultiByte
> >  true
> >  v142
> > +Spectre
> >
> > Condition="'$(Configuration)|$(Platform)'=='Release|x64'"
> Label="Configuration">
> >  StaticLibrary
> >  MultiByte
> >  true
> >  v142
> > +Spectre
> >
> > Condition="'$(Configuration)|$(Platform)'=='Release|ARM64'"
> Label="Configuration">
> >  StaticLibrary
> >  MultiByte
> >  true
> >  v142
> > +Spectre
> >
> > Condition="'$(Configuration)|$(Platform)'=='Debug|Win32'"
> Label="Configuration">
> >  StaticLibrary
> >  MultiByte
> >  v142
> > +Spectre
> >
> > Condition="'$(Configuration)|$(Platform)'=='Debug|x64'"
> Label="Configuration">
> >  StaticLibrary
> >  MultiByte
> >  v142
> > +Spectre
> >
> > Condition="'$(Configuration)|$(Platform)'=='Debug|ARM64'"
> Label="Configuration">
> >  StaticLibrary
> >  MultiByte
> >  v142
> > +Spectre
> >
> >
> >
> > diff --git a/src/openvpn/openvpn.vcxproj b/src/openvpn/openvpn.vcxproj
> > index 5b3e0c6c..8d27f9c6 100644
> > --- a/src/openvpn/openvpn.vcxproj
> > +++ b/src/openvpn/openvpn.vcxproj
> > @@ -38,33 +38,39 @@
> >  true
> >  NotSet
> >  v142
> > +Spectre
> >
> > Condition="'$(Configuration)|$(Platform)'=='Release|x64'"
> Label="Configuration">
> >  Application
> >  true
> >  NotSet
> >  v142
> > +Spectre
> >
> > Condition="'$(Configuration)|$(Platform)'=='Release|ARM64'"
> Label="Configuration">
> >  Application
> >  true
> >  NotSet
> >  v142
> > +Spectre
> >
> > Condition="'$(Configuration)|$(Platform)'=='Debug|Win32'"
> Label="Configuration">
> >  Application
> >  NotSet
> >  v142
> > +Spectre
> >
> > Condition="'$(Configuration)|$(Platform)'=='Debug|x64'"
> Label="Configuration">
> >  Application
> >  NotSet
> >  v142
> > +Spectre
> >
> > Condition="'$(Configuration)|$(Platform)'=='Debug|ARM64'"
> Label="Configuration">
> >  Application
> >  NotSet
> >  v142
> > +Spectre
> >
> >
> >
> > @@ -146,6 +152,7 @@
> >Level2
> >true
> >
> ..\compat;$(SolutionDir);%(AdditionalIncludeDirectories)
> > +  Guard
> >  
> >  
> >  
> > @@ -161,6 +168,7 @@
> >Level2
> >true
> >
> ..\compat;$(SolutionDir)include;$(SolutionDir);%(AdditionalIncludeDirectories)
> > +  Guard
> >  
> >  
> >  
> > @@ -176,6 +184,7 @@
> >Level2
> >true
> >
> ..\compat;$(SolutionDir);%(AdditionalIncludeDirectories)
> > +  Guard
> >  
> >  
> >  
> > @@ -191,6 +200,7 @@
> >Level2
> >true
> >
> ..\compat;$(SolutionDir);%(AdditionalIncludeDirectories)
> > +  Guard
> >  
> >  
> >  
> > @@ -206,6 +216,7 @@
> >Level2
> >true
> >
> 

Re: [Openvpn-devel] [PATCH] CI: github actions: keep "pdb" in artifacts

[Илья Шипицин]

Sorry, I missed "signed off by". Please add during commit

On Thu, Aug 26, 2021, 3:20 PM Lev Stipakov  wrote:

> Patch is missing SOB line, but I guess this can be fixed by the
> committer, if needed?
>
> Checked https://github.com/chipitsine/openvpn/actions/runs/1108264158
> so that PDBs are indeed stored as artifacts.
>
> Acked-by: Lev Stipakov 
>
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] is this expected when using "--dev null" ?

[Илья Шипицин]

I tried 2.4.7:

Sat Jun 26 07:36:39 2021 /sbin/ip link set dev null up mtu 1500
Cannot find device "null"
Sat Jun 26 07:36:39 2021 Linux ip link set failed: external program exited
with error status: 1


сб, 26 июн. 2021 г. в 12:34, Илья Шипицин :

> Hello,
>
> I'm using "null" for testing (to avoid modifiyng routes and interfaces).
> current master tells me
>
> 2021-06-26 07:27:03 net_iface_mtu_set: rtnl: cannot get ifindex for null:
> No such device (errno=19)
> 2021-06-26 07:27:03 Linux can't set mtu (1500) on null
> 2021-06-26 07:27:03 Exiting due to fatal error
>
>
> is this considered as a feature or bug ?
>
>
>
> cheers,
> Ilya
>
>
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

[Openvpn-devel] is this expected when using "--dev null" ?

[Илья Шипицин]

Hello,

I'm using "null" for testing (to avoid modifiyng routes and interfaces).
current master tells me

2021-06-26 07:27:03 net_iface_mtu_set: rtnl: cannot get ifindex for null:
No such device (errno=19)
2021-06-26 07:27:03 Linux can't set mtu (1500) on null
2021-06-26 07:27:03 Exiting due to fatal error


is this considered as a feature or bug ?



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

Re: [Openvpn-devel] [PATCH] Add github actions

[Илья Шипицин]

вт, 8 июн. 2021 г. в 20:26, Arne Schwabe :

> dummy0 gives strange errors on the Ubuntu 16 runner on github actions
> because
> dummy already exist, so use a more unique ovpn-dummy0 name instead.
>
> Github actions are a good alternative to travis-ci, which futrure is
> questionable
> at the moment without payment. The github actions also allows building on
> macOS
>

we can remove most configurations from travis, except unique like s390x,
ppc64le, ...



> and Windows (not included in this commit). The  matrix is a bit different
> than Coverity and uses different Ubuntu version with their native OpenSSL
> (1.0.2, 1.1.1)/mbed TLS instead of manually compiling different OpenSSL
> versions on just Ubuntu 20.04.
>
> Signed-off-by: Arne Schwabe 
> ---
>  .github/workflows/build.yaml   | 184 +
>  tests/t_net.sh |   2 +-
>  tests/unit_tests/openvpn/test_networking.c |   2 +-
>  3 files changed, 186 insertions(+), 2 deletions(-)
>  create mode 100644 .github/workflows/build.yaml
>
> diff --git a/.github/workflows/build.yaml b/.github/workflows/build.yaml
> new file mode 100644
> index 0..7ff379802
> --- /dev/null
> +++ b/.github/workflows/build.yaml
> @@ -0,0 +1,184 @@
> +# The name of our workflow
> +name: Build
> +on: [push, pull_request]
> +
> +jobs:
> +  mingw:
> +strategy:
> +  matrix:
> +include:
> +  - target: mingw64
> +chost: x86_64-w64-mingw32
> +  - target: mingw
> +chost: i686-w64-mingw32
> +
> +runs-on: ubuntu-20.04
> +env:
> +  MAKEFLAGS: -j3
> +  LZO_VERSION: "2.10"
> +  PKCS11_HELPER_VERSION: "1.26"
> +  OPENSSL_VERSION: "1.1.1j"
> +  TAP_WINDOWS_VERSION: "9.23.3"
> +  CHOST: ${{ matrix.chost }}
> +  TARGET: ${{ matrix.target }}
> +steps:
> +  - name: Install dependencies
> +run: sudo apt update && sudo apt install -y mingw-w64 libtool
> automake autoconf man2html unzip
> +  - name: Checkout ovpn-dco-win
> +uses: actions/checkout@v2
> +with:
> +  repository: OpenVPN/ovpn-dco-win
> +  path: ovpn-dco-win
> +  - name: Checkout OpenVPN
> +uses: actions/checkout@v2
> +with:
> +  path: openvpn
> +
> +  - name: autoconf
> +run: autoreconf -fvi
> +working-directory: openvpn
> +
> +  - name: Cache dependencies
> +id: cache
> +uses: actions/cache@v2
> +with:
> +  path: '~/mingw/'
> +  key: ${{ matrix.target }}-mingw-${{ env.LZO_VERSION }}-${{
> env.PKCS11_HELPER_VERSION }}-${{ env.TAP_WINDOWS_VERSION }}
> +
> +  # Repeating  if: steps.cache.outputs.cache-hit != 'true'
> +  # on every step for building dependencies is ugly but
> +  # I haven't found a better solution so far.
> +
> +  - name: Download mingw depnendencies
> +if: steps.cache.outputs.cache-hit != 'true'
> +run: |
> +  wget -c -P download-cache/ "
> https://build.openvpn.net/downloads/releases/tap-windows-${TAP_WINDOWS_VERSION}.zip
> "
> +  wget -c -P download-cache/ "
> https://www.oberhumer.com/opensource/lzo/download/lzo-${LZO_VERSION}.tar.gz
> "
> +  wget -c -P download-cache/ "
> https://github.com/OpenSC/pkcs11-helper/archive/pkcs11-helper-${PKCS11_HELPER_VERSION}.tar.gz
> "
> +  wget -c -P download-cache/ "
> https://www.openssl.org/source/old/1.1.1/openssl-${OPENSSL_VERSION}.tar.gz
> "
> +  tar zxf
> "download-cache/pkcs11-helper-${PKCS11_HELPER_VERSION}.tar.gz"
> +  tar zxf "download-cache/openssl-${OPENSSL_VERSION}.tar.gz"
> +  tar zxf "download-cache/lzo-${LZO_VERSION}.tar.gz"
> +  unzip download-cache/tap-windows-${TAP_WINDOWS_VERSION}.zip
> +
> +  - name: Configure OpenSSL
> +if: steps.cache.outputs.cache-hit != 'true'
> +run: ./Configure --cross-compile-prefix=${CHOST}- shared ${{
> matrix.target }} no-capieng --prefix="${HOME}/mingw/opt"
> --openssldir="${HOME}/mingw/opt" -static-libgcc
> +working-directory: "./openssl-1.1.1j"
> +
> +  - name: Build OpenSSL
> +if: steps.cache.outputs.cache-hit != 'true'
> +run: make
> +working-directory: "./openssl-1.1.1j/"
> +
> +  - name: Install OpenSSL
> +if: steps.cache.outputs.cache-hit != 'true'
> +run: make install
> +working-directory: "./openssl-1.1.1j/"
> +
> +  - name: autoreconf pkcs11-helper
> +if: steps.cache.outputs.cache-hit != 'true'
> +run: autoreconf -iv
> +working-directory: "./pkcs11-helper-pkcs11-helper-1.26"
> +
> +  - name: configure pkcs11-helper
> +if: steps.cache.outputs.cache-hit != 'true'
> +run: OPENSSL_LIBS="-L${HOME}/mingw/opt/lib -lssl -lcrypto"
> OPENSSL_CFLAGS=-I$HOME/mingw/opt/include
> PKG_CONFIG_PATH=${HOME}/mingw/opt/lib/pkgconfig ./configure --host=${CHOST}
> --program-prefix='' --libdir=${HOME}/mingw/opt/lib
> 

Re: [Openvpn-devel] [PATCH applied] Re: build: Remove compat-lz4

[Илья Шипицин]

this probably will break windows cross compile (it uses lz4 bundle).

Samuli, can you please keep any eye on it  (new test installer maybe) ?

чт, 18 мар. 2021 г. в 12:45, Gert Doering :

> Acked-by: Gert Doering 
>
> I have tested compilation "with default options" on FreeBSD with lz4
> (works), Gentoo without lz4 (errors out), Gentoo with lz4 (works), and
> with --disable-lz4 on Gentoo without lz4 (works).
>
> I assume some of the buildbots will need a bit of tending now (because
> "no lz4 installed, since we bundle it anyway").  They will tell me...
>
> Your patch has been applied to the master branch.
>
> commit 24596b258aa3a9c0bd79e7e7bd4753c48a435408
> Author: David Sommerseth
> Date:   Wed Mar 17 23:06:42 2021 +0100
>
>  build: Remove compat-lz4
>
>  Signed-off-by: David Sommerseth 
>  Acked-by: Gert Doering 
>  Message-Id: <20210317220642.38741-1-open...@sf.lists.topphemmelig.net
> >
>  URL:
> https://www.mail-archive.com/search?l=mid=20210317220642.38741-1-open...@sf.lists.topphemmelig.net
>  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 mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] using openssl feature wherever possible

[Илья Шипицин]

we may keep combo.
both #ifdef EVP_PKEY_TLS1_PRF and comment related to supported openssl
versions (to drop support if we decide)

вт, 9 мар. 2021 г. в 17:56, Gert Doering :

> Hi,
>
> On Tue, Mar 09, 2021 at 05:52:12PM +0500,  ?? wrote:
> > > On Tue, Mar 09, 2021 at 04:54:13PM +0500,  ??
> wrote:
> > > > if nobody minds, I can send several patches that eliminates
> comparison of
> > > > OPENSSL_VERSION, for example
> > >
> > > We do mind.  They are coded this way on purpose - so when we drop
> support
> > > for OpenSSL before 1.1.0, it is clear from the code which sections can
> >
> > it is not much fun to catch things like
> >
> https://boringssl.googlesource.com/boringssl/+/49e9f67d8b7cbeb3953b5548ad1009d15947a523%5E%21/include/openssl/base.h
> >
> > (BoringSSL claims itself as 1.1.0, accidentally decided "I'm 1.1.1 now")
>
> We do not support BoringSSL.
>
> (Or any other SSL library that claims "I am compatible with OpenSSL 1.1.1"
> but isn't, really - which is why the LibreSSL adjustments are always very
> minimal)
>
> We sort-of-support LibreSSL because it is the system SSL library on
> OpenBSD.  Otherwise, the answer would be the same as for BoringSSL.
>
> 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
>
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] using openssl feature wherever possible

[Илья Шипицин]

вт, 9 мар. 2021 г. в 17:47, Gert Doering :

> Hi,
>
> On Tue, Mar 09, 2021 at 04:54:13PM +0500,  ?? wrote:
> > if nobody minds, I can send several patches that eliminates comparison of
> > OPENSSL_VERSION, for example
>
> We do mind.  They are coded this way on purpose - so when we drop support
> for OpenSSL before 1.1.0, it is clear from the code which sections can
>

it is not much fun to catch things like
https://boringssl.googlesource.com/boringssl/+/49e9f67d8b7cbeb3953b5548ad1009d15947a523%5E%21/include/openssl/base.h

(BoringSSL claims itself as 1.1.0, accidentally decided "I'm 1.1.1 now")



> be removed completely.
>
> 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
>
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

[Openvpn-devel] using openssl feature wherever possible

[Илья Шипицин]

Hello,

if nobody minds, I can send several patches that eliminates comparison of
OPENSSL_VERSION, for example


diff --git a/src/openvpn/crypto_openssl.c b/src/openvpn/crypto_openssl.c
index 49698e4b..316cca6f 100644
--- a/src/openvpn/crypto_openssl.c
+++ b/src/openvpn/crypto_openssl.c
@@ -51,7 +51,8 @@
 #include 
 #include 

-#if (OPENSSL_VERSION_NUMBER >= 0x1010L) &&
!defined(LIBRESSL_VERSION_NUMBER)
+#ifdef EVP_PKEY_TLS1_PRF
 #include 
 #endif




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

[Openvpn-devel] new coverity release

[Илья Шипицин]

Hello,

how are coverity builds scheduled ?
shouldn't we start new one ?

https://community.synopsys.com/s/question/0D52H5NeWJfSAN/announcement-upcoming-coverity-scan-upgrade-to-coverity-202009-release


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

Re: [Openvpn-devel] is it possible to store saved password in tpm instead of registry ?

[Илья Шипицин]

ср, 13 янв. 2021 г. в 22:01, Jan Just Keijser :

> Hi,
>
> On 13/01/21 17:20, Илья Шипицин wrote:
> > Hello,
> >
> > if user save password, it might be stolen from well known location
> > (there are popular password stealers).
> >
> > in theory, is it possible to keep password in tpm ? will it prevent
> > password from being stolen ?
> >
> in theory, yes, but as always, it depends on the circumstances.
>
> With TPM 1.2 you can only store a very limited amount of data in the TPM
> chip; the (open source) implementation I have seen (tss, trousers) store
>

I meant openvpn-gui + user/password authentication + password is kept in
registry encrypted by data protection api (not clear text, but might be
decrypted and stolen easily).

trousers is linux, right ?


> a key in the TPM to scramble other data with; thus, you can encrypt a
> private key or password with a key stored on the TPM and only if you
> have the TPM will you be able to decrypt it.
> I've never been particularly impressed with the security of this setup,
> however, as trousers seems to suggest to store the actualy decryption
> key in an environment variable...
>
> With TPM 2.0 you can store more data in the chip, including a full
> private key. This makes it behave more like a regular PKCS#11 device,
> where you store the private key, not the user password on it. Of course,
> it will/should also be possible to store a user password on it.
>
> cheers,
>
> JJK
>
>
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

[Openvpn-devel] is it possible to store saved password in tpm instead of registry ?

[Илья Шипицин]

Hello,

if user save password, it might be stolen from well known location (there
are popular password stealers).

in theory, is it possible to keep password in tpm ? will it prevent
password from being stolen ?

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

Re: [Openvpn-devel] Travis-ci is changing billing

[Илья Шипицин]

we can move to Github Actions.
or to Azure Pipelines

both support amd64 linux / osx / windows, very versatile setup.

unfortunately, no support for s390, arm64, ppc64le (unless own build agents
attached)


чт, 24 дек. 2020 г. в 06:42, tincanteksup :

>
>
> On 23/12/2020 18:03, Илья Шипицин wrote:
> > On Wed, Dec 23, 2020, 10:42 PM Gert Doering  wrote:
> >
> >> Hi,
> >>
> >> On Wed, Dec 23, 2020 at 04:06:26PM +, tincanteksup wrote:
> >>> This may help shed some light:
> >>>
> >>> https://blog.travis-ci.com/2020-11-02-travis-ci-new-billing
> >>
> >> I'm more confused than before.  So is what we do still free?  Do we
> >> need to apply somewhere?
> >>
> >
> > It is one time 1000 minutes free tier.
> > Once it is used the free game is over.
> >
> > In theory we can contact and ask for permanent OSS free limit, but Travis
> > did not reply to anybody
> >
> >
>
> Travis did claim "abuse" as their reasoning, which sounds feasible.
>
> On the up-side, builds do seem to be faster :-)
>
>
>
>
>
> >
> >> Do we do MacOS builds?  If yes, we might consider removing them (we
> >> do have a MacOS buildslave)...
> >>
> >> 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
> >> ___
> >> Openvpn-devel mailing list
> >> Openvpn-devel@lists.sourceforge.net
> >> https://lists.sourceforge.net/lists/listinfo/openvpn-devel
> >>
> >
>
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] Travis-ci is changing billing

[Илья Шипицин]

On Wed, Dec 23, 2020, 10:42 PM Gert Doering  wrote:

> Hi,
>
> On Wed, Dec 23, 2020 at 04:06:26PM +, tincanteksup wrote:
> > This may help shed some light:
> >
> > https://blog.travis-ci.com/2020-11-02-travis-ci-new-billing
>
> I'm more confused than before.  So is what we do still free?  Do we
> need to apply somewhere?
>

It is one time 1000 minutes free tier.
Once it is used the free game is over.

In theory we can contact and ask for permanent OSS free limit, but Travis
did not reply to anybody



> Do we do MacOS builds?  If yes, we might consider removing them (we
> do have a MacOS buildslave)...
>
> 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
> ___
> Openvpn-devel mailing list
> Openvpn-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/openvpn-devel
>
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

[Openvpn-devel] Travis-ci is changing billing

[Илья Шипицин]

https://news.ycombinator.com/item?id=25338983

Actually, not many choices, either to drop Travis or to pay for it.




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

Re: [Openvpn-devel] wanted: mechanism to send text messages to client

[Илья Шипицин]

пн, 21 дек. 2020 г. в 23:26, Greg Cox :

> On Mon, Dec 21, 2020 at 7:57 AM Илья Шипицин  wrote:
>
>> that's interesting point.
>> being dependent on whether users logs or not does not look very good.
>>
>
> We only go to their logs when they come to us with issues.  When we can
> head the users off ahead of time, it's easier.
>
>
>> I'd say it is identity management related thing to renew user cert when
>> it is about to expire.
>> i.e. notify user in proper way and tell him to renew.
>>
>> as a side question, how do you inform users ? i.e. is it some self
>> service portal ?
>>
>
> It's definitely "an IAM problem" to begin with... but it becomes "a VPN
> problem" eventually.  (abstractly speaking).
>
> We have a cron that, every day, looks at the CA's VPN certs.  If you are
> at 14, 7, 3, 2, or 1 days left, you get an email warning of the impending
> expiration and links to the login portal + docs so you can renew (or revoke
> the cert and stop being nagged).  At 2 days expired you get a final mail
> explaining that it's expired and you won't be nagged anymore and what to do
> if you need back in.
>

wow.

it is exactly how I meant it :)


>
> This helps tickets a lot, but when people filter their mail and never read
> it, the lack of access falls through to being "a VPN problem."  We did what
> we could to head off the issue ahead of time from the IAM side, and it
> becomes a situation where, as the support personnel, "well, there MUST be
> something vastly wrong because surely nobody would miss 6 emails and end up
> here asking me to look at a problem." ... except, they do.
>

if there's self service portal, can we use dhcp option 114 (which is used
for captive portal) ?



> My contention is, a VPN client has enough information from its own certs
> to know when its certs are expired and thus not going to work (Yes, there's
> plenty of OTHER reasons a connection can fail, but in a well designed
> setup, the user's certs will go stale long before the server).  It tells
> you this problem in the logs, which folks never read.  If the software were
> to contain a mechanism to make certain failure cases automatically more
> prominent, particularly for 'simple' users who have GUI clients, it'll be a
> big win for supportability on larger installs.
>
> And I realize this is getting into advocacy and away from what's right for
> a -devel list, so I'll stop here on this thread.
>

we are still on topic.


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

Re: [Openvpn-devel] wanted: mechanism to send text messages to client

[Илья Шипицин]

пн, 21 дек. 2020 г. в 03:37, Greg Cox :

> tl;dr - anything that lets me selectively put a message in front of my
> users is great.  Yes please.
>
>
> The number one problem my users come across is expired certs.  Nobody
> reads logs until they're forced to.
>


that's interesting point.
being dependent on whether users logs or not does not look very good.
I'd say it is identity management related thing to renew user cert when it
is about to expire.
i.e. notify user in proper way and tell him to renew.

as a side question, how do you inform users ? i.e. is it some self service
portal ?



>
> A notif mechanism like you're describing would be great.
> With that I can set up scripts that push notices when someone is
> connected + within some amount of expiry, and instructions on what to do.
>
> But there's also those users that almost never connect.  I dream of having
> GUI clients changing their text/icons and/or refusing to even attempt to
> connect, with an explicit warning of "your cert is expired", rather than
> connections failing 'silently' when they use the VPN for the first time in
> forever.  A user complaint of "it says my cert is expired, what do I do?"
> is much easier to handle than "is the vpn broken? it worked yesterday!"
> 95% of the time it's certs, but I still have to triage it more fully for
> the times it's not.
>
>
> So IMO, 1-2 are fundamental, 3-5 are
> wishlist/consideration/extensions/ideas, use or ignore as you see fit:
> * Make the ability for receiving messages on a client as described.
> Enabled by default, maybe selectively disable-able because someone will
> think it's spammy, but I'd almost suggest not allowing it.
> * Make the ability to send a user a message via management.  Enabled by
> default, maybe selectively disable-able as a safety mechanism / make
> someone "key the mic to speak."
> * Make the ability to 'wall' a message out to all connected users in one
> command, e.g. 'wall "server going down in 5 mins"' or something like that.
> * Make the ability to 'post' a message for some amount of time, e.g.
> 'wallpost 60m "server going down at 1700"'  Sending a message gets someone
> who is connected now, but misses the user who connects 2m after I go
> through the list of users and I stop looking.  So, this would hang around
> and pop a message to everyone connected now, plus each new connection, for
> the next 60m.
> * Add an option ala --[no-]use-expired-certs.  When true, proceed like you
> do today; when false, if certs are expired, have the client feed itself a
> message via this mechanism to popup that your certs are expired, so a user
> knows right away what's wrong.  It'd be a spammy option if it tried to tell
> you what to do, so I'm keeping the idea simple and generic.
>
> Thanks for considering.
>
> On Sun, Dec 20, 2020 at 10:55 AM Gert Doering  wrote:
>
>> Hi,
>>
>> I find myself looking for a mechanism by which I could send informational
>> messages ("your cert expires in two weeks, go refresh!" - "your openvpn
>> client needs an upgrade") from the openvpn server to incoming clients.
>>
>> Of course this should work with all connecting clients, that is, "text
>> clients", windows GUI, Tunnelblick, iOS Connect, Android.
>>
>> As far as I am aware, there is no such mechanism today.
>>
>> Do we want to make one?
>>
>>
>> From the server / openvpn core side, it could be something totally
>> trivial:
>>
>>   push "info-msg hey there!"
>>
>> ... and the client would then either print this on the console
>> (if !management) or dump it to management, where the GUI/Tunnelblick
>> could pick it up and create a popup window.
>>
>> What do you think?
>>
>> 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
>> ___
>> Openvpn-devel mailing list
>> Openvpn-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/openvpn-devel
>>
> ___
> Openvpn-devel mailing list
> Openvpn-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/openvpn-devel
>
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] [PATCH] compat/lz4: Update to v1.9.2

[Илья Шипицин]

пт, 2 окт. 2020 г. в 13:51, Arne Schwabe :

> Am 01.10.20 um 17:46 schrieb David Sommerseth:
> > It's a long while since the bundled lz4 library has received an update.
> > It pulls in a lot of various fixes and enhancements, some of the changes
> > fixes compiler warnings and hardens the code a bit too.
> >
>
> Ack for release/2.5. I double checked that the file is identical (modulo
> compat defines) to the upsteam.
>
> I think that this file is outdated so much shows that we do not really
> care about compression so much. Also since we included it, lz4 libraries
> have been available on all major distribution and not having lz4 is not
> as problematic as before. For master I would like to see this
> compat-lz4.* removed instead of being updated. For the 2.5.0 release it
> is too late to remove, so okay for that.
>


windows build process uses bundled lz4. if we simply remove it, windows
build silently switch to "no lz4 enabled ... and that is ok"


>
>
> Acked-By: Arne Schwabe 
>
> ___
> Openvpn-devel mailing list
> Openvpn-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/openvpn-devel
>
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] New man-section pages format

[Илья Шипицин]

I thought of using autogen. No time yet

On Fri, Sep 4, 2020, 4:23 PM tincanteksup  wrote:

> Hi,
>
> this is just something to chew-over..
>
> See:
>
> https://github.com/OpenVPN/openvpn/blob/master/doc/man-sections/generic-options.rst
>
> I noticed that generally the option names, eg: --auth-nocache, wrap and
> the result is unpleasant.
>
> However, further down that same page --daemon progname does not wrap and
> looks much nicer.
>
> I know which format I prefer, perhaps this can be changed..
>
> BR
> Richard
>
>
> ___
> Openvpn-devel mailing list
> Openvpn-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/openvpn-devel
>
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] MSI Installer: Add .ovpn file

[Илья Шипицин]

Hello,

we used to put *.ovpn files on special dedicated website (some guide +
installer downloads + ovpn).
works as charm

чт, 30 июл. 2020 г. в 13:37, Robert Grätz :

> Hello,
>
> I am very happy that 2.5 will be hopefully soon released.
>
> I want to integrate my config file inside the msi installer. I think
> that romansi mentioned that there will be a proper solution for this
> issue. Are there any news or documentation yet? I tried something with
> Microsoft Orca [1], but it doesn't work yet.
>
> Best regards
>
> Robert
>
>
> ___
> Openvpn-devel mailing list
> Openvpn-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/openvpn-devel
>
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] Summary of the community meeting (24th June 2020)

[Илья Шипицин]

there's quite an interesting patchset
https://patchwork.openvpn.net/project/openvpn2/list/?series=230
is it scheduled for 2.5 release ?

or I've missed something and all patches are scheduled for 2.5 ?

ср, 24 июн. 2020 г. в 16:11, Samuli Seppänen :

> Hi,
>
> Here's the summary of the IRC meeting.
>
> ---
>
> COMMUNITY MEETING
>
> Place: #openvpn-meeting on irc.freenode.net
> Date: Wed 24th June 2020
> Time: 11:30 CEST (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, plaisthos and uip participated in this meeting.
>
> ---
>
> Talked about the status of OpenVPN 2.5:
>
> 
>
> Ordex promised to have a look at the async-cc patches this week.
> Plaisthos, dazo and cron2 will follow-up on the review comments to get
> them resolved quickly.
>
> OpenVPN 2.5 MSI looks surprisingly good. Mattock was able to produce
> tap-windows6 MSM ("merge module") which he then used to produce OpenVPN
> 2.5-based MSI installer. The only significant challenge is adding
> code-signing support to openvpn-build/generic.
>
> Automating MSI builds also seems easier than expected, given that the
> existing openvpn-build buildslave can perform the actual build and push
> the artifacts to the Windows packager, which can then build and push the
> results to build.openvpn.net.
>
> Code-vise 2.5-alpha1 is in a good shape, mainly missing
>
> - compression
> - async cc
> - VRF (which is quite trivial)
>
> The auth-token fixes are corner-cases and it was agreed that that can be
> resolved between 2.5-alpha1 and 2.5-beta1.
>
> ---
>
> Talked about moving 2.3 into "oldstable" support mode. Previously we had
> agreed to do that when 2.3.19 was released. However, 2.3.18 was released
> a long while ago and there's nothing queued for 2.3.19. So it was
> decided to move 2.3 to "oldstable" now instead of later.
>
> ---
>
> Talked about starting the deprecation of "--ncp-disable". The idea is
> that --ncp-disable has been mostly a debug feature and as we move
> forward and want to be able to manage VPN security more from server
> side, we want to abandon the possibility to ignore NCP.
>
> This is tied with deprecation of --cipher for everything except p2p:
>
>
> https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg20062.html
>
> Uip will bring these topics up with syzzer a.s.a.p.
>
> ---
>
> Talked about OpenVPN 2.6. There are several things that are 2.6 material:
>
> - Kernel acceleration module (client-side only beta ~next week)
> - Work related to "making DNS handling nice"
>
> It is possible that we'd also need to postpone the --ncp-disable and
> --cipher changes.
>
> However, it was agreed that doing a "quick" 2.6 release in, say, early
> 2021 is doable. It was also agreed that supporting both 2.5 and 2.6 as
> "stable" for a while would be acceptable, as the changes would be mostly
> in OpenVPN and the same release and automation tooling could be used for
> both.
>
> ---
>
> Talked about our use of IV_*. Agreed that rather than having tons of
> IV_FOO=1 options IV_PROTO should be considered a wire-protocol-only
> 64-bit mask field and IV_FEAT would be a new 64-bit mask field
> indicating which features the local side supports.
>
> OpenVPN will need to handle a remote side not providing IV_FEAT.
> Default behaviour when this field is missing must be documented.
> IV_FEAT should be sent by OpenVPN 2.6 and newer. This approach allows
> easier deprecation of features as well.
>
> --
>
> Full chatlog attached
> ___
> Openvpn-devel mailing list
> Openvpn-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/openvpn-devel
>
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] [PATCH applied] Re: Add unit tests for engine keys

[Илья Шипицин]

ср, 24 июн. 2020 г. в 00:37, Gert Doering :

> Hi,
>
> On Tue, Jun 23, 2020 at 12:32:42PM -0700, James Bottomley wrote:
> > > James, are you triggering on specific openvpn messages?  "--enable-
> > > small"
> > > changes these (trimming some warnings and help texts).  Can you test
> > > with
> > > "configure --enable-small", please?
> > >
> > > https://travis-ci.org/github/OpenVPN/openvpn/builds/701385033?utm_med
> > > ium=notification_source=email
> >
> > Yes, that's it.  The problem is the message output by openssl is
> >
> > 2020-06-23 19:28:46 OpenSSL: error:0B080074:lib(11):func(128):reason(116)
> >
> > Instead of:
> >
> > 2020-06-23 12:30:43 OpenSSL: error:0B080074:x509 certificate
> routines:X509_check_private_key:key values mismatch
>
> Indeed :-)
>
> > I think I can make the grep work with the former.
>
> Please do not forget to output log.txt when it fails - it eases diagnosing
> remote failures where we do not have easy access to "file system things"
> (like travis or buildbot).
>

I've added output of log.txt, if you are going to modify "grep" magic, can
you adopt something like that, please ?


https://travis-ci.org/github/chipitsine/openvpn/jobs/701409750


diff --git a/tests/unit_tests/engine-key/check_engine_keys.sh
b/tests/unit_tests/engine-key/check_engine_keys.sh
index e0c9d7b0..770a0c9c 100755
--- a/tests/unit_tests/engine-key/check_engine_keys.sh
+++ b/tests/unit_tests/engine-key/check_engine_keys.sh
@@ -8,6 +8,10 @@ password='AT3S4PASSWD'
 key="${builddir}/client.key"
 pwdfile="${builddir}/passwd"

+grep_a_log () {
+  grep -q $1 $2 || { echo $3; cat $2 ; exit 1; }
+}
+
 # create an engine key for us
 sed 's/PRIVATE KEY/TEST ENGINE KEY/' <
${top_srcdir}/sample/sample-keys/client.key > ${key}
 echo "$password" > $pwdfile
@@ -21,10 +25,10 @@ ${top_builddir}/src/openvpn/openvpn --cd
${top_srcdir}/sample --config sample-co
 # first off check we died because of a key mismatch.  If this doesn't
 # pass, suspect openssl of returning different messages and update the
 # test accordingly
-grep -q 'X509_check_private_key:key values mismatch' log.txt || { echo
"Key mismatch not detected"; exit 1; }
+grep_a_log 'X509_check_private_key:key values mismatch' log.txt 'Key
mismatch not detected'

 # now look for the engine prints (these are under our control)
-grep -q 'ENGINE: engine_init called' log.txt || { echo "Engine
initialization not detected"; exit 1; }
-grep -q 'ENGINE: engine_load_key called' log.txt || { echo "Key was not
loaded from engine"; exit 1; }
-grep -q "ENGINE: engine_load_key got password ${password}" log.txt || {
echo "Key password was not retrieved by the engine"; exit 1; }
+grep_a_log 'ENGINE: engine_init called' log.txt 'Engine initialization not
detected'
+grep_a_log 'ENGINE: engine_load_key called' log.txt 'Key was not loaded
from engine'
+grep_a_log "ENGINE: engine_load_key got password ${password}" log.txt 'Key
password was not retrieved by the engine'
 exit 0
-- 
2.26.2







>
> 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
>
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] [PATCH applied] Re: Add unit tests for engine keys

[Илья Шипицин]

вт, 23 июн. 2020 г. в 23:17, James Bottomley <
james.bottom...@hansenpartnership.com>:

> On Tue, 2020-06-23 at 21:43 +0500, Илья Шипицин wrote:
> > as far as I understand, openssl-1.0.2 does not support engines ?
>
> No, it does.  Engines were a pre 0.9.8 thing.  I support openssl in my
> builds for the TPM engine down to 1.0.1
>
> However, the failure:
>
> > Key mismatch not detected
> >
> > FAIL: check_engine_keys.sh
> >
> > 
> >
> > 1 of 1 test failed
> >
> > Please report to openvpn-us...@lists.sourceforge.net
> >
> > 
>
> Is because an expected message isn't found in the output.  I think it's
> this:
>
># first off check we died because of a key mismatch.  If this doesn't
># pass, suspect openssl of returning different messages and update the
># test accordingly
>grep -q 'X509_check_private_key:key values mismatch' log.txt || { echo
> "Key mismatch not detected"; exit 1; }
>
>If I could get hold of log.txt that would confirm that the test is
>outputting something slightly different from what's expected.
>
>I did run this test on openssl-1.0.2j (I keep a copy of
>openSUSE_Leap_42.3 around precisely for this openssl testing) but it
>ran just fine. so there's clearly something different about the 1.0.2u
>you're using (might be a locale issue?).
>

I'll have a look. Also, I think we should out log.txt in case of failure.


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

Re: [Openvpn-devel] [PATCH applied] Re: Add unit tests for engine keys

[Илья Шипицин]

as far as I understand, openssl-1.0.2 does not support engines ?

вт, 23 июн. 2020 г. в 21:42, Илья Шипицин :

> apparently, it fails for some build on travis
> https://travis-ci.org/github/OpenVPN/openvpn/jobs/701158156
>
> вт, 23 июн. 2020 г. в 18:07, James Bottomley <
> james.bottom...@hansenpartnership.com>:
>
>> On Tue, 2020-06-23 at 09:21 +0200, Gert Doering wrote:
>> > Hi,
>> >
>> > On Tue, Jun 23, 2020 at 08:28:36AM +0200, Gert Doering wrote:
>> > > Acked-by: Gert Doering 
>> > >
>> > > Tested on :
>> > >  - MacOS Mojave with OpenSSL 1.1.1c (brew) and out-of-tree build,
>> > > works.
>> > >  - Linux with mbedtls (does not try engine tests, good :-) )
>> > >  - Linux with OpenSSL 1.1.1, works
>> > >  - FreeBSD 11.3 with OpenSSL 1.0.2s -> v6 fails, v6 works \o/
>> > >
>> > > Conferred with Arne, we agreed on "this is good enough, and who
>> > > wants
>> > > something more sophisticated is welcome to send more patches".
>> >
>> > Oh well.  We do need another round - Travis tells me that "make
>> > distcheck"
>> > is failing.  Which hints at "autoconf is not told what to pack in the
>> > tarball"
>> >
>> > https://travis-ci.org/github/OpenVPN/openvpn/jobs/701158155
>> > ...
>> > make[6]: Entering directory
>> > '/home/travis/build/OpenVPN/openvpn/openvpn-
>> > 2.5_git/_build/sub/tests/unit_tests/engine-key'
>> > 3672make[6]: *** No rule to make target
>> > '../../../../../tests/unit_tests/engine-key/openssl.cnf.in', needed
>> > by 'openssl.cnf'.  Stop.
>> > 3673make[6]: Leaving directory
>> > '/home/travis/build/OpenVPN/openvpn/openvpn-
>> > 2.5_git/_build/sub/tests/unit_tests/engine-key'
>> > 3674
>> >
>> > (so now the source file is missing)
>> >
>> > Please... :-)
>>
>> Sorry about that ... it's missing files from EXTRA_DIST ... plus I
>> don't usually use make dist, so I never remember to run make distcheck.
>>  It passes after this
>>
>> ---8>8>8><8<8<8---
>>
>> From: James Bottomley 
>> Subject: [PATCH] Fix make distcheck for new engine key unit test
>>
>> Add config precursor and script to extra dist and make sure
>> built and test leftover files are cleaned up afterwards.
>>
>> Signed-off-by: James Bottomley 
>> ---
>>  tests/unit_tests/engine-key/Makefile.am | 10 --
>>  1 file changed, 8 insertions(+), 2 deletions(-)
>>
>> diff --git a/tests/unit_tests/engine-key/Makefile.am
>> b/tests/unit_tests/engine-key/Makefile.am
>> index 95e7d868..0bfdfcd4 100644
>> --- a/tests/unit_tests/engine-key/Makefile.am
>> +++ b/tests/unit_tests/engine-key/Makefile.am
>> @@ -2,6 +2,9 @@ AUTOMAKE_OPTIONS = foreign
>>
>>  check_LTLIBRARIES = libtestengine.la
>>  conffiles = openssl.cnf
>> +EXTRA_DIST = \
>> +   openssl.cnf.in \
>> +   check_engine_keys.sh
>>
>>  TESTS_ENVIRONMENT = srcdir="$(abs_srcdir)"; \
>> builddir="$(abs_builddir)"; \
>> @@ -12,8 +15,11 @@ TESTS_ENVIRONMENT = srcdir="$(abs_srcdir)"; \
>>  TESTS = check_engine_keys.sh
>>  check_engine_keys.sh: $(conffiles)
>>
>> -clean-local:
>> -   rm -f $(conffiles)
>> +CLEANFILES = \
>> +   client.key \
>> +   passwd \
>> +   log.txt \
>> +   $(conffiles)
>>
>>  $(builddir)/openssl.cnf: $(srcdir)/openssl.cnf.in
>> sed "s|ABSBUILDDIR|$(abs_builddir)|" < $< > $@
>> --
>> 2.26.2
>>
>>
>>
>> ___
>> Openvpn-devel mailing list
>> Openvpn-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/openvpn-devel
>>
>
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] [PATCH applied] Re: Add unit tests for engine keys

[Илья Шипицин]

apparently, it fails for some build on travis
https://travis-ci.org/github/OpenVPN/openvpn/jobs/701158156

вт, 23 июн. 2020 г. в 18:07, James Bottomley <
james.bottom...@hansenpartnership.com>:

> On Tue, 2020-06-23 at 09:21 +0200, Gert Doering wrote:
> > Hi,
> >
> > On Tue, Jun 23, 2020 at 08:28:36AM +0200, Gert Doering wrote:
> > > Acked-by: Gert Doering 
> > >
> > > Tested on :
> > >  - MacOS Mojave with OpenSSL 1.1.1c (brew) and out-of-tree build,
> > > works.
> > >  - Linux with mbedtls (does not try engine tests, good :-) )
> > >  - Linux with OpenSSL 1.1.1, works
> > >  - FreeBSD 11.3 with OpenSSL 1.0.2s -> v6 fails, v6 works \o/
> > >
> > > Conferred with Arne, we agreed on "this is good enough, and who
> > > wants
> > > something more sophisticated is welcome to send more patches".
> >
> > Oh well.  We do need another round - Travis tells me that "make
> > distcheck"
> > is failing.  Which hints at "autoconf is not told what to pack in the
> > tarball"
> >
> > https://travis-ci.org/github/OpenVPN/openvpn/jobs/701158155
> > ...
> > make[6]: Entering directory
> > '/home/travis/build/OpenVPN/openvpn/openvpn-
> > 2.5_git/_build/sub/tests/unit_tests/engine-key'
> > 3672make[6]: *** No rule to make target
> > '../../../../../tests/unit_tests/engine-key/openssl.cnf.in', needed
> > by 'openssl.cnf'.  Stop.
> > 3673make[6]: Leaving directory
> > '/home/travis/build/OpenVPN/openvpn/openvpn-
> > 2.5_git/_build/sub/tests/unit_tests/engine-key'
> > 3674
> >
> > (so now the source file is missing)
> >
> > Please... :-)
>
> Sorry about that ... it's missing files from EXTRA_DIST ... plus I
> don't usually use make dist, so I never remember to run make distcheck.
>  It passes after this
>
> ---8>8>8><8<8<8---
>
> From: James Bottomley 
> Subject: [PATCH] Fix make distcheck for new engine key unit test
>
> Add config precursor and script to extra dist and make sure
> built and test leftover files are cleaned up afterwards.
>
> Signed-off-by: James Bottomley 
> ---
>  tests/unit_tests/engine-key/Makefile.am | 10 --
>  1 file changed, 8 insertions(+), 2 deletions(-)
>
> diff --git a/tests/unit_tests/engine-key/Makefile.am
> b/tests/unit_tests/engine-key/Makefile.am
> index 95e7d868..0bfdfcd4 100644
> --- a/tests/unit_tests/engine-key/Makefile.am
> +++ b/tests/unit_tests/engine-key/Makefile.am
> @@ -2,6 +2,9 @@ AUTOMAKE_OPTIONS = foreign
>
>  check_LTLIBRARIES = libtestengine.la
>  conffiles = openssl.cnf
> +EXTRA_DIST = \
> +   openssl.cnf.in \
> +   check_engine_keys.sh
>
>  TESTS_ENVIRONMENT = srcdir="$(abs_srcdir)"; \
> builddir="$(abs_builddir)"; \
> @@ -12,8 +15,11 @@ TESTS_ENVIRONMENT = srcdir="$(abs_srcdir)"; \
>  TESTS = check_engine_keys.sh
>  check_engine_keys.sh: $(conffiles)
>
> -clean-local:
> -   rm -f $(conffiles)
> +CLEANFILES = \
> +   client.key \
> +   passwd \
> +   log.txt \
> +   $(conffiles)
>
>  $(builddir)/openssl.cnf: $(srcdir)/openssl.cnf.in
> sed "s|ABSBUILDDIR|$(abs_builddir)|" < $< > $@
> --
> 2.26.2
>
>
>
> ___
> Openvpn-devel mailing list
> Openvpn-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/openvpn-devel
>
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] [PATCH v6 2/3] crypto_openssl: add initialization to pick up local configuration

[Илья Шипицин]

пн, 8 июн. 2020 г. в 15:06, Arne Schwabe :

>
> >
> > Sorry about that.  Best guess is it's missing an include for
> > openssl/conf.h.  You don't need that today because pretty much every
> > other openssl header includes it, but that may not always have been so.
> >
> > Does the below patch fix it?  If it does, it should probably be folded
> > into the other patch.  It should be safe because openssl/conf.h has
> > existed for every version of openssl you support.
>
>
> I am also puzzeld by this. On my local machine the OpenSSL 1.0.2 buildis
> fine without this extra include.
>
> But I am ACKing this alone on the basis that including the conf.h header
> is the corect thing to do (the man page says it should be included)
>
> It fixes the travis build error
> (https://travis-ci.org/github/schwabe/openvpn/builds/695947378) but I do
> not really understand why OpenSSL behaves different there.
>

it might happen if includes are mixed from OS openssl and custom openssl.
I'll have a look (what is include path in travis).



>
> So
>
> Acked-By: Arne Schwabe 
>
> >
> > James
> >
> > ---8>8>8><8<8<8---
> > From: James Bottomley 
> > Subject: [PATCH] crypto_openssl: add include for openssl/conf.h
> >
> > Fix build failure on older versions of openssl.
> >
> > Signed-off-by: James Bottomley 
> > ---
> >  src/openvpn/crypto_openssl.c | 1 +
> >  1 file changed, 1 insertion(+)
> >
> > diff --git a/src/openvpn/crypto_openssl.c b/src/openvpn/crypto_openssl.c
> > index fd57edd2..94b6d85b 100644
> > --- a/src/openvpn/crypto_openssl.c
> > +++ b/src/openvpn/crypto_openssl.c
> > @@ -43,6 +43,7 @@
> >  #include "crypto_backend.h"
> >  #include "openssl_compat.h"
> >
> > +#include 
> >  #include 
> >  #include 
> >  #include 
> >
>
>
> ___
> Openvpn-devel mailing list
> Openvpn-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/openvpn-devel
>
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] is anybody running tests on Fedora ?

[Илья Шипицин]

пн, 4 мая 2020 г. в 16:41, Samuli Seppänen :

> Hi,
>
> We do have a Fedora 30 buildslave and run fping tests there. It also
> seems to run t_client IPv6 ping tests.
>

can you please run the following


dnf whatprovides fping6

?


>
> Samuli
>
> Il 03/05/20 23:02, Илья Шипицин ha scritto:
> > Hello,
> >
> >
> > t_client.sh requires "fping6" binary, which is not available on Fedora.
> > on Fedora "fping" is capable of running ipv6 pings.
> >
> >
> > shall we adopt test ?
> >
> >
> > Cheers,
> > Ilya Shipitcin
> >
> >
> > ___
> > Openvpn-devel mailing list
> > Openvpn-devel@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/openvpn-devel
> >
>
>
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

[Openvpn-devel] is anybody running tests on Fedora ?

[Илья Шипицин]

Hello,


t_client.sh requires "fping6" binary, which is not available on Fedora.
on Fedora "fping" is capable of running ipv6 pings.


shall we adopt test ?


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

Re: [Openvpn-devel] Possible memory alignment Problem in 2.4 ?

[Илья Шипицин]

вт, 24 мар. 2020 г. в 22:19, Michael Kress :

> Am Tue, 24 Mar 2020 11:21:56 +0100
> schrieb Arne Schwabe :
>
> > Am 23.03.20 um 17:11 schrieb Michael Kress:
> > > Hello list,
> > >
> > > There seems to be some kind of alignment problem in OpenVPN 2.4
> > > versions on ARMv4 based machines (32 bit), especially when lzo
> > > compression kicks in.
> >
> > LZO is known to miscompile with gcc 10 and requires
> > -fno-strict-aliasing to compile. and also in my OpenVPN for Android
> > app I have to compile lzo with -O1 instead -O2 since it otherwise
> > segfaults on armv7a. Android uses LLVM/clang to compile so the broken
> > behaviour is present also on other compilers. I never investigated
> > which optimisation flag does break in clang/llvm/armv7a.
>
> The alignment errors happen in OpenVPN code, not in LZO code.
> We have to use the (ancient) gcc 4.0.0. After upgrading OpenVPN from
> 2.3 to 2.4 we did not even upgrade LZO from 2.0.6, but linked
> statically to the old compiled lib. I doubt that the compiler itself
> changes anything here.
>
> > But bottom line is that you probably are running in a similar and I
> > would advise to compile lzo with less optimisation.
>
> Thanks for the suggestion!
>
> Anyways I recompiled LZO without any optimazations and then OpenVPN
> 2.4.8. Unfortunatelly this changed nothing.
>
> A few questions:
> 
> 1) Do you run automated tests of the OpenVPN code on any build server?
>
> 2) If that is the case, is there any test with a version, where
>-DVERIFY_ALIGNMENT is enabled?
>

there are several test suites that you can run using "make check" (it
performs several e2e tests and cmocka testing).
also, there's openvpn vagrant suite intended for running several VMs on
VirtualBox (and build and test openvpn on them)

also, there's buildbot (not exposed to internet, but build logs available
on mailing list)

and there's travis-ci for express tests (actually "make check") for several
build configurations: https://travis-ci.org/github/OpenVPN/openvpn

I think we can add -DVERIFY_ALIGNMENT to some travis-ci builds



>
> 3) If that is also the case, can you see any ERRORS regarding the
>alignment in the logs?
>
> The problem is, that we do not have any power over the clients. It
> might well be, that there are even OpenVPN 2.2 clients out there.
>
> --
> Servus
>   Michael
>
>
> ___
> Openvpn-devel mailing list
> Openvpn-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/openvpn-devel
>
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] [PATCH v3] travis-ci: add arm64, s390x builds.

[Илья Шипицин]

sometimes, arm64 build fails

https://travis-ci.org/github/OpenVPN/openvpn/jobs/666389482?utm_medium=notification_source=github_status


if that will become often, we will mark it as "allowed failures"



thanks to everyone, we have cmocka tests back!

вт, 24 мар. 2020 г. в 14:04, Илья Шипицин :

> I guess nobody yet reported that issue.
>
> Maybe, I'll report.
>
> вт, 24 мар. 2020 г. в 14:03, Lev Stipakov :
>
>> Yes, I agree that with name is looks much better.
>>
>> I wonder why displaying arch requires you to be logged in.
>>
>
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] [PATCH v3] travis-ci: add arm64, s390x builds.

[Илья Шипицин]

I guess nobody yet reported that issue.

Maybe, I'll report.

вт, 24 мар. 2020 г. в 14:03, Lev Stipakov :

> Yes, I agree that with name is looks much better.
>
> I wonder why displaying arch requires you to be logged in.
>
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] Possible memory alignment Problem in 2.4 ?

[Илья Шипицин]

thank you for wonderful investigation.


however, are there reasons for using lzo ? it consumes too much cpu
(comparing to lz4). also, it highly depends on traffic itself, many
application already compress their bytes themselves.

if you are stick to lzo, because it is propagated to all configs, in 2.4
you can push compression options just like dhcp option from server to
clients (and it wins over the config file).

пн, 23 мар. 2020 г. в 21:29, Michael Kress :

> Hello list,
>
> There seems to be some kind of alignment problem in OpenVPN 2.4
> versions on ARMv4 based machines (32 bit), especially when lzo
> compression kicks in.
>
> History:
> 
> We run OpenVPN 2.3 happily on a ARMv4 machine. Now we want to upgrade
> to 2.4 because of automatically negotiated AES instead of BlowFish. The
> configuration is unchanged, only OpenVPN and OpenSSL get upgraded. The
> tunnel gets up, but some traffic is dropped on the OpenVPN server side
> MULTI: bad source address from client [10.1.0.75], packet dropped
>
>
> Short version of the story:
> ---
> Only this helps:
>  $ echo 3 > /proc/cpu/alignment
> Compiling with CFLAGS="${CFLAGS} -DVERIFY_ALIGNMENT"
> leads to a lot of alignment failure messages
>
> Long version of the story:
> --
> - Authentication via certificates
> - both server and client are ARMv4 based machines
> - Tunnel IP net is 10.1.0.0/24
> - LZO compression with --comp-lzo (adaptive)
> - IP of OpenVPN server: 192.168.202.82/22
>   IP of OVPN_Client1: 192.168.201.116/22
>   IP of OVPN_Client2: 192.168.203.84/22
>
> A ping from the OpenVPN client to the OpenVPN server works,
> as long the packet payload has a certain size
>   $ ping 10.1.0.1 -s 350
>
> The same ping situation but with a default payload ping failes:
>   $ ping 10.1.0.1
> The server complains with
> Mon Mar 23 14:54:06 2020 us=663594 OVPN_Client1/192.168.201.116 MULTI:
> bad source address from client [10.1.0.75], packet dropped
>
> Interesting: The source IP address is different with every ping packet
> reaching the OpenVPN server: 10.1.0.XXX, with XXX is a random number
> from 0 to 254. Eventually a ping becomes answered with a pong, when
> luckily the correct tunnel IP address is used (chance is 1 to 255 :-)
>
> With the bigger ping payload _every_ packet gets answered, because a
> manually entered debug line prints the correct source address of the
> packet.
>
> Removing LZO compression also solves the problem: With --comp-lzo removed
> from the client and server, no packets are dropped. We used LZO 2.06 and
> 2.10, they behave the same.
>
> Modifying the cipher and/or the hash algorithm doesn't change anything,
> even if no encryption is used at all (none)
>
>
> Then I compilied OpenVPN (all of the three versions) with
>CFLAGS="${CFLAGS} -DVERIFY_ALIGNMENT"
> and started OpenVPN very verbose (verb 14).
>
> This is tail -f /var/log/openvpn.log | grep ERROR:
> Mon Mar 23 13:25:59 2020 us=74 OVPN_Client2/192.168.202.84:53155
> ERROR: Alignment at mss.c/56 ptr=0x00c3ece8 OLC=537/84/2562 I=/1077682176
> Mon Mar 23 13:26:00 2020 us=66 OVPN_Client2/192.168.202.84:53155
> ERROR: Alignment at mroute.h/196 ptr=0x00bfec30 OLC=461/84/2562
> I=crypto.c/397
> Mon Mar 23 13:26:00 2020 us=69 OVPN_Client1/192.168.201.116:49610
> ERROR: Alignment at proto.c/48 ptr=0x00c3ece8 OLC=461/84/2562 I=/1077682176
> Mon Mar 23 13:26:00 2020 us=69 OVPN_Client1/192.168.201.116:49610
> ERROR: Alignment at mss.c/56 ptr=0x00c3ece8 OLC=461/84/2562 I=/1077682176
> Mon Mar 23 13:26:00 2020 us=72 OVPN_Client1/192.168.201.116:49610
> ERROR: Alignment at mroute.h/196 ptr=0x00bfec30 OLC=537/84/2562
> I=crypto.c/573
> Mon Mar 23 13:26:00 2020 us=75 OVPN_Client2/192.168.202.84:53155
> ERROR: Alignment at proto.c/48 ptr=0x00c3ece8 OLC=537/84/2562 I=/1077682176
> Mon Mar 23 13:26:00 2020 us=75 OVPN_Client2/192.168.202.84:53155
> ERROR: Alignment at mss.c/56 ptr=0x00c3ece8 OLC=537/84/2562 I=/1077682176
> Mon Mar 23 13:26:01 2020 us=71 OVPN_Client2/192.168.202.84:53155
> ERROR: Alignment at mroute.h/196 ptr=0x00bfec30 OLC=461/84/2562
> I=crypto.c/397
> Mon Mar 23 13:26:01 2020 us=73 OVPN_Client1/192.168.201.116:49610
> ERROR: Alignment at proto.c/48 ptr=0x00c3ece8 OLC=461/84/2562 I=/1077682176
> Mon Mar 23 13:26:01 2020 us=73 OVPN_Client1/192.168.201.116:49610
> ERROR: Alignment at mss.c/56 ptr=0x00c3ece8 OLC=461/84/2562 I=/1077682176
> Mon Mar 23 13:26:01 2020 us=77 OVPN_Client1/192.168.201.116:49610
> ERROR: Alignment at mroute.h/196 ptr=0x00bfec30 OLC=537/84/2562
> I=crypto.c/573
> Mon Mar 23 13:26:01 2020 us=80 OVPN_Client2/192.168.202.84:53155
> ERROR: Alignment at proto.c/48 ptr=0x00c43188 OLC=537/84/2562 I=/1077682176
> Mon Mar 23 13:26:01 2020 us=80 OVPN_Client2/192.168.202.84:53155
> ERROR: Alignment at mss.c/56 ptr=0x00c43188 OLC=537/84/2562 I=/1077682176
> Mon Mar 23 13:26:02 2020 us=68 OVPN_Client2/192.168.202.84:53155
> ERROR: Alignment at 

Re: [Openvpn-devel] [PATCH v3] travis-ci: add arm64, s390x builds.

[Илья Шипицин]

sorry, I sent it twice.

the last one is good, please ignore previous "v2"

I've managed to resolve "travis_wait" issue. it was non trivial output
redirection  issue.
the rest is just fine.


patch itself is important it re-enables cmocka tests in travis (they are
not running now, after cmocka git submodule was removed)

вс, 22 мар. 2020 г. в 17:35, :

> From: Ilya Shipitsin 
>
> as described on https://docs.travis-ci.com/user/multi-cpu-architectures
> travis-ci
> now supports amd64, ppcle, arm64, s390 architectures. Add arm64 and s390x.
>
> travis-ci images were upgraded to bionic.
>
> "sudo" is deprecated, let us remove it, also "matrix" is deprecated in
> favour of "jobs".
>
> LD_LIBRARY_PATH was replaced by using "rpath" in LDFLAGS, which is more
> elegant way of linking.
>
> also, dependencies were upgraded to the latest versions.
>
> travis_wait was added for long openssl builds.
>
> cmocka was added to linux and osx builds.
> ---
> v3 resolved travis_wait output redirection issue, now it works as
> expected. I had to specify "names" for jobs,
> without names travis puts secure variable as job name
>
> v2 rebased against proper commit
>
>
>  .travis.yml   | 87 +--
>  .travis/build-check.sh| 10 +
>  .travis/build-deps.sh | 10 +++--
>  .travis/run-build-deps.sh | 10 -
>  4 files changed, 62 insertions(+), 55 deletions(-)
>  delete mode 100755 .travis/run-build-deps.sh
>
> diff --git a/.travis.yml b/.travis.yml
> index 40296d87..925d09ea 100644
> --- a/.travis.yml
> +++ b/.travis.yml
> @@ -1,5 +1,4 @@
> -sudo: required
> -dist: xenial
> +dist: bionic
>
>  os: linux
>
> @@ -11,86 +10,111 @@ env:
>  - PREFIX="${HOME}/opt"
>  - TAP_WINDOWS_VERSION=9.23.3
>  - LZO_VERSION=2.10
> -- PKCS11_HELPER_VERSION=1.25.1
> -- MBEDTLS_VERSION=2.16.1
> +- PKCS11_HELPER_VERSION=1.26
> +- MBEDTLS_VERSION=2.16.4
>  - MBEDTLS_CFLAGS="-I${PREFIX}/include"
>  - MBEDTLS_LIBS="-L${PREFIX}/lib -lmbedtls -lmbedx509 -lmbedcrypto"
> -- OPENSSL_VERSION=1.0.2s
> +- OPENSSL_VERSION=1.0.2u
>  - OPENSSL_CFLAGS="-I${PREFIX}/include"
>  - OPENSSL_LIBS="-L${PREFIX}/lib -lssl -lcrypto"
>  # The next declaration is the encrypted COVERITY_SCAN_TOKEN, created
>  #   via the "travis encrypt" command using the project repo's public
> key
>  - secure:
> "l9mSnEW4LJqjxftH5i1NdDaYfGmQB1mPXnSB3DXnsjzkCWZ+yJLfBemfQ0tx/wS7chBYxqUaUIMT0hw4zJVp/LANFJo2vfh//ymTS6h0uApRY1ofg9Pp1BFcV1laG6/u8pwSZ2EBy/GhCd3DS436oE8sYBRaFM9FU62L/oeQBfJ7r4ID/0eB1b8bqlbD4paty9MHui2P8EZJwR+KAD84prtfpZOcrSMxPh9OUhJxzxUvvVoP4s4+lZ5Kgg1bBQ3yzKGDqe8VOgK2BWCEuezqhMMc8oeKmAe7CUkoz5gsGYH++k3I9XzP9Z4xeJKoQnC/82qi4xkJmlaOxdionej9bHIcjfRt7D8j1J0U+wOj4p8VrDy7yHaxuN2fi0K5MGa/CaXQSrkna8dePniCng+xQ2MY/zxuRX2gA6xPNLUyQLU9LqIug7wj4z84Hk9iWib4L20MoPjeEo+vAUNq8FtjOPxMuHNpv4iGGx6kgJm7RXl5vC5hxfK6MprrnYe2U5Mcd8jpzagKBaKHL3zV2FxX9k0jRO9Mccz7M2WnaV0MQ6zcngzTN4+s0kCjhfGKd2F2ANT2Gkhj3Me36eNHfuE0dBbvYCMh4b3Mgd7b/OuXwQWdJ8PjJ1WHXjSOw5sHw1suaV6cEO2Meyz5j1tOkyOi0M9QF+LFenQ9vLH4sBCww8U="
>
> -matrix:
> +jobs:
>include:
> -- env:
> +- name: cl
> +  env:
>- SSLLIB="openssl"
>- OPENSSL_VERSION="1.1.1d"
>- P7Z="c:\Program Files\7-Zip\7z.exe"
>- CC="cl"
>os: windows
>compiler: cl
> -- env: SSLLIB="openssl" RUN_COVERITY="1"
> +- name: Coverity scan
> +  env: SSLLIB="openssl" RUN_COVERITY="1"
>os: linux
>compiler: gcc
> -- env: SSLLIB="openssl" OPENSSL_VERSION="1.0.1u"
> +- name: gcc | openssl-1.0.1u
> +  env: SSLLIB="openssl" OPENSSL_VERSION="1.0.1u"
>os: linux
>compiler: gcc
> -- env: SSLLIB="openssl" OPENSSL_VERSION="1.1.1c"
> +- name: gcc | openssl-1.1.1d
> +  env: SSLLIB="openssl" OPENSSL_VERSION="1.1.1d"
>os: linux
> +  arch: amd64
>compiler: gcc
> -- env: SSLLIB="openssl" OPENSSL_VERSION="1.1.1c" LABEL="linux-ppc64le"
> -  os: linux-ppc64le
> +- name: gcc | openssl-1.1.1d
> +  env: SSLLIB="openssl" OPENSSL_VERSION="1.1.1d"
> +  os: linux
> +  arch: ppc64le
> +  compiler: gcc
> +- name: gcc | openssl-1.1.1d
> +  env: SSLLIB="openssl" OPENSSL_VERSION="1.1.1d"
> +  os: linux
> +  arch: arm64
> +  compiler: gcc
> +- name: gcc | openssl-1.1.1d
> +  env: SSLLIB="openssl" OPENSSL_VERSION="1.1.1d"
> +  os: linux
> +  arch: s390x
>compiler: gcc
> -- env: SSLLIB="openssl" EXTRA_CONFIG="--enable-iproute2"
> +- name: gcc | openssl-1.0.2u | iproute2
> +  env: SSLLIB="openssl" EXTRA_CONFIG="--enable-iproute2"
>os: linux
>compiler: gcc
> -- env: SSLLIB="openssl" CFLAGS="-fsanitize=address" CC=clang-9
> +- name: clang+asan | openssl-1.0.2u
> +  env: SSLLIB="openssl" CFLAGS="-fsanitize=address" CC=clang-9
>os: linux
>compiler: clang
> -- env: SSLLIB="openssl" OPENSSL_VERSION="1.1.1c" CC=clang-9
> +- name: clang | 

Re: [Openvpn-devel] [PATCH] Fix float comparisons of OPENVPN_VERSION_NUMBER

[Илья Шипицин]

чт, 20 февр. 2020 г. в 13:44, Arne Schwabe :

> Am 20.02.20 um 09:38 schrieb Arne Schwabe:
> > These checks are probably the result of copying a
> > check from the LibreSSL and modifying it to be
> > a OpenSSL check. For some arcane reason LibreSSL decided
> > that its version number should be a long float (double) rather
> > than an integer.
> >
> > Signed-off-by: Arne Schwabe 
> > ---
> >  src/openvpn/ssl_openssl.c | 6 +++---
> >  1 file changed, 3 insertions(+), 3 deletions(-)
> >
> > diff --git a/src/openvpn/ssl_openssl.c b/src/openvpn/ssl_openssl.c
> > index 21651a3e..bcdfb543 100644
> > --- a/src/openvpn/ssl_openssl.c
> > +++ b/src/openvpn/ssl_openssl.c
> > @@ -231,7 +231,7 @@ tls_version_max(void)
> >   * We only need to check this for OpenSSL versions that can be
> >   * upgraded to 1.1.1 without recompile (>= 1.1.0)
> >   */
> > -if (OpenSSL_version_num() >= 0x1010100fL)
> > +if (OpenSSL_version_num() >= 0x1010100L)
> >  {
> >  return TLS_VER_1_3;
> >  }
> > @@ -2104,7 +2104,7 @@ show_available_tls_ciphers_list(const char
> *cipher_list,
> >  crypto_msg(M_FATAL, "Cannot create SSL object");
> >  }
> >
> > -#if (OPENSSL_VERSION_NUMBER < 0x101fL)\
> > +#if (OPENSSL_VERSION_NUMBER < 0x101L)\
> >  || (defined(LIBRESSL_VERSION_NUMBER) && LIBRESSL_VERSION_NUMBER <=
> 0x209fL)
> >  STACK_OF(SSL_CIPHER) *sk = SSL_get_ciphers(ssl);
> >  #else
> > @@ -2134,7 +2134,7 @@ show_available_tls_ciphers_list(const char
> *cipher_list,
> >  printf("%s\n", pair->iana_name);
> >  }
> >  }
> > -#if (OPENSSL_VERSION_NUMBER >= 0x101fL)
> > +#if (OPENSSL_VERSION_NUMBER >= 0x101L)
> >  sk_SSL_CIPHER_free(sk);
> >  #endif
> >  SSL_free(ssl);
> >
>
>
> Ignore that patch. I am not awake yet. the fL is not a suffix. LibreSSL
> has has its patch version to be 0f.
>

can you also close it here https://patchwork.openvpn.net/patch/1015/ ?
to prevent someone from taking it accidently


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

Re: [Openvpn-devel] [PATCH v4 2/2] Add unit tests for engine keys

[Илья Шипицин]

сб, 15 февр. 2020 г. в 19:59, James Bottomley <
james.bottom...@hansenpartnership.com>:

> On Fri, 2020-02-14 at 18:33 +0500, Илья Шипицин wrote:
> > пт, 14 февр. 2020 г. в 18:05, James Bottomley <
> > james.bottom...@hansenpartnership.com>:
> >
> > > On Thu, 2020-02-13 at 19:18 +0100, Arne Schwabe wrote:
> > > > Am 10.02.18 um 23:50 schrieb James Bottomley:
> > > > > Testing engines is problematic, so one of the prerequisites
> > > > > built
> > > > > for the tests is a simple openssl engine that reads a non-
> > > > > standard
> > > > > PEM guarded key.  The test is simply can we run a client/server
> > > > > configuration with the usual sample key replaced by an engine
> > > > > key.
> > > > > The trivial engine prints out some operations and we check for
> > > > > these in the log to make sure the engine was used to load the
> > > > > key
> > > > > and that it correctly got the password.
> > > >
> > > > This tests the openssl engine functionality in a sensible way.
> > > > But I
> > > > think it is not fully ready to be commited. To get it working I
> > > > needed to do following changes on my Mac:
> > >
> > > That could be ... I only have a linux box to try this out on.
> > >
> > > > commit afa697cec15b4e54e720efe9de39c9b20b13c5c8 (HEAD ->
> > > > review/enginekeys)
> > > > Author: Arne Schwabe 
> > > > Date:   Thu Feb 13 18:13:34 2020 +0100
> > > >
> > > > foo
> > > >
> > > > diff --git a/tests/unit_tests/engine-key/Makefile.am
> > > > b/tests/unit_tests/engine-key/Makefile.am
> > > > index 73921965..6d7fc9c5 100644
> > > > --- a/tests/unit_tests/engine-key/Makefile.am
> > > > +++ b/tests/unit_tests/engine-key/Makefile.am
> > > > @@ -10,4 +10,6 @@ TESTS_ENVIRONMENT = srcdir="$(abs_srcdir)"; \
> > > >  TESTS = check_engine_keys.sh
> > > >
> > > >  libtestengine_la_SOURCES = libtestengine.c
> > > > -libtestengine_la_LDFLAGS = -rpath /lib -avoid-version
> > > > +libtestengine_la_LDFLAGS = @TEST_LDFLAGS@  -rpath /lib
> > > > +libtestengine_la_CFLAGS  = @TEST_CFLAGS@ -I$(openvpn_srcdir)
> > > > -I$(compat_srcdir)
> > > > +
> > > > diff --git a/tests/unit_tests/engine-key/libtestengine.c
> > > > b/tests/unit_tests/engine-key/libtestengine.c
> > > > index fa7f5de1..46ec1e33 100644
> > > > --- a/tests/unit_tests/engine-key/libtestengine.c
> > > > +++ b/tests/unit_tests/engine-key/libtestengine.c
> > > > @@ -30,7 +30,6 @@ static EVP_PKEY *engine_load_key(ENGINE *e,
> > > > const
> > > > char
> > > > *key_id,
> > > > PKCS8_PRIV_KEY_INFO *p8inf;
> > > > UI *ui;
> > > > char auth[256];
> > > > -   int len;
> > >
> > > the variable is certainly unused and can go.
> > >
> > > > fprintf(stderr, "ENGINE: engine_load_key called\n");
> > > >
> > > > diff --git a/tests/unit_tests/engine-key/openssl.cnf
> > > > b/tests/unit_tests/engine-key/openssl.cnf
> > > > index 53200c46..e9513a92 100644
> > > > --- a/tests/unit_tests/engine-key/openssl.cnf
> > > > +++ b/tests/unit_tests/engine-key/openssl.cnf
> > > > @@ -9,4 +9,4 @@ engines = engines_section
> > > >  testengine = testengine_section
> > > >
> > > >  [testengine_section]
> > > > -dynamic_path   = $ENV::srcdir/.libs/libtestengine.so
> > > > +dynamic_path   = $ENV::srcdir/.libs/libtestengine.dylib
> >
> > we use gost-engine (https://github.com/engine/gost-engine)
> >
> > on both linux and osx.
> >
> > for some time there was a bug in openssl:
> >
> > https://github.com/openssl/openssl/issues/8950
> >
> >
> > however, for now "dylib" is used for osx. and
> > but we do not use "dynamic" path. we use config like that
> >
> > openssl_conf = openssl_def
> >
> > [openssl_def]
> > engines = engine_section
> >
> > [engine_section]
> > gost = gost_section
> >
> > [gost_section]
> > default_algorithms = ALL
> > engine_id = gost
> > CRYPT_PARAMS = id-Gost28147-89-CryptoPro-A-ParamSet
>
> Right, that works if the engine is in the correct directory.  The
> problem with this engine is that it's only built as a test
> demonstration for the openvpn engine code, so it's never installed in
> the openssl engines directory, so we have to tell openssl exactly where
> to find it in the openvpn tree ... and that seems to involve naming the
> whole file and location, including extension.
>
>
yes, I understand reasoning.
maybe we should add dynamic path to our tests as well.


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

Re: [Openvpn-devel] [PATCH v4 2/2] Add unit tests for engine keys

[Илья Шипицин]

пт, 14 февр. 2020 г. в 18:05, James Bottomley <
james.bottom...@hansenpartnership.com>:

> On Thu, 2020-02-13 at 19:18 +0100, Arne Schwabe wrote:
> > Am 10.02.18 um 23:50 schrieb James Bottomley:
> > > Testing engines is problematic, so one of the prerequisites built
> > > for the tests is a simple openssl engine that reads a non-standard
> > > PEM guarded key.  The test is simply can we run a client/server
> > > configuration with the usual sample key replaced by an engine key.
> > > The trivial engine prints out some operations and we check for
> > > these in the log to make sure the engine was used to load the key
> > > and that it correctly got the password.
> >
> > This tests the openssl engine functionality in a sensible way. But I
> > think it is not fully ready to be commited. To get it working I
> > needed to do following changes on my Mac:
>
> That could be ... I only have a linux box to try this out on.
>
> > commit afa697cec15b4e54e720efe9de39c9b20b13c5c8 (HEAD ->
> > review/enginekeys)
> > Author: Arne Schwabe 
> > Date:   Thu Feb 13 18:13:34 2020 +0100
> >
> > foo
> >
> > diff --git a/tests/unit_tests/engine-key/Makefile.am
> > b/tests/unit_tests/engine-key/Makefile.am
> > index 73921965..6d7fc9c5 100644
> > --- a/tests/unit_tests/engine-key/Makefile.am
> > +++ b/tests/unit_tests/engine-key/Makefile.am
> > @@ -10,4 +10,6 @@ TESTS_ENVIRONMENT = srcdir="$(abs_srcdir)"; \
> >  TESTS = check_engine_keys.sh
> >
> >  libtestengine_la_SOURCES = libtestengine.c
> > -libtestengine_la_LDFLAGS = -rpath /lib -avoid-version
> > +libtestengine_la_LDFLAGS = @TEST_LDFLAGS@  -rpath /lib
> > +libtestengine_la_CFLAGS  = @TEST_CFLAGS@ -I$(openvpn_srcdir)
> > -I$(compat_srcdir)
> > +
> > diff --git a/tests/unit_tests/engine-key/libtestengine.c
> > b/tests/unit_tests/engine-key/libtestengine.c
> > index fa7f5de1..46ec1e33 100644
> > --- a/tests/unit_tests/engine-key/libtestengine.c
> > +++ b/tests/unit_tests/engine-key/libtestengine.c
> > @@ -30,7 +30,6 @@ static EVP_PKEY *engine_load_key(ENGINE *e, const
> > char
> > *key_id,
> > PKCS8_PRIV_KEY_INFO *p8inf;
> > UI *ui;
> > char auth[256];
> > -   int len;
>
> the variable is certainly unused and can go.
>
> > fprintf(stderr, "ENGINE: engine_load_key called\n");
> >
> > diff --git a/tests/unit_tests/engine-key/openssl.cnf
> > b/tests/unit_tests/engine-key/openssl.cnf
> > index 53200c46..e9513a92 100644
> > --- a/tests/unit_tests/engine-key/openssl.cnf
> > +++ b/tests/unit_tests/engine-key/openssl.cnf
> > @@ -9,4 +9,4 @@ engines = engines_section
> >  testengine = testengine_section
> >
> >  [testengine_section]
> > -dynamic_path   = $ENV::srcdir/.libs/libtestengine.so
> > +dynamic_path   = $ENV::srcdir/.libs/libtestengine.dylib
>

we use gost-engine (https://github.com/engine/gost-engine)

on both linux and osx.

for some time there was a bug in openssl:

https://github.com/openssl/openssl/issues/8950


however, for now "dylib" is used for osx. and
but we do not use "dynamic" path. we use config like that

openssl_conf = openssl_def

[openssl_def]
engines = engine_section

[engine_section]
gost = gost_section

[gost_section]
default_algorithms = ALL
engine_id = gost
CRYPT_PARAMS = id-Gost28147-89-CryptoPro-A-ParamSet


>
> This can't really be done though: the .dylib extension won't work on
> Linux because shared objects are .so files.
>
> There is a way to generate and use .so files on a MAC as well,
> according to the openssl people (half the mac engines seem to have a
> .so extension and the other half a .dylib one), I'll see if I can
> figure out what it is.
>
> James
> ___
> Openvpn-devel mailing list
> Openvpn-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/openvpn-devel
>
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] [PATCH v2] travis-ci: add arm64, s390x builds.

[Илья Шипицин]

пн, 3 февр. 2020 г. в 14:51, Steffan Karger :

> On 03-02-2020 09:04, Илья Шипицин wrote:
> > also, ARM64 builds are flaky. maybe we should add them as allow_failures.
>
> What is flaky about the ARM64 builds? Is it our build? Is it the travis
> infra?
>

in travis-ci terms "our" failure means "build failed", travis-ci infra
means "build errored"

they run arm64 on linaro cloud, it fails (sometimes) on infra level (I
guess cloud is overloaded or like that). I did not seen yet tests failure


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

Re: [Openvpn-devel] [PATCH v2] travis-ci: add arm64, s390x builds.

[Илья Шипицин]

also, ARM64 builds are flaky. maybe we should add them as allow_failures.

пн, 3 февр. 2020 г. в 12:49, Илья Шипицин :

> https://travis-ci.org/chipitsine/openvpn/jobs/645173717#L62
>
> I expected it to be 30 minutes wait.
>
> пн, 3 февр. 2020 г. в 12:48, Илья Шипицин :
>
>>
>>
>> пн, 3 февр. 2020 г. в 12:40, Lev Stipakov :
>>
>>> Hi,
>>>
>>> Could you provide a link to a travis build with your changes?
>>>
>>
>>
>> https://travis-ci.org/chipitsine/openvpn/builds/645173716
>>
>>
>> there's at least issue regarding "travis_wait 30", as I can see, windows
>> builds waits for 10 minutes.
>>
>> I'll fix it in "v3" (after all reviews)
>>
>>>
>>> --
>>> -Lev
>>>
>>
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] [PATCH v2] travis-ci: add arm64, s390x builds.

[Илья Шипицин]

https://travis-ci.org/chipitsine/openvpn/jobs/645173717#L62

I expected it to be 30 minutes wait.

пн, 3 февр. 2020 г. в 12:48, Илья Шипицин :

>
>
> пн, 3 февр. 2020 г. в 12:40, Lev Stipakov :
>
>> Hi,
>>
>> Could you provide a link to a travis build with your changes?
>>
>
>
> https://travis-ci.org/chipitsine/openvpn/builds/645173716
>
>
> there's at least issue regarding "travis_wait 30", as I can see, windows
> builds waits for 10 minutes.
>
> I'll fix it in "v3" (after all reviews)
>
>>
>> --
>> -Lev
>>
>
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] [PATCH v2] travis-ci: add arm64, s390x builds.

[Илья Шипицин]

пн, 3 февр. 2020 г. в 12:40, Lev Stipakov :

> Hi,
>
> Could you provide a link to a travis build with your changes?
>


https://travis-ci.org/chipitsine/openvpn/builds/645173716


there's at least issue regarding "travis_wait 30", as I can see, windows
builds waits for 10 minutes.

I'll fix it in "v3" (after all reviews)

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

[Openvpn-devel] linux arm64 tests fail

[Илья Шипицин]

Hello,

https://travis-ci.org/chipitsine/openvpn/jobs/644745481?utm_medium=notification_source=github_status

it indicates "ERROR" when running tests, however tests are ok after all.

[ RUN  ] tls_crypt_v2_wrap_too_long_metadata

ERROR: could not crypt: insufficient space in dst

[   OK ] tls_crypt_v2_wrap_too_long_metadata

[ RUN  ] tls_crypt_v2_wrap_unwrap_wrong_key

[   OK ] tls_crypt_v2_wrap_unwrap_wrong_key

[ RUN  ] tls_crypt_v2_wrap_unwrap_dst_too_small

[   OK ] tls_crypt_v2_wrap_unwrap_dst_too_small

[ RUN  ] test_tls_crypt_v2_write_server_key_file

[   OK ] test_tls_crypt_v2_write_server_key_file

[ RUN  ] test_tls_crypt_v2_write_client_key_file

[   OK ] test_tls_crypt_v2_write_client_key_file

[==] 14 test(s) run.

[  PASSED  ] 14 test(s).

PASS: tls_crypt_testdriver



Cheers,

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

Re: [Openvpn-devel] [PATCH] Fix ACL_CHECK_ADD_COMPILE_FLAGS to work with clang

[Илья Шипицин]

Thank you for your efforts.
As you are touching this, can you try "dist: bionic" ? It might bring newer
compilers

On Thu, Nov 14, 2019, 8:41 PM  wrote:

> From: Selva Nair 
>
> Some compilers (e.g., clang) only issue a warning for
> unsupported options unless additional flags such
> as -Werror are used to convert the warning to an error.
>
> Add support for extra flags in ACL_CHECK_ADD_COMPILE_FLAGS.
>
> Note: a similar approach is used in AX_CHECK_COMPILE_FLAG
> in autoconf archives.
>
> Signed-off-by: Selva Nair 
> ---
>
> For successful travis build result see
> https://travis-ci.org/selvanair/openvpn/builds/612019849
>
> But this + https://patchwork.openvpn.net/patch/908/
> alone does not fix the travis build as clang is not
> happy with struct initializers: Like this
>
> crypto.c:1860:31: error: suggest braces around initialization of subobject
>   [-Werror,-Wmissing-braces]
> struct key server_key = { 0 };
>
> I think clang wants {{0}} there.
>
> Darn compilers and darn -Werror :)
>
>  configure.ac | 17 ++---
>  1 file changed, 10 insertions(+), 7 deletions(-)
>
> diff --git a/configure.ac b/configure.ac
> index 807804e5..e59bd91b 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -1275,18 +1275,21 @@ if test "${enable_pkcs11}" = "yes"; then
> )
>  fi
>
> +# Usage: ACL_CHECK_ADD_COMPILE_FLAGS(flag, [extra-flags])
> +# Some compilers require extra flags to trigger an error on
> +# unsupported options. E.g., clang requires -Werror.
>  AC_DEFUN([ACL_CHECK_ADD_COMPILE_FLAGS], [
>  old_cflags="$CFLAGS"
> -CFLAGS="$1 $CFLAGS"
> -AC_MSG_CHECKING([whether the compiler acceppts $1])
> -AC_COMPILE_IFELSE([AC_LANG_PROGRAM()], [AC_MSG_RESULT([yes])],
> +CFLAGS="$2 $1 $CFLAGS"
> +AC_MSG_CHECKING([whether the compiler accepts $1])
> +AC_COMPILE_IFELSE([AC_LANG_PROGRAM()], [AC_MSG_RESULT([yes])];
> CFLAGS="$1 $old_cflags",
>  [AC_MSG_RESULT([no]); CFLAGS="$old_cflags"])]
>  )
>
> -ACL_CHECK_ADD_COMPILE_FLAGS([-Wno-stringop-truncation])
> -ACL_CHECK_ADD_COMPILE_FLAGS([-Wno-unused-function])
> -ACL_CHECK_ADD_COMPILE_FLAGS([-Wno-unused-parameter])
> -ACL_CHECK_ADD_COMPILE_FLAGS([-Wall])
> +ACL_CHECK_ADD_COMPILE_FLAGS([-Wno-stringop-truncation], [-Werror])
> +ACL_CHECK_ADD_COMPILE_FLAGS([-Wno-unused-function], [-Werror])
> +ACL_CHECK_ADD_COMPILE_FLAGS([-Wno-unused-parameter], [-Werror])
> +ACL_CHECK_ADD_COMPILE_FLAGS([-Wall], [-Werror])
>
>  if test "${enable_pedantic}" = "yes"; then
> enable_strict="yes"
> --
> 2.20.1
>
>
>
> ___
> Openvpn-devel mailing list
> Openvpn-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/openvpn-devel
>
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] using arm64 on travis ?

[Илья Шипицин]

пт, 8 нояб. 2019 г. в 14:02, Gert Doering :

> Hi,
>
> On Fri, Nov 08, 2019 at 12:39:00PM +0500,  ?? wrote:
> > https://docs.travis-ci.com/user/multi-cpu-architectures
> >
> > we can switch some builds to arm64. any suggestions ?
>
> Sounds good.  Right now we only have i386 and amd64 builds (since my
> SPARC machine is going away and my Pi3 slave is still not operational).
>

not as good as it could be :)

travis-ci uses the same cache key for amd64 and arm64 builds, so
(currently) openssl build caches are messed up.
but it is easy to resolve


>
> 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
>
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

[Openvpn-devel] using arm64 on travis ?

[Илья Шипицин]

hello,

https://docs.travis-ci.com/user/multi-cpu-architectures

we can switch some builds to arm64. any suggestions ?

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

Re: [Openvpn-devel] [PATCH v2 1/7] Visual Studio: upgrade project files to VS2019

[Илья Шипицин]

чт, 7 нояб. 2019 г. в 22:49, Lev Stipakov :

> From: Lev Stipakov 
>
> Signed-off-by: Lev Stipakov 
> ---
>  src/compat/compat.vcxproj | 12 ++--
>  src/openvpn/openvpn.vcxproj   | 12 ++--
>  src/openvpnmsica/openvpnmsica.vcxproj | 14 +++---
>  src/openvpnserv/openvpnserv.vcxproj   | 12 ++--
>  src/tapctl/tapctl.vcxproj | 14 +++---
>  5 files changed, 32 insertions(+), 32 deletions(-)
>
> diff --git a/src/compat/compat.vcxproj b/src/compat/compat.vcxproj
> index 111dacd..e388008 100644
> --- a/src/compat/compat.vcxproj
> +++ b/src/compat/compat.vcxproj
> @@ -22,30 +22,30 @@
>  {4B2E2719-E661-45D7-9203-F6F456B22F19}
>  compat
>  Win32Proj
> -
> 10.0.17134.0
> +10.0
>
>
> Condition="'$(Configuration)|$(Platform)'=='Release|Win32'"
> Label="Configuration">
>  StaticLibrary
>  MultiByte
>  true
> -v141
> +v142
>
> Condition="'$(Configuration)|$(Platform)'=='Release|x64'"
> Label="Configuration">
>  StaticLibrary
>  MultiByte
>  true
> -v141
> +v142
>


does it limit target platform ?
can we build for Vista ? XP ? 7 ? does this setting affect that ?



>
> Condition="'$(Configuration)|$(Platform)'=='Debug|Win32'"
> Label="Configuration">
>  StaticLibrary
>  MultiByte
> -v141
> +v142
>
> Label="Configuration">
>  StaticLibrary
>  MultiByte
> -v141
> +v142
>
>
>
> @@ -115,4 +115,4 @@
>
>
>
> -
> +
> \ No newline at end of file
> diff --git a/src/openvpn/openvpn.vcxproj b/src/openvpn/openvpn.vcxproj
> index 42b..e77f026 100644
> --- a/src/openvpn/openvpn.vcxproj
> +++ b/src/openvpn/openvpn.vcxproj
> @@ -22,30 +22,30 @@
>  {29DF226E-4D4E-440F-ADAF-5829CFD4CA94}
>  openvpn
>  Win32Proj
> -
> 10.0.17134.0
> +10.0
>
>
> Condition="'$(Configuration)|$(Platform)'=='Release|Win32'"
> Label="Configuration">
>  Application
>  true
>  Unicode
> -v141
> +v142
>
> Condition="'$(Configuration)|$(Platform)'=='Release|x64'"
> Label="Configuration">
>  Application
>  true
>  Unicode
> -v141
> +v142
>
> Condition="'$(Configuration)|$(Platform)'=='Debug|Win32'"
> Label="Configuration">
>  Application
>  Unicode
> -v141
> +v142
>
> Label="Configuration">
>  Application
>  Unicode
> -v141
> +v142
>
>
>
> @@ -301,4 +301,4 @@
>
>
>
> -
> +
> \ No newline at end of file
> diff --git a/src/openvpnmsica/openvpnmsica.vcxproj
> b/src/openvpnmsica/openvpnmsica.vcxproj
> index 5f1d699..afa4fae 100644
> --- a/src/openvpnmsica/openvpnmsica.vcxproj
> +++ b/src/openvpnmsica/openvpnmsica.vcxproj
> @@ -31,32 +31,32 @@
>  {D41AA9D6-B818-476E-992E-0E16EB86BEE2}
>  Win32Proj
>  openvpnmsica
> -
> 10.0.17134.0
> +10.0
>
>
> Condition="'$(Configuration)|$(Platform)'=='Debug|ARM64'"
> Label="Configuration">
>  DynamicLibrary
>  true
> -v141
> +v142
>  Unicode
>  true
>
> Condition="'$(Configuration)|$(Platform)'=='Debug|Win32'"
> Label="Configuration">
>  DynamicLibrary
>  true
> -v141
> +v142
>  Unicode
>
> Label="Configuration">
>  DynamicLibrary
>  true
> -v141
> +v142
>  Unicode
>
> Condition="'$(Configuration)|$(Platform)'=='Release|ARM64'"
> Label="Configuration">
>  DynamicLibrary
>  false
> -v141
> +v142
>  true
>  Unicode
>  true
> @@ -64,14 +64,14 @@
> Condition="'$(Configuration)|$(Platform)'=='Release|Win32'"
> Label="Configuration">
>  DynamicLibrary
>  false
> -v141
> +v142
>  true
>  Unicode
>
> Condition="'$(Configuration)|$(Platform)'=='Release|x64'"
> Label="Configuration">
>  DynamicLibrary
>  false
> -v141
> +v142
>  true
>  Unicode
>
> diff --git a/src/openvpnserv/openvpnserv.vcxproj
> b/src/openvpnserv/openvpnserv.vcxproj
> index 7407757..7061b7b 100644
> --- a/src/openvpnserv/openvpnserv.vcxproj
> +++ b/src/openvpnserv/openvpnserv.vcxproj
> @@ -22,30 +22,30 @@
>  {9C91EE0B-817D-420A-A1E6-15A5A9D98BAD}
>  openvpnserv
>  Win32Proj
> -
> 10.0.17134.0
> +10.0
>
>
> Condition="'$(Configuration)|$(Platform)'=='Release|Win32'"
> Label="Configuration">
>  Application
>  Unicode
>  true
> -v141
> +v142
>
> Condition="'$(Configuration)|$(Platform)'=='Release|x64'"
> Label="Configuration">
>  Application
>  Unicode
>  true
> -v141
> +v142
>
> Condition="'$(Configuration)|$(Platform)'=='Debug|Win32'"
> Label="Configuration">
>  Application
>  Unicode
> -v141
> +v142
>
> Label="Configuration">
>  Application
>  Unicode
> -v141
> +v142
>
>
>
> @@ -139,4 +139,4 @@
>
>
>
> -
> +
> \ No newline at end of file
> diff --git 

Re: [Openvpn-devel] [PATCH] msvc: OpenSSL 1.1.0 support

[Илья Шипицин]

it sounds strange (it does not make a lot of sense), but we can build
openssl without TLS1.3 support

чт, 17 окт. 2019 г. в 19:27, Selva Nair :

> On Thu, Oct 17, 2019 at 8:11 AM Lev Stipakov  wrote:
> >
> > Hi François,
> >
> > François Kooman kirjoitti 17.10.2019 klo 13.39:
> >
> > > "Version 1.1.0 will be supported until 2019-09-11" [1].
> > >
> > > Is there a plan to update to 1.1.1 for the Windows client?
> >
> > Indeed, there is probably no reason to not to switch to newer version.
> > We'll include 1.1.1 into the next release.
>
> Use of 1.1.1 on both client ans server side will default to PSS padding
> for RSA signature (for TLS 1.2 and 1.3) and break
> --management-external-key.
>
> So hold-off on building Windows release with 1.1.1 unless
> we can get https://patchwork.openvpn.net/patch/587/ finalized by then.
>
> Selva
>
>
> ___
> Openvpn-devel mailing list
> Openvpn-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/openvpn-devel
>
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] [PATCH applied] Re: travis-ci: fix osx builds

[Илья Шипицин]

вт, 2 июл. 2019 г. в 12:11, Gert Doering :

> Hi,
>
> On Tue, Jul 02, 2019 at 12:09:48PM +0500,  ?? wrote:
> > , 2 ??. 2019 ??. ?? 12:07, Gert Doering :
> >
> > > Acked-by: Gert Doering 
> > >
> > > (I have no idea what this does, specifically, but it is not a code
> > > change and if it fixes our Travis builds, I'm happy - and the
> explanation
> > > given says "it will fix things")
> > >
> > > Your patch has been applied to the master branch.
> >
> > should we apply to 2.4 as well ?
>
> Good point.  Should have the same brokenness & needs the same fix - so
> here we go
>
>
thank you!



> commit 5e695c7786259049ea2eb4ac78101e3d7edd8280 (HEAD -> release/2.4)
> Author: Ilya Shipitsin 
> Date:   Sat Jun 29 00:46:36 2019 +0500
>
> travis-ci: fix osx builds
>
> 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
>
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] [PATCH applied] Re: travis-ci: fix osx builds

[Илья Шипицин]

вт, 2 июл. 2019 г. в 12:07, Gert Doering :

> Acked-by: Gert Doering 
>
> (I have no idea what this does, specifically, but it is not a code
> change and if it fixes our Travis builds, I'm happy - and the explanation
> given says "it will fix things")
>
> Your patch has been applied to the master branch.
>

should we apply to 2.4 as well ?


>
> commit afeb9c4f30d23082eb2c6a5a3cd93844e48a5bc7
> Author: Ilya Shipitsin
> Date:   Sat Jun 29 00:46:36 2019 +0500
>
>  travis-ci: fix osx builds
>
>  Signed-off-by: Ilya Shipitsin 
>  Acked-by: Gert Doering 
>  Message-Id: <20190628194637.5038-2-chipits...@gmail.com>
>  URL:
> https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg18620.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] [bui...@travis-ci.org: Still Failing: OpenVPN/openvpn#874 (master - 7473f32)]

[Илья Шипицин]

Documentation lacks. The reason of failure is caching homebrew. It is not
common practice, we should either drop cache or enforce update

On Sun, Jun 30, 2019, 12:46 PM Gert Doering  wrote:

> Hi,
>
> On Sun, Jun 30, 2019 at 02:53:18AM +0500,  ?? wrote:
> > I submitted a fix
> >
> > https://patchwork.openvpn.net/project/openvpn2/list/?series=506
>
> I've seen the fix, thanks.
>
> Do you have documentation somewhere (which I did not find) how this
> stuff works?  That is, why is this the right fix?
>
> (I have no idea about travis-ci but would like to understand things
> better)
>
> 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
>
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] [bui...@travis-ci.org: Still Failing: OpenVPN/openvpn#874 (master - 7473f32)]

[Илья Шипицин]

I submitted a fix

https://patchwork.openvpn.net/project/openvpn2/list/?series=506

пн, 24 июн. 2019 г. в 11:17, Илья Шипицин :

> Thank you for the investigation, Gert.
> I'll have a look soon
>
> On Sun, Jun 23, 2019, 11:55 PM Gert Doering  wrote:
>
>> Hi,
>>
>> travis CI builds for MacOS fail (and have failed for quite some time,
>> it seems) because LZO is not installed as pre-requisite - the configure
>> run in the log below ends in line 632 with
>>
>>  configure: error: lzo enabled but missing
>>
>> ... but it *should* be built by ".travis/build-deps.sh" - so it seems
>> that script is failing.  In any case it is not communicating errors
>> back to the caller, because otherwise we'd see the output in the
>> main travis build log...
>>
>> Not sure what is needed to fix these two issues
>>
>>  - get output from build-deps.sh in case of failure
>>  - make the failure go away
>>
>>
>> A naive reading of build-deps.sh seems to suggest that "build_lzo"
>> is only ever called on MinGW cross-builds and not on MacOS - so, that
>> would explain why it's not failing.  But then, how to teach Travis
>> that we want LZO?
>>
>> Anyway, I leave this for somebody who understands Travis-CI better than
>> I do to fix and send a patch.
>>
>> gert
>>
>>
>> - Forwarded message from Travis CI  -
>>
>> Date: Sun, 23 Jun 2019 18:44:30 +
>> From: Travis CI 
>> To: g...@greenie.muc.de, stef...@karger.me
>> Subject: Still Failing: OpenVPN/openvpn#874 (master - 7473f32)
>>
>> Build Update for OpenVPN/openvpn
>> -
>>
>> Build: #874
>> Status: Still Failing
>>
>> Duration: 20 mins and 54 secs
>> Commit: 7473f32 (master)
>> Author: Steffan Karger
>> Message: configure.ac: add lzo CFLAGS/LIBS to the test flags
>>
>> This fixes "make check" builds on systems with lzo on a non-standard
>> location.
>>
>> Signed-off-by: Steffan Karger 
>> Acked-by: David Sommerseth 
>> Message-Id: <20190602101831.21216-1-stef...@karger.me>
>> URL:
>> https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg18482.html
>> Signed-off-by: Gert Doering 
>>
>> View the changeset:
>> https://github.com/OpenVPN/openvpn/compare/06f65a0cbfcb...7473f326366f
>>
>> View the full build log and details:
>> https://travis-ci.org/OpenVPN/openvpn/builds/549429549?utm_medium=notification_source=email
>>
>> --
>>
>> You can unsubscribe from build emails from the OpenVPN/openvpn repository
>> going to
>> https://travis-ci.org/account/preferences/unsubscribe?repository=6518989_medium=notification_source=email
>> .
>> Or unsubscribe from *all* email updating your settings at
>> https://travis-ci.org/account/preferences/unsubscribe?utm_medium=notification_source=email
>> .
>> Or configure specific recipients for build notifications in your
>> .travis.yml file. See https://docs.travis-ci.com/user/notifications.
>>
>>
>> - End forwarded message -
>>
>> --
>> "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
>> ___
>> Openvpn-devel mailing list
>> Openvpn-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/openvpn-devel
>>
>
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] [PATCH] Insert client connection data into PAM environment

[Илья Шипицин]

Do not pay attention to osx. I will fix it soon

On Fri, Jun 28, 2019, 4:29 PM Paolo  wrote:

> Hi,
>
> after rebasing my fork on current master, the are no conflicts with
> current source code. Travis error on osx are not releated to my code,
> they are errors about configuration peace not working on osx.
>
> --
> -***-
> Paolo Cerrito
> -***-
>
>
>
> ___
> Openvpn-devel mailing list
> Openvpn-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/openvpn-devel
>
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] how to migrate users to "no compression" config

[Илья Шипицин]

пт, 28 июн. 2019 г. в 12:49, Gert Doering :

> Hi,
>
> On Fri, Jun 28, 2019 at 12:14:40PM +0500,  ?? wrote:
> > by "high level" compression doc I mean something like that
> >
> > a) road warrior scenario (remote access for enterprise users) - should we
> > enable compression ? or traffic usually is compressed ? RDP is
> compressed ?
> > any way to estimate compression (like $gzip_ratio in nginx)
> > b) lz4, lzo, ... which one to choose ?
> > c) how to push compression settings, best practices on that
> >
> > @mattock, what do you think, should some such documentation present on
> > https://openvpn.net ?
>
> The high level document should propably specify "do not use compression
> at all, unless you have a specific need".
>

I agree with that. It might not be very obvious.


>
> I'm fairly sure we did publish something along that lines already, but
> have no idea where to look for it.
>
> 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
>
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] how to migrate users to "no compression" config

[Илья Шипицин]

by "high level" compression doc I mean something like that

a) road warrior scenario (remote access for enterprise users) - should we
enable compression ? or traffic usually is compressed ? RDP is compressed ?
any way to estimate compression (like $gzip_ratio in nginx)
b) lz4, lzo, ... which one to choose ?
c) how to push compression settings, best practices on that

@mattock, what do you think, should some such documentation present on
https://openvpn.net ?



чт, 27 июн. 2019 г. в 12:39, Gert Doering :

> Hi,
>
> On Wed, Jun 26, 2019 at 11:14:34PM +0200, Arne Schwabe wrote:
> > My patch that enables asymmetrical compression by default adds a bit of
> > documentation in that regard iirc.
>
> Where did that get stuck?  Still in limbo between David and you?
>
> 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
>
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] how to migrate users to "no compression" config

[Илья Шипицин]

Should we add some high level documentation on compression?

On Wed, Jun 26, 2019, 5:05 PM Arne Schwabe  wrote:

> Am 26.06.19 um 08:35 schrieb Gert Doering:
> > Hi,
> >
> > On Wed, Jun 26, 2019 at 01:48:34AM +0500,  ?? wrote:
> >> 2) use push "compress empty" (if there's such an option) ?
> >
> > you can do
> >
> >   push "compress"
> >
> > with no arguments.  According to the docs, this will enable compression
> > framing format, but no actual compression.
> >
>
> Better use stub-v2 since that has no extra byte added and is also
> compatible with clients that do not have a compress/comp-lzo directive.
>
> (Unless you have packets that look like IPv5)
>
> There is also a IV_STUB_V2=1 (or similar to detect if the client can do
> this)
>
> Arne
>
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

[Openvpn-devel] how to migrate users to "no compression" config

[Илья Шипицин]

Hello,

for example, let us imagine we provisioned a lot of users with config files
containing "comp-lzo"
and we want to migrate them to server without compression.

I see two options

1) set up new server (actually, new udp/tcp ports on the same server) and
send new config to users

2) use push "compress empty" (if there's such an option) ?

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

Re: [Openvpn-devel] Summary of the community meeting (20th June 2019)

[Илья Шипицин]

пн, 24 июн. 2019 г. в 23:14, Samuli Seppänen :

> Hi,
>
> Il 24/06/19 14:33, Samuli Seppänen ha scritto:
> > Hi Simon,
> >
> > Thanks for the info again!
> >
> > Il 21/06/19 18:59, Simon Rozman ha scritto:
> >> (21:04:58) mattock: assuming Microsoft's systems are happy with the
> test submission package, that is
> >> (21:05:12) mattock: they _should_ be, but we have not tested submitting
> anything yes
> >>
> >> 1. Do the SDV and DVL to get tap901.DVL.xml.
> >
> > I'm working on this right now. Based on brief practical testing EWDK may
> > not be able to do this, even though it is apparently possible to produce
> > SDV logs from the command-line:>
> >
> https://docs.microsoft.com/en-us/windows-hardware/drivers/develop/creating-a-log-file-for-static-driver-verifier
> >
> > It _seems_ that EWDK might not have all the necessary pieces for
> > producing SDV log files. MS does briefly mention that EWDK is not
> > suitable for doing driver testing, whatever that means. So, to play it
>
> Actually it is probably possible to use the EWDK for running Static
> Driver Verifier:
>
> <
> https://github.com/MicrosoftDocs/windows-driver-docs/blob/staging/windows-driver-docs-pr/develop/creating-a-driver-verification-log.md
> >
> <
> https://docs.microsoft.com/it-it/windows-hardware/drivers/devtest/static-driver-verifier
> >
>
> > safe, I'm installing Visual Studio 2019 plus the "normal" Windows Driver
> > Kit on my tapbuilder VM.
>
> So, I took a stab at producing the Static Driver Verifier logs in Visual
> Studio 2019 ("Extensions" -> "Static Driver Verifier"), but it just
> complains about
>
> "Please select a driver project for sdv to verify"
>
> I wonder if I just hit a usability problem, or if something is actually
> missing from tap-windows6?
>
> Attempting to run SDV from the command-line (adapted from first link
> above) fails as well. The /clean part works fine, but running SDV fails:
>
> PS> msbuild.exe src\tap-windows6.vcxproj /p:Configuration="Release"
> /p:Platform=x64 /target:sdv /p:inputs="/clean"
>
> --- snip ---
>
> PS> msbuild.exe src\tap-windows6.vcxproj /p:Configuration="Release"
> /p:Platform=x64 /target:sdv /p:inputs="/check:default.sdv"
>
>   [INFO] Validating XML against schema: C:\Program Files (x86)\Windows
> Kits\10\TOOLS\SDV\smv\bin\Config.xsd
>   [INFO] Running local scheduler with 2 threads
>   [FATAL ERROR] Unrecoverable error in NormalBuild stage.
> C:\Program Files (x86)\Windows
> Kits\10\build\windowsdriver.Sdv.targets(136,9): error MSB3073: The
> command "staticdv /ch
> eck:default.sdv" exited with code -1.
> [C:\Users\samuli\opt\tap-windows6\src\tap-windows6.vcxproj]
> Done Building Project
> "C:\Users\samuli\opt\tap-windows6\src\tap-windows6.vcxproj" (sdv
> target(s)) -- FAILED.
>
>
> Build FAILED.
>
> "C:\Users\samuli\opt\tap-windows6\src\tap-windows6.vcxproj" (sdv target)
> (1) ->
> (sdv target) ->
>   C:\Program Files (x86)\Windows
> Kits\10\build\windowsdriver.Sdv.targets(136,9): error MSB3073: The
> command "staticdv /
> check:default.sdv" exited with code -1.
> [C:\Users\samuli\opt\tap-windows6\src\tap-windows6.vcxproj]
>
> 0 Warning(s)
> 1 Error(s)
>
> Time Elapsed 00:00:02.65
>
> ---
>
> Am I missing something [that is obvious to a Windows developer]?
>

can you try adding /v:d

to the following line

msbuild.exe src\tap-windows6.vcxproj /p:Configuration="Release"
/p:Platform=x64 /target:sdv /p:inputs="/check:default.sdv"

?

(it means verbosity detailed)



>
> Samuli
>
> [*] Adapting the instructions of the first link, above
>
> >
> >> 2. Compile the driver and EV sign it. Save PDBs too.
> >
> > I assume this is not really necessary if I'm using WDKTest certificates
> > and have enabled test-signing?
> >
> >> 3. Deploy the driver on test computers (including tap901.DVL.xml,
> remember?).
> >> 4. Do the WHLK.
> >> 5. When creating submission package, add the driver binaries and PDBs
> (on HLK Studio submission page).
> >> 6. Submit the driver to Microsoft WHQL.
> >> 7. Miscrosoft should return you a WHQL signed driver in about 10
> minutes.
> >>
> >> (21:07:09) mattock: worst case scenario is that I have to reinstall the
> HLK client as Windows Server 2019 core _if_ Microsoft is not happy with the
> "Operate in Server Core" having been run on a virtual machine, or on some
> old i5 laptop which does not have the required 4 physical processor cores
> >>
> >> Microsoft is fine with that test being run on a virtual Windows Server
> 2019 Core in Wintun case. And this test is pretty straight forward - just
> checks that driver loads and adapter responds, it doesn't need to be
> connected and have traffic. Use devcon to make a single TAP adapter on the
> Server Core. No need to have a running OpenVPN connection for this test to
> pass.
> >
> > This is good news. I can just use a Virtualbox VM then. This test used
> > to pass even on EC2 Windows instances.
> >
> >> (21:14:42) mattock: I also finally ate our own dogfood and installer
> OpenVPN on the virtual host running the 

Re: [Openvpn-devel] [bui...@travis-ci.org: Still Failing: OpenVPN/openvpn#874 (master - 7473f32)]

[Илья Шипицин]

Thank you for the investigation, Gert.
I'll have a look soon

On Sun, Jun 23, 2019, 11:55 PM Gert Doering  wrote:

> Hi,
>
> travis CI builds for MacOS fail (and have failed for quite some time,
> it seems) because LZO is not installed as pre-requisite - the configure
> run in the log below ends in line 632 with
>
>  configure: error: lzo enabled but missing
>
> ... but it *should* be built by ".travis/build-deps.sh" - so it seems
> that script is failing.  In any case it is not communicating errors
> back to the caller, because otherwise we'd see the output in the
> main travis build log...
>
> Not sure what is needed to fix these two issues
>
>  - get output from build-deps.sh in case of failure
>  - make the failure go away
>
>
> A naive reading of build-deps.sh seems to suggest that "build_lzo"
> is only ever called on MinGW cross-builds and not on MacOS - so, that
> would explain why it's not failing.  But then, how to teach Travis
> that we want LZO?
>
> Anyway, I leave this for somebody who understands Travis-CI better than
> I do to fix and send a patch.
>
> gert
>
>
> - Forwarded message from Travis CI  -
>
> Date: Sun, 23 Jun 2019 18:44:30 +
> From: Travis CI 
> To: g...@greenie.muc.de, stef...@karger.me
> Subject: Still Failing: OpenVPN/openvpn#874 (master - 7473f32)
>
> Build Update for OpenVPN/openvpn
> -
>
> Build: #874
> Status: Still Failing
>
> Duration: 20 mins and 54 secs
> Commit: 7473f32 (master)
> Author: Steffan Karger
> Message: configure.ac: add lzo CFLAGS/LIBS to the test flags
>
> This fixes "make check" builds on systems with lzo on a non-standard
> location.
>
> Signed-off-by: Steffan Karger 
> Acked-by: David Sommerseth 
> Message-Id: <20190602101831.21216-1-stef...@karger.me>
> URL:
> https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg18482.html
> Signed-off-by: Gert Doering 
>
> View the changeset:
> https://github.com/OpenVPN/openvpn/compare/06f65a0cbfcb...7473f326366f
>
> View the full build log and details:
> https://travis-ci.org/OpenVPN/openvpn/builds/549429549?utm_medium=notification_source=email
>
> --
>
> You can unsubscribe from build emails from the OpenVPN/openvpn repository
> going to
> https://travis-ci.org/account/preferences/unsubscribe?repository=6518989_medium=notification_source=email
> .
> Or unsubscribe from *all* email updating your settings at
> https://travis-ci.org/account/preferences/unsubscribe?utm_medium=notification_source=email
> .
> Or configure specific recipients for build notifications in your
> .travis.yml file. See https://docs.travis-ci.com/user/notifications.
>
>
> - End forwarded message -
>
> --
> "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
> ___
> Openvpn-devel mailing list
> Openvpn-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/openvpn-devel
>
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] state of sitnl patchset ?

[Илья Шипицин]

пн, 10 июн. 2019 г. в 02:11, Gert Doering :

> Hi,
>
> On Mon, Jun 10, 2019 at 02:06:47AM +0500,  ?? wrote:
> > > On Mon, Jun 10, 2019 at 12:05:52AM +0500,  ??
> wrote:
> > > > https://patchwork.openvpn.net/project/openvpn2/list/?series=428 says
> > > "new"
> > > > however, I see patchset is applied (and travis-ci is somewhat broken)
> > > >
> > > > are all paches applied already ?
> > >
> > > Patch status is communicated via the list - and my comments can be
> > > nicely seen when clicking on each individual patch.
> >
> > it is complicated to view every patch and it's comments.
> > is there a way to change status to "applied" on patchwork ?
>
> I'm leaving them in their current state as a reminder that there is
> more work to do - clean up the code where needed, fix the regression
> in 5/7, fix the buildslave blowup in 7/7.
>


thank you, that's I wanted to hear.
"patches are still New, because it is not finished yet"



>
> (5/7 is actually fine in itself, the problem is an earlier patch which
> already got applied, but where the code was never activated - so when
> that code is fixed, 5/7 could be applied "as is".  OTOH there are code
> warts in 5/7, so maybe a v4 will come)
>
> 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
>
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] state of sitnl patchset ?

[Илья Шипицин]

пн, 10 июн. 2019 г. в 01:37, Gert Doering :

> Hi,
>
> On Mon, Jun 10, 2019 at 12:05:52AM +0500,  ?? wrote:
> > https://patchwork.openvpn.net/project/openvpn2/list/?series=428 says
> "new"
> > however, I see patchset is applied (and travis-ci is somewhat broken)
> >
> > are all paches applied already ?
>
> Patch status is communicated via the list - and my comments can be
> nicely seen when clicking on each individual patch.
>

it is complicated to view every patch and it's comments.
is there a way to change status to "applied" on patchwork ?


>
> Most patches have been applied, 5/7 has not, and some of the other
> code needs polishing.
>
> 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
>
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

[Openvpn-devel] state of sitnl patchset ?

[Илья Шипицин]

Hello,

https://patchwork.openvpn.net/project/openvpn2/list/?series=428 says "new"
however, I see patchset is applied (and travis-ci is somewhat broken)

are all paches applied already ?

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

Re: [Openvpn-devel] Wintun performance results

[Илья Шипицин]

it will most probably get lost in mailing list.
can we add it to https://openvpn.net website ? something like "performance
testing" with full configs provided ?

ср, 15 мая 2019 г. в 18:49, Lev Stipakov :

> Hi guys,
>
> I made openvpn3 (required changes will be incorporated into main branch at
> some point) work with wintun and did performance testing in AWS.
>
> Client:c5.xlarge, Windows Server 2016, patched openvpn3 test client
> and OpenVPN Connect 2.7.1.103 (uses tap-windows6, based on openvpn3).
>
> Server:  c5.xlarge, Ubuntu 18.04, openvpn 2.4.4
>
> Client and server instances are in the same VPC and placement group.
>
> iPerf3 running on server:
>
> > iperf3 -s -B 0.0.0.0 -V
>
> iPerf3 running on client:
>
> > iperf3 -c 10.8.0.1 -V (server VPN address)
> > iperf3 -c 10.0.0.18 -V (server VPC address)
>
> Results:
>
> - no vpn
>
> [ ID] Interval   Transfer Bandwidth
> [  4]   0.00-10.00  sec  8.67 GBytes  7.45
> Gbits/sec  sender
> [  4]   0.00-10.00  sec  8.67 GBytes  7.45
> Gbits/sec  receiver
> CPU Utilization: local/sender 61.4% (5.6%u/55.8%s), remote/receiver 33.9%
> (1.7%u/32.2%s)
>
> - tap-windows6
>
> [ ID] Interval   Transfer Bandwidth
> [  4]   0.00-10.00  sec   404 MBytes   339
> Mbits/sec  sender
> [  4]   0.00-10.00  sec   404 MBytes   339
> Mbits/sec  receiver
> CPU Utilization: local/sender 4.6% (0.3%u/4.3%s), remote/receiver 21.4%
> (2.2%u/19.2%s)
>
> - wintun
>
> [ ID] Interval   Transfer Bandwidth
> [  4]   0.00-10.00  sec   536 MBytes   449
> Mbits/sec  sender
> [  4]   0.00-10.00  sec   536 MBytes   449
> Mbits/sec  receiver
> CPU Utilization: local/sender 2.9% (0.1%u/2.8%s), remote/receiver 10.1%
> (0.7%u/9.3%s)
>
> As you see, wintun performs 30% better comparison to tap-windows6 and
> incurs significantly less CPU usage.
>
> --
> -Lev
> ___
> Openvpn-devel mailing list
> Openvpn-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/openvpn-devel
>
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] cirrus-ci: freebsd builds ?

[Илья Шипицин]

ср, 17 апр. 2019 г. в 14:45, Steffan Karger :

> On Thu, 11 Apr 2019 at 00:54, Илья Шипицин  wrote:
> > 1) error when built with mbedtls-2.16.0 (surprizingly, build does not
> fail)
> >
> > [   OK ] tls_crypt_v2_wrap_unwrap_no_metadata
> > [ RUN  ] tls_crypt_v2_wrap_unwrap_max_metadata
> > [   OK ] tls_crypt_v2_wrap_unwrap_max_metadata
> > [ RUN  ] tls_crypt_v2_wrap_too_long_metadata
> > ERROR: could not crypt: insufficient space in dst
>
> This is not a test error, but an error message printed by the code
> that is tested. See the test name, it feeds the code too much
> metadata, and checks that the code errors out as expected.
>

I do not see same behaviour on mbedtls-2.8.0

https://travis-ci.org/OpenVPN/openvpn/jobs/518916671

(cirrus-ci picks the most recent mbedtls-2.16.0)


>
> > 2) base64 is missing --> build is ok (we have similar "failures" on
> travis-ci osx builds)
> >
> > Testing tls-crypt-v2 key generation (max length
> metadata)/t_lpback.sh: base64: not found
> > OK
> > PASS: t_lpback.sh
>
> This is an error in t_lpback.sh, will check it out.
>
> -Steffan
>
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] cirrus-ci: freebsd builds ?

[Илья Шипицин]

ср, 17 апр. 2019 г. в 14:45, Steffan Karger :

> On Thu, 11 Apr 2019 at 00:54, Илья Шипицин  wrote:
> > 1) error when built with mbedtls-2.16.0 (surprizingly, build does not
> fail)
> >
> > [   OK ] tls_crypt_v2_wrap_unwrap_no_metadata
> > [ RUN  ] tls_crypt_v2_wrap_unwrap_max_metadata
> > [   OK ] tls_crypt_v2_wrap_unwrap_max_metadata
> > [ RUN  ] tls_crypt_v2_wrap_too_long_metadata
> > ERROR: could not crypt: insufficient space in dst
>
> This is not a test error, but an error message printed by the code
> that is tested. See the test name, it feeds the code too much
> metadata, and checks that the code errors out as expected.
>
> > 2) base64 is missing --> build is ok (we have similar "failures" on
> travis-ci osx builds)
> >
> > Testing tls-crypt-v2 key generation (max length
> metadata)/t_lpback.sh: base64: not found
> > OK
> > PASS: t_lpback.sh
>
> This is an error in t_lpback.sh, will check it out.
>

that bug also appears on osx

https://travis-ci.org/OpenVPN/openvpn/jobs/518916670#L1477-L1485


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

Re: [Openvpn-devel] cirrus-ci: freebsd builds ?

[Илья Шипицин]

couple of findings:

1) error when built with mbedtls-2.16.0 (surprizingly, build does not fail)

[   OK ] tls_crypt_v2_wrap_unwrap_no_metadata
[ RUN  ] tls_crypt_v2_wrap_unwrap_max_metadata
[   OK ] tls_crypt_v2_wrap_unwrap_max_metadata
[ RUN  ] tls_crypt_v2_wrap_too_long_metadata
ERROR: could not crypt: insufficient space in dst
[   OK ] tls_crypt_v2_wrap_too_long_metadata
[ RUN  ] tls_crypt_v2_wrap_unwrap_wrong_key
[   OK ] tls_crypt_v2_wrap_unwrap_wrong_key


2) base64 is missing --> build is ok (we have similar "failures" on
travis-ci osx builds)

Testing tls-crypt-v2 key generation (max length metadata)/t_lpback.sh:
base64: not found
OK
PASS: t_lpback.sh


ср, 10 апр. 2019 г. в 23:44, Илья Шипицин :

> hello,
>
> I have implemented cirrus-ci support (with freebsd fix),
> please have a look
>
> https://github.com/OpenVPN/openvpn/pull/125
>
> builds:
>
> https://cirrus-ci.com/task/6511771119517696
> https://cirrus-ci.com/task/5385871212675072
>
> thoughts ? suggestions ?
>
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

[Openvpn-devel] cirrus-ci: freebsd builds ?

[Илья Шипицин]

hello,

I have implemented cirrus-ci support (with freebsd fix),
please have a look

https://github.com/OpenVPN/openvpn/pull/125

builds:

https://cirrus-ci.com/task/6511771119517696
https://cirrus-ci.com/task/5385871212675072

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

[Openvpn-devel] missing cover letter for "modernize travis-ci" patchset

[Илья Шипицин]

Hello,

somehow cover letter was lost for no reason (it was delivered during test
git send-email).
the rationale behind switching to xenial is trusty EOL coming on 30 Apr
2019.

also, it is good time to refresh few more things like building on new arch
"linux-ppc64le"
and simplify osx brew management.

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