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 > <[email protected]> wrote: > > Hi Chris, > > > > Thank you for looking into this! > > > > On Thu, Jun 1, 2023 at 5:56 PM Christopher James Halse Rogers > > <[email protected]> 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 > > > <[email protected]> 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 -- Ubuntu-release mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-release
