= Introduction = This page shows the high-level status of OpenVPN 2.5 release. If you want all the details, see the [report:3 Active Tickets by Milestone] report. = Schedule = As we missed our original deadline (Debian Buster freeze) we don't have a schedule yet, except "in year 2020". Nevertheless, the release will proceed as follows: * 2.5_beta1 (early July) After this date, no new features allowed, stabilising starts for real. Some minor "nice to have patches" might be accepted after evaluation/discussion on IRC; but should be avoided. Man page processing will be converted from the current groff formatting to a markdown formatting right before beta tagging. * ??? - 2.5_beta2 (optional) Only patches related to stabilising and important bug-fixes are allowed after this point. No more "nice to have patches" after this point. If we have no bug fixes or otherwise stabilizing code this release can be skipped. * ??? - 2.5_rc1 Only really needed and critical bug fixes allowed. * ??? - 2.5_rc2 Branching out release/2.5 happens here. * 2.5.0 Final release. == Deadline: To be determined == * Code freeze on June 30st, 2020 (based initially on discussions in Trento hackathon, postponed in IRC meeting on 4th March 2020, postponed again...) * 2.5.0 release on August 15th, 2020 = Features/fixes to include = == must have == ||'''Task description'''||'''Assigned to'''||'''Status'''||'''Ticket'''|| || [wiki:OpenvpnMSIInstaller MSI installers] || mattock || Final integration tests not done ||#1122|| || Implement asymmetric compression || plaisthos || pending, need updated patch + review (syzzer/cron2) || ? || || async client-connect support || plaisthos + ordex || pending, needs more review + work || - || || man page formatting change || dazo || [https://gitlab.com/dazo/openvpn/-/tree/dev/man-reformatting/doc/man-sections in progress] || - || == "we should try to make it happen" (but will likely not make it) == ||'''Task description'''||'''Assigned to'''||'''Status'''||'''Ticket'''|| || support for multiple-protocol sockets (UDP/TCP) || ordex || wip || || Support for multiple sockets (multi-port/multi-IP) || ordex || pending review ||#556|| || Dynamic routes ('route in ccd-file'), depends on netlink support || ??? || ??? || || transport plugin (primary use case: obfuscation) || ordex || wip || || [http://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg10511.html tftp/wpad patch] || jjk ||patch on list, needs review and merge|| || support TLS record splitting (like ovpn3) || syzzer ||(started, but no patches available yet) ||#554|| || [https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg12767.html Allow OpenVPN to communicate to peers via a Linux VRF] || cron2 || [https://github.com/OpenVPN/openvpn/pull/65/commits/1baa7e6782b39ed664eedb9b006728d31e22c07e updated patches] need review + ML submission || || test server that does --auth-user-pass and/or challenge stuff ||cron2 (snair)||not started|| || update auth-user-pass docs || mattock||not started, discussion [https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg12835.html here]|| || Update OpenVPN PRF (move away from SHA1/MD5) || syzzer || not started || || maybe: add PRF plugin interface || ??? || ??? || || maybe: add key exchange plugin interface (allows easily doing .e.g post quantum kex) || ??? || ??? || || maybe: add data channel separation (or, move to ovpn3, which already has this?) || ??? || ??? || || maybe: fix radius-plugin - plugin is useful but not maintained very well || ??? || ??? || || improve control channel performance || syzzer || ??? || == work needed == * trac tickets (2.4.x, 2.5.x, unclassified) * MSI testing and user documentation == items already done == * remove ENABLE_CRYPTO * [https://patchwork.openvpn.net/patch/496/ ChaCha20-Poly1305 support for the data channel] * tls-crypt-v2 (#1121) * MSI packaging * [https://patchwork.openvpn.net/project/openvpn2/list/?series=638 struct argv overhaul] * [https://patchwork.openvpn.net/patch/824/ Wintun support] * [https://patchwork.openvpn.net/project/openvpn2/list/?series=543&submitter=&state=3&q=&archive=&delegate= Auth failure messages back to client] * #6 - VLAN patch set * #1123 - Netlink support (includes route.c / tun.c refactoring) || [https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg16998.html IPv6-only server] || ordex & cron2 || most of the work is done! some details remain to be cleaned up ||#208|| TODO: update list = Missing pieces from MSI = Bundling OpenVPN as an MSI will require changes to several projects: openvpn, openvpnserv2, openvpn-build and tap-windows6. Here's a list of the missing pieces (hopefully) in the order in which they should be merged: 1. ~~[https://patchwork.openvpn.net/project/openvpn2/list/?series=662 openvpn: the openvpnmsica and tapctl patch series]~~ 1. [https://github.com/OpenVPN/tap-windows6/pull/106 tap-windows6: MSM packaging] 1. [https://github.com/OpenVPN/openvpn-build/pull/141 openvpn-build: Windows MSI packaging] 1. [https://github.com/OpenVPN/openvpn-vagrant/pull/7 openvpn-vagrant: Add MSI build support] * Needs to be adapted to final upstream URLs before merging == Dropping tap-windows6 NSI changes? == I (mattock) propose we ''drop'' the following tap-windows6 PRs that change the **NSIS** installer: * [https://github.com/OpenVPN/tap-windows6/pull/98 installer: Refine the WoW64 decision logic] * [https://github.com/OpenVPN/tap-windows6/pull/99 installer: Select Win7/8/8.1 vs. Win10 driver at runtime] * [https://github.com/OpenVPN/tap-windows6/pull/100 installer: Add code signing certificate before installing the driver] Current OpenVPN / tap-windows6 NSIS installers are working well across all the platforms, so I'd prefer not to "rock the boat" by introducing changes unnecessarily. Also, I believe the above PRs were originally meant for OpenVPN 2.5, not for 2.4. And OpenVPN 2.5 does not need these PRs anymore now that we have [https://github.com/OpenVPN/tap-windows6/pull/106 MSM packaging] for tap-windows6. Even if we did decide that the above PRs make sense for 2.4, [wiki:SupportedVersions our support policy] says that 2.4 would move to "Old stable" in ~6 months after 2.5.0, after which we would not provide any Windows installers. So the gain for 2.4. would be rather small, maybe for one or two 2.4.x releases at most.