Here's the summary of the IRC meeting.


Place: #openvpn-meeting on irc.freenode.net
Date: Wednesday 17th Jan 2018
Time: 11:30 CET (10:30 UTC)

Planned meeting topics for this meeting were here:


The next meeting has not been scheduled yet.

Your local meeting time is easy to check from services such as



cron2, dazo, mattock, ordex, plaisthos and syzzer participated in this


Discussed the option of having Buildbot build "release/2.4" branch in
addition to "master". Agreed that it makes sense. Mattock will make it


Discussed the OpenVPN 2.4.5 release. Most of the improvements will be
related to Windows:

- OpenSSL 1.1.0
- Update easy-rsa-old
- Updated openvpn-gui
- PKCS#11 RFC7512 URI compliance

The release date was set to Thursday 25th.


Discussed the "'ecdsa-sig' management interface command" as requested by


It was decided to let Selva make the call based on the feedback (see
full chatlog).


Full chatlog attached.

Samuli Seppänen
Community Manager
OpenVPN Technologies, Inc

irc freenode net: mattock

(12:29:40) syzzer: almost time...
(12:30:12) cron2: time!
(12:30:22) syzzer: go go go!
(12:30:29) ordex: :O
(12:30:33) ***ordex jumps
(12:31:06) ***dazo sits down
(12:31:11) dazo: to hard to type and run at the same time
(12:32:05) syzzer: So, 
(12:32:06) vpnHelper: Title: Topics-2018-01-17 – OpenVPN Community (at 
(12:32:13) ordex: din din din
(12:32:16) ordex: the market opens
(12:33:46) syzzer: I guess we need mattock for #1, so start with #2?
(12:33:46) ordex: buildbot first ?
(12:33:55) ordex: ah ok
(12:34:03) mattock: guten tag
(12:34:07) ordex: aloha
(12:34:36) mattock: I will need to split quite soon, but will follow the 
discussion on my selfphone
(12:34:42) mattock: tight schedule today
(12:34:46) mattock: buildbot first?
(12:34:53) syzzer: ok
(12:34:54) ordex: ok
(12:35:04) cron2: go :)
(12:35:06) mattock: do we want to build release/2.4?
(12:35:30) mattock: if yes, which combos?
(12:35:33) syzzer: I think it would make sense to actually build and test the 
code we ship to users
(12:35:38) ordex: I think it makes sense. that is the one we should pay more 
attention to, I think
(12:35:39) ordex: yeah
(12:35:47) mattock: syzzer: you make a convincing point there :D
(12:35:51) mattock: which build combos?
(12:35:55) mattock: all?
(12:36:27) syzzer: if that's not too much work
(12:36:57) mattock: not really
(12:37:01) mattock: probably a few lines of code
(12:37:07) cron2: ordex: I'm not sure about the "more" attention, as we usually 
do not put things-that-break into 2.4 (but break them in master, fix them, 
backport them, or break master and 2.4 at the same time)
(12:37:10) mattock: I will add a task for myself
(12:37:26) cron2: but generally speaking, testing at least the most common 
build combinations on 2.4 is a good thing
(12:37:34) cron2: t_client.rc will be compatible (unlike 2.3<->2.4)
(12:37:58) mattock: right now we don't have _that_ many builds going on, so 
doubling them is doable
(12:38:00) ordex: cron2: the way you say it looks like you know what is going 
to break and what not :-P
(12:38:25) mattock: shall we move on to 2.4.5?
(12:38:25) ordex: but I get what you mean, still I think buildbot would 
increase confidence in the code correctness, no ?
(12:38:34) mattock: ordex: agreed, and doing that is cheap
(12:38:38) ordex: ok
(12:38:40) ordex: next
(12:38:47) cron2: ordex: usually I have a good idea whether something will blow 
up one of the BSDs, or a particular network corner
(12:39:00) cron2: but yep, ok, next
(12:39:12) ordex: okyz :)
(12:39:14) syzzer: re 2.4.5:  I think mattock, cron2 and dazo need to agree 
when to push it out.
(12:39:23) cron2: mattock: ... and --disable-crypto on master, as that's just 
wasting CPU (which is not cheap)
(12:39:24) mattock: that is the case
(12:39:30) mattock: cron2: will do
(12:39:50) cron2: syzzer: indeed.  What do we want in there?  Windows 
installers with OpenSSL 1.1?  Any particular wishes?
(12:40:33) syzzer: cron2: I'd really like Allow changing cipher from a ccd file 
(https://patchwork.openvpn.net/patch/92/) to go in
(12:40:34) vpnHelper: Title: [v2] Allow changing cipher from a ccd file - 
Patchwork (at patchwork.openvpn.net)
(12:40:49) cron2: syzzer: into 2.4?  I thought that is master stuff?
(12:41:00) cron2: ah
(12:41:02) ***cron2 is confused
(12:41:30) cron2: we effectively have per-client ciphers in 2.4, as we *have* 
NCP, so it's just "remember that we can do that" thing :)
(12:41:58) syzzer: cron2: exactly
(12:42:01) mattock: I'll check my notes for 2.4.5
(12:42:50) dazo: What's in the pipe for 2.4.5 looks mostly to be improving the 
Windows parts as well ... the generic code is just minor clean-ups or minor bug 
(12:42:56) cron2: right
(12:43:10) dazo: I have no issues with shipping this out
(12:43:23) mattock: openssl 1.1.0, updated easy-rsa-old, updated openvpn-gui, 
pkcs#11 RFC7512 uri compliance
(12:43:48) mattock: many of the above have been merged already
(12:43:55) dazo: mattock: any reason not to add the new easy-rsa together with 
(12:44:09) mattock: yes, the need to do extra work :P
(12:44:15) dazo: :-P
(12:44:37) mattock: but yes, I see your point
(12:44:54) mattock: or we could spend the effort into the MSI installer instead
(12:45:31) mattock: which would bundle easy-rsa 3 as the only option maybe?
(12:45:59) syzzer: MSI installer can be an independent thing, right?
(12:46:04) mattock: yeah, definitely
(12:46:16) mattock: an alternative for NSIS installer at first
(12:46:23) syzzer: yeah, perfect
(12:46:38) syzzer: so, should we set a date?
(12:46:42) mattock: yes
(12:46:59) mattock: thursday next week?
(12:47:08) cron2: works for me
(12:47:59) syzzer: +1
(12:48:02) mattock: great!
(12:49:15) ordex: I don't have anything to do, but I agree!
(12:49:22) mattock: :)
(12:49:38) ordex: dazo might be out
(12:49:47) ordex: but let's see what he says
(12:49:52) mattock: ok, so I need to split now
(12:49:56) cron2: if you do not mess with keys too much, I can do that
(12:49:59) mattock: but please check topic #3 from selva
(12:50:04) mattock: I won't be of much use there anyways
(12:50:10) ***cron2 is out on #3
(12:50:33) mattock: moving to my selfphone now...
(12:50:37) syzzer: I already posted to the ml:  I think a generic pkey-sign is 
a good idea
(12:51:49) mattock_ [~mattock@openvpn/corp/admin/mattock] è entrato nella 
(12:52:14) dazo: Next week I'm at devconf.cz ... Thursday is travelling day
(12:52:25) plaisthos [~arne@openvpn/community/developer/plaisthos] è entrato 
nella stanza.
(12:52:31) syzzer: plaisthos might have an opinion
(12:52:37) syzzer: https://community.openvpn.net/openvpn/wiki/Topics-2018-01-17
(12:52:40) syzzer: topic #3
(12:52:41) vpnHelper: Title: Topics-2018-01-17 – OpenVPN Community (at 
(12:53:05) dazo: but I think cron2 can tackle this ... or I can prepare things 
Wed evening
(12:53:37) plaisthos: the pk-sig stuff?
(12:54:16) plaisthos: I think renaming it to pk-sig is better option here
(12:54:39) plaisthos: that is a relatively obscure feature and most client that 
use it will use a bundled openvpn anyway 
(12:54:58) syzzer: ok, perfect.  I think so too.
(12:55:10) plaisthos: and with pk-sig, the client can still then answer with an 
empy sig if it does not support signature of that kind
(12:55:22) plaisthos: instead of hanging forever like it is probably with the 
v1 of the patch
(12:55:58) plaisthos: and worst case for clients that need support <2.5 and 2.4 
is to treat pk-sig and rsa-sig identical so problem there
(12:56:43) plaisthos: and I would not go through deprecation of rsa-sig, just 
rename it now and put into changelog
(12:57:04) syzzer: yeah.  so conclusion is that we agree that selva takes that 
(12:57:52) syzzer: or just keep it around as an alias, simple enough
(12:57:54) plaisthos: tunnelblick will need to adapt :)
(12:58:00) plaisthos: syzzer: nah cannot have that
(12:58:10) plaisthos: for response yes
(12:58:27) syzzer: I know more users who use external-key
(12:59:00) plaisthos: but since the query will change from >RSASIGN to >PK-SIGN 
you need to change the code anyway, so keeping just half compabibility is not 
that nice
(12:59:17) plaisthos: but yeah makes it a bit easier on management client (I 
can always respond with rsa-sign)
(12:59:34) syzzer: hm, I'm not so sure why an alias of RSASIGN wouldn't work?
(13:00:05) syzzer: but let's first leave that to Selva, he usually comes up 
with a good solution :p
(13:00:47) plaisthos: syzzer: the client request the client to send a signature
(13:01:00) plaisthos: currently the client gets RSASIGN with the base64.
(13:01:09) syzzer: ah, right!
(13:01:20) plaisthos: sending both PK-SIGN with base64 and RSASIGN with base64 
would be strange
(13:01:59) syzzer: you convinced me, hard switch makes sense
(13:02:31) plaisthos: (:
(13:03:16) dazo: I'm very sceptical to remove RSASIGN ... this can truly break 
some setups we're not aware of.  Rather make RSASIGN be an "alias" for PK-SIGN
(13:03:31) syzzer: dazo: see discussion above ;-)
(13:05:29) syzzer: the way around would be to keep sending RSA-SIGN for RSA 
sigs "forever"
(13:05:32) dazo: Yeah ... If I've understood correctly, it sounds like RSASIGN 
will be removed and replaced with PK-SIGN ... and that is a no-go
(13:06:10) syzzer: dazo: this is a *command* from openvpn to the mgmt if, so we 
have to either keep it forever 
(13:06:17) syzzer: or make a hard switch
(13:06:24) syzzer: it can not be an alias
(13:06:53) cron2: oh, we could add capability negotiation between openvpn mgmt 
if and mgmt if client
(13:07:02) ***cron2 ducks
(13:07:11) dazo: I don't follow why it can't be an alias ... it needs a minor 
logic in the reply (if command was RSASIGN, respond with >RSASIGN ... otherwise 
(13:07:12) syzzer: cron2: yauh, you better :p
(13:07:28) syzzer: dazo: that is the other end of the mgmt if
(13:07:30) cron2: dazo: that's the reply on the mgmt client side, but what sort 
of request shall openvpn send out?
(13:07:32) syzzer: *we* send the command
(13:07:47) dazo: ahh ... 
(13:08:07) syzzer: glad to see I'm not the only one that overlooked that :p
(13:08:14) dazo: :)
(13:08:47) dazo: That does indeed speak for hard-switch .... but that will 
truly cause lots of bug reports
(13:08:58) dazo: from various implementation we're not aware of
(13:09:40) syzzer: yeah, it will,  so we should be document it clearly in 
changes.rst and only do in a major update
(13:09:45) plaisthos: only alternative we have is to have the burden ourself to 
introduce an option that says that the client is pk-sign ready which introduces 
a lot of complexity for us
(13:10:00) syzzer: yeah, let's not do that
(13:10:01) dazo: Then I think we need a pre-command ... which does the switch 
.... PK-INIT 2  (to use PK-SIGN) ... or PK-INIT 1 (default, as it is today, 
uses >RSASIGN)
(13:10:23) syzzer: I'd rather send RSA-SIGN "forever"
(13:10:30) plaisthos: or always use RSA-SIGN even though it can ask for ecdsa 
(13:11:04) syzzer: we know when we expect an RSA sig, right?  we can just send 
RSA-SIG forever in that case
(13:11:18) plaisthos: yeah
(13:11:27) syzzer: and treat the responses as aliases
(13:11:35) dazo: yeah, that does sound cleaner .... Let me follow-up with this 
question internally, and see if we see any issues from the corp side of things 
.... If the corp side says "PK-SIGN" will work in a major update, then much of 
my concerns are gone
(13:11:41) plaisthos: just document it that it is called rsa-sig for historical 
(13:12:16) plaisthos: dazo: you just need to alias in your code to treat 
(13:12:42) plaisthos: otherwise we stick to the "for historical reasons"
(13:12:47) dazo: right ... but it's not just our code ... we have customers too 
implementing openvpn 2 and 3 in various settings :)
(13:13:58) dazo: Currently I'm now leaning towards "for historical reasons" ... 
that gives the least potential for breakage
(13:14:20) plaisthos: depends if you want to have compatibility reasons
(13:14:49) plaisthos: or let users that upgrade to 2.5 double check that their 
implementation does not segfault when it gets a request with ecdsa signing
(13:15:05) plaisthos: as openvpn did with management-external-key not long ago
(13:17:02) plaisthos: (small risk in normal environment since you need ec certs 
to get that code path)
(13:18:23) syzzer: I don't like "for historical reasons", it results in 
terrible user experience
(13:19:21) syzzer: just recall the SSLv23_new() stuff from openssl
(13:20:18) syzzer: this is a power user corner case.  If we document it well, 
they should be able to deal with it.
(13:21:03) plaisthos: oh yeah, beta API evar. But we then also need another 
implement PK-SIGN that only does RSA and RSA-SIGN that does ecdsa+rsa to fully 
capture the spirit of SSLv23_new
(13:21:19) ordex: :D
(13:22:58) syzzer: (still, we could keep sending RSA-SIG for a while for rsa 
sigs only, and send PK-SIG for EC sigs, right?)
(13:23:52) syzzer: as an escape if we expect troubles
(13:26:00) syzzer: anyway, I think we have plenty of input for Selva :p
(13:26:02) plaisthos: PK-SIG unaware clients would just hang
(13:26:31) plaisthos: and we would have the same discussion for next release
(13:26:32) syzzer: because we wait forever for a response?
(13:26:35) plaisthos: yes
(13:26:44) syzzer: then we should not wait forever?
(13:27:05) syzzer: a timeout sounds like a decent thing anyway
(13:27:13) plaisthos: well
(13:27:28) plaisthos: you might have a smartcard or something else with user 
input in there
(13:27:50) syzzer: sure, so a rather large timeout
(13:27:59) plaisthos: Don't put a timeout there, it is just complicates thing 
for no good reason
(13:29:20) plaisthos: we can expect magement-clients to be well behaved
(13:30:42) syzzer: hm, that makes sense too...
(13:30:57) syzzer: okay, I'll just back off untill I've taking a closer look at 
(13:31:45) cron2: so the ACK for 3/3 should be revoked then, right?
(13:31:53) cron2: because the documentation won't look as proposed
(13:32:16) plaisthos: I think that is implicit 
(13:32:51) syzzer: Un-acked-by: ?
(13:32:59) cron2: no idea if that can be done
(13:33:05) syzzer: haha
(13:33:35) cron2: anyway... I think 3. is concluded?  $Wife is hungry :)
(13:33:37) syzzer: in other news: time's up, I need lunch :p
(13:34:27) ordex: good idea
(13:35:02) cron2: so what about 5.?
(13:35:13) plaisthos: sounds good
(13:35:24) plaisthos: although most bugs end in my github 
(13:35:42) plaisthos: but yeah for the misguided adding a OpenVPN for Android 
component is easier on ordex 
(13:35:45) syzzer: yeah, 5. makes sense
(13:36:10) plaisthos: but users will mix that up anyway
(13:36:27) plaisthos: I also get OpenVPN connect questions
(13:36:40) ordex: plaisthos: we could have "Community clients"
(13:36:45) ordex: to group also tunneblick and other stuff
(13:37:03) ordex: plaisthos: yeah but at least we can later better classify 
(13:37:31) plaisthos: ordex: yeah, feel free, and bugs that my client can be 
closed and dircted to my github issue tracker if needed
(13:37:50) ordex: ok
(13:38:04) ordex: sounds good
(13:38:57) plaisthos: There is the category that is OpenVPN for Android but 
actually core openvpn might be a thing you might think aobut for 5 minutes
(13:39:29) plaisthos: but probably fine that just openvpn
(13:42:29) ordex: yep
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
Openvpn-devel mailing list

Reply via email to