Hi, Here's the summary of the IRC meeting.
--- COMMUNITY MEETING Place: #openvpn-meeting on irc.freenode.net Date: Wednesday 26th Sep 2018 Time: 11:30 CEST (9:30 UTC) Planned meeting topics for this meeting were here: <https://community.openvpn.net/openvpn/wiki/Topics-2018-09-26> 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 cron2, dazo, lev, mattock, ordex, plaisthos, syzzer and tincantech participated in this meeting. -- Discussed tap-windows6 release and HLK testing. An outsourcing company is currently HLK testing the driver, but they are probably unable to fix some of the issues. OpenVPN Inc. may have to hire a Windows kernel driver developer to resolve those issues, after which we can make HLK tests pass, get WHQL certification and finally release a driver that loads on Windows Server 2016 and later. Mattock will discuss this topic in an internal meeting the upcoming Friday. -- Discussed the Lviv hackathon: https://community.openvpn.net/openvpn/wiki/LvivHackathon2018 Agreed that the focus should be on "what should go in to OpenVPN 2.5". It was agreed that being in sync with Debian 10's release cycle would be good: https://lists.debian.org/debian-devel-announce/2018/04/msg00006.html However, it will be a tough deadline to meet due to the number of potential features: https://community.openvpn.net/openvpn/wiki/StatusOfOpenvpn25 Dazo and mattock will try to get more focus on 2.5 from OpenVPN Inc's developers. -- Discussed tap-windows6 in relation to the new Windows VPN API. It was agreed that we can't migrate away from tap-windows6 any time soon, plus the VPN API only works with "modern" apps. OpenVPN Inc has written a proprietary OpenVPN 3-based "modern" app that uses the VPN API, but it is still in beta in Windows Marketplace. Plus there are glitches in the VPN API itself. -- Full chatlog attached. -- Samuli Seppänen Community Manager OpenVPN Technologies, Inc irc freenode net: mattock
(12:30:50) mattock: hi (12:30:52) mattock: meeting time (12:32:12) mattock: who is joining today? (12:33:11) cron2: a mattock! (12:34:21) lev__: hello there (12:34:31) mattock: hi! (12:34:57) mattock: https://community.openvpn.net/openvpn/wiki/Topics-2018-09-26 (12:34:59) vpnHelper: Title: Topics-2018-09-26 – OpenVPN Community (at community.openvpn.net) (12:35:19) mattock: I can start with #1, as that's only a status update for those not in the loop (12:35:27) cron2: go for it (12:35:42) mattock: so, right now tap-windows6 is being HLK-tested by an outsourcing company (12:35:52) mattock: they've made some progress, but some HLK tests are still failing (12:36:28) mattock: according to jon fixing some of the issues might take an experienced NDIS developer a couple of weeks even (12:36:33) mattock: so they're not trivially fixable (12:36:54) cron2: ewwww (12:36:56) mattock: I will discuss the option of hiring such a developer the upcoming Friday (12:37:14) mattock: I'll be in a meeting with CEO of OpenVPN Inc. (12:37:45) cron2: has there been a change of role there? (12:38:01) mattock: then there's another (rather big) company who has the same tap-windows6 / HLK / WHQL certification issue, and we may be able to co-operate with them (12:38:06) ***ordex is here (12:38:13) mattock: cron2: change of role where? (12:38:21) cron2: CEO. Still Francis? (12:38:23) mattock: yes (12:38:39) cron2: ok (I just wondered because you've never spoke so formally) (12:38:43) mattock: :) (12:38:54) mattock: well, people who read the chatlog might not know Francis is the CEO (12:38:58) mattock: that was my reasoning (12:38:59) cron2: yeah (12:39:09) mattock: but now they _will_ know (12:39:10) plaisthos: I am here too (12:39:15) ordex: :D (12:39:45) mattock: oh, I will send email to the "other company" about tap-windows6 WHQL certification - they've been a bit slow to respond after we requested GPG encryption :P (12:39:57) mattock: that's all I have to share about this topic (12:40:29) mattock: Lviv next? (12:40:46) ordex: ok (12:41:02) ordex: it seems it is not going be to be a crowded hackathon (12:41:14) plaisthos: yeah sadly :/ (12:41:48) ***syzzer present too (12:42:11) syzzer: (lost track of time while debugging an issue with $coworker) (12:42:27) cron2: you need to spend less time on work! (12:42:35) mattock: https://community.openvpn.net/openvpn/wiki/LvivHackathon2018 (12:42:37) vpnHelper: Title: LvivHackathon2018 – OpenVPN Community (at community.openvpn.net) (12:42:44) mattock: well we do have a fair amount of people joining (12:42:57) mattock: not like last year, but still (12:43:53) mattock: only two who are _not_ openvpn inc employees, but I guess that's to be expected when OpenVPN Inc has tried to hire almost all OpenVPN devs there are (12:44:18) ordex: :D (12:44:20) cron2: yeah, I noticed the numbers :) (12:44:33) mattock: so anything in particular to discuss about hackathon? goals etc? (12:44:44) mattock: are we aiming for 2.5 there? (12:45:29) cron2: 2.5 release certainly not - far too much stuff missing. An agreement on what should be *in* 2.5 plus a timeline would be good (12:45:35) ordex: yap (12:46:03) cron2: ordex and I discussed this in one of the mattock-free weeks and are aiming for "end of the year for things-should-be-in" and maybe ~march-ish for a release (12:46:06) ordex: I guess we should probably spend some time at the beginning (1 hour?) recapping all the open things and then deciding what we want to put into 2.5 (12:46:12) cron2: yep (12:46:36) cron2: basically #1 in the "What?" list on the hackathon page already (12:46:43) ***dazo is here now :) (12:46:47) ordex: yeah (12:48:40) ordex: #2 is probably going to end nowhere :D but it's good to have such discussion (12:48:57) ordex: #3 can still be hold without Simon? (12:49:10) mattock: good question about #3 (12:49:24) cron2: maybe simon can set aside time that weekend so we could conference? (12:49:30) cron2: "remote-hackathon"? (12:49:33) mattock: yeah (12:49:37) mattock: we can sure ask (12:49:43) ordex: good idea (12:49:55) mattock: I will ask him right now (12:51:06) mattock: sent (12:51:41) syzzer: nice :) (12:51:51) tincantech [~tincantec@unaffiliated/kettlecalling] è entrato nella stanza. (12:51:52) dazo: I added "transport plug-in" to the 2.5 feature list (12:52:37) syzzer: dazo: you have a link handy? (12:52:42) cron2: good point (12:53:53) dazo: syzzer: ? ... to patches? ordex is the one managing that, I think he is getting closer to push something to the ML from the team doing the grunt work (12:54:07) syzzer: dazo: no, the 2.5 featurelist (12:54:10) dazo: ahh (12:54:23) cron2: https://community.openvpn.net/openvpn/wiki/LvivHackathon2018 (12:54:24) vpnHelper: Title: LvivHackathon2018 – OpenVPN Community (at community.openvpn.net) (12:54:32) dazo: https://community.openvpn.net/openvpn/wiki/LvivHackathon2018 ... and I looked at the discussion points from last year: https://community.openvpn.net/openvpn/wiki/KarlsruheHackathon2017 (12:54:33) vpnHelper: Title: KarlsruheHackathon2017 – OpenVPN Community (at community.openvpn.net) (12:54:39) cron2: not sure we have a formal 2.5 page yet (12:54:47) dazo: No, I don't think we do (12:55:09) mattock: let's create one (12:55:16) syzzer: mattock1: +1 (12:55:31) mattock: MSI packaging might be a good goal for 2.5 as well (12:55:36) mattock: both NSI and MSI (12:55:44) mattock: or maybe just MSI... (12:56:30) mattock: in any case, a deadline would be good to get things rolling there (12:57:40) tincantech: be nice to get esayrsa3 in (12:58:12) dazo: isn't easy-rsa 3.0 in the current NSI install packages? (12:58:25) tincantech: no only 2 (12:58:39) mattock: yeah, easyrsa3 would be a fairly trivial addition (12:58:57) dazo: I'd say "skip addition" ... update ;-) (12:59:07) mattock: well yes in the context of 2.5 (12:59:27) dazo: yeah ... for the next 2.4 release, it can be an addition to easy-rsa2 (12:59:34) mattock: I will make some notes to the hackathon page (13:00:00) syzzer: mattock1: were you creating a 2.5 release page, or shall I? (13:00:15) mattock: syzzer: feel free to (13:00:24) mattock: I just added easyrsa3 and MSI as topics for the hackathon (13:01:16) syzzer: will do. Looking if we had such a page for 2.4, but can't find it (13:01:33) syzzer: ah! (13:01:38) syzzer: https://community.openvpn.net/openvpn/wiki/StatusOfOpenvpn24 (13:01:39) vpnHelper: Title: StatusOfOpenvpn24 – OpenVPN Community (at community.openvpn.net) (13:03:40) dazo: hmmm ... I think perhaps we should aim for another round of Debian sync-up :-P https://lists.debian.org/debian-devel-announce/2018/04/msg00006.html (13:03:41) vpnHelper: Title: Bits from the release team: full steam ahead towards buster (at lists.debian.org) (13:03:44) dazo: * 2019-01-12 - Transition freeze (13:03:44) dazo: * 2019-02-12 - Soft-freeze (13:03:44) dazo: * 2019-03-12 - Full-freeze (13:04:19) mattock: sounds quite reasonable (13:04:26) mattock: as long as we don't try to cram too much stuff in (13:04:46) dazo: agreed (13:04:52) cron2: so what does that mean for us? release before 03-12 or 02-12? (13:05:46) cron2: 2.4 release was like "two months of hard work after we thought all the features are in" (13:06:11) dazo: If we manage to have the beta out late November .... and and an RC ready early January, I think we can manage the Debian release date (13:06:19) plaisthos: add OpenSSL 1.1.1 patches to 2.5 (13:06:21) cron2: but we won't maek that (13:06:32) plaisthos: there is also IANA cipher list and other small things (13:06:37) cron2: no way to get all the stuff in until November (13:06:47) ordex: I think we need until the nd of the year to have all the code ready (13:06:50) ordex: *end (13:07:11) mattock: all openvpn inc devs stop what they're doing and start working on 2.5 (13:07:19) mattock: that's the way to reach that deadline :P (13:07:22) plaisthos: mattock1: sure, :) (13:07:27) cron2: works for me :) (13:07:57) dazo: mattock1: that might probably work ... we can discuss this with Francis on Friday (13:08:16) mattock: yeah, and you guys wouldn't really have to stop everything, just allocate a bit more time to 2.5 (13:08:31) mattock: feels like things have moving forward at glacial pace recently (13:08:47) tincantech: because we hasve missed you mattock1 (13:08:50) cron2: the tap driver nightmare sucked up too much energy (13:08:58) mattock: yeah, definitely (13:09:09) dazo: If plaisthos, ordex and I put more time to the 2.5 release, this is not unlikely ... but some of the patch sets would need the eyes of syzzer and cron2 though, but we can do lots of the other grunt work (13:09:28) mattock: and the drama unraveled slowly, so there has not been a point where we could have said "oh, let's just hire a NDIS developer to do the job" (13:10:00) dazo: oh right, the tap-windows6 is the real joker in the v2.5 release (13:10:12) cron2: tap-windows6 needs to be sorted out way sooner (13:10:24) cron2: there is an open security issue in the tap driver... (13:10:32) mattock: two (13:10:56) mattock: but the other is already out there in Git (13:10:59) dazo: I know ... but there seems to be needed to put a lot of efforts into fixing things for the proper certification (13:11:00) cron2: ah (13:11:32) mattock: yes, the work that tap-windows6 needs now is "fluff" to keep HLK/WHQL happy (13:11:37) cron2: dazo: yes... but this nightmare is somewhat independent from 2.5 release - it affects all windows releases (13:11:40) mattock: basically Windows driver development esoteria (13:11:44) dazo: that's right (13:12:00) mattock: hence I will propose that we hire somebody to do the job (13:12:09) mattock: e.g. Thomas Divine who ported tap-windows into tap-windows6 (13:12:17) dazo: mattock1: any chance we can get some help from jkunkee to "loan" some Microsoft resources to fix this? (13:12:29) mattock: well, we can sure ask (13:12:36) plaisthos: also OpenVPN's commercial client depends on it (13:12:37) ordex: at some point we should consider gettind rid of that driver - if you sum up all the effort required to patch and fix and tuck (13:12:44) mattock: then there's the other company (I won't hand out names here) that has the same issue we do (13:13:06) plaisthos: ordex: is there a good alternative? Or are you thinking going the UWP path for community? (13:13:18) mattock: ordex: my main worry is if Microsoft starts requiring WHQL certification for non-server OS (13:13:19) cron2: UWP? (13:13:30) ordex: cron2: new windows API (13:13:32) mattock: universal windows platform? (13:13:34) plaisthos: cron2: universial windows aaPs? or something like that (13:13:37) ordex: plaisthos: I was thinking about a new slimmer driver (13:13:38) dazo: Universal Windows Platform .... has it's own VPN API (13:13:41) cron2: isn't that only available for tile apps? (13:13:55) cron2: so, "full rewrite of everything"? (13:13:58) mattock: ordex: this problem is not tap-windows6 related per se, but to kernel-mode windows drivers in general (13:14:08) mattock: so we need to get rid of the driver to get rid of this problem (13:14:20) cron2: there is a VPN API in Win10, but to my understanding "only for tile apps" (13:14:21) syzzer: Initial page: https://community.openvpn.net/openvpn/wiki/StatusOfOpenvpn25 (13:14:22) vpnHelper: Title: StatusOfOpenvpn25 – OpenVPN Community (at community.openvpn.net) (13:14:38) ordex: I have often heard that the code of the driver itself also carries its own set of issues/complexity, regardless of the kernel-mode (13:14:44) ordex: but I am not deep into the topic (13:14:48) ordex: thanks syzzer (13:15:06) dazo: cron2: lev__ has something working for the OpenVPN3 code base already .... but we've discovered lots of bugs in that API, so it will require a fairly recent Windows 10 to function correctly (and still there are still a few unresolved issues left) (13:15:13) mattock: ordex: probably, but the amount of development effort required by tap-windows6 has been minimal so far (13:15:22) dazo: syzzer++ (13:15:41) mattock: I don't think it is realistic to expect tap-windows6 / kernel driver to go away any time soon (13:15:44) cron2: ordex: the driver isn't that bad. The DHCP hacky bits are hacky, but the code is fairly small. The problematic bits are the NDIS parts we have to implement because they are now mandatory, but that we don't use, so "nobody knows what it's good for" (13:15:53) dazo: mattock1: I agree (13:16:03) ordex: hm interesting (13:16:18) cron2: dazo: interesting (openvpn3/VPN API) (13:16:29) mattock: lev took the beating on that (13:16:35) cron2: ... plus, won't help us for all other windows platforms... (13:16:39) mattock: yeah (13:17:00) cron2: we should just hire Thomas Divine and split the bill with that other company (13:17:14) ordex: remove ENABLE_CRYPTO <<< we are good with this, no ? (13:17:22) plaisthos: I think so (13:17:25) cron2: yep (13:17:29) ordex: ok, I am removing it (13:17:33) ***ordex is editing the page (13:17:36) syzzer: I briefly looked into the UWP VPN API too. My conclusion was that it didn't fit current OpenVPN very well, but that some dirty hacks could make it work for us. (13:18:18) ***ordex saved the page (13:18:18) syzzer: ordex: yeah, thought so too but didn't remember 100%, so just left it up to you guys to update,e xtend, fix, etc. (13:18:46) plaisthos: but the expection that Microsoft has for VPN has (long living TCP control connection) + TCP/UDP data channel is reasonable especially on mobile devices (13:18:49) dazo: the UWP handles VPNs more like a plug-in to Windows .... so it won't be an easy move for OpenVPN 2 -> UWP (13:18:55) plaisthos: but openvpnwas designed in another time (13:19:15) syzzer: ordex: you could have moved it to the 'items already done' section, which would make you the lonely dev to accomplish finishing a 2.5 feature :p (13:19:47) cron2: whee :) (13:19:50) ordex: opsss (13:19:52) ordex: let me move it (13:20:10) lev__: syzzer: we have more-or-less working port of openvpn3 for UWP (13:20:24) syzzer: lev__: ah, cool (13:20:31) ordex: syzzer: is there an "already done" section ? (13:20:36) ordex: ah, that'd be the first (13:20:38) syzzer: bottom of the page (13:20:47) ordex: oh ok (13:21:36) ordex: done (13:23:21) lev__: UWP client is available in Windows Store for restricted audience, DM me if you want to help with testing (13:25:53) syzzer: lev__: sorry - would love to, but too much on the plate currently (13:27:02) dazo: syzzer: pro-tip ... get a bigger plate! :-P (13:27:28) plaisthos: syzzer: did you my question regarding stupid tls-cipher api for tls 1.3 in #openvpn-devel? (13:28:01) syzzer: plaisthos: no, didn't read the backlog yet (13:28:20) plaisthos: ah (13:28:29) plaisthos: in short tls-cipher is only for tls 1.2 and below (13:28:43) plaisthos: and for tls 1.3 cipher list there is a new api (13:28:44) tincantech: syzzer: see https://community.openvpn.net/openvpn/ticket/1118 (13:28:45) vpnHelper: Title: #1118 (OpenVPN 2.4.6 does not respect -tls-cipher priority when using TLS 1.3) – OpenVPN Community (at community.openvpn.net) (13:29:46) plaisthos: so OpenSSL s_client/s_server now have: (13:29:47) plaisthos: -cipher val Specify TLSv1.2 and below cipher list to be used (13:29:50) plaisthos: -ciphersuites val Specify TLSv1.3 ciphersuites to be used (13:30:58) syzzer: ah, expected something like that (13:31:16) syzzer: guess we'll need to add an option too then (13:31:38) dazo: :/ (13:31:50) plaisthos: okay and just ignore it when having no openssl 1.1.1 (13:32:35) syzzer: yeah (13:32:53) dazo: Could we switch the openssl call in the openvpn code, depending on TLS version being used? (13:32:54) syzzer: the cipher suites are sufficiently different that it's never going to be an easy to use api... (13:33:08) syzzer: dazo: we don't know which TLS version will be used (13:33:15) dazo: ahh (13:33:15) syzzer: depends on the peer we connect with (13:33:27) plaisthos: dazo: I think anything other than exposing this idiosyncrasy to users will hurt us as both options are "take strings from users and program should not modify them" (13:33:46) dazo: how will this be handled within mbed TLS? (13:33:57) syzzer: dazo: don't know yet (13:34:09) ordex: we should not make "our API" a clone of the "OpenSSL API" - can't we decide for the user somehow ? (13:34:09) plaisthos: has no 1.3 support yet (13:34:19) plaisthos: ordex: we already do (13:34:20) syzzer: the mbed guys are not saying anything more than "we will support TLS 1.3 at some point" (13:34:25) plaisthos: ordex: we have a sane default for tls-cipher (13:34:32) dazo: I'd say that we should sit on the fence a little bit longer until we know what happens in the mbed TLS ... so that we can have a way to unify those two (13:34:34) plaisthos: and the OpenSSL default for tls-ciphersuite is also sane (13:35:07) syzzer: ordex: the user-friendly API would be to not expose this mess... (13:35:16) syzzer: so we have that now :p (13:35:21) cron2: can we figure out that we just negotiated TLS 1.3 and log a message to that extent? (13:35:22) ordex: plaisthos: does it mean that if a user specifies -ciphersuites to s_client, then s_client will only use tls1.3 ? (13:35:33) ordex: syzzer: :P (13:35:36) cron2: "TLS 1.3 negotiated, ignoring --tls-cipher because OpenSSL"? (13:35:36) syzzer: cron2: yes, we could (13:35:43) dazo: as a side remark ... I'm fairly disappointed how mbed TLS has developed over the later years ... it is not as fast moving as it used to be, almost feels like ARM has put mbed TLS on the back-burner (13:36:22) syzzer: dazo: yes, I'm also getting less enthousiastic about it (13:36:47) plaisthos: ordex: nope (13:36:47) syzzer: the code is still a lot cleaner than OpenSSL's, but on all other fronts OpenSSL is improving a lot faster them mbed is (13:36:55) ordex: it's not the small/clean/agile project it was, I believe (13:36:56) plaisthos: ordex: it only sets the 1.3 tls preferences (13:37:05) ordex: plaisthos: ah ok - bleah (13:37:29) dazo: syzzer: right ... and openssl development is now properly funded ... so it does move better forward, resolving issues faster (13:37:45) plaisthos: I think the most sensible is to add tls-ciphersuites now (13:37:51) syzzer: but... we're running over our hour-mark. should we continue next week? (13:37:54) plaisthos: maybe mark it is as experimential or so (13:38:01) plaisthos: and note it in the manpage (13:38:19) ordex: plaisthos: is there any reasonable way to convert the argument for cipher to ciphersuite ? (13:38:28) plaisthos: ordex: no (13:38:33) syzzer: plaisthos: nah, doesn't need to be experimental I think (13:38:36) lev__: mattock1: I think we need to discuss broken reconnect (13:39:06) plaisthos: ordex: you have to implement logic around OpenSSL logic (13:39:21) ordex: plaisthos: yeah, I didn't mean to pass the same argyument directly (13:39:24) plaisthos: and then OpenSSL adds hacks like @SECLEVL=1 in tls-cipher (13:39:27) lev__: we got many complains from customers who switched from Connect to open source client that reconnect is broken if server uses opt-verify (13:39:27) ordex: but at least we'd hide that logic internally (13:39:43) ***ordex has to go for lunch (13:40:21) mattock: ok sent email to the "other company" asking if they're interested in co-operating with us on the tap-windows6 HLK/WHQL issue (13:40:25) plaisthos: ordex: you could implement something around that but a) would it confuse users since most ssl programs will jsut have two settings from now on and it is also maintainance nightmare (13:40:44) plaisthos: you would have to keep a list which ciphersuite is tl1.2- and which one is 1.3+ in OpenVPN (13:40:57) plaisthos: even for the non common like GOST etc. (13:41:18) mattock: let's close the meeting for today and continue next week as syzzer suggested (13:41:32) cron2: lev__: I hear you. Continue on the list? (13:41:51) mattock: I will prepare meetings on Monday from now on, probably until 2.5 is out (13:41:57) cron2: (And generally speaking, I think --opt-verify in combination with --server is an extremely poor way of handling openvpn 1.x stupidity) (13:41:57) mattock: then we can relax again (13:41:58) mattock: :P (13:42:20) cron2: so maybe we should deprecate --opt-verify + --server in 2.5...? (13:42:31) cron2: mattock1: can you put that on next meeting's agenda? :) (13:42:47) plaisthos: syzzer: I will prepare a --tls-ciphersuite patch then (13:42:51) syzzer: lev__: just to put it out there - does opt-verify still makes sense to use? (13:42:56) mattock: oh, one more thing (13:43:05) mattock: today is the HackerOne demo at 18:00 CEST (13:43:06) syzzer: but still, we need to fix the reconnect (13:43:14) mattock: those who want and can join please do (13:43:15) lev__: I dont know, but for example Access Server uses it (13:43:17) syzzer: plaisthos: +1 (13:43:29) cron2: syzzer: what I said, and "yes" :) (13:43:34) lev__: syzzer: https://patchwork.openvpn.net/patch/467/ (13:43:35) plaisthos: Oh yeah, I still need to figure out, what it is and why my client is included in that program (13:43:36) vpnHelper: Title: [Openvpn-devel,v2] Refactor NCP-negotiable options handling - Patchwork (at patchwork.openvpn.net) (13:43:46) cron2: lev__: last time I looked, Access Server was solidly living in the past... (13:43:57) ***plaisthos knows (13:44:31) cron2: mattock1: wrt hacker one - no promises yet, this is squarely in "kids have dinner now" time. So I might run away earlier (13:44:37) dazo: cron2: Latest AS releases have shipped with v2.4 ... and to my knowledge without any additional patches on top of the community version (13:44:47) plaisthos: cron2: I now also have a hand in AS, if you notice something just scream at me (13:44:54) mattock: I will have to take care of $daughter at the same time, so I will probably mostly listen :P (13:44:54) plaisthos: dazo: almost no patches extra (13:45:05) cron2: dazo, plaisthos: this is good news. (13:45:17) lev__: besides --opt-verify there are scary warnings in logs (13:45:20) cron2: But the mindset behind "using --opt-verify" is still "past" (13:45:29) lev__: (due to options mismatch) (13:45:43) cron2: we should handle option mismatches much better these days, like "just push towards the client what is needed to make things work" (13:45:48) plaisthos: configure --with-crypto-library=mbedtls --disable-plugin-auth-pam --disable-plugin-down-root --disable-pf (13:45:50) dazo: cron2: I'd say the --opt-verify stuff is something we should discuss with James at the hackathon (13:45:50) syzzer: lev__: regardless of opt-verify, we need to fix the bug (13:45:52) syzzer: totally agree (13:45:55) plaisthos: that is the only change to a standard 2.4 (13:46:04) lev__: so I've sent patch to ML which fixes this issue (13:46:09) plaisthos: (and the weird server configuration itself ;)) (13:46:20) syzzer: lev__: yeah, marked it for review, trying to find time to do that... (13:46:21) lev__: syzzer: do you have time to review it ? (13:46:21) cron2: dazo: can you put it on the hackathon page? (13:46:25) dazo: sure! (13:47:14) plaisthos: oh fun, my newest OpenVPN for Android that I pushed for OpenSSL 1.1.1 now segfault in zo1x_decompress_safe+ (13:47:15) cron2: it made sense when so many options couldn't be pushed, but nowadays I find it much better *in a client-server context* to just push what is needed. peer-to-peer is different (no pushing), so there it makes sense (13:47:23) cron2: plaisthos: ouch (13:47:33) cron2: anyway. Kid food time. bbl... (13:47:40) plaisthos: cron2: have fun
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Openvpn-devel mailing list Openvpn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-devel
