Hi,
Here's the summary of today's IRC meeting.
---
COMMUNITY 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:
<https://community.openvpn.net/openvpn/wiki/Topics-2016-11-07>
The next meeting has not been scheduled yet.
Your local meeting time is easy to check from services such as
<http://www.timeanddate.com/worldclock>
SUMMARY
agi, cron2, dazo, lev, mattock and syzzer participated in this meeting.
---
Discussed patchwork:
<http://jk.ozlabs.org/projects/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:
<https://github.com/mattock/openvpn-windows-buildtest>
<https://github.com/mattock/openvpn-windows-test>
The glue would probably more Powershell scripting, along with a
Chocolatey repository for OpenVPN:
<https://chocolatey.org/>
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:
<https://github.com/xkjyeah/openvpnserv2/issues/10>
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:
<https://community.openvpn.net/openvpn/ticket/462>
<https://bugs.launchpad.net/ubuntu/+source/openvpn/+bug/1580356>
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
stanza.
(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
community.openvpn.net)
(21:03:10) cron2: if nobody but agi is here, this is going to be a short
meeting...
(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
parallel
(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
list...
(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:
https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg12871.html
(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
www.mail-archive.com)
(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:
https://paste.fedoraproject.org/475145/14785477/
(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
files?
(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
it
(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
openvpnserv1)
(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:
https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg12764.html
(21:57:49) vpnHelper: Title: [Openvpn-devel] [PATCH] systemd: Improve the
systemd unit files (at www.mail-archive.com)
(21:57:55) mattock: agi:
https://bugs.launchpad.net/ubuntu/+source/openvpn/+bug/1580356
(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:
https://community.openvpn.net/openvpn/ticket/462
(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
https://community.openvpn.net/openvpn/wiki/StatusOfOpenvpn24?
(22:00:34) vpnHelper: Title: StatusOfOpenvpn24 – OpenVPN Community (at
community.openvpn.net)
(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
probably
(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
something
(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
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel
