<div dir="ltr"><div>Hi Chris,</div><div><br></div><div>Thank you for looking into this!<br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Jun 1, 2023 at 5:56 PM Christopher James Halse Rogers <<a href="mailto:raof@ubuntu.com">raof@ubuntu.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi Lena,<br>
<br>
Sorry this has taken so long for someone to get to. Review below:<br>
<br>
On Mon, Feb 27 2023 at 13:25:25 -0700, Lena Voytek <br>
<<a href="mailto:lena.voytek@canonical.com" target="_blank">lena.voytek@canonical.com</a>> wrote:<br>
> Hello,<br>
> <br>
> I would like to request a Microrelease Exception for the OpenVPN<br>
> package in Ubuntu Jammy and Focal. I created a wiki page containing<br>
> relevant information here:<br>
> <br>
> <a href="https://wiki.ubuntu.com/OpenVPNUpdates" rel="noreferrer" target="_blank">https://wiki.ubuntu.com/OpenVPNUpdates</a><br>
<br>
This is a well-written and usefully-detailed MRE process proposal.<br>
<br>
My only question to pin down in the proposal would be exactly what <br>
releases we'll be considering. Certainly releases in the Full stable <br>
support category; presumably also releases made in old-stable support. <br>
Would we also be expecting to pull in snapshots in the git-tree-only <br>
support timeframe under this MRE?<br></blockquote><div>The MRE would ideally support full stable and old stable since both support versioned releases, source tarballs, and provide fixes that may otherwise not be added by the security team. I think the git-tree only lifecycle should be ignored unless a relevant bug fix is provided in which case it should be added through the normal SRU process. I updated the document to show this.<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
> Having an MRE would allow us to take advantage of OpenVPN's stable<br>
> release policy, providing many existing bug fixes to Focal and Jammy,<br>
> which are using 2.4.x and 2.5.x respectively.<br>
> <br>
<br>
After having a bit of a browse of the 2.6 release branch, I'm not <br>
entirely happy that OpenVPN's understanding of “stable release” <br>
matches the SRU policy.<br>
<br>
*Most* of the patches on that branch look like either fixes we want or <br>
changes to code we don't care about (Windows, *BSD, etc), but there's a <br>
thread of patches to DCO which seem to be feature additions at least <br>
one of which¹ modifies user-visible behaviour in <br>
backwards-incompatible ways. This is helpfully called-out in the 2.6.2 <br>
release notes², under “User visible changes”, but this suggests <br>
that we'll *at least* need a process like the for proposed bind9 <br>
exception where someone explicitly checks the release notes and calls <br>
out anything that might be a problem.<br></blockquote><div>I think this is a reasonable case for checking through release notes and announcements to see if there are any problematic changes. I've drafted an additional section, process item, and template item in the document, similar to my changes to bind9. <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
The 2.5 release branch looks better in this regard, although a sampling <br>
there includes a commit³ which includes “Regression warning: shared <br>
secret setups are left out of the backoff logic.” in the commit <br>
message (and nothing in the release notes), and at least one new <br>
feature commit (implementing auth-token-user⁴).<br></blockquote><div>Luckily the auth-token-user addition is already in Jammy, but this would otherwise be a good example of a feature to note for discussion prior to uploading a new release. This is the same case for connect-retry backoff modification commit, which does change behavior slightly to fix timeout issues (<a href="https://community.openvpn.net/openvpn/ticket/1010">bug #1010</a>). It is unfortunate that the note does not show up in the release notes though. I also don't see any other instances of a regression warning statement in a commit message in the repository. <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
I lack the context to decide whether or not these regressions are <br>
concerning and whether these new features are really bug fixes⁵, but <br>
with the context I have I'm not sure that a standing MRE for OpenVPN is <br>
appropriate.<br>
<br>
I note that 2.4.x (in Focal) has already dropped out of *all* support <br>
categories. An SRU to update to Focal to 2.4.12 still might be <br>
appropriate - the degree of testing, both upstream and in-archive, <br>
appears good - and that one-off upload would be the only result of this <br>
MRE for Focal anyway.<br></blockquote><div>I agree that Focal should be a one-time upload to get up to date with 2.4. I've made it more explicit in the document.<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
It's *also* quite possible that 2.5.9 might be an appropriate SRU for <br>
Jammy. I'm just not confident (at the moment) that we can delegate the <br>
“this is an appropriate SRU” decision entirely to OpenVPN upstream, <br>
which is what a standing MRE effectively is.<br>
<br>
> Thank you for considering this request. Please let me know if you need<br>
> any additional information.<br>
> <br>
> Lena Voytek<br>
> <br>
<br>
If there's additional context you can provide that negates my concerns, <br>
or if you think we can propose a half-way process (like that proposed <br>
for bind9), feel free to update us.<br></blockquote><div>A bind9-adjacent process would probably work well for OpenVPN. If there is any additional information I should add to the doc to help with this please let me know.</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Chris Halse Rogers<br>
<br>
¹: <br>
<a href="https://github.com/OpenVPN/openvpn/commit/321b04fac8aaaad254fe884472109042d8fb83d7" rel="noreferrer" target="_blank">https://github.com/OpenVPN/openvpn/commit/321b04fac8aaaad254fe884472109042d8fb83d7</a><br>
²: <br>
<a href="https://github.com/OpenVPN/openvpn/commit/3577442530eb7830709538a2e21282b98a97d4f2" rel="noreferrer" target="_blank">https://github.com/OpenVPN/openvpn/commit/3577442530eb7830709538a2e21282b98a97d4f2</a><br>
³: <br>
<a href="https://github.com/OpenVPN/openvpn/commit/d8dee82f1129ac6d3e4bcdc867726f5d64798dc7" rel="noreferrer" target="_blank">https://github.com/OpenVPN/openvpn/commit/d8dee82f1129ac6d3e4bcdc867726f5d64798dc7</a><br>
⁴: <br>
<a href="https://github.com/OpenVPN/openvpn/commit/d38d61111d08558e2f52cc9bcdc928ca9c4fca61" rel="noreferrer" target="_blank">https://github.com/OpenVPN/openvpn/commit/d38d61111d08558e2f52cc9bcdc928ca9c4fca61</a><br>
⁵: At least *some* of the DCO fixes appear to be infrastructure for <br>
fixing security flaws.<br>
<br></blockquote><div><br></div><div>Thanks,</div><div>Lena Voytek <br></div></div></div>