Here's the summary of today's IRC meeting.



Place: #openvpn-meeting on irc.freenode.net
Date: Monday 7th November 2016
Time: 20:00 CET (19:00 UTC)

Planned meeting topics for this meeting were here:


The next meeting has not been scheduled yet.

Your local meeting time is easy to check from services such as



agi, cron2, dazo, lev, mattock and syzzer participated in this meeting.


Discussed patchwork:


It was agreed that even the minimal level ("show status of patches on the list") would be useful, especially with community LDAP integration. At a later point we can implement a more elaborate process such as this:

Patch comes in to openvpn-devel
Patchwork picks it up
Test "git apply"
  - Failure -> auto-reject
  - Success -> queue
Preliminary human review ("feature-ACK")
  - Makes sense -> trigger build test
    - Failure -> auto-reject
    - Success -> code review
  - Does not make sense -> reject

This approach would be DoS/misuse-resistant: starting builds automatically from random patches sent to list would be dangerous on many levels.

Mattock will start by setting up patchwork with the minimal feature set, as discussed above.


Discussed basic Windows testing, which could be fully automated by integrating these two tools together:


The glue would probably more Powershell scripting, along with a Chocolatey repository for OpenVPN:


Wpkg was also mentioned as an option for Chocolatey, but it is less well suited for a public-facing repository, as some of its features depend on SMB shares.


Discussed OpenVPN 2.4 release schedule. It was agreed to set the deadline for 2.4_beta1 to November 16th. That will give us some time to finish the final set of really important patches. Any major features that remain will be postponed for 2.5. The release date for 2.5_alpha1 could be set to ~6 months after 2.4.0, so this postponement of features would not be the end of the work.


Discussed the only known openvpnserv2 issue:


Agreed that, if possible, the fix should go in to 2.4.0, but if necessary, to a later point release. The fix is important, as it is possible, in certain cases, for connectivity to break, if openvpnserv2 restarts a connection.


Discussed our systemd unit files, which would be good to have in all distros; right now all distros have rolled up their own. Our unit files handle clients and servers separately, which has the benefit that it allows seamless migrations, as well as fixes some issues with certain Cloud providers:


Agi, the Debian package maintainer, will test our systemd unit files and report back.


Discussed latest results from Coverity Scan. Our defect average is way below industry average. The new "defects" in our current code (as reported by Coverity) are not really defects, but more related to coding style.


Discussed OpenVPN 2.3.14 release. The biggest thing missing is "block-outside-dns v2". The remaining things are fairly minor in comparison. Decided to release 2.3.14 after 2.4_beta1 is out to keep our focus clear.


Full chatlog has been attached to this email.

Samuli Seppänen
Community Manager
OpenVPN Technologies, Inc

irc freenode net: mattock

