Hi, Here's the summary of the previous IRC meeting / sprint.
--- COMMUNITY MEETING Place: #openvpn-devel on irc.freenode.net List-Post: openvpn-devel@lists.sourceforge.net Date: Thursday 11th Aug 2011 Time: 17:00 UTC Planned meeting topics for this meeting were on this page: <https://community.openvpn.net/openvpn/wiki/Topics-2011-08-11> Next meeting will be announced in advance, but will probably be on the same weekday and at the same time. Your local meeting time is easy to check from services such as <http://www.timeanddate.com/world clock> or with $ date -u SUMMARY andj, dazo, jamesyonan, mattock and s7r participated in this meeting. -- The first part of this meeting was sprint, where Adriaan's (andj's) PolarSSL patches were reviewed, fixed and ACKed on the fly. The sprint focused on the "Verification functions" patchset. The status of the patches after the meeting can be viewed from here: <https://community.openvpn.net/openvpn/wiki/PolarSSLintegration?version=35#Verificationfunctions> As can be seen, all "Verification function" patches now have an ACK. The ACK status _before_ the meeting is on version 28 of that page. If you have any comments regarding any of the patches, please chime in. If there are no complaints, the ACKed patches will be merged to the main Git repository soon. -- The second part of the meeting focus on more generic things. First, discussed the "Cannot access Syspro 6.0 Server with 2.2RC or 2.2.0" bug: <https://community.openvpn.net/openvpn/ticket/126> Although it is likely that the bug is triggered by the new IPv6-enabled TAP-driver in 2.2 series, more information is needed. The requests for this information along with instructions were appended to the bug report, as well as ideas for reproducing this issue artificially. If none of the bug reporters respond, mattock will try contacting them via email. -- Discussed OpenVPN 2.3 release. The remaining tickets are visible here (milestones 2.3 release/beta): <https://community.openvpn.net/openvpn/report/3> A few of those bugs have been fixed and ACKed, but have not yet been merged to "master". The only major thing holding back the release is the PolarSSL patchset: <https://community.openvpn.net/openvpn/wiki/PolarSSLintegration> It will take 4-5 IRC sprints to go through the remaining patches. Decided to try to get first OpenVPN 2.3 alpha out during September. --- Full chatlog as an attachment -- Samuli Seppänen Community Manager OpenVPN Technologies, Inc irc freenode net: mattock
<mattock> [11-08 19:15:32] jamesyonan: hi! <andj> [11-08 19:15:37] hi <jamesyonan> [11-08 19:15:44] hi guys <mattock> [11-08 19:16:26] ok, here's the topic list: https://community.openvpn.net/openvpn/wiki/Topics-2011-08-11 <vpnHelper> [11-08 19:16:27] Title: Topics-2011-08-11 â OpenVPN Community (at community.openvpn.net) <mattock> [11-08 19:16:33] I propose we start with PolarSSL <andj> [11-08 19:16:43] until dazo gets here at least <mattock> [11-08 19:16:44] and if dazo attends later, we can discuss 2.2.2 and 2.3 <mattock> [11-08 19:16:48] yeah <andj> [11-08 19:16:58] PolarSSL 1.0.0 got released the other day <andj> [11-08 19:17:14] which means there's a nice stable base to build the patches on <mattock> [11-08 19:17:21] jamesyonan: I won't be available between 8:35 - 9:10 PM (catching a train) <mattock> [11-08 19:17:37] but I'll catch up in the train <andj> [11-08 19:17:39] I'll check whether any new stuff will be required <andj> [11-08 19:17:52] for the openvpn patches <mattock> [11-08 19:18:34] andj: maybe another (smaller) round of patches? <andj> [11-08 19:18:58] Don't think there'll be a large difference, the patches were based on 0.99-pre5 <andj> [11-08 19:19:06] But I'll check in the next few days <andj> [11-08 19:19:24] mattock: shall I keep the wiki up-to-date? <andj> [11-08 19:19:37] since you're running after trains and all that <mattock> [11-08 19:19:38] andj: if you can <mattock> [11-08 19:19:47] I can do it for now <mattock> [11-08 19:19:58] shall we start? <andj> [11-08 19:20:08] ok <andj> [11-08 19:20:16] https://github.com/andj/openvpn-ssl-refactoring/commit/840d040a2552da07e948732ffba4dd6ed39581c1 <vpnHelper> [11-08 19:20:17] Title: Commit 840d040a2552da07e948732ffba4dd6ed39581c1 to andj/openvpn-ssl-refactoring - GitHub (at github.com) <andj> [11-08 19:20:32] is the first on, just minor cleanup after all the previous refactoring <andj> [11-08 19:20:36] *one <andj> [11-08 19:22:25] Most of the verifcation ones shouldn't be too complex <jamesyonan> [11-08 19:23:16] that looks fine <andj> [11-08 19:23:27] cool, next one: https://github.com/andj/openvpn-ssl-refactoring/commit/3d5d5b3649f46bd812c146a731fba295473eeeb8 <vpnHelper> [11-08 19:23:28] Title: Commit 3d5d5b3649f46bd812c146a731fba295473eeeb8 to andj/openvpn-ssl-refactoring - GitHub (at github.com) <andj> [11-08 19:23:44] That one just hides the openssl-specific error reporting <andj> [11-08 19:24:27] At some point it should be migrated out of error.c, but now isn't quite the time <jamesyonan> [11-08 19:26:10] right, looks good <andj> [11-08 19:26:14] Straightforward rename: https://github.com/andj/openvpn-ssl-refactoring/commit/368b49096911dfa6b4f1cbf651a2df8ac3d5e937 <vpnHelper> [11-08 19:26:15] Title: Commit 368b49096911dfa6b4f1cbf651a2df8ac3d5e937 to andj/openvpn-ssl-refactoring - GitHub (at github.com) <andj> [11-08 19:26:25] reame the x509 backend function to x509_* <jamesyonan> [11-08 19:28:34] looks good <andj> [11-08 19:28:37] https://github.com/andj/openvpn-ssl-refactoring/commit/11e94d8da97765571ecf91c512bcc559507e5f3b <vpnHelper> [11-08 19:28:38] Title: Commit 11e94d8da97765571ecf91c512bcc559507e5f3b to andj/openvpn-ssl-refactoring - GitHub (at github.com) <andj> [11-08 19:28:43] Is slightly more complex <andj> [11-08 19:28:54] migrates the openssl-specific pkcs#11 stuff <andj> [11-08 19:28:59] https://gist.github.com/1139976 <vpnHelper> [11-08 19:29:01] Title: andj's gist: 1139976 Gist (at gist.github.com) <andj> [11-08 19:29:03] is the matching gist <andj> [11-08 19:29:36] But that has some diff-artifacts unfortunately <mattock> [11-08 19:34:25] mmm... got to go now, wiki page updated up to this point <andj> [11-08 19:34:35] ok, I'll start editing <andj> [11-08 19:34:40] thanks, see you later <mattock> [11-08 19:36:06] no prob! <mattock> [11-08 19:36:39] I'll login to the IRC from my selfphone and get going :) <mattock> [11-08 19:36:41] bye <andj> [11-08 19:36:46] cya <andj> [11-08 19:40:34] any questions, james? <jamesyonan> [11-08 19:41:54] yes, re: goto cleanup, am I correct that cleanup is not at the end of the function? <andj> [11-08 19:42:26] which line? <jamesyonan> [11-08 19:43:14] 102 in the gist <andj> [11-08 19:44:14] no, it's at the end <andj> [11-08 19:44:19] the cleanup is just very long <jamesyonan> [11-08 19:44:23] actually, never mind, you're right <jamesyonan> [11-08 19:44:54] what about the stuff that starts at 229? <andj> [11-08 19:45:10] It's unfortunate that the gist didn't match well <andj> [11-08 19:45:12] let me check <andj> [11-08 19:47:36] That's there to prevent errors due to the handoff of responsiblity for that memory to pkcs11 helper <andj> [11-08 19:47:46] Just an extra safeguard <andj> [11-08 19:48:04] if all goes well, certificate should not be freed * dazo [11-08 19:48:26] is back * andj [11-08 19:48:41] waves <jamesyonan> [11-08 19:48:45] where is the corresponding stuff in the regular diff? <andj> [11-08 19:48:57] checking now <jamesyonan> [11-08 19:49:10] hi dazo <dazo> [11-08 19:49:23] jamesyonan: hey! <andj> [11-08 19:52:30] jamesyonan: looks like it's being freed in pkcs11_init_tls_session (the new function) <andj> [11-08 19:53:58] So, at https://github.com/andj/openvpn-ssl-refactoring/commit/11e94d8da97765571ecf91c512bcc559507e5f3b#L4R89 <vpnHelper> [11-08 19:53:59] Title: Commit 11e94d8da97765571ecf91c512bcc559507e5f3b to andj/openvpn-ssl-refactoring - GitHub (at github.com) <andj> [11-08 19:56:10] is that ok? <jamesyonan> [11-08 19:56:14] where is the non-error path in pkcs11_init_tls_session? <andj> [11-08 19:57:16] that is the non-error path I think <andj> [11-08 19:57:54] I think, if I remember correctly that it has to do with OpenSSL reference counting <jamesyonan> [11-08 19:59:13] yeah, OpenSSL is sometimes vague about documenting whether functions increment refcount or merely borrow an existing reference <andj> [11-08 19:59:47] anyway, the behaviour doesn't change <jamesyonan> [11-08 20:00:01] yes, it looks good <andj> [11-08 20:00:26] It's been a bit too long, but I vaguely remember reference counting issues there <andj> [11-08 20:00:51] ok, next one is simple: https://github.com/andj/openvpn-ssl-refactoring/commit/7c6edbb0e507f8980b83208c43844d6a0bd582ac <vpnHelper> [11-08 20:00:52] Title: Commit 7c6edbb0e507f8980b83208c43844d6a0bd582ac to andj/openvpn-ssl-refactoring - GitHub (at github.com) <andj> [11-08 20:01:07] there was a conflict in naming the base64_ stuff <jamesyonan> [11-08 20:01:16] when you tested this stuff, did you use any memory checking tools such as valgrind? <andj> [11-08 20:01:37] I regularly ran valgrind in my tests setup <jamesyonan> [11-08 20:01:44] great <andj> [11-08 20:01:50] none of the DMALLOC stuff though <jamesyonan> [11-08 20:02:06] valgrind is more complete than DMALLOC * andj [11-08 20:02:17] loves valgrind <jamesyonan> [11-08 20:02:27] but DMALLOC is more portable (to windows for example) <andj> [11-08 20:02:54] hmm, never really played with it, I'll have a look at it given time :) <andj> [11-08 20:03:45] Anyway, if the last one was ok, the base64 one is pretty simple again, just a straightforward rename, to prevent a symbol conflict in polarsslhttps://github.com/andj/openvpn-ssl-refactoring/commit/7c6edbb0e507f8980b83208c43844d6a0bd582ac <vpnHelper> [11-08 20:03:46] Title: Commit 7c6edbb0e507f8980b83208c43844d6a0bd582ac to andj/openvpn-ssl-refactoring - GitHub (at github.com) <jamesyonan> [11-08 20:03:47] the OpenVPN Project actually has access to Coverity Prevent which is a kind of valgrind that runs at compile time rather than run time <andj> [11-08 20:04:33] That's pretty cool <andj> [11-08 20:04:47] As an outreach project to open source? <jamesyonan> [11-08 20:04:51] it would be worthwhile to try to run this patch through it <jamesyonan> [11-08 20:04:53] yes <andj> [11-08 20:05:09] I'd love to hear the results of that <dazo> [11-08 20:05:50] mattock has managed to get our master branch tracked through Coverity <jamesyonan> [11-08 20:06:02] mattock: can we get andj access to Coverity so he can run his patches through it? <andj> [11-08 20:06:28] perhaps we should wait until it's in master, as that's already tracked <andj> [11-08 20:06:40] I promise I won't run away if fixes are needed <andj> [11-08 20:06:53] :) <dazo> [11-08 20:07:01] They don't pull our stuff too frequently, but we're aiming at getting them to do that when we're getting ready for an alpha/beta release <dazo> [11-08 20:08:09] IIRC, there are ~160 remarks in the code, at first glance quite some of them was most likely false positives <mattock_> [11-08 20:09:15] jamesyonan: re: coverity: that is a little difficult... they can only track one branch/tree <andj> [11-08 20:09:40] I'll fix any stuff that comes up during pre-alpha runs <andj> [11-08 20:09:54] jamesyonan: base64 patch ok? <mattock_> [11-08 20:09:59] but we can get them to update the codebase to first 2.3 alpha <jamesyonan> [11-08 20:10:56] base64 patch looks fine <andj> [11-08 20:11:21] ok, second to last verify patch : https://github.com/andj/openvpn-ssl-refactoring/commit/03225fa7939b9bab6f69b50b36af30565692ad51 <vpnHelper> [11-08 20:11:22] Title: Commit 03225fa7939b9bab6f69b50b36af30565692ad51 to andj/openvpn-ssl-refactoring - GitHub (at github.com) <andj> [11-08 20:11:39] basically some final cleanup before polar goes in <andj> [11-08 20:11:51] diff-diff here: https://gist.github.com/1139983 <vpnHelper> [11-08 20:11:52] Title: andj's gist: 1139983 Gist (at gist.github.com) <andj> [11-08 20:12:06] But it's not very useful <jamesyonan> [11-08 20:14:06] what are the changes to tls_ctx_load_extra_certs? <andj> [11-08 20:15:03] I think it just got moved <andj> [11-08 20:15:14] yeah, just got moved in the file <jamesyonan> [11-08 20:16:08] sure, that looks fine <andj> [11-08 20:16:26] last one: https://github.com/andj/openvpn-ssl-refactoring/commit/d235530fe14ccca5b9ef12bfbbd367c78d069e43 <vpnHelper> [11-08 20:16:28] Title: Commit d235530fe14ccca5b9ef12bfbbd367c78d069e43 to andj/openvpn-ssl-refactoring - GitHub (at github.com) <andj> [11-08 20:16:34] https://gist.github.com/1139987 <mattock> [11-08 20:16:34] back <vpnHelper> [11-08 20:16:36] Title: andj's gist: 1139987 Gist (at gist.github.com) <andj> [11-08 20:17:03] moves the tracking stuff to openssl <mattock> [11-08 20:19:51] andj: all previous patches ACKed? <andj> [11-08 20:20:03] yup, and still have the wiki open <mattock> [11-08 20:20:07] ok <mattock> [11-08 20:20:15] I won't edit the page, then <andj> [11-08 20:20:25] I can close it, if you want <mattock> [11-08 20:21:06] andj: ok <jamesyonan> [11-08 20:21:07] so there's no actual code changes here -- just moving stuff around? <andj> [11-08 20:21:34] There is a change: PolarSSL won't support it for nw <andj> [11-08 20:21:40] *now <andj> [11-08 20:21:55] but no, nothing for OpenSSL <andj> [11-08 20:22:53] I do (secretely) have two more related patches <andj> [11-08 20:23:01] since we spoke about them last week <jamesyonan> [11-08 20:23:02] it's useful when you want to have custom scripts look at arbitrary cert fields <andj> [11-08 20:23:15] I know, and I hope to implement it in the future <andj> [11-08 20:23:35] But first some extra support is needed in Polar <andj> [11-08 20:24:11] Not sure whether Polar wants it though, it would involve a large increase in code size <andj> [11-08 20:24:25] and for a library that aims to stay small... <jamesyonan> [11-08 20:24:53] yeah, but doesn't Polar already need x509/asn1 stuff for extracting common name, etc? <andj> [11-08 20:25:00] james: is the patch ok? <jamesyonan> [11-08 20:25:12] yes, patch is fine <andj> [11-08 20:25:14] yeah, but it's kept limited to only the required fields <andj> [11-08 20:25:24] so we could have a look at adding that at some point <andj> [11-08 20:26:01] ok, next one is a bug that I found after our return value discussion last week https://github.com/andj/openvpn-ssl-refactoring/commit/25a2452776e8701ff6f7c59e73d6d3d216bc5048 <vpnHelper> [11-08 20:26:02] Title: Commit 25a2452776e8701ff6f7c59e73d6d3d216bc5048 to andj/openvpn-ssl-refactoring - GitHub (at github.com) <andj> [11-08 20:26:35] which works in combination with https://github.com/andj/openvpn-ssl-refactoring/commit/f543aafc52d8885c36ced7bf0eb74919dc6bb75f <vpnHelper> [11-08 20:26:36] Title: Commit f543aafc52d8885c36ced7bf0eb74919dc6bb75f to andj/openvpn-ssl-refactoring - GitHub (at github.com) <andj> [11-08 20:26:46] which unifies verification to a result_t type <andj> [11-08 20:27:07] and ensures that the same result return convention is always used throughout the SSL verification functions <andj> [11-08 20:27:29] That should help prevent this style of bug from occuring again <andj> [11-08 20:28:06] Basically those patches are the result of last week's discussion <jamesyonan> [11-08 20:28:09] right, good catch <andj> [11-08 20:28:23] I reviewed all return values <andj> [11-08 20:28:34] in the patch set <andj> [11-08 20:30:13] It's a pretty straightforward patch, but it really clarifies some stuff <andj> [11-08 20:30:25] without losing any performance <andj> [11-08 20:31:03] ok, if those patches are ok, I'm done for this week, and we can go for the ssl separation patches next week? <mattock> [11-08 20:32:04] andj: sounds good <mattock> [11-08 20:32:07] dazo: still there? <andj> [11-08 20:32:21] let's wait for an ack though :) <dazo> [11-08 20:32:35] mattock: I am <dazo> [11-08 20:33:04] I've just paid attention to these last reviews with half-n-eye :) <mattock> [11-08 20:33:08] after the ACK/NACK we can discuss the bug and release dates perhaps :) <dazo> [11-08 20:33:35] sure <jamesyonan> [11-08 20:34:03] SUCCESS/FAILURE patch looks fine <andj> [11-08 20:34:15] cool, thanks <dazo> [11-08 20:34:25] (I have roughly 30-40 min available) <andj> [11-08 20:34:32] how long do we expect the rest of the reviews to take? 4-5 more sessions? <andj> [11-08 20:34:45] thinking 2 for ssl library spearation <mattock> [11-08 20:34:54] andj: how hairy are the remaining patches? <andj> [11-08 20:35:13] it's crypto, so it's always hairy <mattock> [11-08 20:35:18] :D <andj> [11-08 20:35:20] but less so than the verification part :) <mattock> [11-08 20:35:31] 4-5 sessions is probably a good guess <andj> [11-08 20:35:43] PolarSSL support addition is a big one <andj> [11-08 20:35:50] https://github.com/andj/openvpn-ssl-refactoring/commit/0ef8d44cc4b9b10f174101cf420af0a5b2150809 <vpnHelper> [11-08 20:35:51] Title: Commit 0ef8d44cc4b9b10f174101cf420af0a5b2150809 to andj/openvpn-ssl-refactoring - GitHub (at github.com) <andj> [11-08 20:35:59] that one is scary in a sense <mattock> [11-08 20:36:06] we could probably have more sessions if 2.3 alpha release is getting too near <andj> [11-08 20:36:22] sure, they don't have to be weekly <mattock> [11-08 20:36:27] yep <andj> [11-08 20:36:38] I won't be available for about 2-3 weeks in september though <dazo> [11-08 20:36:56] I'm thinking that PolarSSL support isn't "that" critical ... as these patches shouldn't change the way OpenSSL stuff works (which will be mostly used, at least in the beginning) ... and PolarSSL can be kind of like a "tech-preview" <mattock> [11-08 20:37:07] dazo: +1 <andj> [11-08 20:37:26] yeah, most important thing is to have the separation in there <mattock> [11-08 20:37:26] I'd be more scared about changes to OpenSSL part <dazo> [11-08 20:37:44] which has mostly been covered already <mattock> [11-08 20:37:57] andj: did you save the wiki page= <mattock> [11-08 20:37:58] ? <andj> [11-08 20:38:03] yes <andj> [11-08 20:38:07] It's closed <mattock> [11-08 20:38:39] so all verification functions have an ACK <mattock> [11-08 20:38:39] I'll update the remaining entries <andj> [11-08 20:38:59] they're updated, right? <mattock> [11-08 20:39:13] ah yeah <mattock> [11-08 20:39:13] ok, next topic? <andj> [11-08 20:39:28] sure <jamesyonan> [11-08 20:39:52] yeah, agreed that the OpenSSL changes are the most critical -- how much actual empirical testing have we done on the verification patch set as a whole? <dazo> [11-08 20:40:35] When this all gets merged into master ... I'm willing to put this into two of my production boxes + my work laptop, running mostly OpenSSL <mattock> [11-08 20:40:39] andj: yes <mattock> [11-08 20:40:39] jamesyonan: have you looked at this bug: https://community.openvpn.net/openvpn/ticket/126 <vpnHelper> [11-08 20:40:40] Title: #126 (Cannot access Syspro 6.0 Server with 2.2RC or 2.2.0) â OpenVPN Community (at community.openvpn.net) <jamesyonan> [11-08 20:40:52] I've gotta run in 20 minutes <mattock> [11-08 20:41:00] ok <mattock> [11-08 20:41:11] got time to check out the bug report and see what you think? <mattock> [11-08 20:41:35] jamesyonan: btw. thanks a lot for reviewing the PolarSSL patches, we've made great progress every week! <dazo> [11-08 20:41:56] if someone can figure out which file is the most likely place to start looking ... using git blame and git log --follow <file>, it should be easy to track down the offending commit <dazo> [11-08 20:42:16] re: PolarSSL ... indeed great progress! <andj> [11-08 20:42:17] yeah, indeed, thanks everyone <mattock> [11-08 20:42:21] I can send mail to the bug reporters/commenters <mattock> [11-08 20:42:43] if they don't send us git-bisect results voluntarily :P <dazo> [11-08 20:43:09] hehe <jamesyonan> [11-08 20:46:00] so is ticket 126 related to windows tap driver ipv6 changes? <dazo> [11-08 20:46:38] that we really don't know ... but that *might* be reasonable to believe <dazo> [11-08 20:47:33] I'll add this as a testing criteria as well <mattock> [11-08 20:48:11] dazo: is it possible to disable IPv6 support completely in OpenVPN 2.2.1? <jamesyonan> [11-08 20:48:27] I wonder if pinging with an explicit ICMP packet length could help to reproduce this? <mattock> [11-08 20:48:32] or will some parts of the code still haunt the IPv4 support? <dazo> [11-08 20:48:52] well, it's only in the TAP driver IPv6 support is added ... and it is not possible to disable it there <mattock> [11-08 20:50:02] yes, of course... <mattock> [11-08 20:50:48] I'm thinking that we could perhaps try to inject custom packets to the pipe as one the guys did <mattock> [11-08 20:51:01] perhaps we could even get a sample packet from him <mattock> [11-08 20:51:31] and I can try poking the reporters for git-bisect results <mattock> [11-08 20:51:55] does this mumbling make any sense? :) <dazo> [11-08 20:53:04] packet injection ... not sure that will help ... unless you use wireshark/ethereal on the other side to see if the packets disappears or not <dazo> [11-08 20:53:35] I've added a more "low-tech" testing approach to the ticket now <andj> [11-08 20:53:36] ICMP doesn;t work? <dazo> [11-08 20:54:04] ICMP might work ... ICMP with size < 51bytes should in theory then not be passed through <dazo> [11-08 20:54:14] (including headers, I presume) <mattock> [11-08 20:55:05] dazo: I'll add clarifications on how to uninstall/install TAP-drivers <mattock> [11-08 20:55:46] do we need anything else for debugging? <dazo> [11-08 20:55:50] jamesyonan: quick question before you go ... have you had time to look at the tmp/svn-merger branch? .... I need to be sure I'm not doing anything stupid there <dazo> [11-08 20:56:11] mattock: great! No, I don't think anything else right now is needed <mattock> [11-08 20:56:12] (I'll add documentation to the Wiki + the ticket after the meeting) <jamesyonan> [11-08 20:56:22] no, I haven't <dazo> [11-08 20:56:43] jamesyonan: would it be possible for you to squeeze that in some day soonish? <jamesyonan> [11-08 20:56:50] what's the url for the branch? * dazo [11-08 20:57:06] fetches it <dazo> [11-08 20:57:41] jamesyonan: http://openvpn.git.sourceforge.net/git/gitweb.cgi?p=openvpn/openvpn-testing.git;a=commitdiff;h=e47fb603ed721bb718495e6f8ed42ec134da2f98 <vpnHelper> [11-08 20:57:43] Title: SourceForge - openvpn/openvpn-testing.git/commitdiff (at openvpn.git.sourceforge.net) <dazo> [11-08 20:57:57] this describes how the conflict has been solved <dazo> [11-08 20:58:21] but if you pull our git tree (openvpn-testing.git), you can checkout the origin/tmp/svn-merger branch <dazo> [11-08 20:58:28] then you get it completely merged <andj> [11-08 20:59:06] oh noes, and ssl.c change <dazo> [11-08 20:59:43] andj: yeah :( <andj> [11-08 21:00:24] thankfully it's pretty small <dazo> [11-08 21:00:34] :) <andj> [11-08 21:01:06] painful merge though from the looks of it :) <dazo> [11-08 21:01:49] I spent two days on it ... ~10-12 hours <jamesyonan> [11-08 21:02:32] dazo: thanks for putting the time into this <mattock> [11-08 21:02:44] jamesyonan: regarding which... how far is your Git migration? <mattock> [11-08 21:02:53] I'd hate to see dazo in such a pain :P <mattock> [11-08 21:03:06] need any help with it? <jamesyonan> [11-08 21:03:12] I <jamesyonan> [11-08 21:03:30] I'm still getting through the final crunch of 1.8.3 AS release <mattock> [11-08 21:04:05] when is it due? <dazo> [11-08 21:04:45] if you need help with migration ... I'm willing to spend some time on that ... as that will help reduce the complexity of getting more of your changes into master <jamesyonan> [11-08 21:04:53] we released in the last few days but I'm still swamped with bugs and other fixes <mattock> [11-08 21:05:04] ah <jamesyonan> [11-08 21:05:26] it was unfortunate that the block-local feature required a refactor of route.[ch] <dazo> [11-08 21:06:29] yeah, probably ... however, I just see that the job of staying in sync without causing more bugs or regressions is getting harder and harder <jamesyonan> [11-08 21:07:04] I don't see any more large patches on the horizon for 2.1 branch <dazo> [11-08 21:07:21] that does indeed sound good :) <andj> [11-08 21:07:58] Can we move on to release dates, I'm interested but need to go soon :) <jamesyonan> [11-08 21:08:09] I gotta run now <dazo> [11-08 21:08:22] jamesyonan: c'ya! take care! <andj> [11-08 21:08:30] cya, thanks for the reviewing <jamesyonan> [11-08 21:08:36] bye guys <s7r> [11-08 21:08:50] dazo: can you confirm the new release of openvpn will have full ipv6 support ? <dazo> [11-08 21:09:12] s7r: OpenVPN 2.3 will have full IPv6 support ... nothing in v2.2.x <dazo> [11-08 21:09:22] v2.2.x are just bugfixes <mattock> [11-08 21:09:32] jamesyonan: bye! <s7r> [11-08 21:09:52] what's with the icmpv6 <mattock> [11-08 21:09:54] andj: release dates it is, then <s7r> [11-08 21:09:56] did you get a chance to study it ? <s7r> [11-08 21:10:10] they say it has multiple functions for autoconfiguration etc. <andj> [11-08 21:10:29] I'm mostly interested, have no opinions/suggestions there :) <dazo> [11-08 21:10:31] s7r: that's better to discuss with cron2, he has implemented parts of that stuff <dazo> [11-08 21:10:55] release dates <mattock> [11-08 21:11:10] so, is polarssl only thing holding back 2.3 alpha? <dazo> [11-08 21:11:14] 2.2.2 ... that heavily depends on debug info we get from bug reporters <mattock> [11-08 21:11:19] or do we have something else? <andj> [11-08 21:11:33] is the windows build stuff working? <dazo> [11-08 21:11:34] v2.3 releases ... polarssl is the biggest one ... but we have quite a list <dazo> [11-08 21:11:45] of tickets we should consider <dazo> [11-08 21:12:18] But I'd prefer not too many big ones, though ... IPv6 + PolarSSL support are big enough + a bunch of stuff from james <andj> [11-08 21:12:18] If you need a speed-up on the patch verification, and have time, I can put in an extra sessions next week and the week after that <andj> [11-08 21:12:43] which should cover most of the stuff <andj> [11-08 21:12:49] in those patches <mattock> [11-08 21:12:52] andj: windows build stuff is fixed, still needs to go to "master" <dazo> [11-08 21:12:54] andj: right now, I'm very happy it doesn't go faster ... because I'm pretty much loaded with paid work as well :) <andj> [11-08 21:13:02] :) <dazo> [11-08 21:13:42] andj: misunderstand me correctly, I'm also very happy with the progress I have seen :) <mattock> [11-08 21:14:04] I'll also improve the (Windows/Debian/Ubuntu) snapshot situation in preparation to 2.3 alpha release <mattock> [11-08 21:14:09] to get the stuff out there faster <andj> [11-08 21:14:18] No worries, I understand your point, it was just suggesting that it's possible, but not that it was necessary <andj> [11-08 21:14:29] it being I there <dazo> [11-08 21:15:44] I'm looking at Milestone release 2.3 here: https://community.openvpn.net/openvpn/report/3 <vpnHelper> [11-08 21:15:47] Title: {3} Active Tickets by Milestone â OpenVPN Community (at community.openvpn.net) <dazo> [11-08 21:16:39] ticket #143 and #128 should be doable to get into the release ... so it's actually looking better than what I thought <dazo> [11-08 21:16:52] whooops <mattock> [11-08 21:16:54] #137 is already fixed <dazo> [11-08 21:17:19] there's a Milestone beta 2.3 ... which is much "worse" <mattock> [11-08 21:17:31] #18 should be trivial(?) <dazo> [11-08 21:17:34] yeah, #137 is on me to get merged in <dazo> [11-08 21:17:47] I believe d12fk is working on #18 <dazo> [11-08 21:17:56] no, he is not .. .that was for Windows <mattock> [11-08 21:18:04] yeah, windows <mattock> [11-08 21:18:44] ah, there's one unclosed, fixed ticket(#125) <dazo> [11-08 21:19:36] oh, true * dazo [11-08 21:19:49] really need to begin to go in 2 min <andj> [11-08 21:20:13] same story <dazo> [11-08 21:20:23] but I'd say that we can try to push through an alpha release (based on master) during September <mattock> [11-08 21:20:41] I think we should... nobody expects it to be perfect <mattock> [11-08 21:20:54] (hopefully) :D <mattock> [11-08 21:21:03] let's call this a day <mattock> [11-08 21:21:10] I'll update the wiki and the bug report <andj> [11-08 21:21:12] be warned that I'll be gone part of september, so some work on my part might pile up a little <mattock> [11-08 21:21:13] and write the summary <dazo> [11-08 21:21:16] when we move over to beta releases, I'll create a branch for it (which will be renamed to release when we're done) <mattock> [11-08 21:21:27] andj: when is that exactly? <dazo> [11-08 21:21:58] andj: understood :) That's why I propose September for the first alpha releases ... so we have time to bang our heads a bit :) <andj> [11-08 21:22:14] rather not say on a public forum, but I won't be available for about 2 weeks <dazo> [11-08 21:22:27] :) * dazo [11-08 21:22:58] runs <andj> [11-08 21:23:17] which shouldn't be too much of problem <andj> [11-08 21:23:25] I'll just pick up any issues when I get back <dazo> [11-08 21:23:51] yeah, that'll work out :) <mattock> [11-08 21:24:02] ok <dazo> [11-08 21:24:04] ciao! <mattock> [11-08 21:24:12] ciao a tutti! <mattock> [11-08 21:24:31] a domani, ecc. :) <andj> [11-08 21:24:33] indeed, see you soon, gotto run as well <andj> [11-08 21:24:35] :) <mattock> [11-08 21:24:38] bye!
