Basic info
- Time: Wednesday 29 July 2026 at 14:00 CEST (12:00 UTC)
- Place: #openvpn-meeting channel on !LiberaChat IRC network
Topics
- Updated: 2.7.6 release We want to do another release soonish due to some pending security fixes. But we're not ready this week so it is planned for next week (~ July 29). One of the two security fixes doesn't seem to be worth an embargo, so we decided to handle the review through Gerrit. MaxF will move his PR to there. Will need a 2.6.22 as well.
Backlog
CVE handling during holidays
Due to holidays, temporarily evaluation of CVE and assigning IDs is postponed. This will be for approximately 3 weeks.
Reports will still be able to come in but determining if it's an actual CVE or not and assigning an ID will have to wait.test latency and MTU in openvpn
A new feature is proposed for adding to master; ability to do latency and MTU tests in the OpenVPN protocol.
Idea is to allow to do a 'best server selection' type of logic, in case there are multiple servers available to connect to.
RFC PR is at https://github.com/OpenVPN/openvpn-rfc/pull/30 and an early initial implementation is available from lev.community meetup 2026
Coordination is currently taking place here: https://community.openvpn.net/Meetups/2026-Paderborn
The date is around 17 and 18 October, location in Paderborn, Germany. ordex has volunteered to update and polish the page, fill in some further details.2.7 security audit
The security audit was completed for 2.7.0 and results are available internally.
We are working to publish this in an official blog post. ordex and novaflash are driving this in OpenVPN Inc. internally.
Amount of open changes in the queue Some discussion about the number of open patches (e.g. about 120 open changes in Gerrit). We definitely need to look into our processes again and how to spread all that work reviewing, testing, and integrating. Likely also a topic for the 2026 Community Meetup in Paderborn. djpig is working on better documenting the current processes, see e.g. 1776: Start a new document CODE_CHECKLIST in Gerrit.
Coordinating big changes A related discussion is how to handle big changesets (e.g. currently the multipeer changes from plaisthos and the oob changes from lev). There was some unhappiness that these changesets are dropped without sufficient context and that makes it hard to keep track of all the developments. One advise is that developers that want to have big (or many) changes merged are encouraged to write a mail to the mailing list to provide a "cover letter" for the patch set and a convenient place to discuss the overall direction without getting bogged down in the discussion of individual changes. We have lost this practice since not generally using mail-based patchsets anymore. That can be also a good opportunity to point out dicussions happening in PRs for the RFC document.
