Wow, a summary that was not written by me :). Thanks Gert!
Il 22/07/20 13:44, Gert Doering ha scritto:
> 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!
>
>
>
> _______________________________________________
> Openvpn-devel mailing list
> Openvpn-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/openvpn-devel
>
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Openvpn-devel mailing list Openvpn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-devel
