Hi, Here's the summary of the previous IRC meeting.
--- COMMUNITY MEETING Place: #openvpn-devel on irc.freenode.net List-Post: openvpn-devel@lists.sourceforge.net Date: Thursday 11th Jul 2013 Time: 18:00 UTC Planned meeting topics for this meeting were on this page: <https://community.openvpn.net/openvpn/wiki/Topics-2013-07-11> Your local meeting time is easy to check from services such as <http://www.timeanddate.com/worldclock> or with $ date -u SUMMARY cron2, dazo, jamesyonan, krzee, mattock, plaisthos and syzzer participated in this meeting. -- Discussed the two-part "TLS versioning" patch: <http://news.gmane.org/find-root.php?message_id=%3c51c77f12.1090...@openvpn.net%3E> <https://github.com/jamesyonan/openvpn/commit/03a5599202bdc3ba07983dc4efdae387fb8fb436> <https://github.com/jamesyonan/openvpn/commit/d23005413b0e0f28a3c48a6342f494763d5c9b40> Also discussed the "setenv opt" patch: <https://github.com/jamesyonan/openvpn/commit/27713761e4110bb92f1c6dfe85db291e8c6e0f56> Both were ACKed in the previous meeting and first one was merged during the meeting. -- Discussed the "Add support to ignore specific options" patch: <http://news.gmane.org/find-root.php?message_id=%3c1371818610-4599-1-git-send-email-a...@rfc2549.org%3E> This patch already has a feature-ACK from the previous meeting. Agreed that the code itself needs some changes before being merged to master. -- Discussed the "Always load intermediate certificates from a PKCS#12 file" patch: <http://news.gmane.org/find-root.php?message_id=%3calpine.deb.2.02.1306201400320.10...@jazz.he.fi%3E> Currently the use of the "ca" parameter prevents any intermediate certificates from a pkcs12 store from being loaded. This patch fixes that behaviour by sending intermediate certificates regardless of the "ca" parameter. Agreed that this patch fixes a bug, and it was given an ACK by jamesyonan, plaisthos and syzzer. Although this patch is OpenSSL-specific, that's not an issue because OpenVPN 3.0 only supports PKCS12 via keychains and PolarSSL does not yet support PKCS12 at all. --- Full chatlog as an attachment -- Samuli Seppänen Community Manager OpenVPN Technologies, Inc irc freenode net: mattock
(21.05.04) mattock: ok, so topic list is here: https://community.openvpn.net/openvpn/wiki/Topics-2013-07-11 (21.05.06) vpnHelper: Title: Topics-2013-07-11 – OpenVPN Community (at community.openvpn.net) (21.05.21) mattock: basically review the remaining unreviewed patches, and if time permits, look at some fairly recent bug reports (21.05.39) mattock: plaisthos has setup a patch tracking page for us (21.06.19) plaisthos: Which may not be complete (21.06.30) mattock: yeah, could be, but we can amend it as necessary (21.06.54) mattock: so, first patch: TLS versioning: http://news.gmane.org/find-root.php?message_id=%3c51c77f12.1090...@openvpn.net%3E (21.06.59) vpnHelper: Title: Gmane Loom (at news.gmane.org) (21.07.03) mattock: was this ACKed already and awaiting merge? (21.07.30) syzzer: I believe so (21.07.34) dazo: I think so too (21.07.51) dazo: cron2 and I have just been too busy ... but I can pull it in now, if I find the ACKs (21.08.04) mattock: ok, next one: "Add support to ignore specific options": http://news.gmane.org/find-root.php?message_id=%3c1371818610-4599-1-git-send-email-a...@rfc2549.org%3E (21.08.07) vpnHelper: Title: Gmane Loom (at news.gmane.org) (21.08.23) mattock: dazo: I think the ACKs are in previous meeting's chatlog (21.08.27) syzzer: dazo: part of the ACK'ing was during the previous meeting I think (21.08.27) mattock: I mean summary (21.09.10) jamesyonan: yes, TLS versioning and "setenv opt" patches were ACKed in last meeting. (21.09.30) mattock: the setenv opt patch is missing from that page, I can summon a link to it (21.09.31) dazo: yepp (21.09.35) cron2: re (21.10.03) mattock: actually, there's a link to that in previous meeting's summary also (21.10.12) cron2: dazo: please do so, so it's done :-) (21.10.51) plaisthos: mattock: the 06-12 OpenVPN versioning (21.11.10) mattock: yep, that big and messy thread :) (21.13.04) mattock: so what about "Add support to ignore specific options": http://news.gmane.org/find-root.php?message_id=%3c1371818610-4599-1-git-send-email-a...@rfc2549.org%3E (21.13.06) vpnHelper: Title: Gmane Loom (at news.gmane.org) (21.13.13) mattock: was this reviewed already? (21.13.43) cron2: it was written to meet what we discussed at one of the previous meetings, so "feature ACK", but I didn't review it yet. (21.13.46) ***cron2 looks (21.13.56) dazo: I think we wanted jamesyonan to have a look at that one (21.13.57) mattock: yeah, that's what I recall also (21.14.44) cron2: dazo: lame excuse :-) - everyone was just too busy (21.14.53) dazo: hehe (21.15.28) dazo: jamesyonan: did you push out your tls-version.patch as a commit? Or do you have a suitable commit message for it handy? (21.15.37) cron2: code-nack, anyway, there's weird stuff happening in the first for() loop which counts up numignored++ to then set it to "i"... (21.17.00) jamesyonan: TLS version negotiation patch is in two parts: (1) https://github.com/jamesyonan/openvpn/commit/03a5599202bdc3ba07983dc4efdae387fb8fb436 and (21.17.01) vpnHelper: Title: TLS version negotiation · 03a5599 · jamesyonan/openvpn · GitHub (at github.com) (21.17.18) jamesyonan: and (2) https://github.com/jamesyonan/openvpn/commit/d23005413b0e0f28a3c48a6342f494763d5c9b40 (21.17.20) vpnHelper: Title: Change to TLS version negotiation patch: remove implicit assumption · d230054 · jamesyonan/openvpn · GitHub (at github.com) (21.17.26) dazo: jamesyonan: ahh, okay ... I'll merge those two messages together (21.17.45) jamesyonan: "setenv opt" patch is here: https://github.com/jamesyonan/openvpn/commit/27713761e4110bb92f1c6dfe85db291e8c6e0f56 (21.17.47) vpnHelper: Title: Added "setenv opt" directive prefix. If present, and if the · 2771376 · jamesyonan/openvpn · GitHub (at github.com) (21.18.00) jamesyonan: both patches should cleanly apply to master (21.18.07) dazo: perfect! (21.19.17) plaisthos: cron2: ah yes. Code is not nice but should work anyway since numignored and i are the same value at that part in the cod (21.19.32) cron2: yeah, but I don't want to commit that :-) (21.20.07) plaisthos: cron2: I will send a fixed version later (21.20.31) plaisthos: But about my patch (21.21.07) cron2: overall I'm fine, I'm just (as usual) picky about the details :) (21.21.14) plaisthos: To ignore more than MAXPARM options I need multiple --ignore-unkown-option statements (21.21.44) plaisthos: At the moment I allocated a new array everytime time with the right siz (21.22.09) plaisthos: there seem to be no way to explicitly free a gc object other than to free the complete gc, right? (21.22.32) cron2: this is not really pretty, but the alternative would be "every new ignore-unknown-option statement overwrites all the previous ones" - which would work, like this: (21.22.37) cron2: ignore-unknown-option foo bar (21.22.38) cron2: foo 123 (21.22.40) cron2: bar 456 (21.22.48) cron2: ignore-unknown-option somethingelse (21.22.52) cron2: somethingelse true (21.23.15) cron2: ... much easier code-wise, but would upset dazo regarding "usage semantics" (21.23.30) plaisthos: And which only works for people who really understand how openvpn parses the config (21.24.53) cron2: or we declare an upper limit of "20 unknown options max"... (21.25.01) dazo: cron2: I can live with that "usage semantic", as long as it's documented in the man page (21.25.22) dazo: that the last usage of that option overrides previous settings (21.25.37) dazo: (that's not an uncommon usage semantic in OpenVPN) (21.26.46) plaisthos: I don't know (21.27.02) plaisthos: perhaps in the future we might to abolish this usage semantic (21.27.24) ***cron2 opts for a static upper limit, and the whole array is allocated once with the max. size, and then only appended to (21.27.27) plaisthos: jamesyonan: how does OpenVPN 3 parse the configuration? Is it still that the latest option "wins?" (21.27.41) jamesyonan: It might be better if multiple ignore-u nknown-option instances append to a global list (21.27.57) cron2: (having a max. of "50" or so wouldn't really harm, given that it only stores pointers - so that's 200 bytes for 50 slots... (21.28.23) dazo: or ... 8 * 50, on 64 bit (21.28.29) jamesyonan: the latest builds of OpenVPN 3 follow the OpenVPN 2 model where latest option wins (for singular options that don't aggregate) (21.28.35) cron2: but on a 64 bit machine, I wouldn't care :) (21.28.43) dazo: heh (21.29.15) dazo: I agree, the static solution for 50 might be good enough, at least for the code simplicity (21.29.29) jamesyonan: you could use a linked list to eliminate memory penalty if option is unused and have potential unlimited size (21.29.29) cron2: ... and it would save 100 bytes of code, at least, and "reallocing using the same effectively-persistent gc" might not be such a good use of memory either (21.29.32) dazo: jamesyonan: which options aggregate today? (21.29.57) plaisthos: cron2: I opted against the static buffer method because I did want to set the limited very high and also I did not want to impose a limit on a function that future version may depend on (21.30.01) plaisthos: dazo: remote (21.30.11) dazo: oh, true! (21.30.26) ***dazo only thought of <connection> blocks, but that's a slightly different story (21.30.28) cron2: how many yet-unknown options do we expect to introduce in the near future? (21.31.11) plaisthos: cron2: we already have some (21.31.11) cron2: s/near/foreseeable/ (21.31.24) plaisthos: like ignore-options ip-win32-method xxxx (21.31.25) jamesyonan: in OpenVPN 3 "ca" and "extra-certs" aggregate (21.31.49) jamesyonan: in addition to remote and <connection> blocks (21.31.58) cron2: plaisthos: indeed, but we're talking about "less than 10" today, so would it be a serious limit if we cap at 50? (21.32.43) mattock: caps can always be upped without breaking anything, right? (21.32.51) cron2: mattock: in that case, no (21.32.55) mattock: ah (21.33.12) plaisthos: to get an idea (21.33.15) cron2: because we're talking about "send configs to old and even older clients that might not be able to handle it" (21.33.27) plaisthos: look at the list in my client to get an idea (21.33.29) plaisthos: http://code.google.com/p/ics-openvpn/source/browse/src/de/blinkt/openvpn/core/ConfigParser.java#231 (21.33.31) vpnHelper: Title: ConfigParser.java - ics-openvpn - Openvpn for Android 4.0+ - Google Project Hosting (at code.google.com) (21.33.32) cron2: so if you can upgrade the client, you wouldn't need the option to be ignored (21.33.44) jamesyonan: plaisthos: what about "ignore-unknown-option" itself crashing earlier OpenVPN versions that don't recognize it? (21.33.59) plaisthos: jamesyonan: sure that is a valid option (21.34.16) jamesyonan: that's why i put "setenv" in my "setenv opt" patch (21.34.22) plaisthos: jamesyonan: I thought as a nicer alternative to setenv opt (21.34.33) plaisthos: a nicer alternative that works on 2.3+ (21.34.36) cron2: plaisthos: but that's a different case again, a pure client importing a ill-understood config that has server-side stuff in it... (21.35.05) plaisthos: cron2: that are all cleint options ;) (21.35.44) cron2: indeed (21.36.26) plaisthos: only as an idea how big the list could be (21.36.29) cron2: but anyway, that's a really special case and not the usage case envisioned for this option: new options that are not *yet* available on clients (as opposed to "will never show up because the platform does it in a different way") (21.36.53) plaisthos: yeah. (21.37.19) plaisthos: But I could (ab)use that option or setenv opt to build a multi platform config (21.38.01) plaisthos: Or do something like routes (21.38.11) plaisthos: ignore-max-options 200 (21.38.25) cron2: yes (21.42.53) mattock: did my IRC client freeze, or did everyone freeze? :P (21.43.01) plaisthos: mattock: everyone (21.43.04) mattock: lol (21.43.19) mattock: ok, so did we reach some sort of consensus, or is everyone pondering what to do with this? (21.43.45) plaisthos: I will try to build a better understandle version of the patch (21.43.51) mattock: ok, let's move on, then (21.44.11) mattock: [PATCH] Always load intermediate certificates froma PKCS#12 file: http://news.gmane.org/find-root.php?message_id=%3calpine.deb.2.02.1306201400320.10...@jazz.he.fi%3E (21.44.13) vpnHelper: Title: Gmane Loom (at news.gmane.org) (21.44.18) mattock: this got a feature-ACK already (21.44.28) mattock: if I recall correctly, some minor changes were requested (21.44.44) mattock: yes, andj said: "One minor nit-picky point: there's a bit of whitespace fixing in there with an extra newline, not sure whether that should be in a separate patch. " (21.45.14) mattock: also, it lacks testing (21.46.21) mattock: maybe we should ask somebody on users list to test this? (21.46.30) mattock: see if it works as it's supposed (21.46.54) mattock: I can try to compile it now, though (21.49.17) cron2: compiling the code is easy, but I can't say I understand the code, so someone with crypto understanding needs to ACK it (21.49.24) cron2: we should poke andj or syzzer... (21.49.30) dazo: or jamesyonan :) (21.49.34) mattock: yeah (21.49.36) cron2: or james :) (21.49.48) ***syzzer wakes up (21.49.51) mattock: jamesyonan: care to take a look? (21.50.14) jamesyonan: looking... (21.50.21) cron2: syzzer: patch is at the URL posted by mattock at 20:44 :) (21.50.29) syzzer: I could take a look, but James probably has a better understanding of openssl (21.53.18) jamesyonan: so if I understand this correctly, if PKCS#12 intermedate certs are not used for trust, this patch will add them to the "extra-certs" list so they can be transmitted to server as supporting certs for the client cert? (21.54.11) plaisthos: jamesyonan: right (21.54.23) plaisthos: (At least what I understood) (21.54.41) dazo: Hes: you around? (21.54.48) dazo: (that's the guy behind this patch) (21.56.39) dazo: jamesyonan: iirc, the use case is that a 3rd party CA provides personal certificates, with a CA certificate embedded ... but the openvpn server uses a certificate from their own CA ... so it's to avoid rejecting valid client certificates (21.57.21) jamesyonan: right, that's what "extra-certs" option is for (21.57.51) plaisthos: and the 3rd party ca "randomly" changes the intermediate certificates but put them into the p12 file (21.57.53) dazo: right, and this particular CA provides only PKCS#12 files .... (21.57.59) dazo: right (21.58.24) jamesyonan: what option is used to trigger this feature (21.58.38) jamesyonan: i.e. what causes load_ca_file to be false (21.58.39) syzzer: not 'only PKCS#12 files' iirc, but that's just the convenient format for the users (21.59.08) plaisthos: jamesyonan: If <ca> is also present the intermediate certificates of the pkcs12 files are ignored (22.00.58) jamesyonan: we need to think this through so it does the right thing on OpenVPN 2/3 and OpenSSL/PolarSSL (22.01.34) dazo: currently polarssl have no pkcs#12 support ... but agreed on 2/3 (22.01.40) mattock: hmm, I'm having issues applying the patch on top of master and release/2.3 branches (22.01.59) jamesyonan: for example on mobile, PKCS#12 files are usually accessed via OS-level keychain (22.02.57) plaisthos: yes (22.03.10) plaisthos: we should do the same logic for them as for /real/ pkcs12 files (22.03.30) plaisthos: I don't know iOS but Anroid does also provide the certificate chain (22.03.32) mattock: ah, the email client cut the lines short (22.04.15) jamesyonan: another example of where this could break things -- on iOS it's normal to include <ca> along with a keychain-stored PKCS12 because ios (as of iOS 6) doesn't give the app the ability to extract the intermediate certs from the PKCS12 (22.04.39) jamesyonan: maybe there should be an explicit option for this such as extra-certs-pkcs12 (22.05.09) jamesyonan: to tell OpenVPN to add the PKCS12 intermediates to extra-certs list rather than ca list (22.06.01) vpnHelper: RSS Update - testtrac: TLS version negotiation <https://github.com/OpenVPN/openvpn/commit/4b67f9849ab3efe89268e01afddc7795f38d0f64> (22.07.53) jamesyonan: I guess I would say that I'm unsatisified with the implicit nature of the option, where the option is enabled if ca is not used (22.08.21) dazo: fair enough (22.09.12) mattock: so explicit option (extra-certs-pkcs12) (22.09.36) mattock: also I didn't manage to apply the patch easily from an MBOX file (22.09.41) mattock: could be some formatting issue (22.10.06) plaisthos: what is doneside of always adding them to the extra list? (22.10.10) plaisthos: does it hurt? (22.11.00) plaisthos: the presence of the ca does only change if the certificates of the pkcs12 are trusted or untrusted (22.11.00) syzzer: they are always added (22.11.17) syzzer: just not trusted when a ca is supplied separately (22.11.31) cron2: syzzer: but that's *with* the patch, isn't it? (22.11.38) syzzer: yes (22.11.47) jamesyonan: what if you have a ca directive but you also want to specify extra-certs-pkcs12 (22.12.26) jamesyonan: or what if you have a pkcs12 file and you want to ignore all but the leaf cert? (22.12.34) syzzer: if your want to also add the certificates from the pks12 as trusted you mean? (22.12.37) plaisthos: jamesyonan: like trusting the ca *and* the pkcs12 certificates? (22.13.08) jamesyonan: well the use case is where the client and server use different CA chains (22.13.31) plaisthos: jamesyonan: yes that is the use case of the patch submitter (22.13.59) syzzer: yes, where the itermediate ca's from the client's might differ, but their always rooted at a known cert (22.14.25) plaisthos: jamesyonan: they set --ca to the CA of the other endpoint (22.14.45) plaisthos: but need reading the certs from the pkcs12 so the server also get the intermediate certificate (22.14.50) syzzer: so you can add the known root cert as an extra cert to your server and with this patch have the clients push their intermediates to the server to complete the chain (22.15.33) jamesyonan: yes, I do agree that the feature is useful, I'm just not sure if making it implicit is the right thing to do (22.16.43) plaisthos: I think current behaviour is worse. (22.17.01) plaisthos: where it completly ignores the pkcs12 extra certs if the --ca option is set (22.17.12) syzzer: I agree with plaisthos (22.17.21) jamesyonan: because by making it implicit you are creating a feature that now causes pkcs12/ca behavior on OpenVPN 2 + OpenSSL to diverge from OpenVPN 3 or PolarSSL usage (22.17.30) syzzer: current behaviour is 'parse the pkcs12 only if no ca is supplied' (22.17.58) syzzer: new behaviour would be 'trust certs from the pkcs12 only if no ca is supplied' (22.18.17) syzzer: but I also agree this implicit behaviour is not very likable (22.18.27) jamesyonan: whereas if you add it as an explicit option, then other platforms/SSL libraries can implement it in their own time without creating any incompatibilties with existing ca/pkcs12 semantics (22.19.06) krzee: sounds like a good case for explicit to me (22.19.19) mattock: yep (22.19.35) mattock: so make this an explicit option (22.19.49) syzzer: what about the current implicit behaviour? (22.19.50) mattock: and fix the funky formatting of the patch... I doubt it was just me (22.20.42) cron2: mattock: if it applied from MBOX, it's just you (22.21.00) ***plaisthos still feels that more a bugfix then a new feature (22.21.42) mattock: somebody else might want to take a shot at applying it, so that if the patch is indeed borked Hes won't accidentally send another broken patch (22.21.56) plaisthos: I mean it is the expected behaviour (22.22.08) plaisthos: at least what I expect from other software that uses TLS (22.22.42) plaisthos: that will also always try to send the extra intermediate certificates to the server (as a client) (22.23.44) jamesyonan: but the feature is being controlled via whether ca directive is present or not (22.25.09) jamesyonan: I actually do agree that expected behavior would be to send full PKCS12 list of CAs to server as supporting chain for client cert, but I don't see why the presence of ca option should affect this (22.26.18) jamesyonan: because "ca" should be used to provide certs that validate server while "extra-certs" and pkcs12 should be used as supporting certs for client cert (22.26.35) plaisthos: jamesyonan: I see the current situation as follows: CUrrently the client sends the correct list of cert if only --pkcs12 is present. If you add a ca option to that working configuration (to do a stricter server validation) the client stops sending the full cert list (22.26.48) jamesyonan: but when a client-cert-side option is being controlled by a server-cert-side option (ca), that seems wrong (22.27.31) syzzer: but this patch should fix exactly that issue, right? (22.28.03) syzzer: because now the certs from the pkcs12 are only sent when no ca is supplied, while after this patch they are always sent (22.28.11) krzee: syzzer, right, but is it a "feature" or a "bugfix" ? (22.28.30) syzzer: I'd say bugfix (22.28.32) krzee: or a feature added to fix a big :D (22.28.35) krzee: bug* (22.29.28) syzzer: as right now the intermediates might be ignored, while they might be needed to verify the chain (22.31.05) MeanderingCode ha abbandonato la stanza (quit: *.net *.split). (22.33.55) mattock: so it the new implicit behavior in this patch more correct than before it? (22.34.23) syzzer: yes, I think so (22.34.42) syzzer: there's less implicit behaviour (22.34.59) mattock: so applying the patch as-is actually makes sense? (22.35.08) mattock: rather than make it explicit (22.35.27) mattock: or should we have an explicit option + change the implicit behavior? (22.35.52) syzzer: before it's 'if ca is set, then do not load intermediates from pkcs12', while after it's 'if ca is set, then do not trust intermediates from pkcs12' (22.36.04) mattock: and we don't want that (22.36.23) ***plaisthos does not see why the current behaviour could be desirable (22.36.37) krzee: <jamesyonan> because by making it implicit you are creating a feature that now causes pkcs12/ca behavior on OpenVPN 2 + OpenSSL to diverge from OpenVPN 3 or PolarSSL usage (22.36.53) mattock: ah, that one (22.37.00) plaisthos: apart from saving a few bytes in the initial connection (22.37.02) syzzer: polarssl doesn't do pkcs12 at all, right/ (22.37.10) mattock: I don't think so, atm (22.37.16) dazo: syzzer: that's right (22.37.28) mattock: https://polarssl.org/discussions/generic/how-to-support-pkcs12-file (22.37.30) krzee: hah im obviously confused, i thought syzzer was the polarssl guy :D (22.37.30) vpnHelper: Title: how to support pkcs#12 file ? - Discussion Forum - PolarSSL (at polarssl.org) (22.37.32) mattock: "no" (22.37.32) jamesyonan: I think PolarSSL is adding PKCS12 support soon (22.37.57) dazo: yeah, I think so too (22.38.07) syzzer: " msg(M_FATAL, "PKCS #12 files not yet supported for PolarSSL.");" (22.38.20) mattock: does that in any way affect the possible ACK/merge of this patch? (22.38.23) jamesyonan: I do tend to agree that this might be viewed as a bugfix (22.38.31) syzzer: so the polarssl bahaviour could be made to match the openssl implementation (22.38.52) MeanderingCode [~meande...@cedarpark.aetherislands.net] è entrato nella stanza. (22.38.58) mattock: jamesyonan: what about openvpn 3? change the implicit behavior to what this patch introduces? (22.39.11) jamesyonan: since in both cases of ca present and not present the patch will still send intermediate certs to server, which is expected behavior (22.39.32) syzzer: yup (22.39.45) jamesyonan: OpenVPN 3 currently only supports PKCS12 through an OS-level keychain (22.39.48) mattock: ah (22.39.53) mattock: so no problem there, I presume (22.40.49) mattock: so if I've read correctly behind the lines, it's an ACK then (22.42.12) mattock: ACK from jamesyonan, plaisthos and syzzer? (22.42.14) syzzer: let's make that explicit then. ACK from me. (22.42.36) mattock: syzzer: uh, make what explicit? the patch or the ACK? :P (22.43.45) mattock: I suggest we stop for today after this patch, as we're at 1:43 already (22.44.05) mattock: I think more frequent but shorter meetings are less tiresome and effective (22.44.10) mattock: I mean more effective <freenode freeze> ... </freenode freeze> (22.54.03) mattock: uh, freenode froze (22.54.24) mattock: was it just me? (22.54.32) syzzer: you've missed out on silence ;) (22.54.39) mattock: I had plenty of silence (22.54.41) syzzer: nopes, 4 quits at the same time (22.54.51) mattock: ok, that explains it (22.55.03) mattock: I thought all of you went to sleep without further comment :P (22.55.08) cron2: I'm still here, and those that went away (except for mattock) didn't say anything anyway :) (22.55.44) mattock: ok, so ACK the last patch (syzzer, jamesyonan, plaisthos) and call it a day (22.56.12) mattock: continue in next meeting that would be nice to have next week (22.56.17) mattock: ok? (22.56.20) plaisthos: ok (22.56.30) syzzer: I'll try, can't promise (22.56.35) mattock: ok, np (22.56.43) cron2: mattock: sounds good to me (22.57.06) mattock: I think the almost weekly meetings were really useful, and we should aim for that if we wish to keep the wheels moving (22.57.30) mattock: I recall we sometimes could get through a meeting in less than an hour even :) (22.57.38) syzzer: btw, I believe the patch from https://community.openvpn.net/openvpn/ticket/304 can be applied too (22.57.40) vpnHelper: Title: #304 (List or indicator of supported tls/ciphers/hashes) – OpenVPN Community (at community.openvpn.net) (22.58.05) mattock: anyways, thanks guys and have good night! (22.58.10) mattock: I'll write the summary tomorrow
