MRE request for OpenVPN

Thu Jul 6 04:40:34 UTC 2023

Hi Lena,

On Tue, Jun 6 2023 at 10:25:15 -0700, Lena Voytek 
<lena.voytek at canonical.com> wrote:
> Hi Chris,
> 
> Thank you for looking into this!
> 
> On Thu, Jun 1, 2023 at 5:56 PM Christopher James Halse Rogers 
> <raof at ubuntu.com> wrote:
>> 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?
> 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.
>> 
>>  > 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.
> 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.
>> 
>>  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⁴).
> 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 (bug #1010). 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.
>> 
>>  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.
> 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.

I've floated this with some of the rest of the SRU team, and I think 
I'm going to (narrowly) reject this MRE request.

That said, I'm only rejecting a blanket MRE here. The test plan you've 
documented on https://wiki.ubuntu.com/OpenVPNUpdates is good, updates 
to OpenVPN would be valuable, and upstream seems *mostly* trustworthy 
(although a little less trustworthy than bind9).

I'm not saying that we shouldn't update Focal to 2.4.12. I think that 
we *should* update Focal to 2.4.12 - that looked like a pretty safe set 
of changes - and I would accept such an SRU. I'd also be happy to 
consider 2.5.9 for Jammy, although I'm less confident there.

Upstream microreleases of OpenVPN can be considered for SRUing (as for 
*all* packages!), but I think we should keep the additional friction of 
“here are the changes, and why they are safe” SRU review rather 
than presume upstream microreleases are safe.

>> 
>>  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.
> 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.
>> 
>>  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.
>> 
> 
> Thanks,
> Lena Voytek

Thanks again for your work,
Chris