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.
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
--
Ubuntu-release mailing list
[email protected]
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/ubuntu-release
