Hi, Here's the summary of the IRC meeting.
--- COMMUNITY MEETING Place: #openvpn-meeting on irc.freenode.net Date: Wednesday 2nd October 2019 Time: 11:30 CEST (9:30 UTC) Planned meeting topics for this meeting were here: <https://community.openvpn.net/openvpn/wiki/Topics-2019-10-02> Your local meeting time is easy to check from services such as <http://www.timeanddate.com/worldclock> SUMMARY cron2, dazo, lev, mattock, ordex, rozmansi and syzzer participated in this meeting. --- Discussed tap-windows6. Mattock produced a test installer which includes two PRs: <https://github.com/OpenVPN/tap-windows6/pull/84> <https://github.com/OpenVPN/tap-windows6/pull/86> An installer for Windows 10 and Server 2016/2019 is here: <https://build.openvpn.net/downloads/temp/tap-windows-9.24.2-I601.exe> It has only been install-tested so far. -- Discussed the VLAN patchset. At the moment it is compiled in by default, but can be disabled at build time with --disable-vlan. This approach seemed adequate for all. The changes the patchset makes are fairly non-intrusive (no effect on tun mode, very minimal effect on tap mode). A new round of VLAN patches with minor fixes is coming up soon. -- Discussed the OpenVPN 2.5 release. Syzzer will have a look at Lev's wintun patches and wintun installer. Ordex will work on client-connect and transport-API after VLAN patchset is done. Dazo will look into the struct argv overhaul patches. -- Discussed OpenVPN 2.4.8 release. Agreed that it will be based on "release/2.4" branch, an updated tap-windows6 installer (see above) and the "openssl: Fix compilation without deprecated OpenSSL 1.1 APIs" patch: <https://patchwork.openvpn.net/patch/787/> -- Full chatlog attached.
(12:30:37) mattock: howdy (12:30:42) rozmansi: hi (12:31:50) lev__: hello (12:34:26) mattock: anyone else? (12:34:48) mattock: https://community.openvpn.net/openvpn/wiki/Topics-2019-10-02 (12:34:49) vpnHelper: Title: Topics-2019-10-02 – OpenVPN Community (at community.openvpn.net) (12:35:17) lev__: no, just me and Simon having wintun party here (12:35:17) mattock: I can cover #3 quickly while waiting (12:35:34) mattock: the signing computer is up again which mean I can produce a test installer (12:35:41) mattock: for tap-windows6, including the two PRs (12:36:42) mattock: the rest of the topics will require input from cron2 and ordex (12:36:59) mattock: anything outside of the topic list we should bring up? (12:37:06) ordex: here here (12:37:08) cron2: I want output, not input :) (12:37:17) mattock: :D (12:37:23) mattock: hi guys btw! (12:37:40) mattock: topic #1vlan patches / --enable-vlan or --disable-vlan? or no #ifdef at all? (12:37:55) ordex: right (12:37:56) ordex: so (12:37:58) syzzer: hi :) (12:38:10) ordex: the implementation now enables VLAN code by default at compile time (12:38:10) mattock: oh hi syzzer! (12:38:14) cron2: that is my input - "what do we want this to be?" - but usually dazo is the one with strong opinions here (12:38:17) cron2: hi syzzer (12:38:17) ***dazo is here (12:38:20) ordex: and it can be compiled out by providing --disable-vlan (12:39:10) ordex: this way everybody gets the functionality without any hassle (12:39:11) dazo: what is the impact of this feature, code wise? Intrusive? How useful is this for "everyone"? (12:39:44) ordex: it touches code paths in multi.c (server side) and is not too intruisive if you ask me (12:39:59) syzzer: how much would this code impact setups that doe not enable any vlan functionality in their config? (12:40:00) cron2: it intrudes on tap mode, adds a few extra clauses and a new vlan.c, and a few (not much) kbyte of code (12:40:10) cron2: syzzer: not at all (12:40:27) syzzer: so why make it compile-time configurable it all then? (12:40:28) cron2: (and not in the tun code path at all) (12:40:28) ordex: well, there are "ifs" that will of course lead to "skip the vlan logic" (12:40:32) syzzer: less ifdefs, more better (12:40:42) cron2: ordex did it without visible #ifdefs (12:40:52) ordex: it's all hidden in vlan.h (12:41:01) ordex: the code has no ifdef VLAN anywhere (12:41:14) dazo: then I think --disable-vlan is reasonable ... I see the argument of "no #ifdef" ... but I think brand new features can have the advantage of disabling them when debugging odd behaviours (12:41:17) cron2: aka, vlan.h has lots of "vlan_make_decision()" functions which either get compiled to "the condition" or "no vlan, return 0" inlines (12:41:21) syzzer: ah, good. then "I don't care" :) (12:41:57) ordex: :D (12:42:00) cron2: ordex: there you go, dazo has spoken :) (12:42:25) dazo: if you are 100% convinced this will not cause any negative impact for any configuration, I'm willing to be more relaxed on #ifdef (12:42:40) cron2: dazo: I expected you to go for "we want new features default-off, and thus --enable-vlan" - and before we have this discussion *after* merging, I wanted to bring it up first :-) (12:43:01) dazo: :) (12:43:14) ordex: hehe (12:43:23) cron2: dazo: 100% for tun, 99% for tap (I do not see any possible impact, but I might be wrong) (12:43:24) dazo: Probably (or rather hopefully!) getting older and wiser ;-) (12:44:01) cron2: ok, done. Now I have to leave anyway, but I got my answer - thanks :-) (12:44:06) ordex: well, we have to throw it in the wild to see the bugs :p (12:44:11) ordex: hehe (12:44:12) ordex: goed ! (12:44:55) cron2: (which actually brings us to "updates on 2.5" - vlan patches have had their first round of review, things are looking mostly nice, I complained about stylistic things, but nothing dramatic - new round to be expected "soonish!") (12:45:06) cron2: plaisthos auth-token stuff has been fully merged (12:45:34) dazo: thx! (12:45:45) ordex: client-connect and transport-API are next on my list after we're donew it the VLANs (12:45:52) dazo: I'll have a look at the struct argv overhaul patches ... rebase them on latest master and see if there's anything else to fix (12:46:41) ordex: oky (12:51:20) lev__: did anyone had a chance to look at wintun patches / wintun installer ? (12:51:31) syzzer: lev__: not yet, but I do plan to (12:51:48) syzzer: mostly the integration into openvpn (12:52:37) lev__: nice, thanks! (12:53:23) syzzer: I'm considering to ship openvpn-nl with wintun. Less code, less attack surface. (12:55:00) ordex: yap, from that perspective should be much better than tap-windows6 (12:56:10) mattock: 2.4 release? (12:57:37) syzzer: 2.4.8? (12:59:13) ordex: yap (12:59:30) ordex: what do we miss before being able to make this release ? (12:59:35) ordex: I geuss we wanted to wait for tap-windows ? (12:59:48) mattock: I'm producing a test installer while you talk (13:00:02) ordex: do we still want to wait for that actually ? (13:00:15) cron2: I need input on whether there are unmerged patches that need to go in (13:00:58) mattock: cabinet file being scanned and hopefully signed by MS now (13:01:32) mattock: I think we should bundle the tap-windows6 release with 2.4.8 release if possible (13:02:20) dazo: that's what we've been waiting for with the 2.4.8 release since the beginning, right? Due to some important fixes in tap-windows6, right? (13:02:21) mattock: it is not a biggie unless some issues are found in testing or if testing takes too long (13:02:55) mattock: dazo: not sure, but we have no "must release due to security reasons" motive anymore (13:03:13) mattock: but there are two fixes for tap-windows6 which will be included in the test installer that baking right now (13:03:21) mattock: that is (13:04:08) dazo: alright (13:05:50) mattock: I'll have the tap-windows6 installer ready in <30 minutes (13:06:27) mattock: besides 2.4.8 - is it just about "updated tap-windows6 + latest code from release/2.4"? (13:06:38) mattock: or is there something that is not yet finished and should go in? (13:07:13) cron2: 12:00 < cron2> I need input on whether there are unmerged patches that need to go in (13:07:14) dazo: that's what cron2 asked for @ 12:00:15 :-P (13:07:18) cron2: yes :) (13:07:33) ordex: I Don't think any of us is aware of something missing :D (13:07:34) cron2: (I'm still around due to an unexpected meeting in my office) (13:07:46) cron2: there's some sort of openssl/libressl/tls1.3 backport I think (13:08:02) cron2: https://patchwork.openvpn.net/patch/787/ (13:08:03) vpnHelper: Title: [Openvpn-devel,v3] openssl: Fix compilation without deprecated OpenSSL 1.1 APIs - Patchwork (at patchwork.openvpn.net) (13:08:12) cron2: this one, I think it wants to go back (due to "long-term compat") (13:08:34) cron2: plus the mbedtls explosion patch :) (13:09:21) dazo: oh ... and we need to discuss if some of the auth-token-hmac stuff need to go to 2.4.x as well ... not the server side, but client side ... as I spotted that git master behaves more predictably than 2.4.x when tokens expires (13:09:47) cron2: client side compat/stability things are "ok for 2.4", so, makes sense (13:09:51) dazo: (due to not sending the token, but the users password on token expiry) (13:10:10) ordex: but auth-token-hmac is a new feature isn't it ? (13:10:17) cron2: yes (13:10:24) ordex: so not really 2.4-material, no? (13:10:24) cron2: server-side and fairly big (13:10:44) dazo: it's a fairly big change on the server side ... but there are some client side changes as well, to make things go smoothly when AUTH_FAILED with token expired messages are sent (13:12:45) ordex: yap, but they should go together, no? (13:13:29) ordex: meaning: we are talking about new behaviours that will interact with each other (server <--> client) so having both in 2.5 sounds reasonable (13:14:00) cron2: we usually pull in client side long-term compat stuff to 2.4, if "it makes interop with 2.5 servers better" (13:14:34) cron2: it's *mostly* independent, except if sending an auth-token and getting back an "EXPIRED! go away!" reply (13:14:57) cron2: dazo: please do double-check, it might be already in release/2.4 (because that was an independent patch from the "auth-token-hmac" patchset) (13:15:18) ordex: hmm ok, I don't get what it fixed then (13:15:29) dazo: oh, might be ... I only tested against 2.4.7 which was released, not the release/2.4 branch (13:15:30) ordex: (but maybe I should have complained at review time :P) (13:15:44) cron2: the client used to "just loop" if getting an "auth failed, expired" (13:15:53) cron2: instead of "fall back to password" (13:15:56) ordex: oh ok (13:16:07) dazo: ordex: these changes doesn't make things worse for 2.4.7 and older .... it would just improve things there as well (13:16:15) cron2: the auth-token-hmac stuff is not visible on the wire (13:16:28) cron2: it's just "now the server generates these tokens" (13:16:47) ordex: okok, so this is something that could happen also when the server has the classic token mechanism in place, under certain conditions (13:16:49) ordex: ok (13:16:52) cron2: yes (13:17:00) dazo: +1 (13:17:38) cron2: commit 004f13b60d87fe7815f4feee9aded22ae4eacbaf (13:17:38) cron2: Author: Arne Schwabe <a...@rfc2549.org> (13:17:38) cron2: Date: Wed Oct 10 16:30:51 2018 +0200 (13:17:39) cron2: Fallback to password authentication when auth-token fails (13:17:41) cron2: in release/2.4 (13:17:44) cron2: so it might be already in (13:17:53) cron2: Acked-by: Antonio Quartulli <anto...@openvpn.net> (13:17:53) cron2: :) (13:18:13) dazo: Yeah, saw that just now .... and it's in 2.4.7 ... need to retest my setup then (13:19:25) ordex: !!! (13:19:26) ordex: :D (13:19:42) ordex: move on move on, don't look! (13:20:07) dazo: :-P (13:21:38) syzzer: so, does this wrap it up? (13:24:00) mattock: so a couple of things missing from release/2.4, plus new tap-windows6 installer (13:24:55) ordex: I guess only this: https://patchwork.openvpn.net/patch/787/ (13:24:57) vpnHelper: Title: [Openvpn-devel,v3] openssl: Fix compilation without deprecated OpenSSL 1.1 APIs - Patchwork (at patchwork.openvpn.net) (13:25:02) ordex: and the tap-windows 6 ? (13:25:04) cron2: yes (13:25:30) ordex: ok (13:25:44) ***ordex has to leave for lunch (13:25:50) ordex: but it seems we're done ? (13:26:12) mattock: ok good (13:26:30) syzzer: excellent :) (13:26:33) mattock: MS signed the tap-windows6 driver, time to produce an installer (13:26:38) mattock: I will add a link to the meeting summary (13:26:43) syzzer: ah, nice :D (13:26:47) mattock: then link in the tap-windows6 PRs (13:27:13) mattock: we're also going to get a new signing computer that can also act as a tap-windows6 build computer (13:27:31) mattock: meaning the process will be less convoluted (no need to to mount build dir via SMB shares) (13:27:55) mattock: plus the new signing computer should not be as prone to overheating as the previous one (it was down every other time somebody tried to use it) (13:28:20) mattock: anyways, good meeting, summary will be sent soon
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Openvpn-devel mailing list Openvpn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-devel
