[Openvpn-devel] new coverity release

2021-01-25 Thread Илья Шипицин
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 ?

2021-01-13 Thread Илья Шипицин
ср, 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 ?

2021-01-13 Thread Илья Шипицин
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

2020-12-24 Thread Илья Шипицин
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

2020-12-23 Thread Илья Шипицин
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

2020-12-22 Thread Илья Шипицин
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

2020-12-21 Thread Илья Шипицин
пн, 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

2020-12-20 Thread Илья Шипицин
пн, 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

2020-10-02 Thread Илья Шипицин
пт, 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

2020-09-04 Thread Илья Шипицин
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

2020-08-04 Thread Илья Шипицин
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)

2020-06-24 Thread Илья Шипицин
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

2020-06-23 Thread Илья Шипицин
ср, 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

2020-06-23 Thread Илья Шипицин
вт, 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

2020-06-23 Thread Илья Шипицин
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

2020-06-23 Thread Илья Шипицин
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

2020-06-08 Thread Илья Шипицин
пн, 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 ?

2020-05-04 Thread Илья Шипицин
пн, 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 ?

2020-05-03 Thread Илья Шипицин
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 ?

2020-03-24 Thread Илья Шипицин
вт, 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.

2020-03-24 Thread Илья Шипицин
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.

2020-03-24 Thread Илья Шипицин
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 ?

2020-03-23 Thread Илья Шипицин
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.

2020-03-22 Thread Илья Шипицин
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

2020-02-20 Thread Илья Шипицин
чт, 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

2020-02-15 Thread Илья Шипицин
сб, 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

2020-02-14 Thread Илья Шипицин
пт, 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.

2020-02-03 Thread Илья Шипицин
пн, 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.

2020-02-03 Thread Илья Шипицин
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.

2020-02-02 Thread Илья Шипицин
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.

2020-02-02 Thread Илья Шипицин
пн, 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

2020-02-01 Thread Илья Шипицин
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

2019-11-14 Thread Илья Шипицин
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 ?

2019-11-08 Thread Илья Шипицин
пт, 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 ?

2019-11-07 Thread Илья Шипицин
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

2019-11-07 Thread Илья Шипицин
чт, 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

2019-10-17 Thread Илья Шипицин
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

2019-07-02 Thread Илья Шипицин
вт, 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

2019-07-02 Thread Илья Шипицин
вт, 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)]

2019-06-30 Thread Илья Шипицин
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)]

2019-06-29 Thread Илья Шипицин
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

2019-06-28 Thread Илья Шипицин
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

2019-06-28 Thread Илья Шипицин
пт, 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

2019-06-28 Thread Илья Шипицин
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

2019-06-26 Thread Илья Шипицин
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

2019-06-25 Thread Илья Шипицин
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)

2019-06-24 Thread Илья Шипицин
пн, 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)]

2019-06-24 Thread Илья Шипицин
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 ?

2019-06-09 Thread Илья Шипицин
пн, 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 ?

2019-06-09 Thread Илья Шипицин
пн, 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 ?

2019-06-09 Thread Илья Шипицин
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

2019-05-15 Thread Илья Шипицин
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 ?

2019-04-17 Thread Илья Шипицин
ср, 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 ?

2019-04-17 Thread Илья Шипицин
ср, 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 ?

2019-04-10 Thread Илья Шипицин
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 ?

2019-04-10 Thread Илья Шипицин
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

2019-03-11 Thread Илья Шипицин
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


Re: [Openvpn-devel] [PATCH (2.4)] Fix --disable-crypto build

2018-10-05 Thread Илья Шипицин
shall we add "--disable-crypto" to travis-ci matrix in 2.4 branch ?

пт, 5 окт. 2018 г. в 19:00, Steffan Karger :

