Hi, Here's the summary of the previous IRC meeting / sprint.
--- COMMUNITY MEETING Place: #openvpn-devel on irc.freenode.net List-Post: openvpn-devel@lists.sourceforge.net Date: Thursday 29th Sep 2011 Time: 18:00 UTC Planned meeting topics for this meeting were on this page: <https://community.openvpn.net/openvpn/wiki/Topics-2011-09-29> Next meeting will be announced in advance, but will probably be on the same weekday and at the same time. Your local meeting time is easy to check from services such as <http://www.timeanddate.com/worldclock> or with $ date -u SUMMARY andj, cron2, dguerri, jamesyonan, mattock, scifiCinereller and SviMik participated in this meeting. -- Discussed "Client's routes ageing timer" patch from dguerri: <http://article.gmane.org/gmane.network.openvpn.devel/4994> An earlier version of this patch was ACKed by dazo in previous meeting, on the condition that minor changes are made. Those changes are implemented in this patch, which was subsequently given an ACK by cron2 and andj. -- Discussed status of our buildbot environment / buildslaves: <https://community.openvpn.net/openvpn/wiki/SettingUpBuildslave#Listofexistingbuildslaves> Cron2 informed us that his company (space.net) could offer several buildslaves (e.g. various FreeBSD flavours) for the project, with cron2 managing them. However, some form of acknowledgement would be required. Agreed that "Sponsors" page on the community wiki would suffice. Jamesyonan will discuss this offer with others in OpenVPN Tech and report back. Mattock said that he plans to have connectivity tests on buildslave up again by 2.3 alpha release (in 2-3 weeks). -- Discussed the "Segfault in PF" bug: <https://community.openvpn.net/openvpn/ticket/163> More information about the setup that trigger bug this is available here: <http://backreference.org/2010/06/18/openvpns-built-in-packet-filter> Andj and jamesyonan came up with a patch, which in SviMik's tests fixed the bug. -- Discussed Eike's question regarding openvpn-status.log: <http://thread.gmane.org/gmane.network.openvpn.user/32525> Jamesyonan said that "Bytes Received, Bytes Sent" refers to bytes sent over the tunnel socket. So janjust's analysis (on ml) was correct. -- Discussed the ooshirts.com T-shirt order. Agreed that it's best if mattock creates a few designs for review first. -- Reviewed andj's PolarSSL "Misc cleanup" patches. Their status before and after the meeting: <https://community.openvpn.net/openvpn/wiki/PolarSSLintegration?version=61#Misccleanup> <https://community.openvpn.net/openvpn/wiki/PolarSSLintegration?version=65#Misccleanup> Also discussed handling of isolated PolarSSL patches that don't modify existing files. Agreed that they don't necessarily need a thorough review _right now_, as OpenSSL will still be used by default. So, initially, PolarSSL code would be in the "use at your own risk" category. More careful review could come later, after the code is already in Git. --- Full chatlog as an attachment -- Samuli Seppänen Community Manager OpenVPN Technologies, Inc irc freenode net: mattock
andj 21:01:35 evening all jamesyonan 21:01:45 hi dguerri 21:03:55 hi there mattock 21:04:15 hi all! topics here: https://community.openvpn.net/openvpn/wiki/Topics-2011-09-29 21:04:36 vpnHelper 21:04:38 Title: Topics-2011-09-29 â OpenVPN Community (at community.openvpn.net) mattock 21:04:54 perhaps we could start with dguerri's patch? dguerri 21:05:06 would be great andj 21:05:09 sure dguerri 21:05:31 it's very tiny indeed so it could be done quickly mattock 21:05:47 so, it's this one: http://article.gmane.org/gmane.network.openvpn.devel/4994 vpnHelper 21:05:50 Title: Gmane -- Mail To News And Back Again (at article.gmane.org) mattock 21:06:07 dguerri: so dazo basically gave this an ACK already? dguerri 21:06:14 yes, i've provided you the patch against the trunk as requested mattock: yes, in the previous meeting 21:06:35 mattock 21:06:52 on the condition that a few changes were made? dguerri 21:06:56 but requested some minor changes mattock 21:07:00 yep dguerri 21:07:12 that i've done mattock 21:07:34 cron2, andj, jamesyonan: any comments? dguerri 21:07:34 so I think this patch would be generally useful but it's up to you 21:07:51 andj 21:07:56 I'm opening it now, just a sec cron2 21:07:58 if dazo already ACKed it, I'm fine with it (and from a cursory glance, it looks useful and sane) dguerri 21:08:41 there is only a question⦠i'm pretty sure it coulee be very useful in tap mode not sure about tun 21:08:47 cron2 21:09:14 in tun mode, there's not really something to learn and to age as the server *knows* which network is where 21:09:26 (OTOH, it installs specific entries for hosts where a network-iroute exists, IIRC, and as v6 networks can be *large*, it could be useful there as well) 21:10:03 dguerri 21:10:24 right... cron2 21:10:54 well, yes. If you iroute v6 networks, and there is churn, you ned to age as well. andj 21:11:02 cursory glance says ack on the 2.1.0 one cron2 21:11:20 we don't take feature patches for 2.1 so I only looked at the -master one 21:11:35 andj 21:11:36 I know, I was looking at the wrong one, my bad 21:11:47 dguerri 21:11:52 I've patched 2.1 because the latest ubuntu LTS use that version lol 21:11:58 cron2 21:12:35 dguerri: yes, for "I need to have something that works now", patching 2.1 or 2.2 is the way to go - for "inclusion in the upstream sources", 2.3 is the wa y 21:12:38 dguerri 21:12:54 no prob please let me know hot to proceed 21:13:10 how to proceed 21:13:18 cron2 21:13:29 prod dazo 2x/day until he commits it to git andj 21:13:31 ack from my side mattock 21:13:48 nice! I second cron2's suggestion cron2 21:13:59 I think that's all we need - useful feature, two ACKs, now it's "dazo needs to find time" mattock 21:14:05 next topic? andj 21:14:09 sure dguerri 21:14:14 great, thanks 21:14:24 cron2 21:14:24 let's start with first topic, buildbot dguerri 21:14:41 so, i'll be poke dazo next days cron2 21:14:59 dguerri: he said he's quite busy these days, but "next month" should be easier dguerri 21:15:08 ok mattock 21:15:14 what about the Segfault in PF issue? andj 21:15:18 yeah, that being in just a few days cron2 21:15:25 mattock: first things first mattock 21:15:34 from the top you mean? 21:15:42 cron2 21:15:43 mattock: how's your time availability? We should have buildbot connectivity tests back yep 21:15:46 mattock 21:15:55 yep, agreed cron2 21:16:08 ok, next mattock 21:16:29 a realistic estimate for that is maybe 2-3 weeks cron2 21:16:38 as I said I can get sponsored CPU + connectivity for more buildbots, and will use that for FreeBSD 6, 7, 8, OpenBSD, and OpenSolaris testing mattock 21:16:56 cron2: can you handle the buildslave setup and all for those? cron2 21:16:58 $company wants an acknowledgement - ecist suggested to have a "Sponsors" page in the community wiki mattock: if your documentation is up to the task, yes... 21:17:13 mattock 21:17:22 if it is not, it will be cron2 21:17:28 heh, indeed mattock 21:17:39 "Sponsors" page on Trac sounds reasonable and maybe forum "Thank you" post? 21:17:48 SviMik 21:18:18 if anybody have questions about Segfault in PF - I'm here mattock 21:18:27 SviMik: great! cron2 21:18:57 ok, anybody who *objects* to having a Sponsors-page? I don't want to go forward without an OK from you folks mattock 21:18:58 cron2: my honest intention is to get the connectivity tests back at time for first 2.3 alpha cron2 21:19:07 mattock: that would be great andj 21:19:27 I can see why a sponsor of CPU/bandwidth/whatever would want some mention so no problem here 21:19:34 cron2 21:19:34 mattock: (and my intention is to make IPv6-p2mp-tap work for all platforms ) mattock 21:19:36 as well as streamlined Debian/Ubuntu (and perhaps Fedora) packaging cron2 21:19:50 good mattock 21:19:50 jamesyonan: any thoughts? as one of the official company representatives 21:20:02 L'utente raidz si è disconnesso (Remote host closed the connection) 21:20 mattock 21:21:46 if not, I'd say "sponsors" page is fine jamesyonan 21:21:54 which company? L'utente raidz è entrato nella stanza 21:21 cron2 21:22:18 the sponsoring company would be Space.Net, the ISP I'm working for but mattock is talking about openvpn tech 21:22:24 mattock 21:23:00 providing buildslaves for the project jamesyonan 21:23:05 so Space.Net would be donating VMs? cron2 21:23:38 yep I administer them (on spare time), Space.Net donates CPU, public IP addresses, bandwidth 21:24:08 jamesyonan 21:24:21 I'm open to it, but I'd have to discuss it with the others at OpenVPN Tech cron2 21:24:44 please do and let us know mattock 21:25:19 next topic? cron2 21:25:29 pf fault mattock 21:25:44 https://community.openvpn.net/openvpn/wiki/Topics-2011-09-29#Bugs vpnHelper 21:25:45 Title: Topics-2011-09-29 â OpenVPN Community (at community.openvpn.net) SviMik 21:26:21 I hope my bugreport is as detailed as possible ) cron2 21:26:23 I have seen the comment that it's "just a NULL ptr deref", but I haven't seen anyone look into the code yet why that happens mattock 21:26:45 waldner analyzed that earlier... I'll try to find his comments (the "details" link leads to his page) 21:27:05 SviMik 21:27:37 waldner: mattock: #163 seems plausible for me ... There is a NULL pointer being passed into pf_cn_test() ... and when a that should point at a struct and you try to access (*null)->struct_member (pfs->kill in this case) ... an explosion is not unexpected ... just need to figure out if this NULL pointer is valid or not ... to find the proper place to exit the function if the pointer is NULL at entry cron2 21:28:44 yep, that one mattock 21:29:49 SviMik: you were faster than me SviMik 21:29:54 L'utente SviMik si è disconnesso (Disconnected by services) 21:33 L'utente SviMik è entrato nella stanza 21:33 mattock 21:33:45 left everybody speechless? SviMik disconnected... have I missed something? 21:33 mattock 21:34:00 nope cron2 21:34:07 mattock: someone needs to dig into the code now and find answers to waldner SviMik 21:34:11 I hope it's easy to fix? I tried to look at the code, but I see openvpn sources first time, so I got lost there andj 21:34:33 it's not my area either, but I'm poking around a little jamesyonan 21:35:13 is the segfault at the "if (!pfs->kill)" line? cron2 21:35:16 yep jamesyonan 21:35:44 because pfs is NULL? cron2 21:35:49 yep the bug report has a stack trace 21:36:17 L'utente SviMik si è disconnesso (Disconnected by services) 21:39 L'utente SviMik è entrato nella stanza 21:39 SviMik disconnected... again 21:39 jamesyonan 21:40:10 I'm looking at it... SviMik 21:40:42 yes, I found and compiled openvpn-devel version to get stack trace... L'utente SviMik si è disconnesso (Disconnected by services) 21:43 L'utente SviMik è entrato nella stanza 21:43 jamesyonan 21:43:44 it looks like there's an assumption in the code that when struct pf_context is initialized, that if enabled var is true, then pfs must be non-NULL SviMik switched from wifi to LAN hope no more disconnects 21:43 jamesyonan 21:43:58 it looks like that gets violated somehow so the question is under what circumstances could a struct pf_context be initialized with enabled=true but pfs=NULL 21:45:26 SviMik 21:46:32 yes, to get this bug I need to connect two clients with some delay so it happens when one client is connected, but another is in process 21:47:20 [another small compilation bug] I can't compile some versions here: ftp://ftp.secure-computing.net/pub/FreeBSD/ports/openvpn-devel/ 21:49:41 openvpn-201135.tar.gz and earlier versions are OK 21:49:42 openvpn-201136.tar.gz and later - socket.c:786: error: 'SO_MARK' undeclared (first use in this function) 21:49:42 cron2 21:50:22 which version of FreeBSD is that? jamesyonan 21:53:13 so the fix is probably to patch pf.c so that enabled var is never set to true unless pfs var is non-NULL mattock 21:53:53 anybody willing to create that patch for SviMik to test? SviMik 21:54:24 cron2 oops... it's for FreeBSD. I compiled it in centos ok, never mind. cron2 21:54:55 SviMik: well, it's just a snapshot, but I assumed FreeBSD it should compile on Centos as well, but I'm not the one who does Linux portability fixing 21:55:14 mattock 21:55:34 SviMik: you could try latest "master" branch and see if it has the same issue https://community.openvpn.net/openvpn/wiki/DeveloperDocumentation#Maindevelopmentrepositorygit 21:56:19 vpnHelper 21:56:21 Title: DeveloperDocumentation â OpenVPN Community (at community.openvpn.net) andj 21:56:46 It looks like there could be a brief amount of time between setting pf.enabled and pf_check_reload calls would adding an extra check to pf_c2c_test be enough? 21:58:34 or should pf_init_context() call pf_check_reload after enabling pf? 21:59:41 SviMik 22:01:02 if somebody create a patch, I can test it now jamesyonan 22:01:45 yeah, I'm thinking that we should try to fix it by preserving the invariant that the code already expects that's more along the lines of pf_init_context() should call pf_check_reload after enabling pf? 22:02:08 andj 22:02:20 thing is, that invariant just states that pf is enabled if a file goes missing 22:02:26 enabled would still be enabled 22:02:41 enabled would still be _true_ 22:02:53 is better there 22:02:56 but pfs might not be set 22:03:01 jamesyonan 22:03:45 well it's a security question in a sense -- if the firewall is enabled, but there's some exception that leaves control data undefined, how do you then handle packets? andj 22:04:20 exactly, disabling the firewall isn't the solution if a pf file goes missing (e.g. is deleted) 22:04:34 jamesyonan 22:05:00 so maybe in this case you want to drop all packets? andj 22:05:02 so you could say if pfs is NULL drop? if pf.enabled of course 22:05:07 jamesyonan 22:05:22 yeah, that's what I'm thinking cron2 22:05:37 log warning, drop SviMik 22:06:16 why pf file may go missing? as I remember, openvpn shoul create pf file when client connects, and delete it when client disconnects? jamesyonan 22:06:17 I'm wondering if there's other places in the code where enabled==true causes pfs to be used without being tested for non-NULL andj 22:06:49 I just searched for that a minute ago sec 22:06:50 pf_addr_test 22:07:12 but not sure what that does 22:07:17 L'utente krzee si è disconnesso (Ping timeout: 256 seconds) 22:09 jamesyonan 22:09:30 I think pf_addr_test_dowork is testing for IP address conditions and pf_cn_test is testing for common name conditions. If you look at pf_addr_test_dowork, I think it reveals the fix 22:09:46 andj 22:09:58 yeah, just noticed it if (pfs && !pfs->kill) jamesyonan 22:10:11 Note how it starts with if (pfs && !pfs->kill) and then the else rejects the packet by returning false 22:10:22 SviMik 22:11:07 so we can just replace if (!pfs->kill) with if (pfs && !pfs->kill) ? andj 22:11:12 yes jamesyonan 22:11:27 that's what I'm thinking andj 22:11:43 diff --git a/pf.c b/pf.c index 6b4cba4..311495a 100644 22:11:43 --- a/pf.c 22:11:43 +++ b/pf.c 22:11:43 @@ -411,7 +411,7 @@ lookup_cn_rule (struct hash *h, const char *cn, const uint32 22:11:43 bool 22:11:44 pf_cn_test (struct pf_set *pfs, const struct tls_multi *tm, const int type, con 22:11:44 vpnHelper ha espulso andj (Flooding detected. Please use http://pastebin.com for posting logs or configs.) 22:11 jamesyonan 22:11:46 because then if pfs is NULL, we return false L'utente andj è entrato nella stanza 22:11 andj 22:11:58 oops sorry, mispaste 22:12:02 SviMik 22:12:02 andj 22:12:08 I wanted a single line there terribly sorry 22:12:23 that should do the trick though: https://gist.github.com/1251645 22:12:44 vpnHelper 22:12:45 Title: andj's gist: 1251645 Gist (at gist.github.com) L'utente krzee è entrato nella stanza 22:13 jamesyonan 22:13:32 yeah, that looks right andj 22:13:47 there's no else clause, since anything that is correct returns earlier time for a whole bunch of ASSERT_NOT_NULLs 22:15:16 scattered around the code 22:15:21 22:15:22 mattock 22:16:37 so andj's patch is ok? andj 22:17:03 not really my patch, james pointed out the right direction 22:17:09 mattock 22:17:16 well, I guess that's also true regardless, next topic? 22:17:20 SviMik: can you test that patch? 22:17:30 andj 22:17:35 sure, while we wait for feedback from SviMik SviMik 22:17:53 yes, I can try it. I just... need to download-patch-compile-start-test... it will take few minutes mattock 22:18:01 I would propose the two topics from "Other" section first one would be this: http://thread.gmane.org/gmane.network.openvpn.user/32525 22:18:17 vpnHelper 22:18:19 Title: Gmane Loom (at thread.gmane.org) mattock 22:18:50 "The counter Bytes Received,Bytes Sent in status.log, what did they count exactly?" SviMik 22:18:56 and, I need to choose which version to compile, and shoud I use testing or production server ) cron2 calls it a day for today - having a bad cold, go to bed. (I have no good answers for the remaining topics anyway) 22:19 cron2 22:19:37 *sneeze* good night... mattock 22:19:40 cron2: no opinions on the T-shirts? andj 22:19:47 good luck with your cold cron2 22:20:15 mattock: not many opinions on anything right now (but T-Shirts are cool - I think we discussed that already, navy blue or black, wasn't it?) mattock 22:20:27 cron2: I think so try to get better! 22:20:36 scifiCinereller 22:20:36 So, as far as we've seen it in the sourcecode, is it _all_ the data that is sent to the socket after compression/encryption and all the data that is read from the socket before decryeption/decompression? jamesyonan 22:21:02 I believe that Bytes Received,Bytes Sent refers to bytes sent over the tunnel socket mattock 22:21:24 hi scifiCinereller! you just got to "attended the meeting" list L'utente raidz si è disconnesso (Remote host closed the connection) 22:21 scifiCinereller 22:22:12 I just wondered if we are the first ones that come up with this question. If not, does this mean it was already asked frequently enough to get to http://www.openvpn.net/index.php/open-source/faq.html ? vpnHelper 22:22:13 Title: FAQ Community (at www.openvpn.net) L'utente raidz è entrato nella stanza 22:22 mattock 22:23:13 I would guess this is relatively common question L'utente krzee si è disconnesso (Ping timeout: 252 seconds) 22:24 mattock 22:25:00 so, essentially, janjust's analysis is correct: http://thread.gmane.org/gmane.network.openvpn.user/32525/focus=32579 vpnHelper 22:25:01 Title: Gmane Loom (at thread.gmane.org) mattock 22:25:15 if so, we could move on to T-shirts? there are a few questions: a) which model?, b) which color?, c) how many?, d) what sizes? 22:26:39 ...or is there something to add to openvpn-status.log? 22:26:59 scifiCinereller 22:27:16 Nope, I'm fine with the current state mattock 22:27:39 nice! andj 22:27:55 I'm fine with moving on, but haven't got much to say about shirts mattock 22:28:05 andj: even if/when you get one? andj 22:28:32 Let's call that an if, I feel I haven't contributed nearly as much as others mattock 22:29:26 I have a hunch you might be on the list, if I made the choice oh, one important decision... what graphics to use in it? 22:29:42 the logo from here: "http://openvpn.net/"; ? 22:29:53 vpnHelper 22:29:55 Title: Error 404: File not Found (at openvpn.net) mattock 22:30:05 hmm http://openvpn.net/ 22:30:13 vpnHelper 22:30:14 Title: OpenVPN - Open Source VPN (at openvpn.net) mattock 22:30:24 or just the "O" part or something else? 22:30:27 printing only on the front, or also on the back? 22:30:49 andj 22:31:49 I think only on the front, I like the whole word, but that's just my 2c mattock 22:32:07 navy blue / black ok? hmm, the "VPN" part might not be visible enough with navy blue 22:32:30 L'utente krzee è entrato nella stanza 22:32 mattock 22:32:57 I wonder if somebody (e.g. me) should make some simple designs first... andj 22:33:10 perhaps it's a little difficult to visualise 22:33:18 otherwise, and it might start up discussions a little 22:33:28 mattock 22:33:52 ok, let's do that move on to PolarSSL? 22:33:58 if we'd get a few ACKed that'd be great! 22:34:09 (I got to leave myself soonish) 22:34:17 andj 22:34:17 sure, if james is still up for it mattock 22:34:29 jamesyonan: still time for a few PolarSSL patches? jamesyonan 22:34:37 sure andj 22:34:46 warm-up: a bug I found https://github.com/andj/openvpn-ssl-refactoring/commit/86338fd1c7925ca7c84fe697e123dc158289f02b 22:34:47 vpnHelper 22:34:48 Title: Commit 86338fd1c7925ca7c84fe697e123dc158289f02b to andj/openvpn-ssl-refactoring - GitHub (at github.com) andj 22:35:01 nothing harmful, the subject was only used in printing debug messages 22:35:13 slightly embarassing nonetheless 22:35:25 jamesyonan 22:36:34 did it actually compile? andj 22:36:44 yeah, they're both strings mattock 22:37:00 ooshirts.com has a nice T-shirt design webapp... I'll send links when I'm done (tomorrow or early next week) andj 22:37:11 cool, looking forward to them if that one's ok, there's a few patches which I thought had already been acked, but don't have a name next to them 22:38:07 james? 22:40:54 jamesyonan 22:41:36 sure, let's see them andj 22:41:45 https://github.com/andj/openvpn-ssl-refactoring/commit/be63e6e86837cec71b35446a164ab158cd986ab1 vpnHelper 22:41:46 Title: Commit be63e6e86837cec71b35446a164ab158cd986ab1 to andj/openvpn-ssl-refactoring - GitHub (at github.com) andj 22:41:54 These were all done by request as feedback to comments earlier on in the process 22:42:06 and I thought they'd been acked at the time, but can't find the confirmation 22:42:24 SviMik 22:43:43 it seems patch works. at least, I don't see segfault anymore andj 22:43:53 cool, that sounds good are any packets dropped, that you expected to go through? 22:44:05 SviMik 22:44:28 but I see 179 pf files... while I have only 35 clients jamesyonan 22:45:27 ntlm patch looks fine andj 22:45:32 https://github.com/andj/openvpn-ssl-refactoring/commit/84916b43b6d614291ec765d93f615be30d519bbb and https://github.com/andj/openvpn-ssl-refactoring/commit/3f1647d20ff081cefd54ee80cff64c2234f1e48f improve the plugin system to no longer require vpnHelper 22:45:34 Title: Commit 84916b43b6d614291ec765d93f615be30d519bbb to andj/openvpn-ssl-refactoring - GitHub (at github.com) andj 22:45:37 ssl and I'm almost certain those were acked 22:46:16 because the second one is a response to comments on the first one 22:46:30 jamesyonan 22:48:30 looks good scifiCinereller 22:48:34 Fellows, my wife just asked for me. Thanks for your time && good bye. If we have some user-friendly explanations about the traffic amount, I'll post it to the mailing-list. andj 22:48:44 cool, thanks jamesyonan 22:48:51 I also have to run in a few minutes andj 22:48:52 see you soon ok, one more patch and some discussion 22:49:00 https://github.com/andj/openvpn-ssl-refactoring/commit/4970f1485d4d2117ccb3b1932965809fc51d8efe 22:49:02 vpnHelper 22:49:03 Title: Commit 4970f1485d4d2117ccb3b1932965809fc51d8efe to andj/openvpn-ssl-refactoring - GitHub (at github.com) andj 22:49:06 is the PRNG reset patch It resets the nonce periodically 22:49:14 L'utente scifiCinereller si è disconnesso (Quit: Verlassend) 22:49 andj 22:50:06 based on some RNG data from the entropy pool to ensure that the same seed isn't used indefinitly 22:50:27 spelling hard 22:50:33 jamesyonan 22:51:24 that seems reasonable the nonce is only used to generate IVs 22:51:41 andj 22:51:43 using the same value for random for too long scares me a little I know, but I'm paranoid 22:51:49 22:51:53 So this seems like good middle ground 22:52:09 Then there's the question of what to do about https://github.com/andj/openvpn-ssl-refactoring/commit/0ef8d44cc4b9b10f174101cf420af0a5b2150809 22:52:24 vpnHelper 22:52:25 Title: Commit 0ef8d44cc4b9b10f174101cf420af0a5b2150809 to andj/openvpn-ssl-refactoring - GitHub (at github.com) andj 22:52:35 this is a huge patch, adding polarssl I suggest the following: 22:52:42 ack/nack the files that are modified in the normal way, but not the additions 22:53:07 jamesyonan 22:53:24 the argument for IVs being sourced from PRNG is that IV only needs to be unpredictable, not "cryptographically strong" as a key would need to be mattock 22:53:58 andj: agreed it's impossible to know what might lurk in the added (polarssl) code without testing 22:54:29 andj 22:54:45 jamesyonan: true, but putting all your faith in the unpredictablity of a hash function is going a tad far as well this just adds an extra layer 22:55:10 about PolarSSL: the additions can then be checked at a slower pace 22:55:22 I've tested them extensively 22:55:32 but I think for the moment it's best to include them, and let people use it "at their own risk" 22:55:57 and, as discussed let OpenSSL be the default 22:56:13 jamesyonan 22:56:14 agreed -- but remember that even TLS 1.0 and all of the earlier SSLs uses compl etely predictable IVs (which has gotten them into trouble) 22:56:30 andj 22:57:21 yeah, clever way of getting that bug exploitable jamesyonan 22:57:33 you mean BEAST? SviMik 22:57:34 andj is it possible that I get packet drop while reloading pf file? andj 22:57:46 could be, not entirely sure why, are you? 22:57:51 SviMik 22:58:17 when I edit pf file, one ping packet gets lost mattock 22:58:19 I got to split now, feel free to continue https://community.openvpn.net/openvpn/wiki/PolarSSLintegration is updated 22:58:27 vpnHelper 22:58:30 Title: PolarSSLintegration â OpenVPN Community (at community.openvpn.net) jamesyonan 22:58:31 I gotta run too andj 22:58:35 just before you go, ack on my suggestion for the big patch? thanks everyone, hopefully means we can start moving towards getting the last set of patches acked next week 23:00:06 jamesyonan 23:00:18 andj: have we already covered all of the patches that modify existing files? andj 23:00:20 SviMik: oops 23:00:24 mattock 23:00:24 andj: sounds like a plan! see you guys later! 23:00:30 andj 23:00:34 jamesyonan: there's a few left mostly related to PolarSSL though 23:00:53 this kind of stuff: https://github.com/andj/openvpn-ssl-refactoring/commit/5f5eca00f31199571450cceee1f4469154bd4d38 23:01:03 vpnHelper 23:01:04 Title: Commit 5f5eca00f31199571450cceee1f4469154bd4d38 to andj/openvpn-ssl-refactoring - GitHub (at github.com) andj 23:01:06 see you SviMik: it could be 23:01:13 jamesyonan 23:01:45 yes, I'm open to the idea of handling the pure PolarSSL-added files differently andj 23:01:46 It depends how atomic the replacement of a file is thanks, sounds good 23:01:58 we'll get to that next week 23:02:09 jamesyonan 23:02:20 sounds good, take care andj 23:02:26 cya
