Good morning, we had a nice meeting today, and here's the summary and chatlog:
- 2.5 release is nicely taking shape, most features are in, and the
code in master is very well tested already
- we agree on renaming --ncp-ciphers to --data-ciphers, to make clear
that this is not a debugging aid anymore but "the!" control switch
to set (to-be-negotiated) data channel ciphers in the future.
- we broke WolfSSL with the "nonconditional AEAD" patch, which was
unintended but "we really require AEAD in 2.5 to be always available"
- remaining bugs/warts for "must be in 2.5.0!" are to be tracked in TRAC
with "milestone 2.5.0"
- warts that are slightly annoying but not as urgent get set to
"milestone 2.5.1" ("fix after initial release")
- tentative release schedule (which looks doable)
* 2.5_beta1 on August 05
* 2.5.0 on September 10
Slightly redacted chatlog:
11:31 < ordex> aloha
11:32 < dazo> \o/
11:33 -!- dazo changed the topic of #openvpn-meeting to: Agenda at
https://community.openvpn.net/openvpn/wiki/Topics-2020-07-22
11:35 < cron2> and indeed there it is :-)
11:36 < cron2> I've put a few things on the agenda so we can decide how to move
onwards
11:36 < dazo> lets start on the top :)
11:36 < cron2> first, thank you all for amazing work in the last weeks - we're
in pretty good shape for the release (though some odd corners
remain)
11:36 < ordex> yeehaaa!
11:37 < cron2> I totally love my newfound understanding of the plugin APIs :-)
11:37 < cron2> next thing: decided on "do we want to rename ncp-ciphers to
data-ciphers" - this is a bit more than "just code review",
which is why I put it here
11:38 < cron2> the patch is fine, and it also accepts the old option as compat
alias, so it won't break anything
11:38 < ordex> imho, it makes the real goal of the directive more clear
11:38 < ordex> to the users and to us
11:38 < cron2> "the new real goal" :-) - but yes, I agree
11:38 < plaisthos> ncp-ciphers was a good and fitting name when it was
introduced and --cipher was still king of the hill
11:39 < dazo> yeah, I agree to the renaming --ncp-ciphers ... NCP itself is
more a technical detail which users don't really need to care
about ... --data-ciphers describes better what it does
11:39 < ordex> yap yap, what dazo says
11:39 < ordex> ncp is really an "under the hood detail"
11:39 < plaisthos> but moving forward (esp. when my ncp v2.5 patch gets in),
data-ciphers is only thing that remains
11:40 < cron2> good :-) - nobody objects, make it so (I'll review, ACK, merge
later)
11:40 < dazo> I would probably prefer to see a INFO (or WARNING?) when
--ncp-cipehers is used, educate them to move to --data-ciphers so
we in can remove --ncp-ciphers in the future and only have
--data-ciphers
11:40 < cron2> you need to excuse me for ~10 minutes - family business
(collison, unavoidable)
11:42 < plaisthos> dazo: I don't think we should remove ncp-ciphers
11:42 < dazo> why?
11:43 < plaisthos> it is an alias that does not complicate code and giving
people the opportunity to have config that are also
compatible with 2.4 is more important than forcing people to
a bit nicer sounding option
11:43 < ordex> true, but we also don't want to carry legacy things for decades,
no ? I think it would be nice to get rid of it at some point?
like any other deprecate doption
11:43 < dazo> Right, I'm not saying removing NOW ... But more in line of 2.8 or
something like that ... but that we already now just add a
INFO/WARN to tell users to switch to --data-ciphers whenever
--ncp-ciphers is spotted
11:44 < plaisthos> dazo: as compromise, we can keep it around as long as we
kept udp-mtu as an alias for tun-mtu ;)
11:44 < ordex> from the user perspective, there is no difference between
ncp-cipher and anyother option we deprecate, I think >
11:44 < ordex> ?
11:44 < ordex> :D
11:44 < plaisthos> udp-mtu is an alias for link-mtu, sorry
11:44 < dazo> I was not aware of udp-mtu at all
11:45 < plaisthos> see
11:45 < plaisthos> ncp-cipher will fall out of use eventually anyway
11:45 < ordex> hehe
11:45 < plaisthos> and both data-ciphers and ncp-ciphers are not as necessary
as --cipher
11:45 < plaisthos> since they will always have good deafults
11:46 < plaisthos> since we can slowly add and remove cipher in versions
11:47 < dazo> That's what I really dislike about openvpn ... we have so many
options with no good overview of many of them ... we should avoid
leaving things behind like that (udp-mtu got switched to
link-mtu in 1.5_beta1!)
11:47 < syzzer> +1 on --data-ciphers
11:48 < dazo> Had udp-mtu had a warning to switch to link-mtu ... it would be
clearer why we had that option and we could actually kick it out
and have a cleaner code
11:48 < syzzer> and +1 on keeping --ncp-ciphers around for now. Options that
actually add complexity is what hurts us, not aliases.
11:48 < syzzer> we might want to consider adding --data-ciphers as an alias to
2.4 too though
11:49 < syzzer> makes it easier for people to use the new name
11:49 < dazo> I really agree to have --ncp-ciphers as an alias to
--data-ciphers (or vice versa, doesn't matter) .... but I really
want to improve the code cleanliness for the future too
11:51 < syzzer> We all agree like 99%. It's just that I believe plain aliases
add neglegible complexity :)
11:52 < cron2> re
11:52 * plaisthos is with syzzer on this
11:53 < plaisthos> but let's postpone the "deprecate aliases" discussion
11:53 < plaisthos> because that affects a lot more optiosn than just
ncp/data-ciphers
11:54 < cron2> indeed. I suggest we collect aliases on the "deprecated
options" page as well, and decide when and what to do about it
next meeting?
11:55 < dazo> I'm fine with that
11:55 < plaisthos> I peronsally think the effort deprecating them etc is not
worth what we gain
11:55 < plaisthos> deprecation udp-mtu would gain us nothing but makes a lot of
effort
11:55 < cron2> I'm curious how many we have and what effort it would be
11:55 < dazo> patch already on the way to the ML ... didn't take that much
effort ;-)
11:56 < cron2> where's the dazo that always rejects anything that might
people's running configs?
11:56 < cron2> "break"
11:57 < dazo> :-P
11:57 < ordex> "his was changed in
11:57 < ordex> OpenVPN 1.5_beta1 (release July 2003)"
11:57 < dazo> For aliases the effort shouldn't be big ... as they already have
a 100% compatible replacement ... so it's more the aspect of
defining a process to review alias options to clean up
11:57 < ordex> :p
11:57 < cron2> seriously: the change is trivial, but usually it's you worrying
about "someone might have this in an old config and they are not
aware because it always worked"
11:58 < dazo> I know ... but as long as there is a reasonable transition period
... and users are informed about it in advance, I'm fine with
cleaning up stuff
11:59 < plaisthos> can we postpone the discussion for time and move on with 2.5
release?
11:59 < ordex> dazo is getting compromised
11:59 < dazo> agreed
11:59 < ordex> yeah
11:59 < cron2> yes, as we agreed already
11:59 < plaisthos> I am drafting a reply to your udp-mtu patch on the mail to
give my perspective
11:59 < cron2> so, NCP rework patch - I do not want to discuss this *now*, but
I'm searching for a review victim^Wvolunteer
12:00 < dazo> plaisthos: it's less efforts to just ACK it :-P
12:00 < cron2> syzzer: this is really your territory :-)
12:01 * syzzer was afk for 5 mins. Reading backlog...
12:01 < plaisthos> testing is for everyone :P
12:03 < cron2> I'm happy to whack the patch from all sides, but I'd really love
to have someone who understands crypto sanity-check code and
concept.
12:03 < ordex> I think having syzzer read that patch would be nice too :)
12:03 < cron2> syzzer: if you do not object very quickly, I'll assume that is a
lazy-ACK on volunteering *cough* :-)
12:03 < syzzer> yeah, I'll try to review it. Stare-at-code should work. Testing
from others is very welcome.
12:04 < cron2> lev__: can you hit your testbed with it?
12:04 < dazo> plaisthos: in the .rst file .... it should not be a space between
the "--option" line and the block below
12:05 < cron2> dazo: if the content is OK otherwise, I can fix whitespace on
the fly
12:05 < cron2> and typos
12:06 < lev__> I think I can
12:06 < cron2> cool :-)
12:06 < lev__> what patch exactly is that
12:06 < dazo> sounds good! ... side-note: I'll try to update the README.man
file with recommended styling for our .rst files
12:06 < cron2> lev__: https://patchwork.openvpn.net/patch/1291/
12:06 < vpnHelper> Title: [Openvpn-devel,9/9] Rework NCP compability logic and
drop BF-CBC support by default - Patchwork (at
patchwork.openvpn.net)
12:06 < cron2> dazo: +1
12:07 < cron2> so.
12:07 < ordex> \o/
12:08 < cron2> 1.3. -> how do we track "small things we find at testing"? I
currently track stuff that I find during ACK-and-merge in my
mailbox, but that does not scale well. Not sure the
"StatusOfOpenVPN25" page is ideally suited for that, so I
suggest using trac more active, with "milestone 2.5.0" for "must
be fixed!" patches, and maybe "milestone 2.5.1" for "yeah, this
sucks, but it can be done after
12:08 < cron2> release"
12:09 < syzzer> +1
12:09 < dazo> Sounds reasonable
12:09 < ordex> yeah using trac sounds meaningful
12:10 < dazo> Would be good to have the patchwork link into the trac tickets,
though ... so it's easy to find the related patches
12:10 < ordex> I think if we all agree on that, it could easily become a way to
coordinate and oversee the status of the project
12:10 < ordex> we can add a field I guess
12:10 < dazo> ordex++
12:10 < ordex> or just add the link manually
12:10 < plaisthos> implicit declaration of function 'CRYPTO_memcmp' is invalid
in C99
12:10 < plaisthos> ah dman
12:10 < dazo> I don't care how ... just that it is there :-)
12:11 < ordex> yeah
12:11 < plaisthos> and EVP_CIPH_FLAG_AEAD_CIPHER
12:11 < plaisthos> also undefined
12:11 < plaisthos> the latter is worrying
12:11 < cron2> plaisthos playing with WolfSSL again
12:12 < plaisthos> first time actually
12:12 < plaisthos> but it does not compile at the moment ...
12:12 < ordex> I think last time I tested that (?)
12:12 < plaisthos> yeah
12:12 < plaisthos> but the removal of OpenSSL 1.0.1 breaks it
12:12 < ordex> yeah
12:12 < plaisthos> not
12:13 < plaisthos> actually that we assume that AEAD API is always there breaks
it
12:13 < ordex> so for 1.3 it seems there is agreement in trying to use trac ?
[ redacted ]
12:13 < cron2> ordex: yup. I'll summarize this accordingly.
12:13 < ordex> thanks
12:13 < ordex> 1.4 !
12:14 < cron2> [ vaction dates ]
12:16 < cron2> so how do we organize "MSI building" (mattock), "reasonable test
period", "release" around that?
12:16 < ordex> probably we should target mid august for the release ?
12:17 < cron2> that is a bit short on "get people to test", if we can only have
a MSI installer by Aug 5 or so
12:17 < lev__> MSI building is mostly automated, except for signing
12:17 < cron2> lev__: can you generate signed MSIs? Or only mattock?
12:17 < lev__> I can do that for testing purposed (already did for testing my
installer fix)
12:18 < lev__> not sure about signing, but if needed I can ask mattock
12:18 < ordex> cron2: but we can still release the beta (or rc1) for mid august
and then we let people test ? or that's not what was planned ?
12:18 < cron2> ordex: yeah, beta/rc1, but not "2.5.0 release in mid August"
12:18 < cron2> I thought you wanted the full release then
12:18 < cron2> so, my suggestion would be:
12:18 < dazo> I will also be partially away next week and the following week
... but I will pay attention to e-mails and can step in if there
are some urgent things requiring my attention
12:18 < cron2> - we test internally and fix like crazy :-)
12:19 < ordex> :D
12:19 < cron2> - when mattock returns, we release rc1/beta/whateveryoucallit,
with signed MSIs
12:19 < cron2> (that would be "August 5")
12:19 < cron2> then we test more and solicit as much feedback as we can
12:19 < cron2> and aim for formal release like "September 10" or so
12:20 < ordex> that sounds like a plan
12:20 < ordex> even though you may not have enough time to chime in ?
12:20 < cron2> I do not want the actual release to happen while I'm not there
12:21 < cron2> but "read bug reports and tell people that it's their own
fault", I can do remotely
12:21 < ordex> :D
12:22 < plaisthos> I am on my way to lunch in 5 minutes
12:22 * ordex is typing from the dining table :>
12:23 * cron2 just ate some leftovers from the fridge :)
12:23 < ordex> ok, so can we agree on the schedule proposed by cron2 ?
12:23 < cron2> anyway, plaisthos, syzzer, dazo: any amendments?
12:23 < ordex> dazo: ^
12:23 < cron2> can we get QA folks to do some creative testing, like "git
master client against 2.3 servers, older AS builds, ..."?
12:24 < dazo> No, that's fine ... I would say the code quality of git master is
of beta quality ... so I would recommend that we just jump into
beta releases
12:24 < cron2> especially "against old AS" would be interesting, as this can be
"modified old 2.3"
12:24 < cron2> dazo: so we do "beta1" and then "2.5.0" (unless something
serious is found)?
12:24 < dazo> which means we branch of the 2.5 branch and starts the code
freeze phase for that branch
12:25 < ordex> sounds good
12:25 < dazo> Yeah, beta1 ... if we see we need to fix anything, then that will
be either beta2 or rc1, depending on the issue
12:26 < dazo> or if we go straight from beta2 -> 2.5.0 ... that's also possible
... as long as we are satisfied with the code
12:26 < cron2> do we want a "rc" release?
12:26 < dazo> Not necessarily ... I would say that depends on what the beta
cycle reveals
12:26 < plaisthos> I don't want to force syzzer to be the blocker in reviewing
the ncp patch
12:27 < cron2> when do we want to branch release/2.5? at "2.5_beta1" or at
"rc1"? I hear mixed signals
12:27 < plaisthos> so it would be good if ordex or dazo or lev can help to that
12:27 < plaisthos> anyway off to lunch
12:27 < cron2> yes
12:27 < cron2> enjoy :)
12:27 < plaisthos> (I don't want to put that burden on syzzer I mean)
12:27 < ordex> cron2: I think after we have merged the latest bits on the ml ?
i.e. by mid august ?
12:28 * dazo need to run in 5 minutes too
12:28 < ordex> (or earlier if we manage)
12:28 < cron2> ordex: there will always be bits to merge
12:28 < cron2> at some point we'll merge more bits to "master" and
"release/2.5" :-)
12:28 < ordex> cron2: once we branch off i expect no new features in
release/2.5 for a bit
12:28 < cron2> I think it makes sense to branch release/2.5 the moment we
change version.m4 to be "something with a name"
12:28 < cron2> ordex: features are all in. From now on, only bugfixes.
12:29 < ordex> well --ncp-ciphers -> --data-ciphers is not in yet :p
12:29 < ordex> anyway
12:29 < cron2> except for those two, yes :)
12:29 < ordex> how about branching off once these 2 ncp things are in ?
12:29 < cron2> and small featurettes and cleanup, of course
12:30 < ordex> and version.m4 is modified
12:30 < dazo> once we have all features we wants ... we can branch off, I'd say
12:30 < cron2> version.m4 is modified at 2.5_beta1 release, which happens at
August 5
12:30 < dazo> "code freeze" to me means "bug fixes only" :)
12:30 < ordex> yeah
12:30 < cron2> yes
12:30 < ordex> let's branch off on aug 5th then
12:30 < dazo> yeah .... Aug 5 is a good time
12:30 < syzzer> I'll try to review the rework NCP patch this afternoon
12:31 < syzzer> should work
12:31 < ordex> syzzer: that'd be nice ! I'll check the patch too
12:31 < cron2> syzzer: thanks
12:31 < ordex> just to offer another half-eye
12:31 < cron2> I have updated the StatusOfOpenVPN25 page with the new timline
12:31 < syzzer> ordex: yes, very welcome. You'll look at the code an a
different way.
12:32 < ordex> yeah
12:32 < ordex> ok
12:32 < cron2> ordex will complain about missing whitespace and added blank
lines, and totally miss the travis explosions :-) (but that is
good, travis can look for itself)
12:32 < ordex> it seems the schedule is settled!
12:32 < syzzer> Nice!
12:33 < ordex> anything else? or can we all jump into lunch ?
12:33 < cron2> nothing on the agenda (except patch review)
12:33 < cron2> and that is being worked on
12:34 < ordex> cool
12:35 < ordex> I will jump out then
12:35 < cron2> enjoy :)
12:35 < cron2> I'll send a summary soon, leaving out the exact vacation dates
12:36 < ordex> thanks a lot
12:37 < dazo> thx!
12:37 < lev__> thanks!
--
"If was one thing all people took for granted, was conviction that if you
feed honest figures into a computer, honest figures come out. Never doubted
it myself till I met a computer with a sense of humor."
Robert A. Heinlein, The Moon is a Harsh Mistress
Gert Doering - Munich, Germany g...@greenie.muc.de
signature.asc
Description: PGP signature
_______________________________________________ Openvpn-devel mailing list Openvpn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-devel