> Commit d2ff5164 was fine for the master branch, but broke the 2.4 build if
> the --disable-crypto configure options was used (which is removed in the
> master branch).
>
> Signed-off-by: Steffan Karger 
> ---
>  src/openvpn/init.c | 4 
>  1 file changed, 4 insertions(+)
>
> diff --git a/src/openvpn/init.c b/src/openvpn/init.c
> index 0950f07e..2d201c44 100644
> --- a/src/openvpn/init.c
> +++ b/src/openvpn/init.c
> @@ -621,9 +621,11 @@ uninit_proxy(struct context *c)
>  static void
>  do_set_ncp_options(struct context *c)
>  {
> +#ifdef ENABLE_CRYPTO
>  c->c1.ciphername = c->options.ciphername;
>  c->c1.authname = c->options.authname;
>  c->c1.keysize = c->options.keysize;
> +#endif ENABLE_CRYPTO
>  }
>
>  /*
> @@ -635,9 +637,11 @@ do_set_ncp_options(struct context *c)
>  static void
>  do_unset_ncp_options(struct context *c)
>  {
> +#ifdef ENABLE_CRYPTO
>  c->options.ciphername = c->c1.ciphername;
>  c->options.authname = c->c1.authname;
>  c->options.keysize = c->c1.keysize;
> +#endif ENABLE_CRYPTO
>  }
>
>  void
> --
> 2.17.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] travis: add OpenSSL 1.1 Windows build

2018-10-05 Thread Илья Шипицин
openssl versions were aligned to those used in "openvpn-build" repo, i.e.
the same version were used as in installer creation.
not sure why do we want to have big matrix for cross builds.

but I do not mind, the more tests the better :)

пт, 5 окт. 2018 г. в 17:40, Steffan Karger :

> So we catch both compilation errors against OpenSSL 1.0 and 1.1 on Windows.
>
> Signed-off-by: Steffan Karger 
> ---
>  .travis.yml | 5 -
>  1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/.travis.yml b/.travis.yml
> index 216f0a04..ede2aaa6 100644
> --- a/.travis.yml
> +++ b/.travis.yml
> @@ -53,7 +53,10 @@ matrix:
>os: osx
>osx_image: xcode7.3
>compiler: clang
> -- env: SSLLIB="openssl" CHOST=x86_64-w64-mingw32
> +- env: SSLLIB="openssl" CHOST=x86_64-w64-mingw32
> OPENSSL_VERSION="1.0.1u"
> +  os: linux
> +  compiler: ": Win64 build only"
> +- env: SSLLIB="openssl" CHOST=x86_64-w64-mingw32
> OPENSSL_VERSION="1.1.0h"
>os: linux
>compiler: ": Win64 build only"
>  - env: SSLLIB="openssl" CHOST=i686-w64-mingw32
> --
> 2.17.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] Slow outbound network speed for Windows Server 2016 only via the OpenVPN tunnel

2018-10-04 Thread Илья Шипицин
are you using intel drivers instead of windows drivers ?
is version the same accross servers ? firmware ?


we dropped using vendor drivers since win 2012.
what I was talking about is DCB implementation in windows, not in intel
drivers (I never used that since win 2012)

чт, 4 окт. 2018 г. в 17:58, Rostyslav Maryliak <
rostyslav.maryl...@idealscorp.com>:

> Dear Ilya,
>
> No, it is disabled.
>
> [image: image.png]
>
>
> On Thu, Oct 4, 2018 at 3:14 PM Илья Шипицин  wrote:
>
>> congestion can be setup using datacenter bridging
>>
>>
>> https://docs.microsoft.com/en-us/windows-server/networking/technologies/dcb/dcb-manage
>>
>> actually, I thought it works in another direction (i.e. you specify it in
>> windows and distribute to network switches).
>> is DCB in use ?
>>
>> чт, 4 окт. 2018 г. в 17:02, Rostyslav Maryliak <
>> rostyslav.maryl...@idealscorp.com>:
>>
>>> Dear Ilya,
>>>
>>> Sure, the results are the same for all our win2016 servers:
>>>
>>> PS C:\Users\Administrator> [environment]::OSVersion.Version
>>>
>>> Major Minor BuildRevision
>>> ---  
>>> 10  014393  0
>>>
>>> On Thu, Oct 4, 2018 at 2:45 PM Илья Шипицин 
>>> wrote:
>>>
>>>>
>>>>
>>>> чт, 4 окт. 2018 г. в 15:50, Rostyslav Maryliak <
>>>> rostyslav.maryl...@idealscorp.com>:
>>>>
>>>>> Dear Illya,
>>>>>
>>>>> Sorry for misleading you. I want to set this parameter to "none"
>>>>> globally.
>>>>> I CAN change "Congestion Control Provider" setting for different
>>>>> templates (i.e. Internet. Datacenter etc) in Powershell, but not to a
>>>>> "None" value.
>>>>>
>>>>> In Powershell there is simply no option for this value:
>>>>> PS C:\Users\Administrator> Set-NetTCPSetting -SettingName Datacenter
>>>>> -CongestionProvider [ CTCP | CUBIC | DCTCP | Default | LEDBAT | NewReno ]
>>>>>
>>>>> I've tried different values, but still no luck.
>>>>>
>>>>> In CMD there is such option, but it does not apply any changes for it:
>>>>> C:\Users\Administrator> netsh int tcp set supplemental
>>>>> template=datacenter congestionprovider=*none*
>>>>> Ok.
>>>>>
>>>>> C:\Users\Administrator> netsh int tcp show supplemental
>>>>> template=datacenter
>>>>> TCP Supplemental Parameters
>>>>> --
>>>>> Minimum RTO (msec)   : 20
>>>>> Initial Congestion Window (MSS) : 10
>>>>> Congestion Control Provider : *dctcp*
>>>>> Enable Congestion Window Restart  : enabled
>>>>> Delayed ACK timeout (msec): 10
>>>>> Delayed ACK frequency: 2
>>>>> Enable RACK        : disabled
>>>>> Enable Tail Loss Probe : disabled
>>>>>
>>>>> Also, as I've mentioned in referred thread, such issue occurs on all
>>>>> our win2016 servers, except one.
>>>>>
>>>>
>>>> can you provide the output of
>>>>
>>>>
>>>> [environment]::OSVersion.Version
>>>>
>>>> for that 2016 server ? (and for other servers)
>>>>
>>>>
>>>>
>>>>> This exception server has "Congestion Control Provider" setting set to
>>>>> "none" somehow.
>>>>> But still it is very strange for me that I have such slow network
>>>>> speed via the tunnel for all win2016 servers "out of the box".
>>>>>
>>>>> Can you please check this from your side as well and confirm or
>>>>> disprove the issue?
>>>>>
>>>>>
>>>>> On Thu, Oct 4, 2018 at 12:10 PM Илья Шипицин 
>>>>> wrote:
>>>>>
>>>>>> thank you for your investigation.
>>>>>>
>>>>>> congestion provider can be customized if you select "*Datacenter
>>>>>> Custom"*
>>>>>>
>>>>>> чт, 4 окт. 2018 г. в 13:58, Rostyslav Maryliak <
>>>>

Re: [Openvpn-devel] Slow outbound network speed for Windows Server 2016 only via the OpenVPN tunnel

2018-10-04 Thread Илья Шипицин
congestion can be setup using datacenter bridging

https://docs.microsoft.com/en-us/windows-server/networking/technologies/dcb/dcb-manage

actually, I thought it works in another direction (i.e. you specify it in
windows and distribute to network switches).
is DCB in use ?

чт, 4 окт. 2018 г. в 17:02, Rostyslav Maryliak <
rostyslav.maryl...@idealscorp.com>:

> Dear Ilya,
>
> Sure, the results are the same for all our win2016 servers:
>
> PS C:\Users\Administrator> [environment]::OSVersion.Version
>
> Major Minor BuildRevision
> ---  
> 10  014393  0
>
> On Thu, Oct 4, 2018 at 2:45 PM Илья Шипицин  wrote:
>
>>
>>
>> чт, 4 окт. 2018 г. в 15:50, Rostyslav Maryliak <
>> rostyslav.maryl...@idealscorp.com>:
>>
>>> Dear Illya,
>>>
>>> Sorry for misleading you. I want to set this parameter to "none"
>>> globally.
>>> I CAN change "Congestion Control Provider" setting for different
>>> templates (i.e. Internet. Datacenter etc) in Powershell, but not to a
>>> "None" value.
>>>
>>> In Powershell there is simply no option for this value:
>>> PS C:\Users\Administrator> Set-NetTCPSetting -SettingName Datacenter
>>> -CongestionProvider [ CTCP | CUBIC | DCTCP | Default | LEDBAT | NewReno ]
>>>
>>> I've tried different values, but still no luck.
>>>
>>> In CMD there is such option, but it does not apply any changes for it:
>>> C:\Users\Administrator> netsh int tcp set supplemental
>>> template=datacenter congestionprovider=*none*
>>> Ok.
>>>
>>> C:\Users\Administrator> netsh int tcp show supplemental
>>> template=datacenter
>>> TCP Supplemental Parameters
>>> --
>>> Minimum RTO (msec)   : 20
>>> Initial Congestion Window (MSS) : 10
>>> Congestion Control Provider : *dctcp*
>>> Enable Congestion Window Restart  : enabled
>>> Delayed ACK timeout (msec): 10
>>> Delayed ACK frequency: 2
>>> Enable RACK: disabled
>>> Enable Tail Loss Probe : disabled
>>>
>>> Also, as I've mentioned in referred thread, such issue occurs on all our
>>> win2016 servers, except one.
>>>
>>
>> can you provide the output of
>>
>>
>> [environment]::OSVersion.Version
>>
>> for that 2016 server ? (and for other servers)
>>
>>
>>
>>> This exception server has "Congestion Control Provider" setting set to
>>> "none" somehow.
>>> But still it is very strange for me that I have such slow network speed
>>> via the tunnel for all win2016 servers "out of the box".
>>>
>>> Can you please check this from your side as well and confirm or disprove
>>> the issue?
>>>
>>>
>>> On Thu, Oct 4, 2018 at 12:10 PM Илья Шипицин 
>>> wrote:
>>>
>>>> thank you for your investigation.
>>>>
>>>> congestion provider can be customized if you select "*Datacenter
>>>> Custom"*
>>>>
>>>> чт, 4 окт. 2018 г. в 13:58, Rostyslav Maryliak <
>>>> rostyslav.maryl...@idealscorp.com>:
>>>>
>>>>> Dear Ilya,
>>>>>
>>>>> I've checked "Get-NetTCPConnection" command output on both win2012r2
>>>>> and win2016 servers.
>>>>>
>>>>> win2012r2 server works as OpenVPN server. Internal IP address -
>>>>> 10.0.4.1. OpenVPN tunnel IP address - 172.16.144.1
>>>>> win2016 server works as OpenVPN client. Internal IP address -
>>>>> 10.0.44.1. OpenVPN tunnel IP address - 172.16.144.18
>>>>>
>>>>>
>>>>> *From win2012r2 server:*
>>>>>
>>>>> PS C:\Users\Administrator> Get-NetTCPConnection -RemoteAddress
>>>>> 10.0.44.1
>>>>> LocalAddressLocalPort  RemoteAddress
>>>>>RemotePort State  
>>>>> AppliedSetting
>>>>>    -
>>>>>  -   --
>>>>> - --
>>>>> 172.16.144.1 56437   

Re: [Openvpn-devel] Slow outbound network speed for Windows Server 2016 only via the OpenVPN tunnel

2018-10-04 Thread Илья Шипицин
чт, 4 окт. 2018 г. в 15:50, Rostyslav Maryliak <
rostyslav.maryl...@idealscorp.com>:

> Dear Illya,
>
> Sorry for misleading you. I want to set this parameter to "none" globally.
> I CAN change "Congestion Control Provider" setting for different
> templates (i.e. Internet. Datacenter etc) in Powershell, but not to a
> "None" value.
>
> In Powershell there is simply no option for this value:
> PS C:\Users\Administrator> Set-NetTCPSetting -SettingName Datacenter
> -CongestionProvider [ CTCP | CUBIC | DCTCP | Default | LEDBAT | NewReno ]
>
> I've tried different values, but still no luck.
>
> In CMD there is such option, but it does not apply any changes for it:
> C:\Users\Administrator> netsh int tcp set supplemental template=datacenter
> congestionprovider=*none*
> Ok.
>
> C:\Users\Administrator> netsh int tcp show supplemental template=datacenter
> TCP Supplemental Parameters
> --
> Minimum RTO (msec)   : 20
> Initial Congestion Window (MSS) : 10
> Congestion Control Provider : *dctcp*
> Enable Congestion Window Restart  : enabled
> Delayed ACK timeout (msec): 10
> Delayed ACK frequency: 2
> Enable RACK: disabled
> Enable Tail Loss Probe : disabled
>
> Also, as I've mentioned in referred thread, such issue occurs on all our
> win2016 servers, except one.
>

can you provide the output of


[environment]::OSVersion.Version

for that 2016 server ? (and for other servers)



> This exception server has "Congestion Control Provider" setting set to
> "none" somehow.
> But still it is very strange for me that I have such slow network speed
> via the tunnel for all win2016 servers "out of the box".
>
> Can you please check this from your side as well and confirm or disprove
> the issue?
>
>
> On Thu, Oct 4, 2018 at 12:10 PM Илья Шипицин  wrote:
>
>> thank you for your investigation.
>>
>> congestion provider can be customized if you select "*Datacenter Custom"*
>>
>> чт, 4 окт. 2018 г. в 13:58, Rostyslav Maryliak <
>> rostyslav.maryl...@idealscorp.com>:
>>
>>> Dear Ilya,
>>>
>>> I've checked "Get-NetTCPConnection" command output on both win2012r2
>>> and win2016 servers.
>>>
>>> win2012r2 server works as OpenVPN server. Internal IP address -
>>> 10.0.4.1. OpenVPN tunnel IP address - 172.16.144.1
>>> win2016 server works as OpenVPN client. Internal IP address - 10.0.44.1.
>>> OpenVPN tunnel IP address - 172.16.144.18
>>>
>>>
>>> *From win2012r2 server:*
>>>
>>> PS C:\Users\Administrator> Get-NetTCPConnection -RemoteAddress 10.0.44.1
>>> LocalAddressLocalPort  RemoteAddress
>>>  RemotePort State  AppliedSetting
>>>    -
>>>  -   --
>>> - --
>>> 172.16.144.1 56437   10.0.44.1
>>>   53005  Established
>>> *Datacenter*
>>>
>>> PS C:\Users\Administrator> Get-NetTCPConnection -RemoteAddress
>>> 172.16.144.18
>>> LocalAddress   LocalPort   RemoteAddress
>>>  RemotePort State  AppliedSetting
>>>    -
>>>  -   --
>>> - --
>>> 10.0.4.111616
>>> 172.16.144.1856882  Established
>>> *Datacenter*
>>> 10.0.4.111616
>>> 172.16.144.1856905  Established
>>> *Datacenter*
>>>
>>>
>>> *From win2016 server:*
>>>
>>> PS C:\Users\Administrator> Get-NetTCPConnection -RemoteAddress 10.0.4.1
>>> LocalAddress   LocalPort   RemoteAddress
>>>  RemotePort State AppliedSetting
>>>OwningProcess
>>>    -
>>>  -   --
>

Re: [Openvpn-devel] Slow outbound network speed for Windows Server 2016 only via the OpenVPN tunnel

2018-10-04 Thread Илья Шипицин
thank you for your investigation.

congestion provider can be customized if you select "*Datacenter Custom"*

чт, 4 окт. 2018 г. в 13:58, Rostyslav Maryliak <
rostyslav.maryl...@idealscorp.com>:

> Dear Ilya,
>
> I've checked "Get-NetTCPConnection" command output on both win2012r2 and
> win2016 servers.
>
> win2012r2 server works as OpenVPN server. Internal IP address - 10.0.4.1.
> OpenVPN tunnel IP address - 172.16.144.1
> win2016 server works as OpenVPN client. Internal IP address - 10.0.44.1.
> OpenVPN tunnel IP address - 172.16.144.18
>
>
> *From win2012r2 server:*
>
> PS C:\Users\Administrator> Get-NetTCPConnection -RemoteAddress 10.0.44.1
> LocalAddressLocalPort  RemoteAddress
>RemotePort State  AppliedSetting
>    -
>  -   --
> - --
> 172.16.144.1 56437   10.0.44.1
> 53005  Established
> *Datacenter*
>
> PS C:\Users\Administrator> Get-NetTCPConnection -RemoteAddress
> 172.16.144.18
> LocalAddress   LocalPort   RemoteAddress
>RemotePort State  AppliedSetting
>    -
>  -   --
> - --
> 10.0.4.111616
> 172.16.144.1856882  Established
> *Datacenter*
> 10.0.4.111616
> 172.16.144.1856905  Established
> *Datacenter*
>
>
> *From win2016 server:*
>
> PS C:\Users\Administrator> Get-NetTCPConnection -RemoteAddress 10.0.4.1
> LocalAddress   LocalPort   RemoteAddress
>RemotePort State AppliedSetting
>  OwningProcess
>    -
>  -   --
>  -   -- -
> 172.16.144.18  5690510.0.4.1
>11616   Established   *
> Internet *   13300
> 172.16.144.18  5688210.0.4.1
>11616   Established   *
> Internet  *  13300
>
>
> PS C:\Users\Administrator> Get-NetTCPConnection -RemoteAddress 172.16.144.1
> LocalAddress   LocalPort   RemoteAddress
>RemotePort State AppliedSetting
>  OwningProcess
>    -
>  -   --
> --- -
> 10.0.44.1  53005172.16.144.1
> 56437  Established
> *Internet*  13300
>
>
> I've changed the "AppliedSetting" value to Datacenter on win2016 server as
> well by running this commands and restarting the VPN:
> New-NetTransportFilter -SettingName Datacenter -DestinationPrefix
> 10.0.4.0/24
> New-NetTransportFilter -SettingName Datacenter -DestinationPrefix
> 172.16.144.0/24
>
> Now it shows Datacenter on both servers. But the network speed remains the
> same. My changes do not affect the issue.
> I've noticed that global TCP settings influence that, especially "Chimney
> Offload", "Congestion Control Provider" and "ECN Capability":
>
> C:\Users\Administrator> netsh int tcp show global
> Querying active state...
>
> TCP Global Parameters
> --
> Receive-Side Scaling State   : enabled
> Chimney Offload State  : disabled
> NetDMA State   : disabled
> Direct Cache Access (DCA)  : disabled
> Receive Window Auto-Tuning Level : normal
> Add-On Congestion Control Provider   : default
> ECN Capability  : enabled
> RFC 1323 Timestamps : disabled
> Initial RTO : 3000
> Receive Segment Coalescing State : enabled
> Non Sack Rtt Resiliency   : disabled
> Max SYN Retransmissions   : 2
> TCP Fast Open : disabled
&g

Re: [Openvpn-devel] Slow outbound network speed for Windows Server 2016 only via the OpenVPN tunnel

2018-10-03 Thread Илья Шипицин
Hello,

can you do some things and tell us your observation ?

starting with win2012 so called network profiles were introduced (Internet
/ Intranet / Datacenter)
those profiles are very different for tcp connection (if you observe
degradation in case of udp, most probably that is not related)


so, let's start

start powershell (I assume you are familiar)
call

Get-NetTCPConnection

pay attention to "AppliedSetting" column.
what's there  ?

we did observe strange things when win2012 classified some traffic as
"Internet" and appropriate tcp settings were applied.

is there some correlation in your case ?

ср, 3 окт. 2018 г. в 20:45, Rostyslav Maryliak <
rostyslav.maryl...@idealscorp.com>:

> Dear OpenVPN developers,
>
> I've faced a very strange issue with slow outbound network speed from
> Windows Server 2016 Standard server via the OpenVPN tunnel.
> OpenVPN server is Windows Server 2012 R2, client is Windows Server 2016.
> The inbound network speed for Windows Server 2016 is great.
> But the outbound network speed is nearly 30-40 kbps. I've got the same
> results using several tests: iperf testings, file download via SMB,
> Web-based downloading (using HTTP) etc.
>
> The tunnels is getting up and it works greatly, but only in one direction
> - from Windows Server 2012 R2 to Windows Server 2016.
> I've been using such server-client configurations setup for several years
> with Windows Server 2012 R2 servers and I've never faced such issue before.
> At first I thought that our ISP has some network limitations, but it
> turned out that the same tests shows great network speed results using the
> public IP addresses in both directions.
> The issue only occurs inside the VPN tunnel. I've spent 3 days tryng to
> figure it out, but failed. I've installed all latest Windows updates,
> reinstalled OpenVPN, tried to switch from UDP to TCP,
> played with performance settings in configs (link-mtu, sndbuf, rcvbuf etc)
> but still no luck. I've tested the same setup between two Windows Server
> 2012 R2 servers and it works greatly in both directions.
> Then I've tested it with another Windows Server 2016 Standard server
> (different server and different ISP) and it showed the same awful results
> in outbound direction.
> When I've set the same OpenVPN tunnel between two Windows Server 2016
> Standard servers I've got the same poor network speed in both directions.
>
> I believe that the issue is somehow related only to the Windows Server
> 2016 version and I am more than confident that it depends on server's TCP
> stack settings.
> I've noticed that Windows Server 2016 has a congestion control provider
> setting set to "default", while previous versions of Windows has this
> setting set to "none".
>
> I've created a topic on OpenVPN Support Forum and it was suggested to post
> my issue to you and reference the thread.
>
> You can reference to the
> https://forums.openvpn.net/viewtopic.php?f=6=27173 for config files and
> additional information.
>
> Have you faced a similar issue before? Can you provide any hint how can I
> resolve the issue? What did I missed?
> I would be very grateful for any help. Thank you in advance.
>
>
> --
>
> Best regards,
>
> *Rostyslav Maryliak*
>
> System Administrator
>
>
>
> *iDeals™ Solutions Group*| + 38(073)437-72-51 <%2B%2038%28093%29575-35-16> |
> Skype: rostyslav.maryliak.ideals| *rostyslav.maryl...@idealscorp.com
> * | www.idealsvdr.com
> 
>
> CONFIDENTIALITY NOTE: The information transmitted, including attachments,
> is intended only for the person(s) or entity to which it is addressed and
> may contain confidential and/or privileged material. Any review,
> retransmission, dissemination or other use of, or taking of any action in
> reliance upon this information by persons or entities other than the
> intended recipient is prohibited. If you received this in error, please
> contact the sender and destroy any copies of this information.
> ___
> 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] switching openvpn-gui to github releases (instead if http://build.openvpn.net/...)

2018-10-01 Thread Илья Шипицин
sorry, I meant "OPENVPN_GUI_URL" variable of course.

пн, 1 окт. 2018 г. в 14:49, Илья Шипицин :

> Hello,
>
> I was absent for few days :) Glad to see you again.
> I want to discuss whether we can choose github releases as primary source
> here:
>
> https://github.com/OpenVPN/openvpn-build/blob/master/generic/build.vars#L15
>
>
> Cheers,
> Ilya Shipitsin
>
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel


[Openvpn-devel] switching openvpn-gui to github releases (instead if http://build.openvpn.net/...)

2018-10-01 Thread Илья Шипицин
Hello,

I was absent for few days :) Glad to see you again.
I want to discuss whether we can choose github releases as primary source
here:

https://github.com/OpenVPN/openvpn-build/blob/master/generic/build.vars#L15


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


Re: [Openvpn-devel] [PATCH] [openvpn-gui] Update system tray to populate Windows VPN flyout

2018-07-25 Thread Илья Шипицин
чт, 26 июл. 2018 г. в 1:04, Kevin Kane via Openvpn-devel <
openvpn-devel@lists.sourceforge.net>:

> Alright, I found the SMTP server and sent the patches out again with git
> send-email. Let me know how those look.
>


looks good from patchwork point of view:

https://patchwork.openvpn.net/project/openvpn2/list/


>
> -Original Message-
> From: Gert Doering 
> Sent: Wednesday, July 25, 2018 11:18 AM
> To: Kevin Kane 
> Cc: Gert Doering ; openvpn-devel <
> openvpn-devel@lists.sourceforge.net>
> Subject: Re: [Openvpn-devel] [PATCH] [openvpn-gui] Update system tray to
> populate Windows VPN flyout
>
> Hi,
>
> On Wed, Jul 25, 2018 at 06:08:19PM +, Kevin Kane wrote:
> > Ugh. Thanks, Outlook. I'd have to use a personal e-mail account to use
> something other than Exchange.
> >
> > The other option is for me to add the files to the e-mail as
> attachments. Is that acceptable, or do you really need the patch text to be
> in the message body?
>
> For applying with "git am" and for reviewing with "I can just quote parts
> of the patch and comment on it", attachments in anything that is not
> text/plain format are also not ideal, but we can try that.
>
> We've had a few patches come in recently that were attachment in a signed
> mail, and neither patchwork nor git could handle these mails in a
> satisfying way - as in: patchwork did not recognize them as "patch", and
> "git am" declared "no patch in there" - so "save patch as individual file,
> git am, manually add in-reply-to to the auto- generated "patch applied"
> reply mail, etc.
>
> It's a bit of try and error what works in a given environment.
>
> (git send-email talking SMTP to Exchange might actually work more nicely
> than outlook.  Maybe that was just one particularily weird version of
> Exchange, or "too many virus scanner plugins hooked in", given that this
> was Sophos...)
>
> 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
>
>
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> Openvpn-devel mailing list
> Openvpn-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/openvpn-devel
>
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel


Re: [Openvpn-devel] Upstreaming pqcrypto changes from microsoft/openvpn

2018-07-04 Thread Илья Шипицин
Hi,

I meant "vpndialer" part first :)

as for PQ crypto - I played with it, however, it is currently far from
worldwide adoption (if that would have been implemented as openssl loadable
engine, it would be more luck)

ср, 4 июл. 2018 г. в 5:17, Kevin Kane :

> Hello all,
>
> Thanks to Jon for making the introduction. My team works on post-quantum
> (PQ) cryptography, which is algorithms used by regular computers but which
> are resistant to attack by a sufficiently powerful quantum computer. This
> OpenVPN fork is an example application we released so the public could
> experiment with it.
>
> The following sites have information on what we're doing:
>
> Our openvpn, openvpn-build, and openvpn-gui forks are subprojects of the
> following repo: https://github.com/Microsoft/PQCrypto-VPN
>
> I just realized there are no back-pointers from the subprojects back to
> the main repo. I've just corrected that.
>
> On this site are scripts and instructions for doing our custom build of
> OpenVPN for Windows and Linux, to use the PQ crypto-enabled fork of OpenSSL
> we use, and how to properly configure it for PQ crypto. We also provide
> instructions for building an image for a Raspberry Pi to be used as a wifi
> access point that tunnels all traffic to a remote server protected by PQ
> key exchange. We also have released pre-built Linux x64 and Windows
> binaries. Our current build process works but there is plenty of room for
> improvement.
>
> A more in-depth description of the PQ VPN is here:
> https://www.microsoft.com/en-us/research/project/post-quantum-crypto-vpn/
>
> And our introduction to post-quantum cryptography overall is here:
> https://www.microsoft.com/en-us/research/project/post-quantum-cryptography/
>
> As Jon said, these algorithms are experimental and so it would be
> inappropriate to introduce them into production code until the
> standardization and thorough analysis by the cryptographic community are
> completed. When that happens, we want to be ready to quickly integrate
> these algorithms into existing software. My colleagues are already
> contributing to a PQ crypto-enabled fork of OpenSSL (
> https://github.com/open-quantum-safe/openssl), and similarly we believe
> there is value in maintaining a PQ-enabled fork of OpenVPN, so that both
> are ready when there is consensus on a standard.
>
> I will be updating the fork to track the forward progress of both the
> PQ-enabled OpenSSL fork and OpenVPN as time allows, but I welcome the
> participation of anyone who's interested in helping with the updates or
> making other improvements, as well as any suggestions you may have on
> future directions for this work.
>
> -Original Message-
> From: Jon Kunkee
> Sent: Tuesday, July 3, 2018 4:20 PM
> To: Samuli Seppänen ; Илья Шипицин <
> chipits...@gmail.com>; Kevin Kane 
> Cc: openvpn-devel 
> Subject: Upstreaming pqcrypto changes from microsoft/openvpn
>
> Hi,
>
> (Retitling thread from RE: [Openvpn-devel] Topics for the community
> meeting (Wed, 13th June 2018))
>
> > do you know this activity https://github.com/Microsoft/openvpn/ ?
> > there are interesting things
>
> There are *very* interesting things there!
>
> > Do you know if Kevin (or his manager/team) plans to push his work
> upstream (i.e. to us) at some point?
>
> Samuli and Илья, I'd like to introduce you to Kevin Kane. He is the
> current maintainer of the Microsoft\openvpn pqcrypto branch on Github.
>
> He is working on developing encryption standards that are resistant to
> quantum-mechanics-based attacks. This includes taking existing products and
> adding experimental implementations of the experimental standards to
> them—including OpenVPN and OpenSSL. Over time these new techniques will be
> studied, refined, tested, and otherwise hammered on in the furnace of
> open-source cryptography until they gain some measure of trust.
>
> Both the experimental and untested nature of his work mean that no, his
> code isn’t ready to be merged into OpenVPN/master…yet!
>
> In the meantime, he would love to work with someone from the OpenVPN
> community—or even the organization itself—to make the connection official
> and to refine his additions. Some of the needed refinement requires
> familiarity with the overall build system, while a forward-looking
> cryptographer or protocol guru might take interest in what's developing
> under the hood.
>
> I don't know much about the current status of the project, but Kevin is
> happy to answer questions and would love to hear from you.
>
> Thanks,
> Jon
>
>
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel


Re: [Openvpn-devel] Topics for the community meeting (Wed, 13th June 2018)

2018-07-03 Thread Илья Шипицин
Hello, Jon.

do you know this activity https://github.com/Microsoft/openvpn/ ?
there are interesting things

вт, 3 июл. 2018 г. в 22:43, Jon Kunkee via Openvpn-devel <
openvpn-devel@lists.sourceforge.net>:

> Hi,
>
> 2. Tap-windows6 patches, building and testing
>
> In order to get the tap-windows6 driver signed properly for Windows Server
> 2016, it needs to pass the Windows Hardware Certification Program subset of
> the Windows Hardware Logo Kit (HLK) tests. Samuli has the tests running in
> EC2, but there are some failures.
>
> Some of the failures are basically paperwork, like the Static Verification
> logs test. Some reflect needed tweaks in the environment, like the Running
> on Server Core test. Others reflect possible code bugs, and since I have
> significant experience doing Windows kernel debugging I'm investigating
> those.
>
> I spent yesterday setting up a local HLK-based test environment with
> kernel debugging. Today I'm trying to get two OpenVPN clients to be able to
> talk to each other over a VPN so I can start reproducing and investigating
> the failures. (I will be sending a mail to openvpn-users asking for help
> since it would be quite noisy to explain  on IRC.)
>
> Cheers,
> Jon Kunkee
> Software Developer
> Microsoft
>
> -Original Message-
> From: Samuli Seppänen 
> Sent: Tuesday, July 3, 2018 10:30 AM
> To: openvpn-devel@lists.sourceforge.net
> Subject: [Openvpn-devel] Topics for the community meeting (Wed, 13th June
> 2018)
>
> Hi,
>
> We're going to have an IRC meeting starting at 11:30 CET
> (9:30 UTC) on #openvpn-meeting  irc.freenode.net. You do not have to
> be logged in to Freenode to join the channel.
>
> Current topic list along with basic information is here:
>
> <
> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcommunity.openvpn.net%2Fopenvpn%2Fwiki%2FTopics-2018-06-13data=02%7C01%7Cjkunkee%40microsoft.com%7C2ff5949944a34864919b08d5e10aa0b2%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636662358125323471sdata=E2tnMk95DPL%2BFpUNM8td0lQd0PTMmfZ8ZAXUsGBES%2FA%3Dreserved=0
> >
>
> If you have any other things you'd like to bring up, respond to this mail,
> send me mail privately or add them to the list yourself.
>
> In case you can't attend the meeting, please feel free to make comments on
> the topics by responding to this email or to the summary email sent after
> the meeting. Whenever possible, we'll also respond to existing, related
> email threads.
>
> --
> Samuli Seppänen
> Community Manager
> OpenVPN Technologies, Inc
>
> irc freenode net: mattock
>
>
>
>
>
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> Openvpn-devel mailing list
> Openvpn-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/openvpn-devel
>
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel


Re: [Openvpn-devel] [PATCH v2] travis-ci: cleanup, refactor, upgrade ssl libraries

2018-06-23 Thread Илья Шипицин
Someone who has admin rights, can purge the cache

On Sun, Jun 24, 2018, 8:28 AM Antonio Quartulli  wrote:

> Hi,
>
> On 28/05/18 03:00, Ilya Shipitsin wrote:
> > -- MBEDTLS_VERSION="2.5.1"
> > +- MBEDTLS_VERSION="2.8.0"
>
> I know travis-ci currently is caching both the downloaded tarball and
> the built library, therefore my question: what will happen to
> mbedtls-2.5.1-*? Will that be wiped after some time? Or do we need to
> wipe the cache manually?
>
> Cheers,
>
> --
> Antonio Quartulli
>
>
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel


Re: [Openvpn-devel] tap-windows6 and AppVeyor

2018-06-15 Thread Илья Шипицин
hi,

I have some very amazing expirience with app veyor when I was playing with
mingw builds.
there was an issue related to mingw and I saw it between builds (mingw
upgraded), so I first decided "could it be app veyor ?!"

people from app veyor were very helpful in troubleshooting that.


so, I guess we can try to open an issue in their tracker this time as well.


as for network share - due to "wanna cry" and similar malwares, network
shares are blocked over internet usually.
another option might be to try build services at https://visualstudio.com

пт, 15 июн. 2018 г. в 11:28, Samuli Seppänen :

> Perhaps we could make the ISO available as a network share?
>
> Il 14/06/2018 23:43, Jon Kunkee ha scritto:
> > As I read the license (IANAL), consumers of the EWDK can copy,
> 'install', and run
> > it pretty much anywhere in support of building software for Windows,
> just not
> > as a public download.
> >
> > A 5GB download is prohibitive, but do note that 'unpacking' is as simple
> as
> > mounting the ISO file.
> >
> > -Original Message-
> > From: Simon Rozman 
> > Sent: Thursday, June 14, 2018 10:35 AM
> > To: chipits...@gmail.com; Jon Kunkee 
> > Cc: Samuli Seppänen (sam...@openvpn.net) ;
> openvpn-devel (openvpn-devel@lists.sourceforge.net) <
> openvpn-devel@lists.sourceforge.net>
> > Subject: tap-windows6 and AppVeyor
> >
> > Hi!
> >
> > Given all the recent updates to tap-windows6 building process, the
> AppVeyor
> > integration needs an update too.
> >
> > Now the Microsoft EWDK is used to build the driver, I wasn't able to find
> > any such build environment on AppVeyor.
> >
> > If the EWDK licence allows us, we could put EWDK online and have the
> > AppVeyor download and unpack it before build. Although portable, the
> EWDK is
> > 5GB making this option far from ideal.
> >
> > Or, we could politely ask AppVeyor to introduce an EWDK building
> > environment. :)
> >
> > Does anybody have any idea how to address this challenge?
> >
> > Best regards,
> > Simon
> >
>
>
> --
> Samuli Seppänen
> Community Manager
> OpenVPN Technologies, Inc
>
> irc freenode net: mattock
>
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel


Re: [Openvpn-devel] linking interactive service and openvpn.exe into single binary ?

2018-05-23 Thread Илья Шипицин
2018-05-23 14:06 GMT+05:00 David Sommerseth <
open...@sf.lists.topphemmelig.net>:

> On 23/05/18 10:08, Илья Шипицин wrote:
> > Hello,
> >
> > we observe weird registry corruption, when "exe_path" points to wrong
> location.
> > I came to an idea, why not to link both service and openvpn.exe into
> single
> > openvpn.exe thus removing the need to specify exe_path at all ?
> >
> > thoughts ?
>
> Why not just use dirname() of the openvpn.exe binary path and expect the
> service to stay in the same directory?
>

we agreed with Selva Nair to use dirname() as the last resort when registry
is missing.
(I haven't send patch yet)

however, what I talk about is a different case. "exe_path" exists, but it
points to wrong location.


>
> Linking openvpn.exe and the interactive service is not going to be a
> trivial
> task at all and will mandate two different main() functions which are
> triggered depending on either basename(argv[0]) or some options ... this is
> going to be messy.
>
> Plus this approach can more open up new attack vectors as well, as a single
> binary can do much more work.  Like a buffer overflow in the packet
> processing
> (UDP/TCP or TUN/TAP code paths) triggering execution of interactive service
> functions - this can easily be abused for privilege separation as the
> interactive service runs with elevated privileges while the plain openvpn
> side
> runs unprivileged now.
>
> So no, we should not "link" the interactive service with openvpn.exe.  Even
> though I am no big fan of qmail and the ucspi-tcp package, there are a few
> key
> things to learn from that approach.  Each individual piece in the qmail
> chain
> does a very limited set of tasks and focuses only on that.  So if there's a
> exploit happening in one of the pieces in the chain, the damage is quite
> controlled and limited to the privileges of that individual piece.  It can
> truly be a big hassle and pain to set up such an environment, but it has
> some
> merits regardless.  I do not say we should split up OpenVPN like qmail,
> but we
> should try to keep the footprint privileged code running as small and
> controlled as possible.  Which is why we have interactive service and why
> we're working on a NETLINK integration on Linux.  And OpenVPN 3 on Linux
> takes
> a very different approach to this as well, and there is work in the pipe to
> reduce the privileged footprint even further.
>
>
> --
> kind regards,
>
> David Sommerseth
> OpenVPN Inc
>
>
>
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel


[Openvpn-devel] linking interactive service and openvpn.exe into single binary ?

2018-05-23 Thread Илья Шипицин
Hello,

we observe weird registry corruption, when "exe_path" points to wrong
location.
I came to an idea, why not to link both service and openvpn.exe into single
openvpn.exe thus removing the need to specify exe_path at all ?

thoughts ?

Ilya Shipitsin
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel


[Openvpn-devel] Getting rid of bundled lz4 ?

2018-03-04 Thread Илья Шипицин
Hello,

It was broadcasted several times that we will get rid of bundled lz4
someday.

Currently, windows installer is built using that lib. Does it make sense to
change windows installer?

Cheers,
Ilya Shipitsin
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
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: modify openssl build script to support openssl-1.1.0

2018-02-24 Thread Илья Шипицин
2018-02-25 8:26 GMT+05:00 Selva Nair :

> Hi,
>
> On Tue, Feb 20, 2018 at 8:07 AM, Gert Doering  wrote:
> > Your patch has been applied to the master and release/2.4 branch.
> >
> > commit 437be780996501becb18f0d34c256ab9c9fe27af (master)
> > commit b7aea67aa11b73417eeff595d13b0e2a7b9c925c (release/2.4)
> > Author: Ilya Shipitsin
> > Date:   Mon Jan 15 13:05:55 2018 +0500
> >
> >  travis-ci: modify openssl build script to support openssl-1.1.0
> >
>
> This added openssl 1.1.0 to the build matrix, but only for Linux, it seems.
>
> Can we also have an openssl 1.1.0 based build for windows? Or
> replacing the current ones with 1.1.0 will also do, I suppose.
>


after 2.4.5 we will replace


>
> Thanks,
>
> Selva
>
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel


Re: [Openvpn-devel] challenge/response example ?

2018-02-21 Thread Илья Шипицин
2018-02-22 8:52 GMT+05:00 Selva Nair <selva.n...@gmail.com>:

> Hi,
>
> On Wed, Feb 21, 2018 at 10:18 PM, Илья Шипицин <chipits...@gmail.com>
> wrote:
> >
> >
> > 2018-02-21 22:03 GMT+05:00 Selva Nair <selva.n...@gmail.com>:
> >>
> >> Hi,
> >>
> >> On Tue, Feb 20, 2018 at 10:10 AM, Илья Шипицин <chipits...@gmail.com>
> >> wrote:
> >> > Hello,
> >> >
> >> > is there any step-by-step example of implementing either static or
> >> > dynamic
> >> > challenge response ?
> >>
> >> Static is easy:
> >> On client: add --static-challenge "Enter OTP" 1 to the client config.
> >> On server, merge my auth-pam plugin patch :)
> >
> >
> >
> > if static challenge is handled via pam, so ... there's only true/false ?
> > I mean, is there a way to tell a user "your password is wrong" or
> "password
> > is good, but response is wrong" ?
>
> The usual practice with PAM is not to indicate that the user input is
> partially correct as that leaks information to an attacker.  Of course
> you can set it up in a less secure way. But avoid it unless you have a
> strong reason.
>
> In case of openvpn, anyway there is no easy way[*] to pass back such
> info from server to client, so auth either succeeds or fails.
>

well, what I can say about it

1) definetly we need some examples on challenge/response

2) for example, windows ldap can response with "password is ok, but account
is locked" or "password is ok, but password is expired". we definetly need
some way for that messaging


>
> Selva
>
> [*] Its possible to send back an AUTH_FAIL reason, but currently only
> supported by --management-client-auth (not by auth scripts or plugins)
> and used only to trigger dynamic challenge.
>
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel


Re: [Openvpn-devel] challenge/response example ?

2018-02-21 Thread Илья Шипицин
2018-02-21 22:03 GMT+05:00 Selva Nair <selva.n...@gmail.com>:

> Hi,
>
> On Tue, Feb 20, 2018 at 10:10 AM, Илья Шипицин <chipits...@gmail.com>
> wrote:
> > Hello,
> >
> > is there any step-by-step example of implementing either static or
> dynamic
> > challenge response ?
>
> Static is easy:
> On client: add --static-challenge "Enter OTP" 1 to the client config.
> On server, merge my auth-pam plugin patch :)
> https://patchwork.openvpn.net/patch/212/
> and see the commit message for examples on using the plugin
>
> Dynamic is even easier on the client side, if Windows -- just use
> OpenVPN Windows GUI
> But for server side, the only way I know is to consult the
> management-notes.txt and implement a custom setup using
> management-client-auth.
>

any known example of such an implementation?


>
> Selva
>
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel


[Openvpn-devel] challenge/response example ?

2018-02-21 Thread Илья Шипицин
Hello,

is there any step-by-step example of implementing either static or dynamic
challenge response ?

Cheers,
Ilya Shipitsin
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel


Re: [Openvpn-devel] [Openvpn-users] "Reconnect" button in openvpn-gui

2018-02-08 Thread Илья Шипицин
2018-02-08 20:40 GMT+05:00 Selva Nair <selva.n...@gmail.com>:

> Hi,
>
> On Thu, Feb 8, 2018 at 3:15 AM, Samuli Seppänen <sam...@openvpn.net>
> wrote:
> > Il 07/02/2018 21:58, David Sommerseth ha scritto:
> >> On 07/02/18 20:32, Илья Шипицин wrote:
> >>> After auth-token were introduced, when user press "Reconnect", it
> leads to
> >>> auth fail (saved password is forgotten), we run about 1000 users,
> nobody
> >>> complains.
> >>
> >> This is actually expected, I'd say - but smells like a bug on the
> server side
> >> authentication.
> >>
> >> Selva may correct me if I'm wrong, but my understanding of it when
> clicking
> >> "Reconnect", the local OpenVPN process which caches the auth-token is
> stopped
> >> and a new OpenVPN process is started.  The client should in this case
> ask for
> >> username/password again.  So in this case, the server side should treat
> this
> >> connection as a fresh connection with no initial state.
> >>
> >> The step of stopping the local client and starting a new and fresh one
> is
> >> definitely not a bad feature to have on clients.
> >>
> >>> It looks like nobody uses that button.
> >>>
> >>> So, I asked several users, they confirmed they do not use Reconnect.
> >>
> >> This is no good argument for me.  This is one specific setup with 1000
> users.
> >> It would be more valuable with 50 different setups having 20 users
> each.  Your
> >> conclusion is based on a very homogeneous environment.
> >
> > I agree. I also agree that the underlying problem should be fixed.
> >
> > That said, Ilya's message was sent to both openvpn-users and
> > openvpn-devel and nobody has screamed "do not remove the Reconnect
> > button" :). The only additional thing we can do is post a message to the
> > forums. As usual, the only sure way to get feedback (read: complaints)
> > is to release the changes in an official build/installer.
>
> Only recently we added a reconnect item to the menu (earlier it was
> only available as a button in the status window) for ease of doing
> reconnects and based on user requests -- though I can't now find who
> asked for it.
>

it is interesting.


>
> I wouldn't take lack of response on the user's list as an indication
> that no one uses it. In fact its very handy -- how else will you
> restart a connection after editing the config file? Disconnect and
> connect again? That would close the status window and lose all
>

yes. disconnect and connect again.



> messages in it and also takes a number of mouse clicks because of the
> way tray popup menu behaves.
>
> Anyway the purported reason to remove it is totally bogus. Its like
> auth-token cant cope with SIGHUP, so let's remove that signal.
>

no, that is wrong interpretaion.
I actually meant

"it is broken" --> "users do not complain" --> "users do not care" -->
"other buttons will keep their places" --> "let us remove unused button"


>
> Finally, I'm an user too and I use that button all the time, though
> mostly for testing. If that counts as a dissenting voice.
>


yes, I also meant that. it is "designed by developers for themselves" :)
same as "edit config" menu item.
developers need edit config all the time and reconnect. but do users do
same things as well ?


as for "edit config", I'd like to keep it. it's removal will change menu
order, people will click at wrong items.


>
> Selva
>
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel


Re: [Openvpn-devel] [Openvpn-users] "Reconnect" button in openvpn-gui

2018-02-07 Thread Илья Шипицин
2018-02-08 1:43 GMT+05:00 Selva Nair <selva.n...@gmail.com>:

> Hi,
>
> On Wed, Feb 7, 2018 at 3:30 PM, Илья Шипицин <chipits...@gmail.com> wrote:
> >
> >
> > 2018-02-08 1:21 GMT+05:00 Selva Nair <selva.n...@gmail.com>:
> >>
> >> Hi,
> >>
> >> On Wed, Feb 7, 2018 at 2:58 PM, David Sommerseth
> >> <open...@sf.lists.topphemmelig.net> wrote:
> >> > On 07/02/18 20:32, Илья Шипицин wrote:
> >> >> After auth-token were introduced, when user press "Reconnect", it
> leads
> >> >> to
> >> >> auth fail (saved password is forgotten), we run about 1000 users,
> >> >> nobody
> >> >> complains.
> >> >
> >> > This is actually expected, I'd say - but smells like a bug on the
> server
> >> > side
> >> > authentication.
> >> >
> >> > Selva may correct me if I'm wrong, but my understanding of it when
> >> > clicking
> >> > "Reconnect", the local OpenVPN process which caches the auth-token is
> >> > stopped
> >> > and a new OpenVPN process is started.  The client should in this case
> >> > ask for
> >> > username/password again.  So in this case, the server side should
> treat
> >> > this
> >> > connection as a fresh connection with no initial state.
> >>
> >> GUI's reconnect button is wired to send a SIGHUP to the client openvpn
> >> process. The problem is that if auth-token is in use, the client
> >> openvpn.exe does not forget it it when restarting the connection by
> >> SIGHUP or SIGUSR1 -- I think it should but it doesn't. That leads to
> >> an AUTH_FAILED from server. The GUI has hard time distinguishing
> >> between reasons for AUTH_FAILED, so it just assumes that password
> >> verification failed and clears the saved password and prompts for a
> >> new one. Obviously users are not happy.
> >
> >
> > users don't care :)
> >
> > if they we ever unhappy, we should fix it.
> >
> > currently, I'm open to ideas how to perform a (proper) investigation in
> > order to actually remove "Reconnect" button
>
> I do not understand why you keep harping about removing the reconnect
> button.
>
> If you are angry with auth-token do not take it out on the wrong
> victim. Its not reconnect button's fault. In fact if your users do not
> use it, why bother?
>


those victims are not mutually exclusive.

I noticed that nobody cares of broken behaviour of "REconnect" button. So,
I suggest to remove it (as a user, I cannot imagine when
I would press it ... probably something like "change IP address on
reconnect", like I do with Tor)

Also, I think that auth-token should be handled in better way.


>
> Selva
>
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel


Re: [Openvpn-devel] [Openvpn-users] "Reconnect" button in openvpn-gui

2018-02-07 Thread Илья Шипицин
2018-02-08 1:21 GMT+05:00 Selva Nair <selva.n...@gmail.com>:

> Hi,
>
> On Wed, Feb 7, 2018 at 2:58 PM, David Sommerseth
> <open...@sf.lists.topphemmelig.net> wrote:
> > On 07/02/18 20:32, Илья Шипицин wrote:
> >> After auth-token were introduced, when user press "Reconnect", it leads
> to
> >> auth fail (saved password is forgotten), we run about 1000 users, nobody
> >> complains.
> >
> > This is actually expected, I'd say - but smells like a bug on the server
> side
> > authentication.
> >
> > Selva may correct me if I'm wrong, but my understanding of it when
> clicking
> > "Reconnect", the local OpenVPN process which caches the auth-token is
> stopped
> > and a new OpenVPN process is started.  The client should in this case
> ask for
> > username/password again.  So in this case, the server side should treat
> this
> > connection as a fresh connection with no initial state.
>
> GUI's reconnect button is wired to send a SIGHUP to the client openvpn
> process. The problem is that if auth-token is in use, the client
> openvpn.exe does not forget it it when restarting the connection by
> SIGHUP or SIGUSR1 -- I think it should but it doesn't. That leads to
> an AUTH_FAILED from server. The GUI has hard time distinguishing
> between reasons for AUTH_FAILED, so it just assumes that password
> verification failed and clears the saved password and prompts for a
> new one. Obviously users are not happy.
>

users don't care :)

if they we ever unhappy, we should fix it.

currently, I'm open to ideas how to perform a (proper) investigation in
order to actually remove "Reconnect" button


>
> In my view auth-token handling in openvpn.exe is broken at multiple levels:
>
> Client process:
> (i) it should not remember the token after a reconnect is issued
> (ii) it should not remember the auth-token when auth-nocache is in
> effect --- without that there is no way for the GUI to take over
> handling auth-token. In my view auth-nocache is the only way
> openvpn.exe can stand aside and let the GUI take over all password
> handling. Unless we introduce a --management-auth-token flag. Else
> what's the use of sending the token to the management interface?
> In other words if a user wants auth-token and no GUI, they should not
> use auth-nocache, GUI users should use it if they want the GUI to
> control all password requests. No need to bend over backwards to
> support auth-nocache with auth-token as we now do.
>
> Server process
> (iii) --gen-auth-token with an expiry just doesn't work -- we need to
> have a mechanism for the server to tell the client that the token has
> expired.
>
> >> It looks like nobody uses that button.
> >>
> >> So, I asked several users, they confirmed they do not use Reconnect.
> >This is no good argument for me.  This is one specific setup with 1000
> users.
> >It would be more valuable with 50 different setups having 20 users each.
> Your
> >conclusion is based on a very homogeneous environment.
>
> Indeed. Actually I use that button frequently.
>
> >> After auth-token were introduced, when user press "Reconnect", it leads
> to
> >> auth fail (saved password is forgotten),
>
> That reads as if introduction of auth-token broke reconnect. It did
> not. Only those users who have 2-factor turned on and use
> --gen-auth-token on the server are affected.
>
> Selva
>
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel


Re: [Openvpn-devel] "Reconnect" button in openvpn-gui

2018-02-07 Thread Илья Шипицин
After auth-token were introduced, when user press "Reconnect", it leads to
auth fail (saved password is forgotten), we run about 1000 users, nobody
complains.

It looks like nobody uses that button.

So, I asked several users, they confirmed they do not use Reconnect.

On Feb 8, 2018 12:07 AM, "Selva Nair" <selva.n...@gmail.com> wrote:

> Hi,
>
> On Wed, Feb 7, 2018 at 1:47 AM, Илья Шипицин <chipits...@gmail.com> wrote:
> > Hi,
> >
> > based on our UX investigation, I think we can remove "Reconnect" button
> for
> > good.
>
> I also would like to know how and why you came to that conclusion.
>
> Thanks,
>
> Selva
>
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel


[Openvpn-devel] "Reconnect" button in openvpn-gui

2018-02-06 Thread Илья Шипицин
Hi,

based on our UX investigation, I think we can remove "Reconnect" button for
good.

any reason to keep it ?


Cheers,
Ilya Shipitsin
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel


Re: [Openvpn-devel] [Openvpn-users] test latest binary on vista

2018-01-30 Thread Илья Шипицин
2018-01-30 14:33 GMT+05:00 Samuli Seppänen :

> Hi,
>
> Il 29/01/2018 20:09, Selva Nair ha scritto:
> > (Cross posting to users and devel)
> >
> > Hi,
> >
> > 2.4.x needs to support, Vista, isn't it?
>
> Good question and we have discussed in the past. Windows Vista is no
> longer supported by Microsoft:
>
>  lifecycle-fact-sheet>
>
> But then again, we do provide installers which work on Windows XP, which
> is similarly EOL. So I guess we do support Windows Vista for the time
> being.
>
> >
> > Can anyone please latest 2.4 release branch on Windows Vista using an
> > RSA certificate in Windows cert store (using --cryptoapicert option) ?
> >
> > Need to be built with openssl 1.1. Not sure the snapshots are built that
> way..
> > https://build.openvpn.net/downloads/snapshots/
>
> Not yet. I will switch snapshot builds to OpenSSL 1.1 once
> openvpn-build's openvpn.nsi stops failing on OpenSSL 1.1 libraries
> (names have changed). A PR is pending but it still needs one minor fix.
>


snapshot builds are different from release builds (they do not support lzo,
for example)
I was going to unify snapshot/release builds. Hope to do that soon

but UI is the same :)


>
> > The recent changes to cryptoapi uses CNG api which is supposedly
> > supported on Vista but some testing would be useful. I no longer have
> > access to a Vista machine.
> >
> > Thanks,
> >
> > Selva
> >
>
>
>
> --
> Samuli Seppänen
> Community Manager
> OpenVPN Technologies, Inc
>
> irc freenode net: mattock
>
> 
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> Openvpn-devel mailing list
> Openvpn-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/openvpn-devel
>
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel


Re: [Openvpn-devel] On testing with openssl 0.9.8

2018-01-20 Thread Илья Шипицин
it might depend on why do we want support openssl-0.9.8

vanilla openssl is different from redhat, I mean

which one do we want ?

2018-01-20 22:22 GMT+05:00 Selva Nair :

> Hi,
>
> Does openvpn-vagrant include any VM provisioning with openssl-0.9.8?
> Until recently I had access to a few old debian boxes but now all
> updated and 0.9.8 testing is getting harder.
>
> Selva
>
> 
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> Openvpn-devel mailing list
> Openvpn-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/openvpn-devel
>
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel


Re: [Openvpn-devel] consider exe_path optional ?

2018-01-18 Thread Илья Шипицин
what if we determine GetModuleFileNameW of openvpnserv.exe ... and consider
it as a "trusted" (instead of
taking installation path from registry)?

if windows service is running, it means it was installed with trusted way
(which is relatively hard to break)

2018-01-18 22:11 GMT+05:00 Selva Nair <selva.n...@gmail.com>:

>
> On Thu, Jan 18, 2018 at 3:49 AM, Илья Шипицин <chipits...@gmail.com>
> wrote:
>
>> Hello,
>>
>> changes https://github.com/OpenVPN/openvpn-gui/pull/197 actually make
>> openvpn-gui less dependent on registry
>>
>>
>> we sometimes see similar issue with interactive service:
>>
>> openvpnserv error: Не удается найти указанный файл. (0x2) Error querying
>> registry value: HKLM\SOFTWARE\OpenVPN\exe_path
>>
>> (I've no idea why "exe_path" was deleted)
>>
>> @selvanair , what do you think if we'll try to guess exe_path by picking
>> directory from where openvpnserv was started ? (it is a good guess to
>> assume openvpn.exe is in the same directory)
>>
>
> Patch 86 (https://patchwork.openvpn.net/patch/86/) does this. The only
> registry key that will be required would be HKLM\Software\OpenVPN whose
> default value should point to the installation directory.
>
> One of the security features of the service is that it starts only
> "authorized" openvpn.exe executables -- so we need to have at least the
> installed location set by the admin. Then we can safely guess the rest of
> the parameters if not explicitly set. Eliminating all registry dependence
> wouldn't be safe for the service.
>
> That wouldn't fix issues faced by users who delete registry keys or use
> non-standard installation methods. Generally those are power users who can
> fix things on their own. If not, just ask them to re-install openvpn.
>
> Selva
>
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel


Re: [Openvpn-devel] consider exe_path optional ?

2018-01-18 Thread Илья Шипицин
2018-01-18 22:11 GMT+05:00 Selva Nair <selva.n...@gmail.com>:

>
> On Thu, Jan 18, 2018 at 3:49 AM, Илья Шипицин <chipits...@gmail.com>
> wrote:
>
>> Hello,
>>
>> changes https://github.com/OpenVPN/openvpn-gui/pull/197 actually make
>> openvpn-gui less dependent on registry
>>
>>
>> we sometimes see similar issue with interactive service:
>>
>> openvpnserv error: Не удается найти указанный файл. (0x2) Error querying
>> registry value: HKLM\SOFTWARE\OpenVPN\exe_path
>>
>> (I've no idea why "exe_path" was deleted)
>>
>> @selvanair , what do you think if we'll try to guess exe_path by picking
>> directory from where openvpnserv was started ? (it is a good guess to
>> assume openvpn.exe is in the same directory)
>>
>
> Patch 86 (https://patchwork.openvpn.net/patch/86/) does this. The only
> registry key that will be required would be HKLM\Software\OpenVPN whose
> default value should point to the installation directory.
>
> One of the security features of the service is that it starts only
> "authorized" openvpn.exe executables -- so we need to have at least the
> installed location set by the admin. Then we can safely guess the rest of
> the parameters if not explicitly set. Eliminating all registry dependence
> wouldn't be safe for the service.
>

I do not think that speciying a path is somewhat related to security (for
example, I can put a malware named "openvpn.exe" in that path).


However, patch is very good, why is it still not applied ?


>
> That wouldn't fix issues faced by users who delete registry keys or use
> non-standard installation methods. Generally those are power users who can
> fix things on their own. If not, just ask them to re-install openvpn.
>

as those users say, they do not delete anything. it happens after "install
windows updates" + "reboot"
(there was an earlier case with running ccleaner, which wipes registry in
random way)


>
> Selva
>
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel


[Openvpn-devel] consider exe_path optional ?

2018-01-18 Thread Илья Шипицин
Hello,

changes https://github.com/OpenVPN/openvpn-gui/pull/197 actually make
openvpn-gui less dependent on registry


we sometimes see similar issue with interactive service:

openvpnserv error: Не удается найти указанный файл. (0x2) Error querying
registry value: HKLM\SOFTWARE\OpenVPN\exe_path

(I've no idea why "exe_path" was deleted)

@selvanair , what do you think if we'll try to guess exe_path by picking
directory from where openvpnserv was started ? (it is a good guess to
assume openvpn.exe is in the same directory)

Cheers,
Ilya Shipitsin
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel


Re: [Openvpn-devel] travis builds

2018-01-16 Thread Илья Шипицин
it started to happen after travis-ci image was updated to clang-5.0,
somehow it does not work well with ccache (that's why we removed ccache
recently)

2018-01-15 22:28 GMT+05:00 Selva Nair :

> Hi,
>
> Out of the 12 or so jobs we have in the travis build matrix a few
> sometime fail with "write error" (happened a number of times for some
> local feature branches). On restarting only the failed jobs, one by
> one, they succeed indicating possible resource starvation?
>
> Is there anything one can do to avoid this?
>
> Thanks,
>
> Selva
>
> 
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> Openvpn-devel mailing list
> Openvpn-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/openvpn-devel
>
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel


Re: [Openvpn-devel] [PATCH] travis-ci: modify openssl build script to support openssl-1.1.0

2018-01-15 Thread Илья Шипицин
I've built an installer without "no-multilib" and tested on both x86 and
x64.

2018-01-14 23:33 GMT+05:00 Илья Шипицин <chipits...@gmail.com>:

>
>
> 2018-01-14 21:05 GMT+05:00 Steffan Karger <stef...@karger.me>:
>
>> Hi,
>>
>> On 14-01-18 15:06, Ilya Shipitsin wrote:
>> > no-multilib is only supported on openssl-1.0.X, do not use it
>> > if OPENSSL_VERSION is 1.1.0
>> >
>> > Signed-off-by: Ilya Shipitsin <chipits...@gmail.com>
>> > ---
>> >  .travis/build-deps.sh | 5 +++--
>> >  1 file changed, 3 insertions(+), 2 deletions(-)
>> >
>> > diff --git a/.travis/build-deps.sh b/.travis/build-deps.sh
>> > index bc538853..1761932e 100755
>> > --- a/.travis/build-deps.sh
>> > +++ b/.travis/build-deps.sh
>> > @@ -110,8 +110,9 @@ build_openssl_mingw () {
>> >  export TARGET=mingw64
>> >  fi
>> >
>> > -./Configure --cross-compile-prefix=${CHOST}- shared \
>> > -   ${TARGET} no-multilib no-capieng --prefix="${PREFIX}"
>> --openssldir="${PREFIX}" -static-libgcc
>> > +./Configure --cross-compile-prefix=${CHOST}- shared ${TARGET}
>> \
>> > +   $([[ ${OPENSSL_VERSION} == "1.0."* ]] && echo
>> "no-multilib") \
>> > +   no-capieng --prefix="${PREFIX}" --openssldir="${PREFIX}"
>> -static-libgcc
>> >  make install
>> >  )
>> >  }
>> >
>>
>> Do we need no-multilib for 1.0.x builds?  If not, I'd prefer to just get
>> rid of it.
>>
>
> it came from windows installer.
> let me build windows installer without no-multilib and test
>
>
>
>>
>> -Steffan
>>
>> 
>> --
>> Check out the vibrant tech community on one of the world's most
>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>> ___
>> Openvpn-devel mailing list
>> Openvpn-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/openvpn-devel
>>
>
>
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel


Re: [Openvpn-devel] [PATCH] travis-ci: modify openssl build script to support openssl-1.1.0

2018-01-14 Thread Илья Шипицин
2018-01-14 21:05 GMT+05:00 Steffan Karger :

> Hi,
>
> On 14-01-18 15:06, Ilya Shipitsin wrote:
> > no-multilib is only supported on openssl-1.0.X, do not use it
> > if OPENSSL_VERSION is 1.1.0
> >
> > Signed-off-by: Ilya Shipitsin 
> > ---
> >  .travis/build-deps.sh | 5 +++--
> >  1 file changed, 3 insertions(+), 2 deletions(-)
> >
> > diff --git a/.travis/build-deps.sh b/.travis/build-deps.sh
> > index bc538853..1761932e 100755
> > --- a/.travis/build-deps.sh
> > +++ b/.travis/build-deps.sh
> > @@ -110,8 +110,9 @@ build_openssl_mingw () {
> >  export TARGET=mingw64
> >  fi
> >
> > -./Configure --cross-compile-prefix=${CHOST}- shared \
> > -   ${TARGET} no-multilib no-capieng --prefix="${PREFIX}"
> --openssldir="${PREFIX}" -static-libgcc
> > +./Configure --cross-compile-prefix=${CHOST}- shared ${TARGET} \
> > +   $([[ ${OPENSSL_VERSION} == "1.0."* ]] && echo "no-multilib")
> \
> > +   no-capieng --prefix="${PREFIX}" --openssldir="${PREFIX}"
> -static-libgcc
> >  make install
> >  )
> >  }
> >
>
> Do we need no-multilib for 1.0.x builds?  If not, I'd prefer to just get
> rid of it.
>

it came from windows installer.
let me build windows installer without no-multilib and test



>
> -Steffan
>
> 
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> Openvpn-devel mailing list
> Openvpn-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/openvpn-devel
>
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel


Re: [Openvpn-devel] [PATCH 0/2] Make cryptoapicert work with TLS 1.2

2018-01-08 Thread Илья Шипицин
2018-01-08 7:21 GMT+05:00 :

> From: Selva Nair 
>
> Hi,
>
> I am not sure how receptive the crypto maintaineres are to the
> idea of adding more code into cryptoapi.c, but here goes:
>
> I've been wanting to add TLS 1.2 support for certs in the
> Windows cert store using management external key. But that's
> a lot more work than extending cryptoapicert support. And,
> rather surprsingly, it turns out that the CNG API for signing is
> easy to use (well after some groping in the dark..) and doesn't
> take much to implement.
>
> So these patches..
>
> The first patch is not really related and to make the existing code
> "openssl-1.1 ready" (missed by past patches as no one probably builds
> Windows binary with 1.1..).
>

there was an agreement on one of the recent community meetings to
gracefully deprecate both libressl and openssl-1.0.X in favour of
openssl-1.1.X

so, we should learn how to build windows binary with 1.1.X :)




>
> The second patch is not dependent on this, but close-by code paths
> are touched by both.
>
> Selva
>
> Selva Nair (2):
>   Bring cryptoapi.c upto speed with openssl 1.1
>   TLS v1.2 support for cryptoapicert -- RSA only
>
>  configure.ac |   1 +
>  src/openvpn/Makefile.am  |   2 +-
>  src/openvpn/cryptoapi.c  | 155 ++
> -
>  src/openvpn/openssl_compat.h |  14 
>  src/openvpn/options.c|  18 -
>  5 files changed, 140 insertions(+), 50 deletions(-)
>
> --
> 2.1.4
>
>
> 
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> Openvpn-devel mailing list
> Openvpn-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/openvpn-devel
>
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
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 brew cache, remove ccache

2018-01-04 Thread Илья Шипицин
2018-01-05 3:23 GMT+05:00 Antonio Quartulli :

>
>
> On 05/01/18 03:37, Ilya Shipitsin wrote:
> > 1-2 minutes speedup osx builds by using brew cache.
> > Also, ccache was removed for a while (builds fail
> > after travis-ci upgraded clang to version 5.0.0)
> > ---
> > v2: this is a "v2" of previously issued "enable ccache for osx and mingw
> builds"
> > patch. I decided not to enable ccache for mingw builds as it does not
> > speedup them
> >
> > v3: removed ccache at all, because it fails on clang-5.0.0
>
> Does this patch make "[PATCH] travis-ci: speedup osx build by enabling
> brew cache​" obsolete?
>

yes


>
>
> Regards,
>
>
> --
> Antonio Quartulli
>
>
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel


Re: [Openvpn-devel] [PATCH] travis-ci: speedup osx build by enabling brew cache

2018-01-04 Thread Илья Шипицин
wait a bit,

we might need to remove ccache (it became broken after travis-ci upgraded
to clang-5)

https://travis-ci.org/chipitsine/openvpn/jobs/325002858

2018-01-04 17:19 GMT+05:00 Ilya Shipitsin :

> 1-2 minutes speedup by using brew cache, also ccache
> is no more disabled for osx build (even it does not
> speedup significantly, it simplifies the overall script)
>
> ---
> this is a "v2" of previously issued "enable ccache for osx and mingw
> builds"
> patch. I decided not to enable ccache for mingw builds as it does not
> speedup them
>
>  .travis.yml   | 5 +++--
>  .travis/build-deps.sh | 7 ++-
>  2 files changed, 5 insertions(+), 7 deletions(-)
>
> diff --git a/.travis.yml b/.travis.yml
> index 1f669b30..34e0ac04 100644
> --- a/.travis.yml
> +++ b/.travis.yml
> @@ -82,10 +82,11 @@ cache:
>directories:
>- download-cache
>- ${HOME}/opt
> +  - ${HOME}/Library/Caches/Homebrew
>
>  before_install:
> -  - if [ "${TRAVIS_OS_NAME}" = "osx" ]; then brew update ; fi
> -  - if [ "${TRAVIS_OS_NAME}" = "osx" ]; then brew install lzo; fi
> +  - if [ "${TRAVIS_OS_NAME}" = "osx" ]; then brew update; fi
> +  - if [ "${TRAVIS_OS_NAME}" = "osx" ]; then brew install lzo ccache; fi
>
>  install:
>- if [ ! -z "${CHOST}" ]; then unset CC; fi
> diff --git a/.travis/build-deps.sh b/.travis/build-deps.sh
> index e787abab..e7036b6b 100755
> --- a/.travis/build-deps.sh
> +++ b/.travis/build-deps.sh
> @@ -130,11 +130,8 @@ build_openssl () {
>  fi
>  }
>
> -# Enable ccache
> -if [ "${TRAVIS_OS_NAME}" != "osx" ] && [ -z ${CHOST+x} ]; then
> -# ccache not available on osx, see:
> -# https://github.com/travis-ci/travis-ci/issues/5567
> -# also ccache not enabled for cross builds
> +# Enable ccache except cross builds
> +if [ -z ${CHOST+x} ]; then
>  mkdir -p "${HOME}/bin"
>  ln -s "$(which ccache)" "${HOME}/bin/${CC}"
>  PATH="${HOME}/bin:${PATH}"
> --
> 2.14.3
>
>
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel


Re: [Openvpn-devel] [PATCH] Return NULL if GetAdaptersInfo fails

2018-01-03 Thread Илья Шипицин
is it related to trac#973 ?

2018-01-03 9:02 GMT+05:00 :

> From: Selva Nair 
>
> - Currently a pointer to potentially uninitialized IP_ADAPTER_INFO
>   struct is returned on error causing ill-defined behaviour.
>
> Signed-off-by: Selva Nair 
> ---
>
> There have been some reports of unexpected failure in GetAdaptersInfo.
> When and why that happens is still unclear but this bug could explain
> why the process goes into a tailspin in such occasions.
>
>  src/openvpn/tun.c | 7 ++-
>  1 file changed, 2 insertions(+), 5 deletions(-)
>
> diff --git a/src/openvpn/tun.c b/src/openvpn/tun.c
> index 25831ce..6e16348 100644
> --- a/src/openvpn/tun.c
> +++ b/src/openvpn/tun.c
> @@ -4178,15 +4178,12 @@ get_adapter_info_list(struct gc_arena *gc)
>  else
>  {
>  pi = (PIP_ADAPTER_INFO) gc_malloc(size, false, gc);
> -if ((status = GetAdaptersInfo(pi, )) == NO_ERROR)
> -{
> -return pi;
> -}
> -else
> +if ((status = GetAdaptersInfo(pi, )) != NO_ERROR)
>  {
>  msg(M_INFO, "GetAdaptersInfo #2 failed (status=%u) : %s",
>  (unsigned int)status,
>  strerror_win32(status, gc));
> +pi = NULL;
>  }
>  }
>  return pi;
> --
> 2.1.4
>
>
> 
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> Openvpn-devel mailing list
> Openvpn-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/openvpn-devel
>
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel


Re: [Openvpn-devel] better handling of revoked certs

2018-01-01 Thread Илья Шипицин
2018-01-01 17:56 GMT+05:00 Antonio Quartulli :

> Hi,
>
> On 01/01/18 20:30, Steffan Karger wrote:
>
> [CUT]
>
> >
> > Note the '5 seconds' reconnect loop, which is the same as what current
> > released openvpn would do in response to an alert.  So if we change our
> > servers to send alerts, they will experience quite a bit more load from
> > clients attempting to reconnect.  We can make newer clients use some
> > exponential back-off, but older clients will be around for quite a while.
> >
>
> If we really go this way, we could even have the client "understand" the
> alert and stop retrying if the error is permanent (i.e. certificate
> revoked).
>
>
> However, are we sure we're not going to introduce surface for a DoS
> attacks by opening this hole for unauthorized clients?
>

what kind of DoS attacks are you talking about ?



> Basically anybody with a revoked certificate is now able to trigger some
> kind of logic on the server side (this is how I understand it).
>
> Consider that obtaining a revoked certificate is not that difficult
> (i.e. VPN providers granting free periods normally do that by issuing
> and revoking a new cert).
>
>
>
> Cheers,
>
>
> --
> Antonio Quartulli
>
>
> 
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> Openvpn-devel mailing list
> Openvpn-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/openvpn-devel
>
>
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel


Re: [Openvpn-devel] [PATCH] travis-ci: enable ccache for osx and mingw builds

2017-12-30 Thread Илья Шипицин
2017-12-30 16:19 GMT+05:00 Steffan Karger :

> Hi,
>
> Sorry for taking so long to respond.
>
> On 21-11-17 07:36, Ilya Shipitsin wrote:
> > --
> > ccache was now tested by me and works for osx
> > and mingw builds as well
>
> By how much does this improve build times?  I'm asking, because I
>

I noticed 1-2 minutes speedup on osx builds. however, it might be
due to brew slowness


> recently noticed that brew on the osx slaves takes a serious amount of
> time.  So I was wondering if we shouldn't try to avoid any brew
> operations for the osx builds.
>

I will add brew to travis-ci cache in "v2"

ccache itself seem to add about zero speedup (and definetly no speedup on
mingw builds)


>
> > ---
> >  .travis.yml   |  2 +-
> >  .travis/build-deps.sh | 14 ++
> >  2 files changed, 7 insertions(+), 9 deletions(-)
> >
> > diff --git a/.travis.yml b/.travis.yml
> > index 366e6599..8efb1cbd 100644
> > --- a/.travis.yml
> > +++ b/.travis.yml
> > @@ -88,7 +88,7 @@ cache:
> >
> >  before_install:
> >- if [ "${TRAVIS_OS_NAME}" = "osx" ]; then brew update ; fi
> > -  - if [ "${TRAVIS_OS_NAME}" = "osx" ]; then brew install lzo; fi
> > +  - if [ "${TRAVIS_OS_NAME}" = "osx" ]; then brew install lzo ccache; fi
>
> Before adding ccache here, we could reduce the build time by three
> minutes using --disable-lzo.
>
> >
> >  install:
> >- if [ ! -z "${CHOST}" ]; then unset CC; fi
> > diff --git a/.travis/build-deps.sh b/.travis/build-deps.sh
> > index e787abab..001565f3 100755
> > --- a/.travis/build-deps.sh
> > +++ b/.travis/build-deps.sh
> > @@ -130,15 +130,13 @@ build_openssl () {
> >  fi
> >  }
> >
> > -# Enable ccache
> > -if [ "${TRAVIS_OS_NAME}" != "osx" ] && [ -z ${CHOST+x} ]; then
> > -# ccache not available on osx, see:
> > -# https://github.com/travis-ci/travis-ci/issues/5567
> > -# also ccache not enabled for cross builds
> > -mkdir -p "${HOME}/bin"
> > -ln -s "$(which ccache)" "${HOME}/bin/${CC}"
> > -PATH="${HOME}/bin:${PATH}"
> > +mkdir -p "${HOME}/bin"
> > +if [ -z ${CHOST+x} ]; then
> > +ln -s "$(which ccache)" "${HOME}/bin/${CC}"
> > +else
> > +ln -s "$(which ccache)" "${HOME}/bin/${CHOST}-cc"
> >  fi
> > +PATH="${HOME}/bin:${PATH}"
> >
> >  if [ ! -z ${CHOST+x} ]; then
> >#
> >
>
> Code-wise the patch looks good.  But curious about your thought on the
> above.
>
> -Steffan
>
> 
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> Openvpn-devel mailing list
> Openvpn-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/openvpn-devel
>
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel


Re: [Openvpn-devel] --with-mem-check, what to do with it?

2017-12-29 Thread Илья Шипицин
2017-12-29 16:02 GMT+05:00 Antonio Quartulli <a...@unstable.cc>:

> Hi,
>
> On 29/12/17 18:23, Steffan Karger wrote:
> > Hi,
> >
> > On 29-12-17 11:11, Илья Шипицин wrote:
> >> thank for the patch.
> >>
> >> not directly related to the patch itself, but openvpn is shipped with
> >> several memory debugging options
> >>
> >> --with-mem-check=TYPE   build with debug memory checking
> >>
> >>
> >> should we get rid of them (in favour of sanitizers) ? or, maybe add to
> >> tests instead ?
> >
> > I've tried to use those in the past, but found them hard to use.  I
> > think they're a remnant of the past.  I would personally prefer to get
> > rid of them and use the (nowadays much better) fully external memory
> > checking tools instead (sanitizers, valgrind, etc).
>
> As Selva pointed out, we don't use --with-mem-check in any test,
> therefore I am not even sure it still works as expected.
>
> I am also in favour in of getting rid of our custom made check and use
> compilers provided sanitizers instead (also gcc provides interesting
> sanitizers, thus everybody should be bale to enable them).
>

I played with those sanitizers, they are nice. But memory sanitizers are
noisy on openssl.
seem to need some work (either resolving issues on openssl side or muting
them)


>
> Cheers,
>
> --
> Antonio Quartulli
>
>
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel


Re: [Openvpn-devel] [PATCH] travis: use clang's -fsanitize=address to catch more bugs

2017-12-29 Thread Илья Шипицин
thank for the patch.

not directly related to the patch itself, but openvpn is shipped with
several memory debugging options

--with-mem-check=TYPE   build with debug memory checking


should we get rid of them (in favour of sanitizers) ? or, maybe add to
tests instead ?

2017-12-29 14:47 GMT+05:00 Steffan Karger :

> The clang address sanitizer is able to catch quite a number of
> memory-related bugs, such add memory leaks and buffer under/overruns.
> So, enable the address sanitizer for one openssl and one mbedtls build.
>
> This would have caught the buffer list unittest memory leak that
> <1512724338-22197-1-git-send-email-stef...@karger.me> wants to fix.
>
> Signed-off-by: Steffan Karger 
> ---
>  .travis.yml | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/.travis.yml b/.travis.yml
> index 1f669b3..99cd5e2 100644
> --- a/.travis.yml
> +++ b/.travis.yml
> @@ -33,7 +33,7 @@ matrix:
>  - env: SSLLIB="openssl" OPENSSL_VERSION="1.1.0f"
>os: linux
>compiler: gcc
> -- env: SSLLIB="openssl"
> +- env: SSLLIB="openssl" CFLAGS="-fsanitize=address"
>os: linux
>compiler: clang
>  - env: SSLLIB="openssl" OPENSSL_VERSION="1.1.0f"
> @@ -42,7 +42,7 @@ matrix:
>  - env: SSLLIB="mbedtls"
>os: linux
>compiler: gcc
> -- env: SSLLIB="mbedtls"
> +- env: SSLLIB="mbedtls" CFLAGS="-fsanitize=address"
>os: linux
>compiler: clang
>  - env: SSLLIB="openssl"
> --
> 2.7.4
>
>
> 
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> Openvpn-devel mailing list
> Openvpn-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/openvpn-devel
>
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel


Re: [Openvpn-devel] [PATCH v2] Use lowest metric interface when multiple interfaces match a route

2017-12-06 Thread Илья Шипицин
2017-11-06 6:14 GMT+05:00 :

> From: Selva Nair 
>
> Currently a route addition using IPAPI or service is skipped if the
> route gateway is reachable by multiple interfaces. This changes that
> to use the interface with lowest metric. Implemented by
>
> (i)  Do not over-write the return value with TUN_ADAPTER_INDEX_INVALID in
>  windows_route_find_if_index() if multiple interfaces match a route.
> (ii) Select the interface with lowest metric in adapter_index_of_ip()
>  instead of the first one found when multiple interfaces match.
>
> Reported by Jan Just Keijser 
>
> v2: - A private get_interface_metric() method and better error reporting
> - Revert an unintented edit of route.c (a_index = ...)
> - Improve the commit message
>
> Signed-off-by: Selva Nair 
> ---
>  src/openvpn/route.c |  1 -
>  src/openvpn/tun.c   | 59 ++
> +--
>  2 files changed, 57 insertions(+), 3 deletions(-)
>
> diff --git a/src/openvpn/route.c b/src/openvpn/route.c
> index 8c71e6e..66a8ae3 100644
> --- a/src/openvpn/route.c
> +++ b/src/openvpn/route.c
> @@ -2780,7 +2780,6 @@ windows_route_find_if_index(const struct route_ipv4
> *r, const struct tuntap *tt)
>  msg(M_WARN, "Warning: route gateway is ambiguous: %s (%d
> matches)",
>  print_in_addr_t(r->gateway, 0, ),
>  count);
> -ret = TUN_ADAPTER_INDEX_INVALID;
>  }
>
>  dmsg(D_ROUTE_DEBUG, "DEBUG: route find if: on_tun=%d count=%d
> index=%d",
> diff --git a/src/openvpn/tun.c b/src/openvpn/tun.c
> index 3639718..7603133 100644
> --- a/src/openvpn/tun.c
> +++ b/src/openvpn/tun.c
> @@ -4474,6 +4474,49 @@ is_ip_in_adapter_subnet(const IP_ADAPTER_INFO *ai,
> const in_addr_t ip, in_addr_t
>  return ret;
>  }
>
> +/**
> + * Given an interface index return the interface metric.
> + *
> + * Arguments:
> + *   index : The index of the interface
> + *   family: AF_INET for IPv4 or AF_INET6 for IPv6
> + * On error returns -1
> + */
> +
> +/* function signature missing in mingw iphlpapi.h */
>

