Hi, Here's the summary of the previous community meeting.
--- COMMUNITY MEETING Place: #openvpn-devel on irc.freenode.net List-Post: openvpn-devel@lists.sourceforge.net Date: Thursday, 30th June 2011 Time: 18:00 UTC Planned meeting topics for this meeting were on this page: <https://community.openvpn.net/openvpn/wiki/Topics-2011-06-30> 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, cron2, dazo, essobi, jamesyonan and mattock were present in this meeting. -- Discussed easy-rsa patches that fix Trac ticket #125 and hold back OpenVPN 2.2.1 release: <https://community.openvpn.net/openvpn/ticket/125> <http://thread.gmane.org/gmane.network.openvpn.devel/4729> <http://thread.gmane.org/gmane.network.openvpn.devel/4780> <http://thread.gmane.org/gmane.network.openvpn.devel/4781> Jamesyonan and cron2 gave these patches their ACK. -- Discussed OpenSSL 0.9.6 support in easy-rsa and other places in OpenVPN. Agreed that support should be dropped in OpenVPN 2.3, as the latest OpenSSL 0.9.6 release was made in 2004. -- Discussed andj's OpenVPN Doxygen patchset: <http://thread.gmane.org/gmane.network.openvpn.devel/4740> Agreed that they need more through review. The plan is to do this review within two weeks, as andj's later patches depend on these. -- Discussed andj's OpenSSL crypto refactoring and SSL separation patchsets: <http://thread.gmane.org/gmane.network.openvpn.devel/4764> <http://thread.gmane.org/gmane.network.openvpn.devel/4788> Agreed that the patches need a thorough review (and testing) before being merged into "master". Andj will make a few modifications that were suggested and publish his own Git tree in Github (or similar). This tree will then be tested by dazo and mattock, and integrated to buildbot connection tests. If all goes well, they will be merged in "master" and published in first OpenVPN 2.3 alpha. -- Discussed the domake-win (mingw) and Python-based buildsystems used on Windows: <https://community.openvpn.net/openvpn/wiki/BuildingOnWindows> Agreed that the domake-win buildsystem will has some rough edges and it needs modernization. It was also agreed that it should be maintained even though official releases are now built with the Python-based buildsystem. Two primary motivations for this were cross-compiling and the ability to build OpenVPN on Windows without Visual Studio. Nobody volunteered to take the role of domake-win maintainer. --- Full chatlog as an attachment -- Samuli Seppänen Community Manager OpenVPN Technologies, Inc irc freenode net: mattock
mattock 21:00:22 meeting time... everybody ready? 21:00:30 andj 21:00:34 yup cron2 21:01:14 ay mattock 21:01:21 topic list here: https://community.openvpn.net/openvpn/wiki/Topics-2011-06-30 vpnHelper 21:01:23 Title: Topics-2011-06-30 â OpenVPN Community (at community.openvpn.net) mattock 21:02:31 dazo, jamesyonan: there? jamesyonan 21:02:38 hi dazo 21:02:51 uhh ... it's time already ... hours fly quickly today 21:02:59 mattock 21:03:09 yep 21:03:10 could we begin with my patches, so that we can get 2.2.1 out of the door? 21:03:42 L'utente dazo è ora conosciuto come dazo_afk 21:03 cron2 21:04:00 dazo just ran away mattock 21:04:02 those related to Trac ticket #125 yeah 21:04:03 any comments on those? 21:04:28 they've been tested on Windows XP, Ubuntu 11.04 (openssl 0.9.8) and Fedora 15 (openssl 1.0.0) 21:04:58 and also less extensively on FreeBSD 21:05:19 cron2 doesn't really understand the fine details of easy-rsa 2.0, but on a cursory glance, the patches look fine to me 21:06 L'utente dazo_afk è ora conosciuto come dazo 21:06 cron2 21:06:40 and if it has been tested on XP and "some sort of Unix", I think that's good enough for me mattock 21:06:54 jamesyonan: any comments on the easy-rsa patches? jamesyonan 21:07:10 they look pretty reasonable mattock 21:07:28 cron2: yes, the only potential problem I see is the usage of "grep -E" and GNU grep -style regexps although FreeBSD seemed to use GNU grep by default 21:07:40 not sure about openbsd and such 21:07:49 dazo 21:08:14 mattock: according to the (Fedora) man page ... -E should be POSIX compliant mattock 21:08:28 dazo: ok, then it's all good next topic? two ACKs were given already 21:08:39 I would suggest another quickie, namely OpenSSL 0.9.6 support 21:08:59 dazo 21:09:06 okay, I'll give james and cron2 the blame for the ACKs in the commit log mattock 21:09:17 dazo: good thinking dazo 21:09:20 let's rip that support out ... that's my vote cron2 21:09:22 well, one could just do "fgrep '0.9.6'" here, but hey, if OpenBSD can't do -E, I don't care andj 21:09:28 What esoteric embedded systems still use OpenSSL 0.9.6? cron2 21:09:39 dazo: +1 mattock 21:09:40 jamesyonan: what's your take on this? I vote for scrapping all 0.9.6 -related code 21:09:57 jamesyonan 21:10:06 I'd tend to agree that we don't need it andj 21:10:12 The 0.9.6 support is less of a problem with my patches though as it's all localised 21:10:16 dazo 21:10:17 http://www.fpaste.org/t4Z2/ jamesyonan 21:10:21 even RHEL 4 uses 0.9.7 dazo 21:10:38 (my paste is: git grep 0.9.6 ) 21:10:39 andj 21:11:10 Could we remove it after my patches have been applied though mattock 21:11:17 and mine andj 21:11:19 rebasing would not be that cool cron2 21:11:20 nah that would be too easy dazo 21:11:21 andj: sounds fair enough cron2 21:11:27 *duck&run* dazo 21:11:28 hehe andj: cron2 just volunteered to do the rebase 21:11:39 andj 21:11:39 hah a 21:11:40 cron2 21:11:49 but yeah, leave it as it is for now, get andj's patches in, then drop 0.9.6 dazo 21:11:59 yeah, makes sense cron2 21:12:31 (which implies "don't drop it in 2.2.x series", as the patches wouldn't be "just cherry-picking") dazo 21:12:54 cron2: the cherry-picking could actually work out ... but no sense in doing that for 2.2.x, though cron2 21:13:14 yeah, not in the middle of a release train "only bugfixes here" 2.3 is cleanup + new features 21:13:19 dazo 21:13:26 it would probably complain about wrong offsets, but with rebase it tends to be more gentle agreed 21:13:30 mattock 21:13:40 next topic? (we got lots of stuff to cover) 21:13:47 dazo 21:14:17 Doxygen patches? mattock 21:14:18 I'd say let's leave MinGW for the last, or skip it entirely dazo: +1 21:14:21 jamesyonan: have you had time to review the doxygen patches? 21:14:55 dazo 21:14:59 I've not had too much time to look at it ... first of all, a publicly big thank you to andj for an enormous documentation work cron2 21:15:02 let's cover mingw, but after the other stuff andj 21:15:33 doxygen is actually not directly mine, a colleague dit that, so if you credit anything, just credit Fox-IT dazo 21:15:35 I'd like to have jamesyonan's eyes on the doxygen stuff, to make sure it is 100% correct ... jamesyonan 21:15:43 do patches include any functional changes? dazo 21:16:20 I think I spotted something ... but need to re-check that ... but it mostly doesn't do any feature stuff at all andj 21:16:20 It doesn't change anything functionally. some variables move around a little though dazo 21:16:30 ahh, that's probably what I've seen andj: your colleague wants to stay anonymous? 21:17:01 andj 21:17:16 I'll ask him at work tomorrow dazo 21:18:04 perfect! We'll need to highlight this in ChangeLog, so Fox-IT will also get credit too, mattock 21:18:18 if there are no functional changes and the documentation is even "about right" I'd say ACK the whole set I think documentation with occasional small errors is better than no documentation at all 21:19:02 dazo 21:19:05 mattock: whooo, not so fast ... it's good to review/check that the documentation is fairly correct as well .... silly if the documentation is wrong mattock 21:19:22 yes, "fairly correct" sound good 21:19:23 dazo 21:19:31 yeah, minor mistakes is fine mattock 21:19:51 maybe "about right" was not the best expression jamesyonan 21:20:36 the docs appear to be well-written, though I haven't digested all them yet dazo 21:20:37 mattock: the openssl docs is "about right" ... which can be a hurdle to understand some times mattock 21:20:48 ok, let's not go that route then dazo 21:21:23 jamesyonan: would it be possible for you to allocate some time for a review? I'll try to get some work-time available for doing the same as well andj 21:21:46 Easiest is to just generate them, and read up... I'm pretty confident that they'll pass your judgment though dazo 21:21:59 yeah mattock 21:22:08 andj: what's the command to generate the documentation (in HTML)? obviously doxygen is needed, but after that 21:22:15 andj 21:22:25 you need both doxygen and dot (from graphviz) 21:22:30 dazo 21:22:34 andj: any chance you're able to push your git tree to a public server? (http or git protocol) jamesyonan 21:22:39 agreed that it makes sense for me to look at them in more detail -- but the quality looks very good dazo 21:22:48 indeed! andj 21:22:53 then run doxygen doxygen/openvpn.doxyfile mattock 21:23:02 ok, the standard process dazo: I agree, fetching a Git tree would be more convenient 21:23:22 or even a tarball with the code 21:23:27 dazo 21:23:51 nah, I'll tackle mail easier than tarballs ... really andj 21:23:59 I'll see about pushing them to a public tree, I haven't got the source code handy right now, as I'm not at work mattock 21:24:24 jamesyonan: are you confident enough to give the patchset an ACK? Or is more review needed? dazo 21:24:44 andj: no worries, it just simplifies the merging ... if each of these steps you provide are separate branches ... that makes it even easier for me to work with ... but, let's see what you have first jamesyonan 21:25:12 I'd like to do a closer reading before I ACK mattock 21:25:19 ok dazo 21:25:20 +1 andj 21:25:20 It would be useful to apply it, as the patchset is the basis for the other patches, merging is difficult if you haven't got the doxygen dazo 21:25:53 mattock: when doxygen is accepted ... could buildbot automatically build doxygen docs and publish it? mattock 21:26:00 dazo: yes dazo 21:26:09 that'd be awesome! mattock 21:26:38 although it would be waste of resources... no need to test that doxygen works on n different platforms I think it's easier to automated docs creation usings scripts 21:26:52 andj 21:26:59 Separate job for a single platform? mattock 21:27:13 yep dazo 21:27:18 mattock: well, I meant that each push to the git tree would update the docs published cron2 21:27:48 that would indeed be nice mattock 21:28:17 dazo: if we want near real-time docs publishing then I can create a separate buildfactory which runs on one platform and publishes the doxygen documentation or just run something from cron and get nearly the same results... but in either case, it's very doable 21:28:53 dazo 21:28:58 and I'm even thinking that (when this is applied), all new patches *must* have proper documentation in place as a ACK criteria, for all new functions/structs/etc or change of behaviour in such mattock 21:29:17 dazo: +1 dazo 21:29:18 mattock: that makes sense cron2 21:29:19 -1 andj 21:29:22 doxygen is mdi-level though, doesn't cover every function *mdi=mid 21:29:28 dazo 21:29:46 yeah, true enough ... but as much as possible should be documented andj 21:29:49 it's pretty detailed, but mostly aimed at quickly understanding the code base And not being exhaustive 21:29:58 dazo 21:30:07 cron2: why -1? afraid you need to do a lot of updates? cron2 21:30:09 forcing doxygen to people that have never done any work with it but just want to contribute something minor is overkill to add meaningful documentation would mean "understand how the existing documentation works", not only "understand the code" 21:30:48 andj 21:30:53 Changing any existing affected doxygen is important though cron2 21:31:19 yes, sure, but I was thinking of "new stuff that has no doxygen docs yet" mattock 21:31:35 cron2: we could just require that the patch author writes the documentation (in some format) and convert it to doxygen ourselves cron2 21:31:43 that would be fine dazo 21:31:44 well, good documentation in the code is the goal .... doxygen documentation is fairly simple ... so that the patch contributors document that "this new function xyz does abcde with arguments 1, 2 and 3" cron2 21:32:33 well, let's discuss that when we have the first batch in and see how it works out mattock 21:32:39 +1 andj 21:33:07 ok, shall I walk you through patches 10 and 11, to give you a quick picture of what they look like? mattock 21:33:07 I think setting a deadline for Doxygen patchset review would make sense dazo 21:33:08 well, doxygen docs is mostly done *inline* in the C code ... that's the neat thing about it .... so you document it while writing the functions/structs/whatever .... so it makes the C code more understandable ... and can create great HTML docs from the C code mattock 21:33:37 next Thursday? cron2 21:33:51 andj: I've looked at it, and it seems not to be too complicated - but I'm wary of putting up too much hurdles for new contributors. It's not like we're overrun with volunteers. dazo 21:33:56 mattock: too early ... I think I'd need more time mattock 21:34:05 dazo: ok two weeks? 21:34:11 dazo 21:34:20 yeah, that makes more sense .... jamesyonan? cron2 won't be available next Thursday anyway, so 2 weeks sounds good 21:34 andj 21:34:48 Is it a problem to include it in the mainline earlier, and patching up problems as we go? mattock 21:35:18 andj: I don't think so, as long as we do the reviewing (in two weeks) and fix the issues dazo: what's your take? 21:35:27 cron2 21:35:27 well, if dazo has no time, nothing happens to the tree anyway jamesyonan 21:35:36 yes, I can review by then dazo 21:35:46 andj: not at all ... we can have a goal of trying to accept half of the patches by next Thursday ACKed ... and the second half the following week andj 21:36:16 ok, that's fine mattock 21:36:35 next patchset? cron2 21:36:49 that's the crypto refactoring dazo 21:36:57 yeah jamesyonan 21:36:58 it's a good discussion on to what extent contributors need to contribute more than just code to be accepted -- some projects even require that unit tests be contributed as well mattock 21:37:17 for example buildbot... unit tests + documentation andj 21:37:33 I actually tried unittests on OpenVPN at first cron2 21:37:35 like "anybody but me has provided test code recently"... andj 21:37:38 but it was alittle though dazo 21:38:01 I can imagine that's tough .... andj 21:38:03 as everything is interconnected through error.h and a few others cron2 21:38:10 jamesyonan: but yes, I understand your side. It's a balance thing between stagnation and chaos. cron2 still needs to do t_server.sh 21:38 dazo 21:38:23 +1 cron2 21:39:06 but that's sidetrackign dazo 21:39:07 I like the idea of having unit tests available too ... but that needs more refactoring of the code, I think ... and we need to get a decent framework for it in place cron2 21:39:28 dazo: yeah dazo 21:40:07 mattock: what about having such a discussion in a later meeting? ("what must contributors provide to get ACKed quickly and neatly") mattock 21:40:22 dazo: sounds good cron2 21:40:23 back to the refactoring patches - skimming through the mails, it looked halfway sane to me. But then, I do not understand any of the crypto stuff, so I might be overlooking something. dazo suggests some time in August 21:40 mattock 21:40:41 dazo: again, sounds good andj 21:40:42 The goal of that patchset is to create a neat crypto API as defined in ssl_backend.h, which can be used by the other modules. The first patch (#10) adds configure support, the rest is refactoring cron2 understood that bit 21:41 andj 21:41:42 rand_bytes() in #11 is as simple as it gets dazo 21:41:49 so basically this patchset doesn't change any features ... it just adds a glue layer like: openvpn code base :: crypto API :: OpenSSL ? 21:41:51 cron2 21:41:56 yes andj 21:42:28 yeah, a pretty thin layer, but it allows another backend to be used. There's a few important files: 21:42:46 crypto_backend.h - API definition 21:42:56 crypto_openssl.c - implementation using OpenSSL 21:43:14 cron2 21:43:19 I'm a bit unhappy with #18 - des_cblock key1, key2, key3; 21:43:25 jamesyonan 21:43:26 andj: what's the motivation for using something other than OpenSSL? code size? cron2 21:43:28 + unsigned char key1[8], key2[8], key3[8]; andj 21:43:50 jamesyonen: codesize, and evaluation-readiness it's a lot easier to evaluate a smaller crypto library 21:44:00 cron2 21:44:10 andj: this sort of introduces magic numbers "char key[8]" is something I find less obvious than "des_key_block key1", to be honest andj 21:44:41 point taken, I can add DES_KEY_LENGTH? as a define 21:44:55 cron2 21:45:03 what's the reason for going away from a typedef? since we're not accessing individual elements of the array here, nobody needs to know what type is "under the hood" 21:45:24 andj 21:45:30 Mostly it was moving away from a des-specific key type to a universal key-type 21:45:41 cron2 21:45:42 mmh cron2 likes opaque typedefs for things that I don't want to see the insides of 21:46 cron2 21:46:31 but maybe that's just me andj 21:47:12 both sides work for this, having a key just being a byte array matches the rest of OpenSSL more closely dazo 21:47:58 cron2++ mattock 21:48:52 jamesyonan: any comments on these patches? dazo 21:48:53 I agree, if we can do things opaque for readability of the generic stuff ... that makes a lot of sense to me ... like typedef stuff which don't need to be explicit those parts which needs these details, will anyway need to deal with it ... and then it might even improve understanding of the code, with proper typedef's 21:49:30 mattock 21:50:06 I personally like the idea of abstracting the SSL functionality... makes the code more modular and thus flexible andj 21:50:30 OK, I'll create a patch that adds a des_keytype, aes_keytype, etc? cron2 21:50:31 mattock: you are aware that this will double the amount of buildbot runs you need to do? mattock 21:50:44 cron2: now you're telling me dazo 21:50:49 yeah, and these patches does that ... it's just that we can probably make things even better cron2 21:50:54 andj: it would help *me* reading the code dazo too 21:51 mattock 21:51:53 besides this one issue, can the patchset be given an ACK? cron2 21:52:12 mmmh, the patches actually follow the generic coding conventions more closely than the original code andj 21:52:38 I tried to clean up where I could there were some debris lying around from past patches, especially in the ssl separation patches 21:53:10 jamesyonan 21:53:25 andj: what about generic OpenSSL objects that are not directly crypto-related, like BIOs andj 21:54:11 Not in there, as PolarSSL doesn't use them. Most of the loading is "cipher_load_key_file(***)" like abstracting away from how the underlying library actually works 21:54:36 For SSL there are PolarSSL-specific bio types 21:55:16 but they are only related to the streams, and not file reading, etc. 21:55:41 mattock 21:56:29 andj: so everything OpenSSL does in OpenVPN is also covered by PolarSSL? andj 21:56:46 Almost... CryptoAPI support is not there and a few small other things. I can give you a more detailed list tomorrow if you want 21:57:12 jamesyonan 21:57:18 right, but OpenSSL uses BIOs to make it easy for a function that accepts, say a certificate in a file, to also accept the cert in a string -- hence the ability of BIOs to work with files as well andj 21:57:48 I know, and I like the feature, but unfortunately PolarSSL doesn't understand the concept and other SSL libs might not either 21:57:58 which is why the concept isn't used in the backend API, and hidden from OpenVPN 21:58:20 jamesyonan 21:58:37 Re: CryptoAPI, there's actually three different cases where OpenVPN uses RSA offloading -- CryptoAPI, pkcs-11 connector, and management-external-key Essobi 21:59:00 Is Polar FIPS compliant? andj 21:59:04 management external key I'm working on atm, not sure if I'll implement that for PolarSSL Essobi: no, but the dutch government is evaluating it for the approved version of OpenVPN 21:59:33 dazo 21:59:34 andj: would it make sense to have that kind of support in the API ... but where not supported by the backends, it's either "worked around" some how, or kind of returning a "FEATURE_NOT_SUPPORTED" error, somehow? andj 22:00:13 dazo: at the moment I'm thinking of handling that sort of thing in configure mattock 22:00:24 we can always document these missing features with "Not supported by backend X" andj 22:00:26 pkcs11 support is there with PolarSSL Anyway, most of the feature you would expect are there in Polar 22:01:02 jamesyonan 22:01:46 can PolarSSL handle "split-CA" where the root CA for client certs is different than the root CA for server certs? andj 22:02:01 I think so let me check 22:02:13 jamesyonan 22:02:37 management-external-key is fairly important to support arbitrary key stores like in the Access Server we use it to interoperate with the Mac OS X keychain 22:03:08 andj 22:03:11 that's why I'm working on it, I'll see if I can fit it into PolarSSL It is supported in OpenSSL though, so the patches don't break anything 22:03:40 mattock 22:04:28 so, can we accept the patchset with the changes proposed by cron2? Essobi 22:04:40 andj: Doesn't mean much to me then. andj: I just deployed 800 vpns where FIPS is required. 22:04:54 mattock 22:05:14 ...and wait for further patches (e.g. management-key-external) from andj andj 22:05:21 FIPS isn't a big deal in most of Europe, as most countries are a little stricter dazo 22:05:34 mattock: again, you're pushing it a bit too hard for an ACK ... it needs more review as well ... just glaring at some of ~20 patches isn't good enough, IMO andj 22:05:37 management-key-external is part of SSL-separation and not crypto-separation jamesyonan 22:06:38 SSL-separation might be somewhat trickier than crypto-separation andj 22:06:54 it is believe me, it was 22:07:00 cron2 22:07:06 mattock: someone who understands the crypto needs to look through it, with some brains and some time. mattock: I haven't seen any obvious show-stoppers, but that's only enough for "not giving a NAK", but I don't feel fully qualified to give an ACK here. 22:07:41 andj 22:07:46 jamesyonan: I'm pretty happy about the result of the SSL separation though. Verification is split out pretty clearly, the x509 stuff is in a separate moduel mattock 22:08:08 cron2, dazo: sounds reasonable... I just wouldn't want these patches to left lying around for too long... dazo 22:08:17 agreed! mattock 22:08:31 and I fear patchsets this large do have that tendency... dazo 22:08:45 these ones, needs attention ... and every day I see "32 unread mails" in my openvpn-devel folder I have it like this on purpose ... to be reminded everytime I look at the mail 22:09:02 andj 22:09:17 jamesyonan: PolarSSL supports separate ca's for server and client dazo: want another 50? 22:09:32 mattock 22:09:34 jamesyonan: could you review these patches in more detail? jamesyonan 22:09:40 andj: so PolarSSL can enumerate X509 attributes in certs? dazo 22:09:49 andj: my mailbox can handle more cron2 22:10:00 mattock: well, you could become a crypto export and ACK them mattock 22:10:18 cron2: I could, if I had the time andj 22:10:19 jamesyonan: I'm not following, what do you mean? jamesyonan 22:11:21 I'm thinking of stuff like extract_x509_field_ssl in ssl.c andj 22:11:31 http://polarssl.org/apidoc/x509parse_8c.html vpnHelper 22:11:32 Title: PolarSSL v0.99-pre5: x509parse.c File Reference - PolarSSL (at polarssl.org) jamesyonan 22:12:18 does it handle x509v3 attributes? like extendedKeyUsage? 22:12:41 andj 22:12:44 yeah, it does there's a x509_get_ext_key_usage() function for that 22:13:13 dazo 22:13:43 jamesyonan: http://en.wikipedia.org/wiki/Comparison_of_TLS_Implementations ... does this one help? vpnHelper 22:13:45 Title: Comparison of TLS Implementations - Wikipedia, the free encyclopedia (at en.wikipedia.org) andj 22:14:32 I can even point out the source: http://polarssl.org/apidoc/x509parse_8c_source.html#l00887 vpnHelper 22:14:34 Title: PolarSSL v0.99-pre5: x509parse.c Source File - PolarSSL (at polarssl.org) andj 22:14:56 Little outdated, that Comparison... PolarSSL 0.99 has my PKCS#11 module in it jamesyonan 22:14:57 does it abstract out x509 cert verification from the SSL/TLS negotiation, so cert verification can be done separately from SSL/TLS -- this is useful for verifying signatures andj 22:15:15 jamesyonan: yeah, I added support to PolarSSL for that Shall we move on to the 4th patchset then, the SSL separation ones? 22:15:52 if there's no more about crypto? 22:16:01 Essobi 22:16:53 andj: Yea.. but in North America... it's mandated by law, for FIPS compliance. Even if it's MORE secure, doesn't matter, it's not audited and you can't use it. andj 22:17:11 Essobi: I know jamesyonan 22:17:28 this is not really an OpenVPN issue, but one of the annoying things about OpenSSL is the monumental effort required to wrap it in high level languages like Python -- it would be great if PolarSSL objects and functionality could be fully exposed to high level languages Essobi 22:17:39 Just saying... *SHRUG* Good luck thou guys. andj 22:17:54 Essobi: yeah, I don't envy you jamesyonan: don't know if it's been done, don't think so 22:18:18 jamesyonan 22:18:19 andj: does PolarSSL do DTLS? Essobi 22:18:29 As long as you guys don't toss out openssl all together, I'll be fine. andj 22:18:48 I spoke to the author a little while ago, and he was thinking about it DTLS would be great 22:18:53 at the moment he's mostly gearing up to PolarSSL v1.0 with all the features required to run OpenVPN 22:19:50 we gave him a bunch of patches too 22:19:58 jamesyonan 22:20:06 it would be great to have a solid DTLS implementation -- the OpenSSL implementation is still somewhat buggy andj 22:20:57 There's a ticket http://polarssl.org/trac/ticket/16 vpnHelper 22:20:58 Title: #16 (DTLS support) â PolarSSL Trac page (at polarssl.org) jamesyonan 22:21:02 what do you have as far as unit tests are concerned in PolarSSL? andj 22:21:15 PolarSSL has a fairly good test suite It's pretty extensive 22:21:25 L'utente jamx è entrato nella stanza 22:21 andj 22:21:52 If a feature gets added, tests get added jamesyonan 22:22:08 one thing I would tell you -- if you can wrap PolarSSL objects for Python, you'll immediately have a very powerful unit testing framework andj 22:23:24 Anyway, to give the bird's eye view on SSL separation: there's a split into two main sections: ssl and ssl_verify 22:23:45 ssl_Verify abstracts the verification part of the control channel 22:23:58 and helps clean up the control channel code a little 22:24:17 then, as with crypto 22:24:35 there's ssl_backend.h and ssl_verify_backend.h 22:24:49 the first deals with what you would expect 22:25:08 while the second handles the SSL verification callback, and x509 verification 22:25:36 and finally, again, there's the openssl specific implementaion: ssl_openssl.c and ssl_verify_openssl.c 22:26:46 patches 30-56 deal with the SSL layer 22:29:55 57-79 deal with verification 22:30:05 mattock 22:33:13 hmm, would having a separate feature-testing tree for these patches make sense? external (by andj) or in sf.net 22:33:21 cron2 22:33:23 no mattock 22:33:30 why? andj 22:33:36 I'm worried that they would lie around for too long dazo 22:33:51 agreed mattock 22:33:52 andj: me too cron2 22:33:56 mattock: nobody would test that... mattock: but what I could see is having them (temporarily) in a branch off "master" in openvpn-testing.git, and you could tell buildbot to build and test that branch as well 22:34:27 I think this is the crucial issue: get this code tested as deeply as possible 22:34:48 dazo 22:34:58 that's doable cron2 22:35:13 (so we might need to add more tests, like "SSL certificate validation / failure tests" etc) andj 22:35:14 It's pretty easy to follow the patches though by visual inspection as the code doesn't change its functionality 22:35:32 cron2 22:35:49 same thing with separate branch as we did with the two ipv6 patch sets mattock 22:36:18 I think the only way to get reasonable amount of testers is to release these patches in 2.3 alphas cron2 22:36:24 andj: well, "the goal is to not change functionality", but bugs could creep in... andj 22:36:31 cron2: I know mattock: agreed 22:36:43 cron2 22:36:47 increas our test coverage mattock 22:37:02 cron2: you mean automated tests? jamesyonan 22:38:03 I think having a separate branch, at least initially, makes sense for any large patch cron2 22:38:06 that's the best we can have. testers will find "very obvious" stuff, or "weird combination of features trigger these" bugs - and the first category, we should be able to automatically find ourselves mattock 22:38:59 cron2: agreed andj 22:39:39 dazo: would that mean you gave me write access to a branch, or would you apply the patches? cron2 22:40:07 what we did for the ipv6 payload stuff was that I setup my own repository, and dazo pulled from there to his branch mattock 22:40:10 cron2: re: "nobody would use it"... we _could_ eat our own dogfood? dazo 22:40:22 andj: what cron2 says cron2 22:40:48 mattock: yes, but that would only catch bugs that affect the specific combination of options you use mattock 22:40:51 I definitely would like to eat our own dogfood here dazo 22:40:53 I would be willing to run this in production on a openvpn client on one box, with polarssl mattock 22:41:08 cron2: true... but that's always the case cron2 22:41:20 buildslave, polarssl, t_client.sh, t_server.sh now if somebody had time to write t_server.sh... 22:41:41 mattock 22:42:00 cron2: obviously buildbot integration would make perfect sense, too cron2 22:42:08 but even automated client tests with openssl and polarssl would help mattock 22:42:10 and cover more ground jamesyonan 22:42:31 well there's really two issues here -- the stability of the refactoring (which can be tested as easily with OpenSSL as with PolarSSL) and the issue of the PolarSSL integration itself dazo 22:42:42 andj: to add more details, I can create a feat_crypto_mod branch ... where I "clone" your branch ... so that you're branch would be my upstream (meaning: I would only rebase against you) ... this would then be merged into master when ACKed (that's the routine I have with cron2) 22:43:23 andj 22:44:06 dazo: how would that work with upstream patches from openvpn/master ? dazo 22:44:35 andj: you would need to rebase against openvpn/master ... push it, and it would go into the feat-branch via your tree andj 22:44:49 jamesyonan: the PolarSSL patch(es) should be done somewhere tomorrow, if I don't run into any snags cron2 22:44:50 what he said andj 22:45:03 dazo: any tips on where to host? github? mattock 22:45:45 andj: that would probably work... lots of stuff is hosted there nowadays dazo 22:45:49 andj: if you have a web server with ssh access ... you can push directly there ... and in the git directory on the server just run: git update-server-info ... and give me the URL mattock 22:45:51 I would guess their Git support is ok dazo 22:46:01 andj: or else github or similar git services work as well andj 22:46:16 dazo: not at my work I can't, we're properly paranoid dazo 22:46:31 okay, then wherever ... git and http protocols are the simplest ones ... so as long as I can reach it ... it can be on the moon for my part 22:47:12 andj 22:47:26 So, summarizing, my TODO for this meeting:  - Set up feature branch 22:47:34  - add des_key typedef 22:47:36 - finish PolarSSL integration patch 22:48:07 (porting that is) 22:48:37 kisom 22:49:12 any specific reason to move away from openssl besides the size of the library? andj 22:49:30 It's not really a move away, more a choice dazo wonder how many times andj will answer that 22:49 andj 22:49:47 mattock 22:50:08 and I will setup buildslaves to test andj's feature branch (within next two weeks?) dazo 22:50:14 kisom: modularity isn't such a bad thing .... and considering that some places want complete review of the software they use ... reviewing PolarSSL is far simpler than OpenSSL mattock 22:50:15 and I will also eat my own dogfood dazo 22:50:43 and I will create the -testing.git/feat_crypto_mod branch andj 22:50:43 mattock: been doing that for a while with 2.1.4 and these patches cool, in that case, if there are no more questions I've got to head off in about 5 minutes or so 22:51:38 so fire away 22:51:45 mattock 22:51:49 I think we covered everything important and have a solid plan going forward 22:51:55 which is what I hoped 22:52:02 dazo 22:52:19 yeah, definitely good cron2 22:53:03 so, 8 more minutes to go (then I need to do some customer work)... dazo 22:53:12 andj: and one key thing to get stuff applied quicker ... that is to be available and responsive .... so even though you have a gigantic patchset ... your responsiveness helps building the trust we need to go further mattock 22:53:16 we can definitely cover MinGW in 8 mins cron2 22:53:29 yeah mattock 22:53:53 dazo: and we need to avoid getting decisions paralysis cron2 22:53:53 my point on this is: we need to have a *free* build system for a free software package, so I'm not very much in favour of paying for MS VC andj 22:54:14 dazo: I've got some work time slotted for OpenVPN, but it won't be as much as the past two weeks (near full-time) 22:54:19 mattock 22:54:46 cron2: I agree... but who will take care of the maintenance? cron2 22:55:02 explain to me again why we need MS VC? mattock 22:55:14 I'm not too keen on maintaining two buildsystems cron2 22:55:28 with the amount of time you spent on the python system in the last year, that would have easily taken care of 10 years of mingw maintenance mattock 22:55:41 cron2: cron2 is strictly opposed to having only a commercial build system available 22:55 dazo 22:56:02 andj: fair enough ... but begin somewhat available, at least on mail is good ... we don't want to completely get full responsibility for further maintaining such changes alone .... kind of like drop'n'run style andj 22:56:14 But it should be enough to fix any problems, and help out jamesyonan 22:56:22 how well is mingw being supported right now? andj 22:56:31 dazo: don't worry I'm not planning on orphaning the patches dazo 22:56:55 mattock: I would like to have mingw/msys working, as there are users who don't want to install MS-VC just to compile OpenVPN or other F/OSS stuff mattock 22:56:57 jamesyonan: mingw seems somewhat outdated... when did you last use it for building official releases? or how did you build them previously? andj 22:56:59 especially the PolarSSL part, as we're the primary reason it's there dazo 22:57:02 andj: good cron2 22:57:08 jamesyonan: well, it works, and the resulting code runs on Win7... jamesyonan 22:57:46 one problem was that mingw wasn't keeping up with changes in windows include files cron2 built a 2.2.0+ipv6 snapshot on WinXP a few weeks ago, and the changes have been fairly minor 22:57 dazo 22:58:13 mattock: What we need to do is to make sure the mingw stuff isn't lagging .... and in Fedora, cross-compiling is a breeze, if the right support is implemented ... (mingw32-configure and mingw32-make, for instance) ... and we know that Alon also does a lot of cross-compiles as well 22:58:38 cron2 22:58:43 jamesyonan: which is only a problem if there is a concurring build system on the same platform (which is what we have now, the MS VC patches breaking mingw compile) mattock 22:58:57 in my limited testing I'd say MinGW would need cleaning up I mean, the domake-win buildsystem 22:59:09 dazo 22:59:19 agreed, we have had much focus on cleaning up MS-VC ... now we need to look at mingw cron2 22:59:21 definitely. adjust path names, version numbers, etc. mattock 22:59:28 there are a few issues here and there, as well as some inconsistencies dazo 22:59:31 mattock: maybe we need to re-think the domake-win stuff? mattock 22:59:52 dazo: how deep rethinking? jamesyonan 23:00:35 other open source projects that run on windows rely on MSVC -- like Python for example dazo 23:00:36 to something which works more easy, with less maintenance ... hard-coding versions, paths and such stuff which is in domake-win now, is kind of nasty L'utente krzee si è disconnesso (Quit: This computer has gone to sleep) 23:01 dazo 23:01:22 jamesyonan: true, but that doesn't make cross compiling as easy, when mingw is the cross compiler andj 23:01:28 thanks for your time guys, speak to you soon dazo 23:01:34 andj: thx a lot! mattock 23:01:40 andj: talk to you later! jamesyonan 23:01:48 take care I found that I burned more time trying to make mingw do what I wanted 23:03:05 cron2 23:03:54 looking at the amount of time mattock burned, MSVC doesn't look so good either dazo 23:03:55 maybe we need to get more visible among the mingw community, and raise our concerns louder there? jamesyonan 23:03:56 I also like the idea of using a non-GNU compiler on at least one platform, because it's a good cross-check of the C portability dazo 23:04:14 yeah, that makes some sense cron2 23:04:20 MSVC forced us to add a lot of changes because it's too retarded jamesyonan 23:04:32 yeah, but look at the difference between a build system written in bash and one written in python mattock 23:04:39 cron2: well, the buildsystem was pretty incomplete when I started jamesyonan 23:04:54 python is a much better language for developing build systems than bash cron2 23:05:00 I'm all fine for "using different C compilers", but not something that got stuck in 1995... (*and* python is another external dependency that is not already there on most systems) dazo 23:05:12 Maybe we should consider a more truly build system written for cross platform support natively? Like CMake or that kind of type? mattock 23:05:26 dazo: that's worth considering jamesyonan 23:05:33 Python is supported very well on Windows cron2 23:05:34 dazo: configure handles cross-building perfectly dazo 23:05:34 (however, CMake adds it's own set of challenges ...) cron2: on POSIX platforms, yes 23:05:47 jamesyonan 23:05:51 while support for bash seems marginal dazo 23:06:00 CMake goes further there are others as well, but I have most experience with autotools and CMake 23:06:16 cron2 23:06:22 we don't support non-POSIX platforms anyway (except for windows), so please no cmake on unix andj 23:06:34 CMake is nice in that it gives visual studio support http://www.scons.org/ is enteresting too 23:06:39 vpnHelper 23:06:40 Title: SCons: A software construction tool (at www.scons.org) cron2 objects to everything that requires installation of additional tools for normal openvpn building on a standard off-the-shelf unix box 23:07 cron2 23:07:17 be it cmake, ant, jmake, you-name-it-of-the-week have been burnt by that too often trying to build "nice opensource package" 23:07:33 dazo 23:07:57 cron2: CMake, with some work can provide a ./configure type of experience ... if we go deeper with CPack ... but to generate the source balls, you need CMake binaries installed however, I've never gone deep with CPack 23:08:25 cron2 23:08:30 "if it's not broken, don't try to fix it" mattock 23:09:00 cron2: atm domake-win is somewhat broken... I think the question is "who will fix it" dazo 23:09:10 yeah, I agree ... however, we have broken build system situation now .... based on different requirements .... POSIX and MSVC mattock: unfortunately, I think some of the fixes will require patching some of the C code as well ... esp. JJO's stuff 23:09:40 mattock 23:10:02 dazo: can't they (autotools + MSVC/Python) live side by side? dazo 23:10:18 yes, that's doable ... but more maintenance and as long as the compilers agree 23:10:29 like cron2's rant about MSVC's compiler being stuck in 1995 23:10:58 cron2 23:11:01 include file changes can be a bit of a challenge, but that's normally a one-off task for larger change sets, and nothing you need to do on a regular basis dazo 23:11:33 caps in include filenames (since some filesystems are case sensitive, others not) 23:11:56 cron2 23:12:49 get that right for the case sensitive environments, don't bother with the rest dazo 23:12:59 true mattock 23:13:13 the biggest change I'd like to see in domake-win is removing hardcoded dependency paths (install-win32/version.in) and making it use the same dependency directory structure as Python-based buildsystem and, unlike you think, I'm not volunteering for the job 23:13:27 I got my hands full already 23:13:36 dazo 23:14:09 mattock: do we have a buildbox ready for mingw on Windows? mattock 23:14:10 and also fixing some of the assumptions about the dependencies dazo can try to have a look at it ... without promising anything 23:14 mattock 23:14:31 dazo: not really... I only got far enough to test my latest patches also, it's on my private Win7 smoketest VM with no access from outside 23:14:49 dazo 23:14:50 because we should try domake-win on both Windows and Linux for cross-compiles mattock 23:15:35 dazo: I think we could use the Windows 2008 r2 build computer for that I don't think installing MinGW or man2html on it would break stuff 23:15:57 https://community.openvpn.net/openvpn/wiki/BuildingOnWindows 23:16:05 dazo 23:16:05 mattock: maybe as a separate user, so we don't mess up the MSVC build environment vpnHelper 23:16:07 Title: BuildingOnWindows â OpenVPN Community (at community.openvpn.net) mattock 23:16:58 dazo: most the build dependencies are the same, so I don't think we'd even need to use separate users dazo 23:18:02 I still am leaning towards something separate ... to be absolutely sure those two environments don't interfere ... I honestly don't trust Windows enough to separate things well enough (on the same user account, that is) 23:18:18 mattock 23:18:18 in that case another VM would be the best bet dazo 23:19:01 yeah, true ... but a middle way, would be a separate user account, I think ... but separate VM is definitely the safest mattock 23:19:17 let's go with a separate user account and see what happens _after_ 2.2.1 is out 23:19:23 dazo 23:19:24 goodie! L'utente krzee è entrato nella stanza 23:19 dazo 23:19:29 yeah mattock 23:19:31 regarding 2.2.1... L'utente krzee si è disconnesso (Changing host) 23:19 L'utente krzee è entrato nella stanza 23:19 mattock 23:20:11 dazo: can you push my three patches to release/2.2 today/tomorrow morning? I could then prepare the installers for jamesyonan for signing 23:20:47 dazo 23:20:51 mattock: I can try that tomorrow ... have had a rougher week than planned ... so my head begins to melt soon mattock 23:21:15 ok, if that start happening, just drop the ball on this dazo 23:22:00 mattock: mattock 23:22:10 jamesyonan: when do you usually start working? I doubt I'd get the installers out before you stop for today dazo 23:22:26 I need to run now ... need to grab some food before shop closes mattock 23:22:46 dazo: have fun! dazo 23:22:58 thx L'utente dazo ha lasciato la stanza ("Leaving") 23:23 jamesyonan 23:23:25 I usually start about 1700 or 1800 UTC L'utente dazo è entrato nella stanza 23:23 mattock 23:23:37 when do you stop working? jamesyonan 23:23:52 good question mattock 23:23:55 L'utente dazo è ora conosciuto come dazo_afk 23:24 mattock 23:24:35 well, it does not matter... I'll try to prepare the files for you to sign as early as possible and if you're still awake, I'll mail you 23:24:46 I can do the rest of the release preparations during the day 23:25:21 I think I got to get some sleep now, and most others have vanished already so... have a nice day/evening/night everyone! 23:26:11 I'll write the summary tomorrow, as usual 23:26:19