(20:52:36) ***cron2 wonders who will make it (in 8 min), and who will be 
timezone-confused :)
(20:56:46) agi [~a...@etc.inittab.org] è entrato nella stanza.
(20:56:58) agi: hi there
(20:58:01) cron2: hi!
(21:00:11) syzzer [~syzzer@openvpn/community/developer/syzzer] è entrato nella 
(21:00:16) syzzer: evening :)
(21:00:43) mattock: evening!
(21:01:04) mattock: https://community.openvpn.net/openvpn/wiki/Topics-2016-11-07
(21:01:06) vpnHelper: Title: Topics-2016-11-07 – OpenVPN Community (at 
(21:03:10) cron2: if nobody but agi is here, this is going to be a short 
(21:03:41) cron2: mattock: your QA list is great, we need this on a proper 
page, not "just in the meeting notes"
(21:04:03) mattock: cron2: yeah, indeed - I just did not want to maintain it in 
two places until it stabilizes
(21:04:10) mattock: and having it on the meeting page makes sense iniitally
(21:04:15) mattock: initially
(21:04:55) mattock: shall we start or wait for someone?
(21:04:56) cron2: what is missing from the page is one of the things we're 
notoriously bad at: updating our web page of "open patches on the list"
(21:05:15) mattock: I believe that is where patchwork would help afaik
(21:05:17) cron2: so patches are properly referenced and can be checked off as 
"done", "rejected"
(21:05:33) cron2: right, this is one of the reasons why I put it in (was my 
initial draft) :-)
(21:05:54) mattock: I'm not particularly interested in the other features of 
patchwork (e.g. triggering builds), as those are covered quite well already
(21:06:00) cron2: I spent some time talking QA and CI with Martin Winter @ 
quagga a week ago
(21:06:03) mattock: but as a overview of patches it is good
(21:06:08) cron2: oh, to the contrary
(21:06:31) cron2: just imagine: someone sending in a patch that works on their, 
say, linux system with openssl, but breaks all BSDs and mbedtls compiles
(21:07:03) mattock: yeah, I was about to say that if it can build Git + patch, 
then it starts to make sense
(21:07:05) cron2: having patchwork trigger an immediate test build a) does it 
apply at all?  b) does it break platform compiles   c) will "make check" still 
run?   would be very very useful
(21:07:37) cron2: I'm not sure if patchwork can do this on its own, or if you 
need external machinery - but quagga does this, and patches that do not apply 
or not compile get auto-rejected right away
(21:07:43) cron2: "here's why, please fix and come back"
(21:08:06) cron2: this is actually much nicer than our process "after 4 months, 
I've found time to look at this, and it does not apply!"
(21:08:09) mattock: yep, makes sense
(21:08:53) mattock: having patchwork trigger buildbot runs would be good
(21:09:08) mattock: that would probably be a fair amount of integration work
(21:09:28) cron2: maybe not the regular buildbots, but something on (vagrant?) 
VMs that get rebuilt every time (or reset to "known good" afterwards)
(21:09:52) mattock: depends on whether we want a full build every time someone 
sends a patch
(21:09:55) cron2: a malicious user could send a patch that will add a spambot 
(21:10:06) mattock: that could be used to DoS our buildslaves
(21:10:30) mattock: ah yes, good point
(21:10:56) cron2: maybe not a "full full really full" build, but sort of a 
cross-section - "build with no options on Linux, FreeBSD, Windows" and "build 
with the option combinations (--disable-crypto etc) on linux"
(21:11:00) mattock: maybe launch builds manually after the "feature-ACK"
(21:11:39) cron2: in that case, we could do a cursory review, and if doesn't 
look suspicious, give it a test compile - right
(21:11:44) lev__ [~l...@stipakov.fi] è entrato nella stanza.
(21:11:52) mattock: hi lev__!
(21:12:02) lev__: hello there
(21:12:35) mattock: regarding QA in general... as you see from the table, we 
could potentially run quite a few of the tests earlier than we do right now
(21:12:38) cron2: so, patch comes in -> patchwork picks it up -> "git apply" is 
tested -> if it fails: auto-reject.  If it works -> queue, if a human says 
"this looks reasonable (feature-ACK)" -> give it a build-test.  Failure -> 
auto-reject, success -> code review
(21:12:42) cron2: or thus
(21:12:55) mattock: makes sense
(21:13:09) syzzer: looks interesting :)
(21:13:14) agi: indeed
(21:13:41) cron2: (I'm not sure how much of this can be done by patchwork on 
its own, and how much glue scripting we would have to do)
(21:15:49) mattock: even the minimal level ("show status of patches on the 
list") is useful
(21:15:55) mattock: I would start with that an build from there
(21:16:02) cron2: sounds good
(21:16:21) mattock: that, plus integration with community LDAP + separate group 
for patchwork
(21:16:26) cron2: heh
(21:16:38) cron2: I was about to suggest "can you run it somewhere where it can 
use community LDAP" :-)
(21:16:51) mattock: definitely, I don't want to maintain extra user accounts :)
(21:17:03) ***dazo is finally here ... catching up
(21:17:16) cron2: dazo: wb :)
(21:20:32) dazo: so regarding the patchwork ... I agree with cron2, we need it 
to trigger buildbots ... but I'm concerned about not just a DoS attack.  But 
also that someone adds a patch which replaces t_client.sh with "lets send 
150.000 spam mails to this list of recipients"
(21:20:47) cron2: read on :)
(21:20:58) mattock: indeed :P
(21:21:03) ***dazo re-reads :)
(21:21:06) cron2: mattock and I agreed on a DoS-resistant approach already
(21:21:16) dazo: great :)
(21:21:29) cron2: 20:12 in my timeline
(21:21:38) ***dazo re-reads the last 10 minutes again
(21:22:35) mattock: dazo: summary: builds would only be triggered after initial 
human review ("feature-ACK")
(21:22:48) ***dazo agrees!
(21:23:17) cron2: cool :) - anything else on QA from your side?
(21:23:36) dazo: nope, just that this would be great to have asap ;-)
(21:23:44) mattock: one place I'd like to improve is quite visible from the QA 
table on the topics page
(21:23:53) mattock: which is: automatically _test_ latest Windows builds
(21:24:05) cron2: that would be tremendously cool
(21:24:11) mattock: most of the pieces are there (openvpn-windows-buildtest and 
openvpn-windows-test), but more glue is needed
(21:24:21) mattock: so no promises on delivery date, but "soonish"
(21:24:47) cron2: mattock: I've sent wpkg.org to you in the mail thread - I use 
that for software distribution to windows systems, it might be nicer (or not) 
than chocolatey
(21:25:14) mattock: as for wpkg vs. chocolatey: I didn't have to to look into 
wpkg, but chocolatey is built for public repositories, which would also benefit 
human testers/power users
(21:25:17) cron2: the nice bit about it is that it can install our existing 
installers, and then "run scripts"
(21:25:54) cron2: wpkg basically executes "recipes" (in cmd.exe) to "install" 
or "upgrade" something
(21:25:57) mattock: chocolatey also runs existing installers
(21:26:04) mattock: it just uses powershell
(21:26:15) mattock: the nasty part (at least historically) has been setting up 
the repo
(21:26:15) cron2: that script *normally* executes something like 
//network/wpkg/software/openvpn-2.3.4.exe --silent
(21:26:24) mattock: yeah, the same idea in choco
(21:26:25) syzzer: jftr, jenkins works pretty good with windows.  and if you 
decide you want that, I can help with setting it up.
(21:26:26) dazo: is powershell available by default on all Windows releases?
(21:26:33) dazo: (which we support, that is)
(21:26:35) mattock: dazo: yes
(21:26:42) mattock: except XP, but we're probably not interested in that
(21:26:46) cron2: but it could be "fetch that installer with wget from $REPO 
and then run --install"
(21:27:03) mattock: cron2: yeah, that would be the minimal approach
(21:27:12) cron2: dazo: it's a bit weird - as far as I understand it's always 
there, but some features need to be enabled first (like, run scripts from 
network shares)
(21:27:35) mattock: yeah, Set-Executionpolicy -Executionpolicy 
unrestricted|bypass or whatever
(21:27:41) cron2: mattock: I have no personal preferences - I just found it 
worth mentioning wpkg since you said chocolatey is a bit complicated to set up
(21:27:43) mattock: but that is a single cmd.exe invocation
(21:27:44) cron2: yes, this
(21:27:57) mattock: is wpkg limited to samba shares?
(21:28:23) cron2: I think the control files (hosts.xml, profiles.xml, 
packages.xml) need to reside on a network share
(21:28:28) mattock: ok
(21:28:40) mattock: then I would prefer chocolatey, provided the repo setup is 
not horrible
(21:28:42) cron2: the actual package to be installed could be downloaded by 
means of the install recipe
(21:28:52) mattock: yep
(21:29:26) cron2: depends on the network closeness of the machines :-) - but 
yeah, if you want to open this to network testers "somewhere in the world", 
wpkg might not work (agent installation is a bit of a nuisance as well)
(21:29:46) cron2: ((it is easy if you have worked it out for your environment 
and just clone the client.xml file...))
(21:30:08) mattock: ok, I will look into this
(21:30:13) mattock: anything else on QA?
(21:30:26) mattock: (I'll also copy the table to the testing page later)
(21:30:57) cron2: windows testing needs to be able to run two instances in 
(21:31:17) cron2: because we've had issues there with "finding a free tap 
adapter" (which d12fk fixed)
(21:31:33) mattock: so two openvpn instances?
(21:31:36) cron2: t_client doesn't do this, because I never considered this to 
be truly relevant
(21:31:39) cron2: yes
(21:31:47) cron2: --block-outside-dns and two instances is broken toda
(21:31:48) cron2: y
(21:31:52) mattock: ok, that should not be too difficult to do
(21:32:23) ***cron2 finds it hard to wrap his mind on "how do I express this in 
the config?"...
(21:32:49) mattock: I did not yet even try, so I could be wrong
(21:32:50) mattock: :P
(21:34:15) cron2: so - 2.4
(21:34:18) mattock: yes
(21:36:00) cron2: the "must haves" are sort of mostly done (4 items listed, but 
besides the reformatting, these are halfway done or trivial)
(21:36:08) syzzer: ah, 2.4, I added some 'try to make it happen' items to the 
(21:36:25) cron2: the "try to make it happen" grows every time we look the 
other way
(21:36:27) cron2: :)
(21:36:52) dazo: but we don't have much time if we want to achieve a few more 
alpha/beta/rc releases until end of December
(21:36:53) mattock: I added "make openvpnserv2 use exit-events" to the "Must 
have section", even though OpenVPN is pretty hard to break even when horribly 
misused (as in: openvpn.exe's killled hard dozens of times)
(21:37:07) cron2: so I think we need to decide on the goal - either it is "make 
these things happen, and release 2.4 when we're happy" or it is "decide on a 
hard deadline, and what is not done is not going to get in"
(21:37:35) dazo: We need a hard deadline ... if we want to manage the next 
debian release
(21:37:38) mattock: yes
(21:37:41) syzzer: I vote the second, even if that means some of my beloved 
features won't go in
(21:37:56) mattock: then we just release 2.5 a bit earlier
(21:38:13) mattock: like 2.5_alpha1 ~6 months after 2.4.0 or so
(21:38:29) dazo: yeah
(21:38:34) ***cron2 is also for hard deadline, because otherwise my lazy behind 
won't ever get up and do the work needed :)
(21:39:25) dazo: My propsosal for a schedule is here: 
(21:39:26) cron2: minor bugfixes can go into 2.4.1 later - like "--cipher 
change causes tun/tap restart" - that is annoying, but a bug really
(21:39:27) vpnHelper: Title: [Openvpn-devel] OpenVPN v2.4 release progress (at 
(21:40:23) dazo: yeah
(21:41:10) mattock: the schedule is strict, but fair :)
(21:41:17) agi: I could get patches into the package after Jan 5th
(21:41:33) mattock: agi: oh, good
(21:41:35) agi: so horrible issues don't have to be released
(21:41:35) dazo: agi: a patch which updates the version.m4 to 2.4.0? ;-)
(21:41:47) agi: dazo: heh
(21:42:17) dazo: this is changes since 2.4_alpha2: 
(21:42:27) dazo: gee ... this has changed!
(21:43:32) agi: it wont be the first time 2.4_1~really_2.4_alpha3_git_2fa23ad23 
makes it into a release
(21:43:44) dazo: :)
(21:43:49) cron2: it's a bit tough to get everything left done until tomorrow
(21:44:35) mattock: dazo: quite a few changes actually
(21:44:44) cron2: I'd change the schedule a bit to do "all we can do" until Nov 
16, and then release that as "beta 1"
(21:44:59) mattock: +1
(21:45:00) dazo: fair enough, I can agree with that
(21:45:00) cron2: so, release alpha3 or not, but do not tighten the rules yet
(21:45:06) syzzer: dazo beat me :(
(21:45:23) cron2: ok, busy week ahead :-)
(21:45:29) dazo: yeah :)
(21:45:58) mattock: so there is one important feature: "combined i686/x96_64 
Windows installers"
(21:46:02) cron2: I think it also means that we won't make tls-record-splitting 
and tls-crypt happen :(
(21:46:30) cron2: mattock: that is actually something which *could* happen later
(21:46:34) dazo: I've reviewed the CRL patch from syzzer and his colleague, 
looks good to me .... but it was a bit too perfect :-P .... so would be good 
with a second pair of eyes, but it really looks reasonable
(21:46:44) syzzer: well, I'll send out --tls-crypt in a minute, and if 
plaisthos indeed reviews those this Thursday...
(21:46:46) syzzer: who knows ;)
(21:46:46) cron2: plaisthos is the other one that understands SSL libraries
(21:46:48) mattock: cron2: as in: update 2.4.x installers?
(21:46:52) cron2: mattock: yes
(21:47:00) mattock: ok, good
(21:47:03) dazo: I can sure have a look at tls-crypt too
(21:47:26) cron2: we've done this before, like "updating openssl inside the 
installer, but having the same openvpn version"
(21:47:28) dazo: agi: what's the chances for Debian to ship our systemd unit 
(21:47:43) cron2: where's my popcorn... *search*
(21:47:52) mattock: I can't promise I can deliver the exit-events thing by Nov 
16th, as I have zero experience with the thing, and my C#-fu is fairly limited
(21:48:09) mattock: I started doing a PoC late last week, but I have not tested 
(21:48:29) dazo: mattock: why C#?
(21:48:30) cron2: is this release relevant, or more a CI/QA item?
(21:48:38) mattock: dazo: because openvpnserv2 _is_ C#
(21:48:38) dazo: good question
(21:48:42) dazo: okay
(21:48:51) dazo: who wrote that one? ;-)
(21:48:56) cron2: mmmh.  Where does openvpnserv2 live today?  in the gui-repo, 
or ...?
(21:48:59) mattock: a guy called xkjyeah
(21:49:09) mattock: I think it now likes under OpenVPN/openvpnserv2
(21:49:20) agi: dazo: as examples? easy. Instead of the current ones... not easy
(21:49:31) mattock: because somewhat surprisingly xkjyeah had "written it for a 
friend", so openvpnserv2 is kind of abandonware
(21:49:38) mattock: that said, I was prepared for that risk
(21:49:51) cron2: openvpnserv1 is also abandonware, so, not much change
(21:49:55) mattock: yeah
(21:50:13) cron2: I could claim that all of openvpn was abandonware at some 
point :-)
(21:50:28) dazo: agi: we really want to unify the systemd unit files across all 
platforms ... because there are so many variants now ... and systemd allows 
this to be unified across distros, which makes support much easier
(21:50:38) dazo: (not to say wiki/blog posts etc)
(21:50:41) mattock: as for release criticality: right now, in some cases 
(certain IPv6 setups) openvpnserv2's behavior ("kill openvpn.exe bluntly") can 
break connectivity
(21:51:02) agi: dazo: the current debian unit files where created in the spirit 
of maintaing old sysv scripts features (as in multiple openvpn config files and 
a config file to choose what to start)
(21:51:21) mattock: there is probably an openvpn issue lurking below, but 
still, openvpnserv2 should use exit-events to shutdown, instead of kill, 
openvpn processes
(21:51:24) cron2: mattock: good point.  Let's aim to have it :-) (but if we 
miss the deadline on that, it can go into 2.4.1, and will still be better than 
(21:51:31) mattock: yep
(21:52:05) dazo: agi: right ... so thats the openvpn.service file?  .... we 
have openvpn-client@.service and openvpn-server@.service, and they do not (by 
design) use /etc/openvpn ... but /etc/openvpn/{client,server} .... so they 
could co-exist
(21:52:37) agi: dazo: we'll have to look into not breaking current debian 
installations (as in the wheezy (sysv) -> jessie (systemd) transition)
(21:52:37) dazo: cron2++
(21:53:32) dazo: agi: sure ... that was actually one of my reasons why not to 
reuse openvpn.service/openvpn@.service :) ... to have a possibility for a 
transition :)
(21:54:00) agi: cool :-)
(21:54:40) slypknot: I think anybody using systemd will be able to figure out 
change from openvpn@. to openvpn-X@. and it can be easily doc'd
(21:54:41) ***syzzer really need a systemd lesson at some point...
(21:55:15) dazo: syzzer: anytime!  it is actually really simple as soon as you 
let go of thinking like sysv init scripts
(21:55:43) agi: slypknot: it's not about a README file, it's about remote 
servers being updated over the VPN and not geting the admin out in the process
(21:55:56) dazo: slypknot: yeah, but if distros choose to ship their own 
openvpn.service/openvpn@.service files .... they may, and ours will not 
interfere with them
(21:56:34) dazo: which ensures that things can be upgraded, and when users are 
ready to transistion, they can do that in a controlled manner
(21:57:16) agi: dazo: I'll test that and let you (-devel) know. 
(21:57:45) agi: I guess it should be OK now that I read your explanation
(21:57:48) dazo: cool!  thx, agi!  Latest patches is here: 
(21:57:49) vpnHelper: Title: [Openvpn-devel] [PATCH] systemd: Improve the 
systemd unit files (at www.mail-archive.com)
(21:57:55) mattock: agi: 
(21:57:58) vpnHelper: Title: Bug #1580356 “OpenVPN causes reboot failure on 
Xenial in AWS” : Bugs : openvpn package : Ubuntu (at bugs.launchpad.net)
(21:58:07) agi: dazo: I've got that mail on my INBOX :-)
(21:58:08) mattock: I'm not 100% sure if Debian is also affected
(21:58:22) ***agi checks
(21:58:22) mattock: but dazo's service files fix the issue at least
(21:58:24) dazo: agi: I'll do one more update .... changing RuntimeDir to 
openvpn-%i, as suggested
(21:58:30) mattock: also linked to from here: 
(21:58:31) vpnHelper: Title: #462 (Systemd unit file shall depend on 
network-online target) – OpenVPN Community (at community.openvpn.net)
(21:59:07) dazo: agi: that ubuntu bug, you're most likely hit by it too
(21:59:26) agi: yep, quite probably
(22:00:11) ***cron2 happily adds stuff to the "nice to have" list :)
(22:00:34) cron2: dazo: can you put your timeline into 
(22:00:34) vpnHelper: Title: StatusOfOpenvpn24 – OpenVPN Community (at 
(22:00:42) dazo: cron2: will do!
(22:00:46) dazo: (after meeting)
(22:00:49) cron2: ack
(22:00:56) agi: mattock: dazo: I'll fix that on debian's (ubuntu's) unit file
(22:01:15) cron2: mattock: can trac do "change notification"?  So I can see 
whenever "StatusOfOpenvpn24" gets changed?
(22:01:20) mattock: agi: ok, great!
(22:01:30) cron2: it does for tickets, but I do not know about wiki pages
(22:01:38) mattock: cron2: no, it can't
(22:01:41) cron2: :(
(22:01:48) mattock: _but_ I can add you to the urlwatch's list
(22:01:56) mattock: then you will see a diff whenever a page is changed
(22:02:02) cron2: then I would see *all* changes?  nah, that's too much :)
(22:02:10) mattock: but not a diff of the page, but a diff of "RecentChanges" 
page, i.e. html diff
(22:02:26) mattock: mainly designed to notice spammers quickly
(22:02:40) cron2: ic... nah, that's not what I want
(22:02:43) mattock: ok
(22:04:18) cron2: the coverity output is interesting
(22:04:56) cron2: (it just sent a mail, I think syzzer triggered a travis build)
(22:06:49) mattock: so "fix issues coverity reported" might be a good candidate 
for "must have"
(22:06:56) cron2: nah
(22:06:58) mattock: or mark them as false positives
(22:07:08) cron2: they are somewhat in between
(22:07:12) cron2: we do stuff like
(22:07:19) cron2: $pointer->thing = bla
(22:07:27) cron2: $pointer->thign = something
(22:07:35) cron2: if ( $pointer && $pointer->thing ) ...
(22:08:01) cron2: so if we have already used $pointer before, there is no point 
checking for NULL in the 3rd line - or if it *can* be NULL, then the first two 
uses are bugs
(22:08:26) syzzer: yeah, I just trigger a coverity run on master
(22:08:49) syzzer: felt like a useful thing to do before releasing any betas ;)
(22:08:54) cron2: I do not think the pointer can ever be NULL there, but in 
that case, we should do an ASSERT($pointer) at the top, and remove the 
"$pointer &&" check later on...
(22:09:26) syzzer: interesting, 7 new, 7 fixed
(22:09:42) mattock: there needs to be balance in the universe
(22:09:43) cron2: our defect density is way above industry average, as far as 
coverity claims :-)
(22:10:14) mattock: others have been more keen in keeping coverity happy 
(22:12:21) cron2: mattock: ah, no.  "way better"
(22:12:34) cron2: we're at 0.16, and the average is 0.48 or so
(22:12:52) cron2: so numerically "below", but quality-wise "above"
(22:13:32) mattock: let's dumb this down a bit: are we better or worse than 
others? :P
(22:14:10) agi: :-D
(22:14:23) dazo: we have far fewer issues in our code than the average
(22:14:42) dazo: iirc, that number indicates number of issues per 1000 lines of 
code, or something like that
(22:14:51) dazo: so lower is better
(22:14:54) mattock: probably
(22:14:56) cron2: yes
(22:15:09) mattock: ok, where were we?
(22:15:16) dazo: 0.16
(22:15:21) mattock: I mean meeting, vise :)
(22:15:23) dazo: and the average is 0.48
(22:15:26) dazo: ahh
(22:15:27) mattock: 2.4 covered?
(22:15:31) cron2: 2.4 covered
(22:15:37) mattock: 2.3.14 next?
(22:15:39) cron2: 2.3.14 next
(22:15:57) cron2: block-outside-dns v2 is missing (for 2.4 and 2.3.14, so "busy 
week for me")
(22:16:31) cron2: besides that, I see some minor bugs in trac (like the FreeBSD 
11 / topology subnet on server breakage)
(22:16:39) dazo: anyone got time to look at the CRL patch from syzzer?
(22:16:42) cron2: but no urgency in releasing that
(22:16:49) cron2: is that for 2.3?
(22:16:56) dazo: 2.4
(22:17:10) ***cron2 points at plaisthos "he understands openssl"
(22:18:07) dazo: both openssl and mbed TLS code looks good to me, so I have no 
concerns in those areas
(22:18:17) cron2: where are your concerns?
(22:18:51) dazo: it's too perfect? ;-)  I'm wondering if I have overlooked 
(22:19:27) syzzer: d12fk says he might want to take a look, but didn't specify 
when ;)
(22:19:35) dazo: but that's more on the overall part of it ... the CRL checking 
itself looks good, but there is a slight refactoring when kicking out openvpn's 
CRL checking with openssl/mbedtls versions
(22:24:15) syzzer: I'll make sure to include some typo's next time, so that you 
feel confident to apply the patch ;)
(22:25:54) dazo: hehehe :)
(22:26:55) cron2: the coverity complaints warrant a cleanup patch, but this 
maze of twisty passages is too much for my brain right now
(22:27:01) dazo: syzzer: also bare in mind that I've been sleep deprived most 
of October and have done a few really silly mistakes already ... so I'm just 
not trusting my own review capabilities fully yet :)
(22:27:27) dazo: cron2: can you send a copy of that mail?  For some reason I 
didn't get one
(22:27:40) ***dazo can have a look at a clean-up this evening
(22:28:03) dazo: plus ack d12fk's first struct argv patch
(22:28:21) cron2: dazo: if you haven't slept enough, this is not for you :)
(22:29:03) ***syzzer also marked the coverity mail for later processing
(22:29:14) cron2: forwarded
(22:29:45) cron2: syzzer: I've flagged the getsockname() one as "intentional".  
Not pretty, but not a bug either.
(22:30:03) cron2: and the "side effect in assertion" as well
(22:30:06) syzzer: well, that's one down
(22:30:11) cron2: two :)
(22:30:13) syzzer: two
(22:30:44) cron2: the hash_remove/hash_add might warrant an ASSERT() or not, 
not sure... what is #ifdef MANAGEMENT_DEF_AUTH?
(22:32:02) cron2: ah. that.
(22:32:47) dazo: cron2: I feel renewed ... had more than 6 hours sleep 3 days 
in a row! ;-)
(22:33:20) ***cron2 had a VERY busy weekend, with much work (non-computer 
related), and not that much sleep :-) - so I go watch TV now, and then to 
bed... :-)
(22:33:20) syzzer: MANAGEMENT_DEF_AUTH is one of those #ifdef's that should 
probably just be unconditionally enabled
(22:33:29) dazo: DEF_AUTH is deferred authentication ... I'm considering to 
kill all of them
(22:33:36) dazo: yeah
(22:33:59) cron2: this looks like a worthy goal... I just looked at the 
syshead.h part of it, and my eyes spin
(22:34:14) cron2: anyway, I think I know what to do this week :-) - good 
meeting! good night!
(22:34:18) ***cron2 is off
(22:34:45) dazo: c'ya!
(22:35:00) mattock: oh wait
(22:35:03) mattock: 2.3.14 release date?
(22:35:18) mattock: after 2.4_beta1?
(22:35:30) dazo: yeah, let's have a 2.4 focus now
(22:35:37) mattock: I agree
(22:35:53) syzzer: "when block-outside-dns-v2 is in"?
(22:36:04) dazo: that is currently far more important right now ... 2.3 stuff 
is important too, but not as important as getting 2.4 out by end of Dec
(22:36:42) syzzer: but indeed
(22:36:53) mattock: we're in agreement, so let's call it day, shall we?
(22:37:04) mattock: and the summary is rather long already :)
(22:37:13) syzzer: yeah, good night!
(22:37:24) dazo: fair enough ... gives me more hacking time :)
(22:37:24) mattock: good night!
(22:37:28) dazo: g'night!
(22:37:31) agi: good night!
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi
Openvpn-devel mailing list

Reply via email to