Hi, Here's the summary of the IRC meeting.
--- COMMUNITY MEETING Place: #openvpn-meeting on irc.freenode.net Date: Wed 15th April 2020 Time: 11:30 CEST (09:30 UTC) Planned meeting topics for this meeting were here: <https://community.openvpn.net/openvpn/wiki/Topics-2020-04-15> Your local meeting time is easy to check from services such as <http://www.timeanddate.com/worldclock> SUMMARY cron2, lev, mattock, ordex and plaisthos participated in this meeting. --- Talked about the WolfSSL patches. Agreed that they're much less invasive and hence more acceptable now than previously. Some changes were requested earlier and we're waiting for WolfSSL's response. --- Talked about the upcoming OpenVPN 2.4.9 release. It will include an important security fix and a few other things we wish to get in: - NCP async fix from lev - two patches from Selva - the ecliptic curve patch (1/3) Agreed that we should have a CVE for the security issue. Dazo had promised to resurface at 14:00 CEST today, which means he can probably handle the CVE generation as usual. Our goal is to release 2.4.9 tomorrow, if possible. --- Mattock will check if it would be possible to give unique identifiers to Windows 7 and Windows 10 flavors of tap-windows6. This would prevent situations where an existing, cached Windows 7 driver is preferred over a Windows 10 (attestation signed) version, hence causing driver installation failures. Mattock will also check if we could, with a reasonable effort, provide users with an easy way to clean up old tap-windows6 drivers in the NSIS installer. The process is already known and can be done with external scripts, but integration / reimplementation in NSIS is missing. These changes would be nice to have in 2.4.9-I601, but we can postpone them to another Windows installer release if needed. -- Full chatlog attached
(12:31:17) mattock: meeting time (12:31:21) cron2: hooray (12:31:25) lev__: hello (12:31:54) mattock: hi guys! (12:32:27) plaisthos: hey! (12:34:27) mattock: https://community.openvpn.net/openvpn/wiki/Topics-2020-04-15 (12:34:51) plaisthos: Okay I will just start with one topic, the quality of the WolfSSL patch approaches a level that might consider it for inclusion (12:35:36) plaisthos: but I would put a note there that it is in the not actively supported by the community project and bugs/problem with it that cannot replicated with OpenSSL need to be reported to WolfSSL (12:35:40) ordex: hi (12:35:46) plaisthos: hey ordex (12:36:18) ordex: well, issues will be reported to our mailing list in any case (12:36:33) ordex: we just have to ensure that wolfssl will stick to the list (12:37:05) cron2: I am fine with merging the patch, as it has nearly no code changes anymore, just pushing autoconf towards "yes, this function is there, even if it's a macro and you can't see it" (12:37:32) ordex: yup (12:37:35) ordex: much better (12:37:36) cron2: and yes, documentation needs to be clear "this is not something we test, so if there are problems, talk to WolfSSL" (12:38:24) ordex: can't the cryptoapi check be performed at configure time ? (12:38:29) ordex: why an #error in the code ? (12:39:38) cron2: ENABLE_CRYPTOAPI is not coming "from configure" but from syshead.h (12:39:44) plaisthos: it basically breaks the build on win32 (12:39:48) cron2: but I think the #error is more an extra saveguard, because (12:39:53) cron2: #if defined(_WIN32) && defined(ENABLE_CRYPTO) && defined(ENABLE_CRYPTO_OPENSSL) (12:39:56) cron2: #define ENABLE_CRYPTOAPI (12:39:59) cron2: #endif (12:39:59) cron2: oh (12:40:06) ordex: ah, so it's a windows thing only (12:40:21) plaisthos: yeah cryptoapi is the windows key sotre (12:40:23) ordex: but it needs ENABLE_CRYPTO_OPENSSL (12:40:30) ordex: which on't be the case with WOLFSSL, no ? (12:40:48) cron2: mmmh, now if WolfSSL enables ENABLE_CRYPTO_OPENSSL, which I think it needs to do (otherwise, we won't compile the openssl stuff...), it will break windows builds (12:40:51) plaisthos: ah yes (12:41:12) ordex: ah (12:41:19) cron2: ssl_openssl.c is guarded by "#if defined(ENABLE_CRYPTO) && defined(ENABLE_CRYPTO_OPENSSL)" (12:41:26) cron2: and WolfSSL provides "openssl compat" headers + API (12:41:45) plaisthos: yeah basically wolfssl is not working on win32 (12:41:51) ordex: yeah (12:41:56) plaisthos: something that I can live with (12:41:58) cron2: I think that #error is not good. They should adjust syshead.h instead, and have an extra WolfSSL check there (12:42:03) ordex: right (12:42:15) ordex: like: #if defined(_WIN32) && defined(ENABLE_CRYPTO) && defined(ENABLE_CRYPTO_OPENSSL) && !defined(ENABLE_CRYPTO_WOLFSSL) (12:42:17) ordex: no ? (12:42:20) plaisthos: cron2: I think the cryptoapi stuff might be called in more places (12:42:37) plaisthos: that might have the wrong ifdef or so (12:42:38) cron2: plaisthos: it should all be wrapped with ENABLE_CRYPTOAPI (12:42:51) cron2: so if we just not define it ("like when building with mbedtls")... (12:43:05) plaisthos: but I don't really care. If they do not care about win32 support, we should not fix it for them (12:43:19) plaisthos: cron2: might have something like if (ossl) in a larger win32 block (12:43:47) ordex: but the problem is only about cryptoapi - not windows in general (12:44:00) ordex: they just have to avoid defining cryptoapi if wolfssl is used, no (12:44:01) ordex: ? (12:44:07) cron2: plaisthos: well, I'd consider this a bug on our side... if we call cryptoapi stuff outside an ENABLE_CRYPTOAPI block, our code is buggy (12:44:22) ordex: agreed (12:45:54) plaisthos: cron2: yes it is a bug on our side (12:46:25) plaisthos: but I just wanted to express that we should just not invest time now in it if there is no strong need fror it (12:46:39) cron2: right (12:47:24) plaisthos: I can prepare a text for README.wolfssl (12:47:38) plaisthos: and post it first here/#openvpn-devel and then later on the mailing list (12:49:22) cron2: yep (12:49:37) mattock: +1 (12:50:38) cron2: so - wolfssl covered? (12:50:48) cron2: (I have sent my concerns about that #error back to the list already) (12:51:09) ordex: sounds good (12:51:14) plaisthos: and I asked why it needs an OpenSSL 1.0.1d workaround :P (12:51:21) cron2: yep (12:51:35) cron2: patchwork set to "changes requested" (12:51:56) plaisthos: +1 (12:52:08) ordex: goood (12:52:24) ordex: the 1.0.1d workaround sounds like something they could fix in their compat thing anyway :-P (12:52:30) ordex: just trying to push the complexity elsewhere hehe (12:52:53) cron2: or leftover from previous versions (12:53:00) plaisthos: also it feels that would break in other project that try to use it without the workaround (12:53:28) plaisthos: also we probably will get rid of all the < 1.0.2 stuff once RHEL6 reaches EOL (12:53:49) cron2: amazeballs (12:54:21) ordex: hehe (12:54:50) plaisthos: which is nov this year (12:54:57) plaisthos: so we might drop that in master soon (12:55:53) ***ordex likes (12:56:35) plaisthos: so 2.4.9 release (12:56:36) ***cron2 sees an ACK and likes that :) (12:56:45) cron2: yes. (12:56:49) cron2: can one of you reach dazo? (12:57:20) cron2: m-a thinks we should have a CVE for that bug... I'm unsure, but in any case we'd need dazo to get one (12:57:21) plaisthos: yeah he got stuck with kids! (12:57:30) cron2: how could that happen (12:57:47) cron2: anyway (12:58:10) lev__: cron2: you mean float bug? (12:58:14) cron2: mattock: we want a 2.4.x release soon, because the bug in floating warrants a "soon!" release, and there is other good stuff in 2.4 that we want out (12:58:17) cron2: lev__: yes (12:58:21) mattock: yes (12:58:42) mattock: is all the "other good stuff" already in? (12:58:45) plaisthos: I think we should include the Fix OpenSSL 1.1.1 not using auto ecliptic curve selection also in 2.4.9 (12:58:57) cron2: on my list is the NCP async fix from lev plus two patches from Selva that he wants in 2.4, plus the ecliptic curve patch (12:59:12) cron2: plaisthos: only 1/3 (the #ifdef jungle) or the whole patch set? (12:59:14) plaisthos: the tls-group stuff is no important because it is only required for exotic curves (12:59:22) cron2: okay, only 1/3 is it, then (12:59:51) plaisthos: tls-group is kinda required if you do not use one of 5 standard curves (13:00:47) ordex: should tls-group be just master material ? (13:00:50) ordex: while 1/3 also for 2.4 ? (13:00:51) mattock: if all the stuff is in by tomorrow morning my time I can do the release tomorrow - otherwise it might have to be postponed to monday (friday is fragmented) (13:01:17) plaisthos: the question is basically how much do you care for people with OpenSSL 1.1.1 and exotic curves (13:01:33) cron2: mattock: okay. This is a clear mandate to me :) (13:01:49) ordex: well, the question is: is it a feature? or are we fixing something that right now breaks? to me it sound slike we are supporting new functionalities (13:02:02) plaisthos: both actually (13:02:07) ordex: exotic curves? not supported yet (13:02:42) ordex: hmm something is broken/buggy right now ? (13:03:35) plaisthos: with openssl 1.0.2/mbedtls exotic curves work since it only used when you use a certificate with that curve (13:03:51) plaisthos: with tls 1.3 ec is also used in ecdh with rsa certificate (13:03:56) plaisthos: so it got decoupled (13:04:25) plaisthos: so you know have a list of curves/groups that are supported and if your cert curve is not in that list, your connection does not work (13:04:51) plaisthos: e.g. if you have a brainpool curve cert, it will work with OpenVPN/OpenSSL 1.0.2 or OpenVPN/mbedTLS (13:05:12) plaisthos: but if you use OpenSSL 1.1.1, you need to override tls-groups to include brainpool (13:05:32) cron2: shouldn't the "/* OpenSSL 1.1.0 and newer have always ecdh auto loading enabled," comment be *after* the #endif, matching the "return" part? (13:05:36) ordex: yeah, still sounds like an unsupported setup (13:06:40) plaisthos: cron2: I put it in the ifdef, so it gets removed when we remove the ifdef for older version (13:07:19) ordex: or maybe it should go on top of the ifdef <1.1.0 ? (13:07:28) ordex: to explain why that if is needed ? (13:07:38) plaisthos: yeah it is quite exotic and I don't think we need to force it into this release (13:07:46) ordex: yap (13:08:58) cron2: the code flow in that function hurts my brain (13:09:12) ordex: yeah (13:09:15) ordex: it's a jungle .. (13:09:20) ordex: but I'd leave the re-style for later (13:09:26) plaisthos: yeah syzzer and I did not catch this when we reviewed that patch (13:10:18) cron2: especially since the code does "more things after the #if jungle, but only if older openssl, which is not obvious due to the returns out of the #if block (13:10:32) cron2: and only for non-default curves (13:10:36) ordex: yeah (13:10:48) ***cron2 gets some booze and just merges this (13:10:51) ordex: I'd love to see the entire thing refactored (13:10:52) plaisthos: or does more things if you have tls-ecdh-curve sets (13:10:56) ordex: but not in release/2.4 (13:11:29) plaisthos: my tls-group patch actually discourages from using ecdh-curve (13:12:05) plaisthos: since the first group is actually the preferred ecdh curve (13:13:59) ordex: the code is still a jungle :p (13:14:00) ordex: hehe (13:14:40) mattock: done with 2.4.9? (13:14:48) mattock: we have 15 (full) minutes (13:14:58) mattock: "release tomorrow" is the goal (13:15:06) ordex: do we need the CVE before releasing ? (13:15:26) plaisthos: hm (13:15:30) cron2: it should go to the announcement and commit, so, yes (13:15:44) cron2: if CVE at all (13:16:23) mattock: I thought I saw dazo here but no (13:16:30) cron2: so, any *other* patches we want in 2.4 that have not yet been mentioned? (13:16:52) plaisthos: auth-token is only 2.5, right? (13:17:22) cron2: the server side is 2.5 (13:17:25) plaisthos: lev__: your async push with ncp, is that 2.4 or 2.5 only? (13:17:30) lev__: both (13:17:42) cron2: that is both, and on my list already ("a review would be nice") (13:18:37) plaisthos: I will review it later then (13:18:59) mattock: can we make dazo create a CVE today? (13:19:09) lev__: plaisthos: se the last comment https://community.openvpn.net/openvpn/ticket/1259 (13:19:13) lev__: *see (13:19:26) cron2: mattock: dunno, haven't seen anything from him in the last two weeks :( (13:20:18) plaisthos: he was on vacation the last two weeks :D (13:20:56) mattock: what shall we do if he remains hidden? (13:21:15) mattock: definitely not postpone the release (13:21:39) ordex: he should be online in the afternoon after 2pm (13:21:44) cron2: he was using a contact at RedHat, if I remember right, to get the CVE number. Maybe we can go via OSTIF / Derek? (13:21:44) ordex: we can poke him and see what he says (13:21:45) lev__: he promised to appear at 14.00 CET (13:21:50) cron2: good enough (13:22:01) mattock: Derek has been missing for ~2 months (13:22:04) ordex: CEST !! we are in summer now (13:22:07) cron2: ewww (13:22:30) mattock: but if dazo resurfaces at 14:00 CEST then we should be ok (13:22:38) ordex: yap (13:22:39) lev__: ordex: it is snowing here right now (13:22:45) ordex: let's reconvene later then (13:22:50) mattock: it was snowing here yesterday and the day before (13:22:50) ordex: lev__: that's your problem!! (13:22:51) ordex: hehe (13:22:55) ordex: lol (13:23:00) mattock: now the sun is shining beautifully (13:23:04) mattock: anyhow (13:23:10) ordex: :) (13:23:12) mattock: shall we conclude the meeting or do we have something else? (13:23:37) ordex: I don't have anything (13:23:42) cron2: 2.5? (13:23:47) cron2: MSI? (13:23:55) cron2: ah, yes (13:24:07) lev__: yeah we need to start testing MSI installer (13:24:10) mattock: no progress on MSI front, don't want to just poke it but fully focus on it (13:24:11) cron2: mattock: what shall we do with the TAP driver complications for 2.4.9? (13:24:16) mattock: lev and I agreed to start looking into it (13:24:27) cron2: so, NSIS installer and tap stuff (13:24:29) mattock: you mean the certificate warning on Windows 7? (13:24:43) cron2: no, the install failure on win10 if that machine has seen a win7 driver before (13:24:47) mattock: ah that one (13:24:55) mattock: hmm (13:25:04) mattock: can't recall what the plan was exactly (13:25:09) plaisthos: it actually snowed here monday morning briefly (13:25:17) cron2: mattock: "unique identifiers" was one of the options (13:25:39) mattock: I need to dig up the plan/discussion to understand if this is a trivial thing to do, or something that takes time (13:25:47) cron2: please :) (13:26:04) mattock: my hunch is "non-trivial", but we'll see (13:26:24) cron2: but we need a solution there (... which could come as a I602 re-spin, but nevertheless) (13:26:42) mattock: yep, no need to force-feed it in first 2.4.9 release (13:26:48) mattock: if time is scarse (13:26:53) mattock: anyhow (13:26:55) cron2: the second thing was "can we have a '[X] remove all remainders of existing tap drivers' checkbox" in the installer, to do the TAP-cleanup (13:27:09) cron2: (off-by-default, just for people that have installation pains) (13:28:15) mattock: it might be enough to just document this well enough - I don't think we will be able to catch the error in the installer to provide any meaningful error message (13:28:55) mattock: which means people will need to figure out what the problem is, and we should make that figuring out as easy as possible (e.g. INSTALL-win32.txt, Wiki, etc) (13:29:09) cron2: I do not want meaningful error messages, I just want installers that succeed (13:29:18) mattock: easier said than done (13:29:39) mattock: we'd need to catch the error or somehow figure out the issue before running the installer (13:29:44) mattock: anyhow (13:29:48) mattock: I'll take a look (13:29:52) cron2: so said checkbox would be a kludge for "more force is required" - you do have all the tools today to remove tap drivers from the system, we just do not give users an ways way to enable them (13:30:00) cron2: so, the strategy is twofold (13:30:22) cron2: - reference the win10 driver with a difference unique identifier than the win7 driver, so we get what we ask for, not "what windows think there is already installed" (13:30:35) mattock: well yeah now it comes back to me (13:30:46) cron2: - provide an easy way to clean up the tap install, without having to download extra scripts and instructions (13:31:00) cron2: ("if it fails with a weird tap driver error, try re-installing with that checkbox enabled") (13:32:07) mattock: I don't look forward to doing the latter in NSIS (13:32:15) mattock: but I will check how much pain it would be (13:32:22) cron2: appreciated :) (13:32:25) mattock: anyhow, overtime and need to go get some lunch (13:32:27) cron2: and with that, our time is over (13:32:28) cron2: enjoy (13:32:33) mattock: thanks!
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Openvpn-devel mailing list Openvpn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-devel
