MRE request for OpenVPN

Thu Jul 6 14:11:16 UTC 2023

Hi Chris,

On Thu, 2023-07-06 at 14:40 +1000, Christopher James Halse Rogers
wrote:
> 
> 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.

I think that's a reasonable outcome for this package. I'll work on
updating Focal then move on to Jammy, seeing what can be done after a
thorough dig through changes. We can always backport individual bug
fixes if upstream microreleases end up being too dangerous. Thanks for
looking into this!

> 
> > > 
> > >  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
> 
> 
Lena