Bug#1033006: unblock: openvpn/2.6.1-1 (preapproval)

[Bernhard Schmidt <berni@debian.org>]

On 15/03/23 04:57 PM, Bernhard Schmidt wrote:

Hi,

> The upcoming DCO change will involve a new version of src:openvpn and a new version
> of src:openvpn-dco-dkms. The list of changes on the kernel side is already visible
> on https://github.com/OpenVPN/ovpn-dco/commits/master .
> 
> In the past we managed to break DCO on above mentioned really heavily loaded
> OpenVPN server within a few hours. The new version is a major overhaul and more
> in-line with code upstreamable in Linux, and did survive torture tests.
> 
> I know this is kind of late, but I think it would be better to include it as well
> as soon as it is released because
> 
> - we cannot support the old deprecated module
> - openvpn uses DCO (of the right version) automatically and will transparently
>   fall-back to non-DCO mode if the module is not found (or the wrong version)
> - it has not been in Bullseye previously, so if we see that DCO is too unstable
>   with the new version we can just drop it before the release

So, the release of 2.6.2 with the new DCO module has been done
yesterday, fixing a number of bugs already present in 2.6.0.

https://github.com/OpenVPN/openvpn/blob/release/2.6/Changes.rst

---
New control packets flow for data channel offloading on Linux. 2.6.2+
changes the way OpenVPN control packets are handled on Linux when DCO is
active, fixing the lockups observed with 2.6.0/2.6.1 under high client
connect/disconnect activity. This is an INCOMPATIBLE change and
therefore an ovpn-dco kernel module older than v0.2.20230323 (commit ID
726fdfe0fa21) will not work anymore and must be upgraded. The kernel
module was renamed to "ovpn-dco-v2.ko" in order to highlight this change
and ensure that users and userspace software could easily understand
which version is loaded. Attempting to use the old ovpn-dco with 2.6.2+
will lead to disabling DCO at runtime.
---

So I need some guidance from the release team how to proceed. I can
think of

- abandoning all of this, leading to a bookworm release using a buggy
  OpenVPN version with a DCO kernel interface that noone else uses
- update experimental to 2.6.2 and the new DCO module, then ask for a
  approval for upload to unstable (2.6.1+2.6.2) in one go
- upload 2.6.2 and the new DCO module to unstable right away
- upload 2.6.1 from experimental to unstable, then stage 2.6.2 and the
  new DCO in experimental for the second review round

I would prefer the last option.

Bernhard