MRE request for OpenVPN

Fri Jun 2 00:56:21 UTC 2023

Hi Lena,

Sorry this has taken so long for someone to get to. Review below:

On Mon, Feb 27 2023 at 13:25:25 -0700, Lena Voytek 
<lena.voytek at canonical.com> wrote:
> Hello,
> 
> I would like to request a Microrelease Exception for the OpenVPN
> package in Ubuntu Jammy and Focal. I created a wiki page containing
> relevant information here:
> 
> https://wiki.ubuntu.com/OpenVPNUpdates

This is a well-written and usefully-detailed MRE process proposal.

My only question to pin down in the proposal would be exactly what 
releases we'll be considering. Certainly releases in the Full stable 
support category; presumably also releases made in old-stable support. 
Would we also be expecting to pull in snapshots in the git-tree-only 
support timeframe under this MRE?

> Having an MRE would allow us to take advantage of OpenVPN's stable
> release policy, providing many existing bug fixes to Focal and Jammy,
> which are using 2.4.x and 2.5.x respectively.
> 

After having a bit of a browse of the 2.6 release branch, I'm not 
entirely happy that OpenVPN's understanding of “stable release” 
matches the SRU policy.

*Most* of the patches on that branch look like either fixes we want or 
changes to code we don't care about (Windows, *BSD, etc), but there's a 
thread of patches to DCO which seem to be feature additions at least 
one of which¹ modifies user-visible behaviour in 
backwards-incompatible ways. This is helpfully called-out in the 2.6.2 
release notes², under “User visible changes”, but this suggests 
that we'll *at least* need a process like the for proposed bind9 
exception where someone explicitly checks the release notes and calls 
out anything that might be a problem.

The 2.5 release branch looks better in this regard, although a sampling 
there includes a commit³ which includes “Regression warning: shared 
secret setups are left out of the backoff logic.” in the commit 
message (and nothing in the release notes), and at least one new 
feature commit (implementing auth-token-user⁴).

I lack the context to decide whether or not these regressions are 
concerning and whether these new features are really bug fixes⁵, but 
with the context I have I'm not sure that a standing MRE for OpenVPN is 
appropriate.

I note that 2.4.x (in Focal) has already dropped out of *all* support 
categories. An SRU to update to Focal to 2.4.12 still might be 
appropriate - the degree of testing, both upstream and in-archive, 
appears good - and that one-off upload would be the only result of this 
MRE for Focal anyway.

It's *also* quite possible that 2.5.9 might be an appropriate SRU for 
Jammy. I'm just not confident (at the moment) that we can delegate the 
“this is an appropriate SRU” decision entirely to OpenVPN upstream, 
which is what a standing MRE effectively is.

> Thank you for considering this request. Please let me know if you need
> any additional information.
> 
> Lena Voytek
> 

If there's additional context you can provide that negates my concerns, 
or if you think we can propose a half-way process (like that proposed 
for bind9), feel free to update us.

Chris Halse Rogers

¹: 
https://github.com/OpenVPN/openvpn/commit/321b04fac8aaaad254fe884472109042d8fb83d7
²: 
https://github.com/OpenVPN/openvpn/commit/3577442530eb7830709538a2e21282b98a97d4f2
³: 
https://github.com/OpenVPN/openvpn/commit/d8dee82f1129ac6d3e4bcdc867726f5d64798dc7
⁴: 
https://github.com/OpenVPN/openvpn/commit/d38d61111d08558e2f52cc9bcdc928ca9c4fca61
⁵: At least *some* of the DCO fixes appear to be infrastructure for 
fixing security flaws.