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: Wednesday 3rd 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-03> Next meeting will be announced in advance, but will 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, ecrist, jamesyonan and mattock 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=28#Verificationfunctions> The ACK status _before_ the meeting is on version 14 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 main Git repository soon. The second part of the meeting focused on the migration of forums.openvpn.net from phpbb to vBulletin. Ecrist had issues migrating forum threads to vBulletin due to the LDAP authentication backend we use. Because of this we agreed that it's best to keep the old phpbb forums around in read-only mode for a limited amount of time (e.g. 1 year) after vBulletin is running up. --- Full chatlog as an attachment -- Samuli Seppänen Community Manager OpenVPN Technologies, Inc irc freenode net: mattock
andj 20:24:09 hi jamesyonan 20:24:13 hi andj 20:24:57 Ready to get started? mattock 20:25:05 hi jamesyonan! yeah, let's do it 20:25:08 20:25:09 jamesyonan 20:25:16 sure andj 20:25:20 ok, starting with the first patch https://github.com/andj/openvpn-ssl-refactoring/commit/ac7cefae3d05f993ff25d6ed6fd51d37b9d1c803 20:25:22 vpnHelper 20:25:24 Title: Commit ac7cefae3d05f993ff25d6ed6fd51d37b9d1c803 to andj/openvpn-ssl-refactoring - GitHub (at github.com) andj 20:25:39 with https://gist.github.com/1111951 as a diff of diffs vpnHelper 20:25:42 Title: andj's gist: 1111951 Gist (at gist.github.com) andj 20:25:55 This factors out the NS_CERT_TYPE stuff mattock 20:25:57 https://community.openvpn.net/openvpn/wiki/Topics-2011-08-03 vpnHelper 20:25:59 Title: Topics-2011-08-03 â OpenVPN Community (at community.openvpn.net) andj 20:26:02 the variable was OpenSSL specific So it got moved to "NS_CERT_CHECK_SERVER" and "NS_CERT_CHECK_CLIENT" 20:26:48 L'utente mattock_ è entrato nella stanza 20:30 L'utente mattock_ si è disconnesso (Client Quit) 20:30 andj 20:32:04 anyway, this one should be relatively straightforward. It adds a small amount of code, but no functionality changes jamesyonan 20:33:34 yes, this looks fine andj 20:33:42 cool similar story, for KU checks: https://github.com/andj/openvpn-ssl-refactoring/commit/2731886dcb714be5af04e0ec5f9df9ff273f8401 20:34:01 vpnHelper 20:34:03 Title: Commit 2731886dcb714be5af04e0ec5f9df9ff273f8401 to andj/openvpn-ssl-refactoring - GitHub (at github.com) andj 20:34:11 and https://gist.github.com/1123165 vpnHelper 20:34:12 Title: andj's gist: 1123165 Gist (at gist.github.com) jamesyonan 20:38:59 this looks good andj 20:39:15 cool, again, for EKU https://github.com/andj/openvpn-ssl-refactoring/commit/fd9c5f659cfe99a2380ce758c1ccc1b9af7e8d01 vpnHelper 20:39:17 Title: Commit fd9c5f659cfe99a2380ce758c1ccc1b9af7e8d01 to andj/openvpn-ssl-refactoring - GitHub (at github.com) mattock 20:39:20 two ACKs, few more to go andj 20:39:24 https://gist.github.com/1123172 vpnHelper 20:39:25 Title: andj's gist: 1123172 Gist (at gist.github.com) andj 20:39:31 we're doing well jamesyonan 20:39:42 BTW, I have to run about one hour from now andj 20:40:15 That's ok, gives me some more time for myself this evening jamesyonan 20:44:20 I assume that verify_cert_eku returns 1 or true on success. andj 20:45:04 yes, see the ssl_verify.c snippet a little later jamesyonan 20:45:44 I notice sometimes you are returning 1/true on success and sometimes 0/false andj 20:45:57 The behaviour hasn't really changed there from what was being returned earlier and now 20:46:06 It might be an idea to normalise stuff in a later patch 20:46:18 jamesyonan 20:46:24 so you're just preserving the return value conventions of original code? andj 20:46:27 once everything is in its own function yes 20:46:28 https://github.com/andj/openvpn-ssl-refactoring/commit/fd9c5f659cfe99a2380ce758c1ccc1b9af7e8d01#L0L286 20:46:54 vpnHelper 20:46:55 Title: Commit fd9c5f659cfe99a2380ce758c1ccc1b9af7e8d01 to andj/openvpn-ssl-refactoring - GitHub (at github.com) L'utente krzee è entrato nella stanza 20:47 andj 20:47:13 is the original stuff We could perhaps intrduce a SUCCESS and FAILURE #define 20:47:32 to clarify stuff even further 20:47:39 once the patches are through 20:47:47 jamesyonan 20:47:58 sure, that makes sense yes, this patch looks fine 20:48:03 andj 20:48:22 thnaks, https://github.com/andj/openvpn-ssl-refactoring/commit/cf90d5f8cd4976e641fab81ac8054432f38df1ee vpnHelper 20:48:23 Title: Commit cf90d5f8cd4976e641fab81ac8054432f38df1ee to andj/openvpn-ssl-refactoring - GitHub (at github.com) andj 20:48:25 is a small one https://gist.github.com/1123177 20:48:33 vpnHelper 20:48:35 Title: andj's gist: 1123177 Gist (at gist.github.com) andj 20:48:38 shows hardly any changes cert_depth is checked a level up 20:48:45 before verify_peer_cert is called 20:49:13 jamesyonan 20:51:01 right this looks good 20:51:05 andj 20:51:23 I promised it would be better this week https://github.com/andj/openvpn-ssl-refactoring/commit/e9a18e013b1dfedc0f21f1d7f7c2e740c0a968cb 20:51:31 vpnHelper 20:51:32 Title: Commit e9a18e013b1dfedc0f21f1d7f7c2e740c0a968cb to andj/openvpn-ssl-refactoring - GitHub (at github.com) andj 20:51:56 and the diffdiff is here: https://gist.github.com/1123185 vpnHelper 20:51:58 Title: andj's gist: 1123185 Gist (at gist.github.com) andj 20:52:16 Basically extracts the plugin call BTW, what do you guys prefer as SUCCESS and FAILURE? 20:53:58 1 or 0? 20:54:07 jamesyonan 20:56:02 personally, I tend to like success being 0 and failure being non-zero because then you can map non-zero integers to specific errors if needed mattock 20:56:38 also, 0 is the normal "success" exit code for *NIx processes... if they behave properly not that there's any relation to that here 20:57:07 andj 20:57:17 typedef enum { SUCCESS=0, FAILURE=1 } result_t; ? 20:57:18 typedef enum { success=0, failure=1 } result_t; 20:57:35 jamesyonan 20:57:44 it's not universal though -- windows APIs often go the other way andj 20:58:02 I'm fine with 0, was just playing around with the patch idea anyway, let's get back to the patches 20:58:14 jamesyonan 20:58:59 yes, e9a18... looks fine andj 20:59:18 Next on for the scripts: https://github.com/andj/openvpn-ssl-refactoring/commit/a60b87394334587f9879da2d469d2a4a4c51a826 vpnHelper 20:59:19 Title: Commit a60b87394334587f9879da2d469d2a4a4c51a826 to andj/openvpn-ssl-refactoring - GitHub (at github.com) andj 20:59:22 https://gist.github.com/1123188 vpnHelper 20:59:25 Title: andj's gist: 1123188 Gist (at gist.github.com) andj 21:00:57 The diff of diffs is a little skewed there jamesyonan 21:10:14 this looks fine... it might be a bit cleaner to have the gc_new and gc_free be called unconditionally any time the function is called. right now, they are only being done if verify_export_cert 21:10:43 andj 21:11:06 yeah, I thought it was symmetrical enough this way But if you're afraid of bugs due to future expansion, I can see your point 21:11:33 jamesyonan 21:11:40 so it's conceivable if someone was modifying the function in the future, they might introduce a code path that would skip the gc_free andj 21:11:51 ok, patching will have one ready soon... 21:12:06 https://github.com/andj/openvpn-ssl-refactoring/commit/e4327902ed2af06f2596cdf306f4a0b76b1f0649 21:12:10 vpnHelper 21:12:11 Title: Commit e4327902ed2af06f2596cdf306f4a0b76b1f0649 to andj/openvpn-ssl-refactoring - GitHub (at github.com) andj 21:12:19 and https://gist.github.com/1123196 are next vpnHelper 21:12:22 Title: andj's gist: 1123196 Gist (at gist.github.com) andj 21:12:35 looks scary, but the gist shows otherwise jamesyonan 21:12:45 my preferred style is to have a "done:" label that all function exits must pass through that cleans up stuff andj 21:13:08 yeah, tended to stick to that too not necessary here though 21:13:14 https://github.com/andj/openvpn-ssl-refactoring/commit/fce243108b1c538359b0f33e7e58a884cc2be2b4 21:17:14 vpnHelper 21:17:16 Title: Commit fce243108b1c538359b0f33e7e58a884cc2be2b4 to andj/openvpn-ssl-refactoring - GitHub (at github.com) andj 21:17:22 is the patch for the gc_new and gc_free movement jamesyonan 21:21:20 sure, gc_new/gc_free patch looks fine (I'm presuming that there's no mid-function return statements that might bypass gc_free) andj 21:21:55 nope and the other one? 21:22:07 https://github.com/andj/openvpn-ssl-refactoring/commit/f67d4841c6edc2d9a9383ae6dce3a694a735dad7 performs a few minor bits of cleanup before the whole verify_cert function gets moved 21:23:20 vpnHelper 21:23:22 Title: Commit f67d4841c6edc2d9a9383ae6dce3a694a735dad7 to andj/openvpn-ssl-refactoring - GitHub (at github.com) jamesyonan 21:24:07 CRL refactor seems fine, though I'm not too happy with the original implementation andj 21:24:31 Yeah, we discussed that last week jamesyonan 21:24:35 doing low-level stuff like verifying CRL issuers and checking serial numbers is something that's better done by the OpenSSL library directly andj 21:25:01 It just adds maintenance burden and potential extra bugs this wa y 21:25:02 jamesyonan 21:29:03 f67d4... looks fine mattock 21:29:16 https://community.openvpn.net/openvpn/wiki/PolarSSLintegration?version=24#Verificationfunctions jamesyonan 21:29:17 I gotta run in a couple minutes vpnHelper 21:29:17 Title: PolarSSLintegration â OpenVPN Community (at community.openvpn.net) andj 21:29:26 ok, last one https://github.com/andj/openvpn-ssl-refactoring/commit/5b118dd62369b8d9cb2b425a27b8e7e9ba05ef5f 21:29:28 vpnHelper 21:29:29 Title: Commit 5b118dd62369b8d9cb2b425a27b8e7e9ba05ef5f to andj/openvpn-ssl-refactoring - GitHub (at github.com) andj 21:29:38 looks huge but does nothing 21:29:41 https://gist.github.com/1123263 21:29:42 vpnHelper 21:29:43 Title: andj's gist: 1123263 Gist (at gist.github.com) andj 21:29:56 just moves the function from one to the other jamesyonan 21:31:20 I see setenv_untrusted being removed but I don't see where it's added back in andj 21:31:40 let me check It was moved in a previous patch 21:32:15 same goes for mod_sslname TLS_USERNAME_LEN and a few others 21:33:02 jamesyonan 21:35:11 I gotta run andj 21:35:18 I'm going to play with a patch that moves the verification values to a single model, and double check the current ones (as they're important) jamesyonan: thanks, was the last one acked? 21:35:28 jamesyonan 21:35:45 yes andj 21:35:58 thanks, see you next week Thursday mattock 21:35:59 ok, end of meeting then andj 21:36:11 There was something about the forums still? or is that for some other time? 21:36:15 mattock 21:36:22 oh, I got to check ah yes 21:36:54 ecrist: there? 21:37:02 andj 21:39:03 oh well, thanks everyone again that was the bulk of the verification stuff 21:39:10 mattock 21:39:22 andj: thanks for taking care of the nasty "diff of diffs" stuff and all these meetings run almost by themselves 21:39:30 andj 21:39:38 no problem, just happy with the progress we're making mattock 21:39:48 latest version of ACK status here: https://community.openvpn.net/openvpn/wiki/PolarSSLintegration?version=26 vpnHelper 21:39:50 Title: PolarSSLintegration â OpenVPN Community (at community.openvpn.net) andj 21:40:12 damn, I'm glad I looked mattock 21:40:18 oh, how come? andj 21:40:22 there's a minor, but annoying mistake in the OpenSSL callback 21:40:28 It expects 0 on failure and 1 on success 21:40:39 mattock 21:40:47 ah andj 21:41:01 and when preverify_ok == 0, it returns 1 which is bad 21:41:03 so I'm fixing that now 21:41:09 Thankfully openvpn does a double check, which hid the bug 21:42:29 during my tests 21:42:41 mattock 21:43:49 ecrist: ? ecrist: personally, I think we should keep the old forums around in read-only mode indefinitely... or at least for a long time 21:47:54 the stuff might have been cached and/or linked to already 21:48:13 andj 21:48:14 Migration is not possible/difficult? mattock 21:48:25 andj: don't know the details ecrist does 21:48:28 migration would be best, of course 21:48:36 unless ecrist says "present" soon, I'll call this a day 21:50:31 andj 21:50:55 same here mattock 21:52:40 ok, let's call it a day 21:52:43 L'utente jamxNL è entrato nella stanza 21:52 andj 21:52:59 speak to you guys soon! mattock 21:53:43 yep, bye all! summary coming up tomorrow 21:53:48 ecrist 22:03:31 pong, sorry mattock: sorry, involved in a project at work. 22:04:44 didn't realize the meeting was today 22:04:51 mattock 22:04:54 ecrist: no problem andj 22:05:00 my fault mattock 22:05:32 andj: no need to take the bullet andj 22:05:42 mattock 22:05:42 "there's nobody to blame" andj 22:05:56 I did ask for it though mattock 22:06:13 ecrist: my 5c... why not keep the old forums in read-only mode indefinitely/very long? ecrist 22:06:34 I think we should keep it around for a while, probably a year or so, at least. mattock 22:06:36 there may be tons of links to them, plus google caches and that yeah, at least a year 22:06:44 ecrist 22:06:57 the reason I don't recommend keeping them around indef is I don't want links there to persist too long. I'm running in to issues cleanly migrating things, especially when there's links to other topics within a topic. 22:07:19 I figure, we're young enough, just migrate to a clean forum, and call it good. 22:07:37 mattock 22:07:38 can you migrate them to some extent? or would it be too embarassing to show to people with all the borked links? 22:08:05 22:08:08 ecrist 22:08:25 it's really messy, to be honest. part of the problem is our ldap back end. 22:08:33 it doesn't allow vbs importer to migrate accounts cleanly, and forum post and counts and such go all wonky 22:09:01 also, the why topics/threads/etc work internally are completely different. 22:09:22 mattock 22:10:19 ah clean install is better, then 22:10:25 ecrist 22:10:52 in my opinion, I think it's best to cut the cord mattock 22:11:18 ok, sounds good how has LDAP extension/plugin worked so far? 22:11:27 ecrist 22:11:48 it seems to be working good, but there are bugs I've been unable to track down having to do with old posts. if I can do away with old posts, I can narrow down any remaining bugs and get things in order. 22:12:03 what I'm going to do now is finish/finalize my ldap plugin for vB and do some testing. 22:12:33 mattock 22:12:46 ok, sounds like plan ecrist 22:12:56 there's a bit of cleanup to do yet, mostly to make it an easy to install package, making future core upgrades easier. what I need from you and Andrew is the templating. 22:13:09 if we can get some styles lined up, and get a final ACK from the community, I'll purchase our license and push it out, hopefully by Sep 1 22:13:49 L'utente raidz ha lasciato la stanza 22:16 L'utente raidz è entrato nella stanza 22:16 andj 22:28:56 I unified the return values https://github.com/andj/openvpn-ssl-refactoring/commit/f543aafc52d8885c36ced7bf0eb74919dc6bb75f 22:28:57 vpnHelper 22:28:59 Title: Commit f543aafc52d8885c36ced7bf0eb74919dc6bb75f to andj/openvpn-ssl-refactoring - GitHub (at github.com) andj 22:29:18 As you can see, it was a bit of a mess with false/true used in different ways 22:29:26 mixed with some 0's and 1's 22:29:38 now it's just SUCCESS and FAILURE 22:29:44
