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 22nd Aug 2013 Time: 18:00 UTC Planned meeting topics for this meeting were on this page: <https://community.openvpn.net/openvpn/wiki/Topics-2013-08-22> 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, ngharo, pekster and waldner participated in this meeting. -- Discussed "Issues with supplying username/password/response via file/stdin/management interface" described here: <https://community.openvpn.net/openvpn/wiki/Topics-2013-08-22> After a lengthy discussion decided to break this into 3-phase wishlist (courtesy of pekster): 1) Support username-only in a --auth-user-pass file, and all the backend code changes this requires. This patch can live on its own. 2) Support inlining the --auth-user-pass file so it doesn't need to be external. 3) Add support for the MI to handle either the user or both user+pass from an external file, and still prompt for the c/r. Waldner will do more testing to fully understand all the code paths and option combinations, after which we can finalize the above plan. -- Discussed adding snappy support to openvpn-build and thus the Windows executables. The problem is that libsnappy pulls in libstdc++ with it, which weighs 8MB, whereas current installers are only ~1.7MB in size. Jamesyonan proposed using LZ4 compressor instead, because it's nearly as fast as snappy, is gaining momentum and does not pull in tons of dependencies. Jamesyonan agreed to implement LZ4 for 2.4 at some point, but it will probably take some months. -- Discussed the "[PATCH 1/2] Allow use of NetBeans without saving nbproject/ directory" patch: <http://news.gmane.org/find-root.php?message_id=%3ccanfrfr0gew0kjt2xpfu6zgmhkpwoqah_pu2hdrod0fdrktz...@mail.gmail.com%3E> Mattock gave this patch an ACK. It was merged during the meeting. -- Discussed the "[PATCH 2/2] When using UDP over SOCKS5, send the actual remote hostname (FQDN) to the proxy server in the first packet" patch: <http://news.gmane.org/find-root.php?message_id=%3ccanfrfr0zuki5mf0vafxpvnrtrsyyfx3etpgpbznjsclbnqz...@mail.gmail.com%3E> The rationale behind this patch is a bit unclear. Decided to ask the author for clarifications on openvpn-devel mailing list. -- Discussed "configure script fails with static openssl libraries" issue: <https://community.openvpn.net/openvpn/ticket/305> Agreed to discuss this on openvpn-devel. -- Full chatlog as an attachment -- Samuli Seppänen Community Manager OpenVPN Technologies, Inc irc freenode net: mattock
(20.53.21) ngharo: o/ (20.57.41) mattock: nice (21.00.45) cron2: o/ (21.00.53) waldner: \o (21.00.59) waldner: (I'm left-handed) (21.01.10) mattock: hi (21.01.18) mattock: shall we start? (21.01.21) jamesyonan [~jamesyona@24.9.78.222] è entrato nella stanza. (21.01.21) modalità (+o jamesyonan) da ChanServ (21.01.34) mattock: https://community.openvpn.net/openvpn/wiki/Topics-2013-08-22 (21.01.35) vpnHelper: Title: Topics-2013-08-22 – OpenVPN Community (at community.openvpn.net) (21.02.07) mattock: so cron2, ngharo, waldner, mattock and jamesyonan already (21.02.11) mattock: good attendance (21.02.41) mattock: first we have a fairly hairy topic, based on pekster's and waldner's earlier discussion: (21.02.41) mattock: "Issues with supplying username/password/response via file/stdin/management interface" (21.02.57) ***pekster is still hiding in the shadows too (21.03.04) mattock: hi pekster! (21.03.13) mattock: krzee promised to be present, too (21.03.36) mattock: waldner: is there something you'd like to add to the very problem brief description in the wiki? (21.04.00) waldner: well, I'll give a short background (21.04.20) waldner: just so everyone can see what we're talking about (21.04.31) waldner: here: http://article.gmane.org/gmane.network.openvpn.devel/7776 (21.04.33) vpnHelper: Title: Gmane -- PATCH Support for username only auth file. (at article.gmane.org) (21.04.53) waldner: that was the (still outstanding) patch that prompted me to do this (21.05.15) waldner: I said, that's great, however I'd like to put the username in the config directly, rather than create a file (21.05.37) waldner: so after some discussion, it was agreed that inlining auth-user-pass would be the way to go (21.05.44) waldner: which seems excellent to me (21.05.58) waldner: so this explains the first two points (21.06.19) waldner: inlining the file, and the possibility to only specifiy a username, rather than both username/pass (21.06.29) waldner: so far so good (21.06.46) waldner: so I started looking at the code and doing tests, to understand how it works currently (21.07.05) waldner: the main function is get_user_pass_cr, misc.c (21.07.44) waldner: doing various tests, I see that function is invoked from many different places (some of which are not a strictly username/password dialog) (21.08.14) waldner: in particular, it is involved in challenge/response (21.08.23) waldner: so when c/r is used, it prompts for username, password, and response to the challenge (statis or dynamic) (21.08.39) waldner: it can prompt on stdin or via the management interface (21.09.07) waldner: now trying a few combination of options to understand how all the code paths work, I came across a few issues (21.09.43) waldner: the main one is that one can in principle use both "auth-user-pass file.txt" *and* "static-challenge sometext" (21.10.06) waldner: when one does that, username and password are read from the file, but the user is not prompted for the challenge at all (21.10.41) waldner: now I agree that this combination of options doesn't make much sense from a security standpoint, but if we allow it it should work, otherwise it should be forbidden (21.10.58) waldner: thoughts? (21.11.05) mattock: jamesyonan: is the above behavior intentional, or accidental? (21.11.29) mattock: I think forbidding it makes most sense (21.12.17) ngharo: walder, curious if you've been in contact with the original patch author? (21.12.30) pekster: The one edge-case I see where it's possibly useful to do both is if we allow --auth-user-pass (inline or not) to supply the username only, then prompt for the pass plus the challenge response (21.12.45) waldner: ngharo: no (not yet, better) (21.12.48) cron2: pekster: this sounds like a useful case for me (21.12.50) pekster: As I understand the issue, this won't work as it stands today, right? (21.12.53) mattock: yep, in that context it makes sense (21.13.33) waldner: correct, as it stands today it doesn't work (21.14.00) jamesyonan: yes, there's no support right now for challenge/response + user/pw file (21.14.30) waldner: so better to bail out if one does that, and if/when support is added lift the restriction? (21.14.50) mattock: does that = use both config option at the same time (21.15.18) mattock: bail out at startup? (21.15.27) waldner: what's "="? (21.15.28) pekster: Right, rather than silently failing when the c/r is never sent (21.15.54) waldner: yes, just where many other checks are done, it would just be one more (21.16.11) waldner: there are already many combinations that are incompatible and openvpn terminates (21.16.31) mattock: so this would allow username-only password file/inline section (21.16.40) mattock: but if c/r is added, then it bails out (21.16.47) waldner: yes (21.16.51) mattock: makes sense (21.16.59) pekster: That's actually an independent issue; as the code stands _today_ it's broken with external --auth-user-pass and c/r used together (21.17.37) waldner: yes, but we can detect that combination and abort (21.17.55) mattock: pekster: but it breaks silently, without a clear error message (21.17.57) mattock: afaik (21.18.04) pekster: And this may be by design ( jamesyonan may have details, or AS usecases,) but I agree it shouldn't silently fail (21.18.16) waldner: doesn't even "break", the user just sees they can't authenticate (21.18.41) mattock: jamesyonan: is there a use-case for not bailing out when --auth-user-pass and c/r are used together? (21.18.49) mattock: currently it just gives "auth failed" (21.19.20) waldner: (probably an attentive user would notice that thay're not prompted for the c/r) (21.19.29) jamesyonan: how hard would it be to just modify c/r code to use user/pw file when available? (21.19.51) waldner: jamesyonan: when the user is prompted on stdin, not too much (21.19.56) jamesyonan: and only prompt for c/r (21.20.04) waldner: however, when the prompt comes in the management, it's more complex (21.20.32) waldner: because in the management interface one is supposed to send a string that contains username and responses encoded together (21.21.02) jamesyonan: I would tend to think that if people are authenticating through management interface, that they wouldn't be using a static user/pw file (21.21.15) waldner: so it would have to be the application that drives the management interface that would need to be smarter (21.21.30) waldner: yes, that's what one option is banning it altogether (21.21.33) waldner: *why (21.22.20) waldner: (sorry, above I meant "password and response encoded together") (21.22.28) pekster: jamesyonan: That was my thought too, so the "frontned" (the app driving the user experiencing) should be the one in this case to read from an external file in this case, if it so chooses (21.23.06) pekster: The alternative here when using c/r over the management interface is make that codepath more complicated by handling inputs with user+pass+c/r, or just permutations, then format the reply to send to the server (21.23.47) waldner: it would probably need a new type of prompt to present to the management interface (21.23.56) pekster: That feels messy to me, and if there's a frontend app that's supposed to be managing the user experience, I'm wondering why it wouldn't do it all in that widget (21.24.01) jamesyonan: how about just don't ask the MI for user/pw when already available in file? (21.24.09) waldner: ie, it would become similar to how the user is prompted on stdin (21.24.52) waldner: jamesyonan: yes, that happens already, however the response should still be prompted (21.25.05) waldner: (the resposne to the challenge) (21.25.11) pekster: So, the proposal is just ask for the needed details and format the reply internal to the code? That might actually make things easier instead of expecting the input on the management interface to be this combination of it all (21.26.16) pekster: For reference, the management-notes.txt says the dynamic c/r is to be formatted: password "Auth" "SCRV1:<BASE64_PASSWORD>:<BASE64_RESPONSE>" (21.26.59) waldner: yes, like password "Auth" "SCRV1:Zm9v:ODY3NTMwOQ==" (21.27.11) pekster: Can we just have the client-side here enter in a normal sequence of pass (if it wasn't supplied in the --auth-user-pass file) and then the c/r as different parts? (21.27.32) waldner: except if the password is read from a file and the user isn't prompted, the management interface has no way to know the password (21.27.37) pekster: Nevermind the SCRV1 part, what if it just takes the input and expects the code to deal with how to format the reply? (21.28.06) waldner: pekster: that's one option, however it requires changing the MI prompts (21.28.13) waldner: (likely) (21.28.32) jamesyonan: well I think the issue here is that the MI expects clients to be able to generate the special packed pw/resp string, while when operating off of stdin, it does the packing itself (21.28.46) waldner: jamesyonan: correct (21.28.58) pekster: Right; is there a way to unify both of these input methods perhaps? (21.29.44) jamesyonan: this was a way to add c/r support without breaking MI compatibility (21.30.46) waldner: so if we introduce a new prompt type, we'd also need to take care that the current way of prompting keeps working (21.31.36) mattock: is there anything preventing adding a new prompt and keeping the old one for compatibility? (21.31.53) waldner: ie, support both "PASSWORD:Need 'Auth' username/password SC:1,Please enter token PIN" (current) and a new, separate prompt to only prompt for the response (21.32.34) pekster: Perhaps adding a `'PASSWORD:Need 'Challenge-Response' password` inquiry across the management interface? (21.32.44) waldner: if we detect that user/pw come from a file we prompt for user/pw only using the standard MI prompt, and then prompt separately for the response (21.32.50) pekster: Then a `challenge-response "Auth" "the response here"` format? (21.32.51) waldner: yes (21.33.01) waldner: that's a new prompt, as said (21.33.05) jamesyonan: I'm okay with that as long as it doesn't break existing clients (21.33.16) pekster: This way the existing behaviour keeps working for SCRV1 query/reply (21.33.27) mattock: and in the long run this new approach would replace the old one? (21.33.28) waldner: it shouldn't, as long as they don't start using user+pw from file (21.33.44) mattock: not just augment it (21.33.59) pekster: mattock: I think it would work as an adjunct to the old method (21.34.12) mattock: ok (21.34.29) pekster: Unless we want to set a target date to deprecate the current feature, and break all frontends relying on it (21.34.38) waldner: I think that's not doable (21.34.39) cron2: we can't do that (21.34.41) pekster: (sounds like it'll break as-yet-unknown things) (21.35.24) pekster: Yea, so I like thte idea of adding a new query method in this case, and implementations using it are expected to know how to speak that method or it'll fail (which it does today anyway, so no loss) (21.35.30) mattock: interesting how this all started from "allow username-only auth-user-pass file" (21.35.52) pekster: Yes... :) (21.36.06) waldner: well, in fact this is how it is *now*, even before trying to do anything (21.36.54) waldner: and since adding the features initially mentioned will necessarily have to pass through that code, it has to be cleared up upfront (21.37.06) jamesyonan: this still needs proof-of-concept testing to ensure that it doesn't break existing clients (21.37.26) mattock: so, if I understood this correctly, we should make openvpn bail out at startup if --auth-user-pass and c/r are used together (21.37.27) pekster: With the advantage that this use-case will actually work. If the username only is supplied externally (which includes "inline") it just uses the existing SCRV1 method. If user+pass are supplied, the fronttend management (or stdin) client needs to use this new response mechanism. Anyone see issues with that solution? (21.38.03) mattock: then we add support for inline auth-user-pass (21.38.08) waldner: well I'd do this: for the time being, and to not break compatibility, we just bail if one uses user/pw from file and static challenge (21.38.18) jamesyonan: for example, what if a client that already understands SCRV1 usage chokes when a new auth field is prompted for by MI and it doesn't recognize it (21.38.42) jamesyonan: and what about dynamic challenge/response mode? (21.39.00) waldner: jamesyonan: that'd require that openvpn knew the capabilities of the application driving the MI (21.39.06) pekster: But it would never choke like that unless the config asked it to use c/r with an external auth file, right? (21.39.08) waldner: jamesyonan: yes, what about it (21.39.31) jamesyonan: will proposed solution work with both static and dynamic c/r? (21.39.45) waldner: jamesyonan: I wasn't able to test dynamic c/r (21.39.50) waldner: does it require an AS server? (21.40.29) waldner: or if not, how do I enable it? (21.41.10) pekster: Ah, so the tricky part here is what does this mean from management-notes.txt: "The OpenVPN dynamic challenge/response protocol works by returning a specially formatted error message after initial successful authentication. This error message contains the challenge question..." (21.41.14) jamesyonan: the docs should explain it (21.41.17) jamesyonan: no AS is required (21.41.21) waldner: (I had it planned to bring this up anyway) (21.41.33) waldner: the docs say the server sends a special error message to the client, which prompts the client's MI to prompt for the response (21.41.46) waldner: I even see the code where it does that (21.41.59) waldner: but for the love of me I'm not able to trigger that response from the server (21.42.43) waldner: otherwise I'd have tested it already to have a more complete picture (21.43.21) waldner: if someone knows how to do it, I'm all ears (21.43.35) jamesyonan: if you don't use AS, the server would need to be driven from the MI and understand how to deliver the special AUTH_FAILED that tells the client to do a dynamic challenge (21.43.54) waldner: right, so which message is that? is it in the docs? (21.44.02) waldner: which MI command is it? (21.44.32) waldner: (the docs I have are http://openvpn.net/index.php/open-source/documentation/miscellaneous/79-management-interface.html) (21.44.34) vpnHelper: Title: Management Interface (at openvpn.net) (21.46.03) waldner: (I've tried with "echo" with no luck) (21.46.18) pekster: Ah, now I think I see it waldner, look at the `COMMAND -- client-deny` section (21.46.37) pekster: It needs to format a special AUTH_FAILED reply as documented in the dynamic challenge response section (21.46.50) pekster: Think of it as "extra text after the AUTH_FAIL part (21.47.17) waldner: pekster: right, it may well be that (21.47.22) jamesyonan: yes, that sounds right (21.47.29) pekster: client-deny {CID} {KID} "reason-text" ["client-reason-text"] <<-- that bit (21.47.39) waldner: I had not associated it with the later paragraph about dymanic challenge (21.47.51) pekster: So, that's the test-case for dynamic auth. And it sounds like this is all fine "as long as current behaviour is maintained" (21.47.59) waldner: right (21.48.05) pekster: waldner: I hadn't either until just now :) (21.48.14) jamesyonan: right, you fail the auth with a CRV1:<flags>:<state_id>:<username_base64>:<challenge_text> string (21.48.26) waldner: yes, makes sense now (21.48.49) ngharo: would it make sense to get the username-only support in now since that is fairly trivial and deal with the c/r and MI issues after, rather than all in one? (21.49.31) pekster: Yes, I'd like to see these treated as independent issues (21.49.37) waldner: ngharo: it isn't as easy as it sounds (21.49.49) pekster: Especially if we end up eventually doing both, the patches will be easier to see what they do, I think (21.49.56) waldner: it certainly can be done regardless of what we've been discussing so far (21.50.28) waldner: however that require changes the very code that also does c/r and prompts for user/pass (21.50.33) pekster: Let me put it this way: adding support for username-only doesn't break anything except user+c/r, and that's already not working today (21.50.47) waldner: and the various ifs and flags that determine what and where to prompt (21.51.56) waldner: pekster: yes, it shouldn't break anything since the MI does not change (21.52.21) mattock: I think it makes sense to implement the username-only stuff first (21.52.40) mattock: and make openvpn bail out if auth-user-pass is used with c/r (21.52.50) pekster: So, how about breaking this into a "3-phase wishlist." 1) support username-only in a --auth-user-pass file, and all the backend code changes this requires. This patch can live on its own. Phase 2) support inlining the --auth-user-pass file so it doesn't need to be external. Phase 3) Add support for the MI to handle either the user or both user+pass from an external file, and still prompt for the c/r (21.52.57) waldner: I propose then I'd do more testing including dynamic challenge and I'll come up with a better/more definitive plan that we can discuss again in a future meeting (21.53.07) waldner: yes, along those lines (21.53.37) waldner: also because we've spent a lot of time on this already and there were other topics for the meeting (21.53.55) pekster: Sounds like we've made some progress anyway, and opened up new lines of testing for you. This feels good (21.54.00) waldner: agreed (21.54.12) ngharo: ^5 (21.54.32) pekster: jamesyonan, thanks for the insight into how the server-initiated challenge works, that helped open the door :) (21.54.38) mattock: waldner: so you'll do more thorough testing now, or after phase 3) as proposed by pekster? (21.55.02) waldner: I'll do more testing to fully understand all the code paths and option combinations (21.55.17) mattock: ok, I'll mention our initial plan in the summary (21.55.18) mattock: next topic (21.55.23) waldner: then I'll come up with a plan, which will likely be as pekster said (21.55.33) mattock: actually, I think we could review some of the patches in the patch queue (21.55.37) waldner: or a small variation thereof (21.55.50) mattock: pekster and me could discuss openvpn-build some other day on this channel (21.55.59) mattock: others are probably not _that_ interested in it :P (21.56.08) waldner: thanks everyone for the comments and ideas (21.56.14) ngharo: I'm working on replying to all open, unreplied GitHub tickets to not discourage potential contributors on GitHub. So I will be replying to the pull request (https://github.com/OpenVPN/openvpn/pull/5) with some information discussed here (21.56.14) mattock: except maybe the snappy support? (21.56.15) vpnHelper: Title: Support for username-only auth file. by mludvig · Pull Request #5 · OpenVPN/openvpn · GitHub (at github.com) (21.56.16) pekster: Yes, I'd rather see pending patches discussed first anyway (21.56.18) cron2: the first patch on the Patches page has already been ACKed by dazo and pushed :) (21.56.37) mattock: cron2: I'll move it to the correct page (21.56.50) mattock: what about Jesse Glick's patches (21.56.53) mattock: he was asking about those (21.56.55) cron2: jamesyonan: do you have built a windows client with snappy support? (21.57.16) cron2: mattock: you brought up snappy, let's stick to that topic for a moment :-) (21.57.18) jamesyonan: cron2: no, haven't attempted that yet (21.57.26) mattock: ok, snappy (21.57.45) mattock: so the issue with snappy support is that it pulls with it libstdc++, which is 8MB (21.57.58) mattock: and OpenVPN windows installers are ~1.7MB currently (21.58.01) mattock: so it's huge (21.58.01) waldner: I'd put the existing username-only from file patch on hold until I've done more testing, not because I want to dismiss it but because I want to see if it can be used as starting point for the bigger changes we're planning (it may very well be) (21.58.08) cron2: ok... well, mattock has it working, but it requires libstdc++.dll, which is 8mb... so that's the currently open issue... find compile options (on the cross-build) that achieve "--static-libstdc++" (21.58.35) cron2: so I was curious whether it builds nicely with MSVC :) (21.58.44) mattock: ngharo: check waldner's comment ^^^ (21.59.06) cron2: pekster: how are you building windows binaries? --disable-snappy? (21.59.11) mattock: I did some work to get it to statically compile, but haven't really succeeded yet (21.59.21) mattock: this is actually related to openvpn-build not being able to resume builds (21.59.39) mattock: because doing this kind of openvpn-build development is fairly painful if you have to reinitiate the build every time (21.59.47) mattock: and it takes ~20 mins on my VM (21.59.48) cron2: who is openvpn-build maintainer these days? mattock? (21.59.50) mattock: me (21.59.52) pekster: cron2, I'm not building git master; my windows builds are 2.3.2 mainline, and I add in individual patches now. Maybe mattock has more info on mater builds (22.00.05) mattock: I usually build 2.3.x too (22.00.08) jamesyonan: cron2: wondering if we should look at LZ4 as a third compressor option (22.00.09) mattock: haven't built master recently (22.00.16) cron2: pekster: ic. 2.3.2 has no snappy support, so you don't run into that (22.00.23) pekster: Exactly (22.00.45) jamesyonan: it's almost as fast as Snappy but is extremely small and without dependencies (22.00.46) cron2: jamesyonan: what would be the benefit? I haven't heard about LZ4 before, and have no real idea about pro/cons of the various algorithms and implementations (22.00.54) cron2: ah (22.01.08) pekster: I haven't looked at how ./build works, but I think it should be easy enough to make it just rebuild openvpn and not the deps, with a way to override this if needed (22.01.26) mattock: does someone actually _need_ openvpn windows binaries with snappy support? (22.01.35) cron2: if LZ4 can be done without fighting libstdc++, that would be nice (22.01.40) mattock: I mean, if someone really does, can't we just offload the work to him/her? (22.01.49) mattock: why bother ourselves (22.02.05) mattock: I don't recall anyone asking for snappy support in the windows binaries (22.02.14) cron2: AS would need to be taught to handle yet another option, while 2.4/master still has no idea about compression negotiation, so we won't lose much (22.02.15) pekster: +1. This is what we do today with enable_x509_alt_username=no (22.03.17) pekster: If there's a "less intrusive" in terms of required library support available for compression, that sounds much preferred for Windows where stdlibc++ isn't generally availalbe system-wide (22.03.43) mattock: jamesyonan: do you have plans to implement LZ4 anyways? (22.03.45) cron2: jamesyonan: so what would be the plan for ios/android? keep snappy there, or drop snappy and move to lz4? (22.04.02) jamesyonan: cron2: LZ4 seems to be getting a lot of momentum, i.e. it's in linux kernel now and used for dynamic filesystem compression (22.04.46) jamesyonan: OpenVPN 3 actually supports LZ4 right now in the code, but the support isn't compiled in atm for Android/iOS clients (22.07.48) cron2: with the new compression framework, it shouldn't be very hard to add - and then we have a fast compressor (LZ4) and a "compatible" one (LZO), and could just leave off snappy on memory- or library-constraint systems (embedded clients, windows, ...) (22.08.06) mattock: who would implement LZ4 support in Git master? (22.08.08) cron2: sounds good to me, though I have no time right now to do the actual coding (22.08.18) ***cron2 points at jamesyonan (22.08.24) mattock: I would tend to do the same :P (22.08.37) mattock: I think I saw jamesyonan o/ :D (22.08.47) cron2: (two busy weeks coming, then two weeks of vacation with lousy Internet, *then* work on the backlog) (22.09.16) cron2: but I'm happy to test and review the result, as I feel comfortable around the compression layer now :) (22.10.34) mattock: next topic? (22.10.48) cron2: lol, you *could* actually wait for James to agree :-) (22.10.59) mattock: that could take a while, if he doesn't want to :) (22.11.29) mattock: jamesyonan: would you be willing to implement LZ4 support in 2.3/2.4 in the near future? (22.11.39) cron2: ok... patches from Jesse. The first one looks harmless enough, but I have no idea what NetBeans is... (22.11.48) mattock: it's like Eclipse (22.11.49) cron2: mattock: 2.4, not 2.3 - 2.3 does not have the compression layer infrastructure (22.11.53) mattock: ah yes (22.11.56) mattock: 2.4 (22.12.03) cron2: so 2.3 is "lzo only" (22.12.05) mattock: you can write and build software with it (22.12.51) jamesyonan: now that we already have compression negotiation, adding LZ4 shouldn't be too difficult (22.13.09) mattock: does that count as a "yes, I can do it"? (22.13.28) jamesyonan: I can certainly do it, but the question is the timeframe (22.13.41) jamesyonan: it would be months before I could get to it (22.13.46) mattock: I don't think we're in a particular hurry (22.13.55) mattock: nobody has requested snappy or lz4 afaik (22.14.03) mattock: in the windows installers or in openvpn itself (22.14.41) mattock: I can give Jesse's first patch an ACK (22.14.45) mattock: the .gitignore one (22.14.53) cron2: mattock: ok, noted (22.14.58) mattock: next one (22.15.11) mattock: "When using UDP over SOCKS5, send the actual remote hostname (FQDN) to the proxy server in the first packet." (22.15.21) cron2: the snappy/lz4 timeframe would be relevant for the openvpn connect windows client - so that's James' timeframe anyway :) (22.15.25) mattock: http://thread.gmane.org/gmane.network.openvpn.devel/7795 (22.15.27) vpnHelper: Title: Gmane Loom (at thread.gmane.org) (22.15.28) pekster: I haven't really looked into the 2nd patch, UDP over SOCKS5, but I don't really understand the usecase, and the fact that it doesn't work with IPv6 is probably an issue now that 2.3 can do IPv6 (22.16.16) cron2: yeah, similar sentiments here - I have no idea *why* he's doing what he's doing, so no feature-ACK from me -> needs more discussion (22.16.22) pekster: Specifically, I'm not sure how this is a benefit: "so that many hostnames can map (22.16.26) pekster: to the same IP of the reverse proxy (22.17.04) cron2: ask for specific use cases, and why it would then not break if the IP address is put into later packets (22.17.14) pekster: Yes, that bit confused me too (22.17.26) cron2: (and maybe we'll have to rewrite SOCKs anyway when plaisthos' dual-stack patches show up) (22.18.38) mattock: can you guys ask for clarifications from Jasse? (22.18.40) mattock: Jesse (22.19.20) mattock: or is it all-out NACK based on current information? (22.19.36) cron2: it's a "convince me that it's useful, then I'll look at the code" (22.20.06) mattock: ok, care to ask Jesse to convince you? (22.20.09) cron2: which is better than "go away, this code is bad and it makes no sense" :-) (22.20.25) mattock: agreed :) (22.20.28) cron2: pekster: can you do that? (22.20.33) pekster: Right, I "sort of" understand the feature, but not the implementation details or the rationale (22.20.43) pekster: Sure, I can draft up a reply to that within a day or two (22.20.51) cron2: thanks (22.21.06) mattock: thanks! (22.21.19) pekster: I'm not too skilled with some of the code bits, but I don't think that's required here since we need a more high-level reasoning/explanation (22.21.23) mattock: shall we try one or two patches? (22.21.44) cron2: pekster: exactly. I'll do the staring-at-the-code then (22.22.49) cron2: mattock: I'm not qualified to comment on the AEAD stuff - that would be James, or andj/syzzer (who are hiding)... (22.23.22) cron2: Arne's 2013-04-20 patch is in my "understand the code, agree with Arne" queue (22.24.01) mattock: ok, then we're more or less done, except for the bug queue (22.24.07) mattock: which grows slowly but steadily (22.24.11) pekster: The AEAD mode lists AES-GCM as an example, but don't we support that specific mode now with TLSv1.2 patch? (22.24.22) cron2: well, there's the "UI version" patch... and maybe James can comment on the AEAD one (22.24.37) mattock: (updated the patches page) (22.24.48) pekster: Some of the bugs are OpenVPN Connected related (eg: #314) (22.24.58) pekster: Should those be forwarded to someone@corp and then closed out with a reference there? (22.25.32) mattock: I personally think it's fine if they're in Trac (22.25.45) mattock: I've been pointing the right people to them (22.25.56) cron2: are they being handled? (22.26.01) mattock: not sure (22.26.02) pekster: Ah, okay. How about a unique component for them though, so we can filter by that? (22.26.04) mattock: and there is one problem (22.26.08) mattock: yes, that one (22.26.13) mattock: we'd need unique components for them (22.26.24) cron2: so let's add them :) (22.26.24) mattock: I think I'll ask about this on our internal email list (22.26.31) cron2: +1 (22.26.37) pekster: ie: the corp folks can filter by "corp feature a OR corp feature B", and I'm willing to set taht up and triage if we go that route; just let me know (22.26.50) mattock: then we can decide whether to forward these reporters somewhere else, or let the company people handle them in Trac (22.26.53) pekster: It'll both help the corp side out, and let the GPL hackers filter them out (22.26.58) mattock: yeah (22.27.33) mattock: taking a quick look at the "bugs since June 1st" list: https://community.openvpn.net/openvpn/query?status=accepted&status=assigned&status=new&status=reopened&time=06%2F01%2F13..08%2F22%2F13&col=id&col=summary&col=status&col=type&col=priority&col=milestone&col=component&order=priority (22.27.34) vpnHelper: Title: Custom Query – OpenVPN Community (at community.openvpn.net) (22.28.22) mattock: this one is fixed, right: https://community.openvpn.net/openvpn/ticket/320 (22.28.24) vpnHelper: Title: #320 ("Add a new TAP-Windows virtual ethernet adapter" doesn't exist anymore) – OpenVPN Community (at community.openvpn.net) (22.28.42) pekster: Yes, as of today that patch is merged into master (22.28.47) mattock: ok, I'll close it (22.29.35) mattock: this is actually more like a patch: https://community.openvpn.net/openvpn/ticket/305 (22.29.36) vpnHelper: Title: #305 (configure script fails with static openssl libraries) – OpenVPN Community (at community.openvpn.net) (22.30.28) mattock: any comments on that one? (22.30.52) mattock: are there any side-effects in doing what the bug reporter suggests? (22.30.56) cron2: no idea (22.31.28) cron2: we should bring it to openvpn-devel, as there's a few people with good autoconf knowledge there (22.31.32) mattock: yep, let's do that (22.31.54) mattock: it's getting pretty late here... shall we call it a day? (22.32.27) cron2: I'd actually like to hear James' opinion on the OPENVPN_GUI_VERSION thing (22.32.37) cron2: jamesyonan: this is http://thread.gmane.org/gmane.network.openvpn.devel/7636/focus=7646 (22.32.38) mattock: if we try to have weekly meetings we should be able to clear the bug and patch backlogs easily (22.32.38) vpnHelper: Title: Gmane Loom (at thread.gmane.org) (22.32.54) mattock: ah, interesting (22.33.03) cron2: if someone actually acks things instead of deferring... :-) (22.33.12) mattock: yep (22.34.07) cron2: jamesyonan: for Android, and maybe for Windows as well, it would be useful to see the GUI version in the server logs, using push-peer-info. We're not exactly sure how to do this "nicely" - so this proposed implementation has a special "IV_" string which can the gui set using "--setenv IV_OPENVPN_GUI_VERSION whatever" (22.34.27) cron2: this works and is safe enough, but maybe you have other ideas how "it should look like" (22.35.27) vpnHelper: RSS Update - testtrac: Allow use of NetBeans without saving nbproject/ directory. <https://github.com/OpenVPN/openvpn/commit/550fe1a3a12ad9affbdff6ab1fc3e846f5e8d0b5> (22.39.08) mattock: jamesyonan: ^^^ (22.39.13) mattock: any comments? (22.40.02) waldner: gtg now, thanks everyone and have a good $part_of_day_in_your_timezone (22.40.16) mattock: waldner: thanks to you too! (22.40.21) mattock: and see you later (22.40.32) waldner: :) bye (22.40.38) mattock: I think I'll split too, unless jamesyonan appear fairly soon :P (22.41.08) jamesyonan: hi, I'm here… NetBeans patch looks fine (22.41.32) mattock: that's merged already (22.41.41) mattock: can you have a look at cron2's question right above (22.42.09) ender^ ha abbandonato la stanza (quit: Remote host closed the connection). (22.42.29) ender| [~ender1@2a01:260:4094:1:42:42:42:42] è entrato nella stanza. (22.46.23) jamesyonan: cron2: agreed that GUI version logging is a good idea (22.47.53) ngharo: How about this, more verbose TLS logging: https://github.com/kdienes/openvpn/commit/c9e78375e13c47c7c279b1f31e853dfe2bcc6d6a (22.47.54) vpnHelper: Title: tls_ctx_load_ca: Improve certificate error messages · c9e7837 · kdienes/openvpn · GitHub (at github.com) (22.48.03) ngharo: i dont think this one made it to the mailing list or other channels (22.49.45) mattock: ngharo: that's probably true (22.50.23) cron2: ngharo: can you send it to openvpn-devel@ please? (22.50.29) ngharo: will do (22.50.37) mattock: thanks! (22.52.09) mattock: jamesyonan: I take it the suggested implementation also makes sense?