that definition apparently present in mingw since 2015

https://sourceforge.net/p/mingw-w64/mingw-w64/ci/ea95d55e3387353e453d6ae8fc5cb8f7503947c2/tree/mingw-w64-headers/include/netioapi.h



> +VOID NETIOAPI_API_
> +InitializeIpInterfaceEntry(PMIB_IPINTERFACE_ROW Row);
> +
> +static int
> +get_interface_metric(NET_IFINDEX index, ADDRESS_FAMILY family)
> +{
> +DWORD err;
> +int msglevel = D_ROUTE|M_WARN;
> +MIB_IPINTERFACE_ROW ipiface;
> +
> +InitializeIpInterfaceEntry();
> +ipiface.Family = family;
> +ipiface.InterfaceIndex = index;
> +
> +err = GetIpInterfaceEntry();
> +if (err == NO_ERROR)
> +{
> +return ipiface.Metric;
> +}
> +else if (err == ERROR_NOT_FOUND)
> +{
> +/*
> + *  This happens if the address family is not enabled for the
> + *  interface, which is benign -- display only at a debug level
> + */
> +msglevel = D_ROUTE_DEBUG;
> +}
> +msg(msglevel, "Note: failed to determine metric of interface "
> +  "<%lu> for %s : (error code = %lu)",
> +  index, (family == AF_INET)? "ipv4" : "ipv6", err);
> +return -1;
> +}
> +
>  DWORD
>  adapter_index_of_ip(const IP_ADAPTER_INFO *list,
>  const in_addr_t ip,
> @@ -4483,6 +4526,7 @@ adapter_index_of_ip(const IP_ADAPTER_INFO *list,
>  struct gc_arena gc = gc_new();
>  DWORD ret = TUN_ADAPTER_INDEX_INVALID;
>  in_addr_t highest_netmask = 0;
> +int lowest_metric = INT_MAX;
>  bool first = true;
>
>  if (count)
> @@ -4496,9 +4540,14 @@ adapter_index_of_ip(const IP_ADAPTER_INFO *list,
>
>  if (is_ip_in_adapter_subnet(list, ip, ))
>  {
> +int metric = get_interface_metric(list->Index, AF_INET);
>  if (first || hn > highest_netmask)
>  {
>  highest_netmask = hn;
> +if (metric >= 0)
> +{
> +lowest_metric = metric;
> +}
>  if (count)
>  {
>  *count = 1;
> @@ -4512,16 +4561,22 @@ adapter_index_of_ip(const IP_ADAPTER_INFO *list,
>  {
>  ++*count;
>  }
> +if (metric >= 0 && metric < lowest_metric)
> +{
> +ret = list->Index;
> +lowest_metric = metric;
> +}
>  }
>  }
>  list = list->Next;
>  }
>
> -dmsg(D_ROUTE_DEBUG, "DEBUG: IP Locate: ip=%s nm=%s index=%d count=%d",
> +dmsg(D_ROUTE_DEBUG, "DEBUG: IP Locate: ip=%s nm=%s index=%d count=%d
> metric=%d",
>   print_in_addr_t(ip, 0, ),
>   print_in_addr_t(highest_netmask, 0, ),
>   (int)ret,
> - count ? *count : -1);
> + count ? 

  1   2   3   4   >