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 24th Apr 2014 Time: 18:00 UTC Planned meeting topics for this meeting were on this page: <https://community.openvpn.net/openvpn/wiki/Topics-2014-04-24> Your local meeting time is easy to check from services such as <http://www.timeanddate.com/worldclock> or with $ date -u SUMMARY cron2, jamesyonan, mattock, pekster, plaisthos, syzzer and timothe participated in this meeting. -- Discussed some of the recently found issues in "TLS versioning", including, but not limited to <http://thread.gmane.org/gmane.network.openvpn.devel/8585> Agreed to apply James' off-by-default patch to the 2.3 branch, but to add information to the man-page describing how TLS versioning can be enabled if necessary. Also agreed to keep TLS versioning on by default for Git master but to revisit that decision when 2.4 is about to be released. -- Discussed our testing procedures. While we do lots of different types of tests, some of them are entirely undocumented so we don't have a good understanding of what we test and how we do it. Decided to a) document our current test procedures in the Trac Wiki to get a good overview of the current situation b) generate a test matrix that we'll go through before each release Also agreed that automated Windows connectivity tests would be very valuable. -- Discussed the 2.3.4 release. Decided to - make the release on Monday - include the TLS versioning changes discussed above - include _bt's Windows installer fixes/enhancements (provided they pass testing) - include latest openvpn-gui which has GUI version reporting (IV_GUI_VERSION) -- In addition discussed a few pending patches briefly. -- Full chatlog as an attachment -- Samuli Seppänen Community Manager OpenVPN Technologies, Inc irc freenode net: mattock
(21.00.37) mattock: ok, the meeting is about to begin (21.00.44) mattock: a few months since the last time (21.00.52) cron2: moh (21.01.26) mattock: here are the topics: https://community.openvpn.net/openvpn/wiki/Topics-2014-04-24 (21.01.28) vpnHelper: Title: Topics-2014-04-24 – OpenVPN Community (at community.openvpn.net) (21.02.27) timothe [~chatzilla@2001:4830:11a2:941:3d00:f28b:3677:42d8] è entrato nella stanza. (21.02.39) syzzer: ah, good timothe is joining too! (21.02.52) mattock: hi timothe! (21.03.09) timothe: Not sure how long I can stay, but thought I'd drop in since I've been browsing... (21.03.12) cron2: cool (21.04.32) syzzer: so we're waiting for James then? (21.04.40) mattock: so today's main topic is TLS versioning, how it broke things, what to do about it and how this affects 2.3.4 (21.04.53) mattock: james should be here shortly (21.05.28) jamesyonan [~jamesy...@c-71-56-216-17.hsd1.co.comcast.net] è entrato nella stanza. (21.05.28) modalità (+o jamesyonan) da ChanServ (21.05.33) timothe: I just sent out a note with my latest findings. Not at root cause, but closer. (21.06.12) jamesyonan: hi guys (21.06.21) mattock: hi jamesyonan! (21.06.25) cron2: hi james (21.06.54) mattock: james: the topic list is here: https://community.openvpn.net/openvpn/wiki/Topics-2014-04-24 (21.06.56) vpnHelper: Title: Topics-2014-04-24 – OpenVPN Community (at community.openvpn.net) (21.07.00) mattock: not really a list, just one major topic (21.07.27) mattock: I assume everyone is more or less familiar with the discussion that took place on openvpn-devel mailinglist? (21.07.43) timothe: More or less... (21.08.05) mattock: I think most / all of it is here: http://thread.gmane.org/gmane.network.openvpn.devel/8585 (21.08.08) vpnHelper: Title: Gmane Loom (at thread.gmane.org) (21.09.27) mattock: could someone summarize the issue and the various fixes that were proposed? (21.09.38) syzzer: I think that the conclusion is that all the problems reported to us through the public channels can be related to TLSv1.2 adding more hashes (with different sizes) (21.09.46) timothe: I can give it a stab (21.10.15) timothe: Others may want to add/revise. (21.10.31) syzzer: go ahead, you've spent quite some time digging into this (21.10.50) timothe: TLS versioning caused OpenVPN to start using TLSV1.2 - previously it was locked to 1.0 (21.11.15) timothe: It turns out that there are some sublties in 1.2 that cause breakage in unexpected places. (21.11.41) jamesyonan: while the new hashes of 1.2 are an issue, I've also seen cases where allowing 1.2 breaks connections through firewalls (21.12.04) timothe: The big one is that 1.2 uses different (and larger) signatures on client certificates that are negotiated between client and server. (21.12.39) timothe: There are parts of openvpn that don't support this. We know that the cryptoapi doesn't. (21.13.09) timothe: There's a partially understood case in the UK that also seems to be hash-based. (21.13.44) timothe: So the question is what to do. Do we unconditionally revert to 1.0 until everything is supported. Or do we do something smarter. (21.14.08) syzzer: yup (21.14.15) timothe: clearly we do need to provide a means to force lower versions. (21.14.47) timothe: I've written something up with more detail - it's posted off the topics wiki page. (21.15.12) timothe: There are two ideas: (21.15.39) timothe: 1) James's - --tls-version-max is a big hammer. I agree we should have it. (21.16.19) timothe: 2) I suggested something more adaptive that would only downgrade when necessary, and would minimize the need for admin smarts and config file changes. (21.16.32) timothe: I think that's the quick summary. (21.16.48) cron2: afk for a moment, need to kill^wtend one of the kids (21.17.06) plaisthos: I would prefer to have at least in 2.4 to have tls 1.2 enabled on default (21.17.24) plaisthos: I see that breaking that from 2.3.2 to 2.3.3 is not good (21.17.28) syzzer: yes, I agree we should leave master as-is and just fix bugs (21.17.45) mattock: syzzer: you mean the 2.3 branch? (21.17.48) timothe: Well, this IS a bug (or bugs). (21.17.50) plaisthos: and provide some tls-max-version or something else for master (21.18.10) syzzer: mattock, no I mean leave 1.2 enabled in 2.4/master (21.18.22) mattock: ah yes, makes sense (21.18.42) mattock: so fix this problem in 2.4/master without reverting back to TLS 1.0 or whatever (21.18.56) syzzer: timothe, I totally agree, but master is instable, so I think having some rough edges there is not an issue (21.19.02) timothe: Certainly just disabling 1.1 and 1.2 in 2.3 is a quick, safe fix. (21.19.26) syzzer: instable as in not meant to be perfectly stable (21.19.42) syzzer: I'd vote for just disabling 1.2 (21.20.01) plaisthos: mattock: there is probably no fix without disabling 1.2 (21.20.04) mattock: also, after the fixes to TLS 1.2 that go into master stabilise a bit we may reconsider backporting them to 2.3 (if it makes sense anymore at that point) (21.20.12) timothe: Do we know that 1.1 doesn't break anything? James? (21.20.26) plaisthos: that is also the reason browsers waited so long to switch to tls 1.2 (21.20.34) timothe: We don't want a series of reversions. (21.21.37) syzzer: 1.1 is much less likely to break stuff (21.22.13) jamesyonan: I would tend to vote for not enabling tls versioning unless the directive is explicitly provided (21.22.32) jamesyonan: we can always change that policy in the future when TLS 1.2 is better supported (21.22.33) timothe: (I mean in the 2.3 series.) "Less likely" doesn't go well with "stable"; if not sure, why not go all the way back to 1.0. The added security isn't all that much, right? (21.22.57) syzzer: 1.1 does bring some significant security improvements (21.23.06) syzzer: 1.2 just adds ciphers suites (21.23.41) timothe: For security geeks, yes. For real world, is it worth the risk of having to say 'oops' again? (21.24.18) syzzer: well, the thing is that I haven't seen any problems that we can relate to 1.1 yet (21.25.27) jamesyonan: I've seen issues where just the act of using tls-versioning breaks stuff (21.25.44) syzzer: ah, that was what I was about to ask (21.25.58) timothe: I wouldn't object to a directive that enabled 1.1, but for stable, as a customer, I would think 1.0 should be the default until 1.1 is proven innocent. (21.26.16) jamesyonan: these issues usually involve government firewalls (21.26.37) timothe: We shouldn't impose an adventure on customers - at least, not on'stable' releases. (21.26.49) jamesyonan: timothe: agreed (21.27.05) syzzer: since jamesyonan actually sees problems regarding tls versioning I agree (21.27.58) cron2: so that would translate to "use James' patch to disable-by-default tls-versioning for 2.3, and go fixing it for good in 2.4"? Or "merge in both, and then go searching for a proper fix in 2.4"? (21.28.41) mattock: what does significant security improvements mean? (21.28.53) mattock: oh, sorry (21.28.56) syzzer: the protocol of 1.0 is just broken (21.29.20) mattock: (was responding to backlog) :) (21.29.30) syzzer: yes, an attack is not easy, but if you're dodging governments, that's really bad (21.30.49) mattock: what about the TLS 1.2 -related issues we've had so far (21.30.50) syzzer: but if you can't dodge governments at all using 1.2, let's just make it as hard as possible ;) (21.31.29) mattock: ... would moving to TLS 1.1 fix those? (21.31.33) jamesyonan: people can always add tls versioning if it's important to them (21.31.53) timothe: 1/3 to 1/2 of the 1.2 issues are understood. 1 or two are not. We think 1.1 doesn't have them. (21.31.55) syzzer: jamesyonan: yes, which I why this should be 'good enough' for now (21.32.12) jamesyonan: OpenVPN clients can even expose the option more prominently in their UIs, so end users can decide (21.32.54) timothe: I'm not for putting it in a GUI. We need to make it 'just work'. (21.33.03) Tech-49 [~ma1com...@host-92-20-12-238.as13285.net] è entrato nella stanza. (21.33.29) syzzer: timothe: making it possible to forcebly enable 1.2 should be fine (21.33.31) mattock: did others have a look at Timothe's suggestion (#2 above) (21.33.48) syzzer: but I agree we should not add 'disable 1.2' buttons (21.34.24) timothe: The less there is in a UI, the greater the chance that the secure choice will be made. End users really don't understand security. (I'm one, though I know more than most.) (21.34.27) syzzer: I think #2 is medium-term, in that it means we have to wait for bug reports and then go add directives in the code (21.35.04) timothe: Not necessarily. We can actively go thru the code for 1.2 dependencies. (21.35.29) syzzer: yes, but I'm not sure we'll catch all the corner cases (21.35.45) timothe: And it does provide a framework for 1.3 or 1.4 - in the future, we would only turn things on when they are tested... (21.36.18) syzzer: but what is tested? the TLS versioning was tested by thousands of Android clients already (21.37.05) timothe: Hopefully, we learn to test better. But there is always risk; the question is how to manage it. (21.38.27) cron2: syzzer: I think the issue with the android clients might be "if they are connecting to a 2.3.2 server that does not have tls-versioning, the code is never excercised" - which might be why James saw so many more issues than plaisthos (21.38.29) syzzer: the problem here is that OpenVPN has a myriad of options, and we (or at least I) don't have time to test them all unfortunately (21.38.59) cron2: +1 - we do our best, but stuff like that ("with firewall type X in between") can not be exhaustively tested (21.39.05) syzzer: cron2: point taken (21.39.34) cron2: otoh, our corp server is running git master with ios clients since $months, so the code *is* used there, and didn't cause issues (21.39.51) timothe: That argues for: (a) documenting what's tested and recommended (b) removing/deprecating marginal options (c) enlisting users who can test what the core team can't. (21.40.30) mattock: agreed (21.41.00) cron2: easier said than done. What sounds uninteresting for me ("cryptoapi on windows") is a killer feature for someone else... (21.41.23) timothe: Then we get the someone else (in that case, me) to agree to test it for us. (21.41.28) cron2: and we know that we have no idea what weird (to us) setups people use "Because it works" (21.41.40) syzzer: ^ that. Still, we try to do exactly that where possible ;0 (21.42.15) cron2: yep. My test framework now runs ~10 different t_client tests before I push anything :-) (21.42.18) pekster: fwiw, I did build some preview packages that I've had on bitbucket (formerly sourceforge) for a few months now, using 2.3.2 as a base with the TLS versioning (21.42.26) timothe: So we ask for help. People usually will help if one asks. "Please tell us what config you are using so we can test it. By the way, can you test for us?) (21.42.44) pekster: In the future, I'm happy to publish them (or make them availbale for "official" signing if we'd like) so early-adopters can test. If it's useful. (21.43.13) cron2: I think we should just get mattock to do nightly builds of "master" and publish them :-) (21.43.24) syzzer: doesn't mattock already do something like that? (21.43.30) pekster: Sure, though beware things like pulling in snappy deps for binary-dists (21.43.41) pekster: (unless the buildsystem is doing --disable-snappy already) (21.43.42) cron2: syzzer: tbh, no idea (21.43.46) mattock: syzzer: I did at one point, then gave up (21.44.11) mattock: also, if we want to get people more involved in testing (which makes sense), we need to be able to define some precise tests they should do (21.44.16) cron2: ok, can we (please) re-focus on "what are we going to do short-term to 2.3.4-to-be, and long-term to master"? (21.44.21) timothe: Back to immediate topic. Is there a decision? (21.44.25) cron2: heh :) (21.44.44) jamesyonan: why don't give tls versioning some time with early adopters then make a decision down the road when to make it the default (21.45.05) cron2: jamesyonan: so you'd opt for "disable by default in 2.3, enable by default in 2.4"? (21.45.13) cron2: (s/2.4/master/) (21.45.18) pekster: Will a 2.3.4 have an option flag then for people who want to keep it? Or will 2.3.3 have it and 2.3.4 not? (21.45.42) pekster: So long as we're clear in the release notes, I'm sort of okay either way, but removing it completely seems wrong (21.45.44) cron2: pekster: there's a patch from James on the ML to make it off-by-default, unless you do --tls-min-version 1.0, which would turn it on (21.46.12) pekster: Ah, okay. Fine by me so long as it's clarified in the release notes (21.46.21) syzzer: yes, even though I still think that is totally confusing behaviour, I vote for using james' patch (21.46.25) jamesyonan: my vote would be to apply the off-by-default patch now, then revisit before 2.4 is released (21.46.38) syzzer: it does give users the ability to enable it / test it (21.46.39) cron2: jamesyonan: apply to both 2.3 and 2.4? (21.46.40) timothe: Which also needs tls-max-version to cap it at 1.1 for some. (21.47.07) cron2: (when I say "2.4" this is "what we have in master now, work in progress") (21.47.11) jamesyonan: cron2: yes (21.47.40) syzzer: 2.4 too? (21.48.06) syzzer: that gives us less test coverage (21.48.14) cron2: it would need an addition to the man page, to clarify that "option not set" = "tls 1.0, only" (21.48.21) jamesyonan: yeah, that's a good point (21.48.23) timothe: Once it's in config files, the directive has to exist for the indefinite future. (21.48.45) syzzer: timothe, that can also mean ignore it if it has no meaning anymore (21.49.10) syzzer: (and issue a deprecation warning) (21.49.15) pekster: It's been discussed before, and I think long-term is gives flexibility to defining a security policy (or policy for passing whatever $appliance has Special Needs.) (21.50.20) plaisthos: IMO I think it is wrong for future OpenVPN releases to have TLS 1.0 only behaviour as default (21.50.30) plaisthos: If you don't do that for 2.4 when will we do it? (21.50.34) timothe: sure, but if we say 'tls-min' means use no less than, and 'tls-max' means 'at most', those aren't ephemeral promises. I think tools deliver mechanisms; configs deliver policies. (21.50.36) cron2: plaisthos: "future" being "2.3.4" or "2.4.0"? (21.50.37) pekster: The only drawback I see is that people depending on the 2.3.3 behavior now need a new option. Manpage + release notes need to clarify any change to this as it's not-backwards-compat (21.50.46) jamesyonan: I'm okay with off-by-default patch only applied to 2.3 for now (21.50.47) plaisthos: cron2: future begin 2.4.0 (21.51.33) jamesyonan: with 2.4 we can revisit before final release (21.51.36) cron2: ok, I think we seem to agree on 2.3.4 -> "off-by-default patch, with man-page explaining what happens" (21.51.57) plaisthos: Just now the browsers (Chrome and FireFOX) have turned on TLS 1.2 on by default (21.52.10) plaisthos: that will probably also help to find and fix these TLS 1.2 vs TLS 1.0 bugs (21.52.15) pekster: I agree with plaisthos on making it a core goal for 2.4 to have this on-by-default. It's a major version bump, and should provide Better Security by default, IMO (21.52.24) pekster: But, that's for a later meeting I guess :) (21.52.44) syzzer: pekster, plaisthos: +1 (21.52.52) cron2: you agree what you want to see in git master "right now" and tell me what to merge where :-) (21.52.54) jamesyonan: +1 (21.53.12) timothe: I'm all for making 1.2 work. But it does have to work. off by default for 2.3.4 is fine with me. On by default (so we can debug) in master is my vote. (21.53.36) timothe: (If I get a vote...) (21.53.50) plaisthos: jamesyonan: did you revert to tls 1.0 only in PolarSSL/OpenVPN3 as well? (21.54.25) jamesyonan: yes (21.55.09) syzzer: brb (21.55.54) jamesyonan: So I ACK on applying off-by-default patch to 2.3 only and revisiting the question before 2.4 release (21.56.12) ***plaisthos agrees (21.56.33) ***cron2 idly speculates whether our ACK rules permit James to ACK his own patches :-) (21.56.55) pekster: Put my name down as a feature-ACK too if you really want :P (21.57.01) cron2: nah (21.57.17) cron2: I was just being silly (21.57.30) jamesyonan: well I'm actually NACKing my own patch for master :) (21.58.13) plaisthos: jamesyonan: will you send a patch for ip_forward so can ACK that version? (21.58.14) mattock: good, a decision based on consensus with this little fighting (21.58.17) mattock: :P (21.59.26) jamesyonan: ip_forward? (21.59.27) mattock: so just to make sure I understood this correctly... we only need to add the "off by default" patch to 2.3.4, plus a man-page patch and we're done with this? (21.59.43) syzzer: ACK ;) (21.59.45) cron2: mattock: well, we still need to fix the actual problems :-) (21.59.50) mattock: of course :) (22.00.03) cron2: "we" being "lots of people, not me" (22.00.12) mattock: was that a disclaimer? (22.00.30) pekster: mattock: Ideally a "well-visible" note of this in the changelog, not just a line-item under James' patches (easy to get lost, angry users, etc) (22.00.48) cron2: mattock: no, it's just that I'm a network coder, not a crypto geek (22.00.54) plaisthos: jamesyonan: Subject: [Openvpn-devel] [PATCH 2/4] Added PIP_OPT_MASK for process_ip_header fast exit path. (22.01.30) mattock: did TLS versioning go into 2.3.3 or 2.3.2? (22.01.36) pekster: 2.3.3 (22.01.38) plaisthos: 2.3.3 (22.01.38) cron2: 2.3.3, brand new (22.01.42) mattock: so it has not been out there for long (22.01.54) plaisthos: which many users downloaded because of heartbleed (22.01.55) pekster: No, but I can tell you that $work is relying on this ;) (22.02.08) mattock: plaisthos: good point (22.02.30) mattock: are we done for today? (22.02.44) syzzer: when will the new release be? (22.02.51) plaisthos: I have looked at Patches list and there is nothing pressing for 2.3.4 (22.02.58) mattock: I vote next monday (22.03.17) mattock: I don't think it's a good idea to release anything on Friday (22.03.17) cron2: mattock: why specifically "monday"? (22.03.20) cron2: ah (22.03.26) timothe: Are there testing criteria? (22.03.47) mattock: "if it builds, ship it"? :P (22.03.55) plaisthos: compile it, ship it? (22.03.58) cron2: there's actually one patch I want to merge - --multihome on FreeBSD is broken, the patch is simple and straight-forward, and has been rotting on -devel for 4+ months now "lazy ack rules" (22.04.09) mattock: cron2: sounds good (22.04.27) mattock: timothe: would you like to be more involved in improving our testing procedures? (22.04.36) cron2: timothe: well, I have my t_client test framework which connects to a few reference servers and tests whether the basic thing ("connect, authenticate, ifconfig/route, move packets") works (22.05.07) mattock: cron2: what we could improve is the server side (22.05.23) mattock: have several different versions of openvpn running on the server-side (22.05.38) mattock: or a few at least (22.05.42) cron2: mattock: I have a test server that builds master every day, and then fires off t_client tests on a different machine (22.05.53) cron2: caught the --inetd breakage :) (22.06.01) mattock: good (22.06.18) timothe: I can certainly review, but as I'm quite new to the product, I'm hardly an expert reviewer. (22.06.39) cron2: but yeah, testing could certainly be improved - more code paths tested ("I have socks and http proxy tests now"), etc. (22.06.57) timothe: I expected to install it and have it work for me - but things rarely work out that way :-( (22.07.20) syzzer: I do run (basic) pkcs#11 tests for polarssl builds, I could do those for openssl too probably (22.07.29) mattock: I guess it depends on how far your needs deviate from the lowest common denomitor kind of setup (22.07.40) cron2: syzzer: that would be good. I have no idea about pkcs#11 (22.07.52) mattock: perhaps a good place to start would be to document what kind of tests we're doing right now? (22.07.58) plaisthos: I let Android users test OpenVPN -master on the client side d: (22.08.04) cron2: mattock: we do need an automated windows test! (22.08.12) mattock: cron2: agreed (22.08.26) mattock: that will be interesting to setup (22.08.30) cron2: mattock: ... and I still wonder why your windows snapshots are building ok (22.08.39) timothe: Yes, document. Then put a checkbox beside each one, and don't release unless all pass. That's a start... (22.09.06) mattock: I'll check if we have something to start from in our wiki... (22.09.25) syzzer: I came along this page a while ago: https://community.openvpn.net/openvpn/wiki/SettingUpBuildslave (22.09.26) vpnHelper: Title: SettingUpBuildslave – OpenVPN Community (at community.openvpn.net) (22.09.30) syzzer: I guess that needs an update ;) (22.09.51) cron2: mattock: as for the 2.3.4 release, d12fk has pushed a new gui version. We should see IV_GUI_VER now, but maybe we should test this "before monday" to make sure it actually works :-) (and I still want the "build version" in there) (22.09.55) mattock: there is something, yes, but it's very high-level, nothing that concrete: https://community.openvpn.net/openvpn/wiki/OpenVPN_QA (22.09.57) vpnHelper: Title: OpenVPN_QA – OpenVPN Community (at community.openvpn.net) (22.10.03) syzzer: I actually run Windows tests for OpenVPN-NL releases btw (22.10.12) cron2: syzzer: how do you do that? (22.10.24) mattock: guys: I will add more concrete stuff to the page above (22.10.25) syzzer: but thats using company tooling (not opensource :( ) (22.10.32) mattock: you can fill in what types of tests you're running atm (22.10.56) ender| ha abbandonato la stanza (quit: Ping timeout: 246 seconds). (22.11.00) cron2: plaisthos: did you get approval for coverity? (22.11.20) mattock: syzzer: re: buildslave page: yes, a guy wanted to donate an arch x64 buildslave today, so I slightly updated the page (22.11.23) mattock: it's still somewhat outdated (22.12.47) plaisthos: cron2: I have to login to check (22.12.52) plaisthos: cron2: I will check tommorrow (22.13.00) plaisthos: I don't have the credentials on this machine (22.13.30) ender| [krneki@2a01:260:4094:1:42:42:42:42] è entrato nella stanza. (22.13.54) mattock: I think we're done for today (22.13.58) mattock: agreed? (22.13.59) cron2: plaisthos: not yet. Two people came in in April 2014, but not you. Weird (22.14.19) cron2: mattock: semi. Plaisthos: did you have time to look at the EC patches? (22.14.23) plaisthos: mattock: Yes. I think so (22.14.55) plaisthos: cron2: 2/2 is the same as in v1 set I think (22.15.03) cron2: yeah, 2/2 is easy (22.16.04) plaisthos: syzzer: is there anything apart PolarSSL and #ifdef changed? (22.16.19) timothe ha abbandonato la stanza. (22.16.33) syzzer: plaisthos: no (22.16.46) plaisthos: + msg (M_DEBUG, "Your OpenSSL library was built without elliptic curve support." (22.16.49) plaisthos: + " Skipping ECDH parameter loading."); (22.17.17) plaisthos: are you sure that you want that in show_available_curves() and not in tls_ctx_load_ecdh_params (22.17.45) syzzer: dammit, copy-pasted that, forgot to change the msg :/ (22.18.02) plaisthos: there is no message at all in load_ecdh (22.18.05) syzzer: but it's on purpose not in tls_ctx_load_params (22.18.35) plaisthos: It would show up every start ... (22.18.37) syzzer: no, that would probably just annoy users. I believe in "only issue warning if its relevant' (22.19.07) pekster: At debug extra noise is fine (enable_debug=no by default) (22.19.11) cron2: ok, so we'll see a v3 of 1/2 then, with the the right message text :) (22.19.18) pekster: At non-debug verb levels though, I agree (22.19.29) ***syzzer makes mental note to not submit patches after 23:30 anymore... (22.19.50) cron2: "still 2:10 hrs to go" (22.19.51) syzzer: cron2: yup (22.20.00) plaisthos: :) (22.20.41) cron2: ok, another thing that is pending (22.20.50) cron2: certificate serial numbers, in decimal or in hex (22.21.09) cron2: since it is (for openssl) a documentation issue only, I think that should also go in, and into 2.3.4 (22.21.49) cron2: and we could include James' patch to make polarssl serial numbers prefixed with "x", so it's clear "these are hex" (22.22.06) cron2: (which means the documentation needs more updating, to explain that there could be both variants) (22.22.24) syzzer: ah, yes. I did think about that one last night (once again, do not submit patches after 23:30...) (22.22.55) syzzer: if we're changing the representation, it might be better to just change it to match OpenSSL behaviour (22.23.09) syzzer: putting an 'x' in front will break script too probably (22.23.21) n13l: syzzer: hi, i did post patch 18:33 :-) (22.23.29) cron2: syzzer: how complicated is it to make PolarSSL spit that out in serial? (22.23.33) cron2: "5 lines" or "50 lines"? (22.23.55) syzzer: something like 20 I think (22.24.13) plaisthos: .oO(String.format("%d", Integer.parseint(serial,16))) (22.24.41) cron2: "it could be up to 20 digits" (22.24.48) syzzer: plaisthos, that actually might not be such a bad plan... (22.24.55) syzzer: the C-variant ofc ;) (22.26.08) syzzer: I'll figure it out and send a patch (22.26.20) cron2: thanks (22.26.57) plaisthos: syzzer: module the BigINt stuff going on there ... :/ (22.27.29) syzzer: n13l: hi :) sorry for not responding - other stuff needed my attention (like the current TLSv1.2 breakage) (22.27.53) cron2: with that, I think I'm fine with calling it a day (22.28.29) syzzer: good, because I have to go too :) (22.28.34) mattock: nice! (22.28.55) cron2: *wave* (22.28.56) mattock: I think I'll summarize this last section as "Discussed various pending patches. Period." :) (22.29.23) syzzer: sounds reasonable (22.29.25) syzzer: bbl :) (22.29.38) mattock: good night guys! (22.29.47) cron2: oh, and mattock needs to merge and test the installer improvements :) (22.29.57) cron2: (just looking at openvpn-build...) (22.30.01) mattock: oh yes, I do (22.30.22) mattock: shall we add them to 2.3.4? (22.30.33) mattock: provided they work ok (22.30.35) mattock: of course (22.30.49) cron2: I'd say so, I had quite a bit of troubles with users not closing the gui before upgrading (22.31.13) mattock: especially in conjunction with the heartbleed vulnerability the current installers are a bit dangerous (22.31.31) mattock: because the old SSL lib could be left lying around (22.31.49) mattock: so let's put the fixes/enhancements to 2.3.4 (22.31.54) cron2: yes (22.32.13) cron2: what is $OPENVPN_GUI_VERSION used for in openvpn-build? (22.32.22) cron2: it is set to "6" but "git grep" can't find anything where it's used (22.33.12) cron2: ah, it's downloading openvpn-gui-$number.tar.gz from somewhere? Or is it building that tarball from git checkout? (22.33.12) mattock: currently it's 6, but I generated that version from openvpn-gui git master ... d12fk had not tagged the release or provided a "real" openvpn-gui-6 installer (22.33.16) mattock: it is (22.33.22) cron2: which one? (22.33.23) mattock: it is downloading a tar.gz (22.33.39) mattock: which is basically openvpn-gui dir wrapped up into tar.gz after running autoreconf (22.34.09) cron2: ok, I'm not going to test the new gui tonight... this will have to wait until I had more sleep (22.35.36) mattock: and d12fk's new GUI with the IV_GUI_VERSION thing will go into 2.3.4, right? (22.36.18) cron2: hopefully. he says he has pushed it yesterday evening, which is why I'm curious and want to test that (22.36.37) cron2: ... and figure out how to get $INSTALLER_VERSION into that (22.36.55) cron2: as 2.3.4-I001 could be broken, and 2.3.4-I002 good, with the very same gui version... (22.37.57) mattock: so embed the installer version into the IV_GUI_VERSION string? (22.38.21) cron2: yep, like a "build I002" or so (Tunnelblick does that, which I definitely like) (22.39.01) cron2: and with that -> sofa. Have a good night, all of you (22.39.09) mattock: good night! (22.39.21) plaisthos: good night
