[Swan-dev] Consdiering maintenance releases?

[Paul Wouters]

On Thu, 13 Jan 2022, Daniel Kahn Gillmor wrote:

> In particular, as the debian maintainer, i appreciate the attention to
> older versions that some stable distros are still shipping. (debian's
> stable release 11 ships libreswan 4.3)

hmmm :P

> But as noted in https://github.com/libreswan/libreswan/pull/613, the
> patch released for 4.2 and 4.3 didn't apply safely (caused a build
> failure).  Not a huge deal, and a relatively obvious fix in this case,
> but i do wonder whether it would make sense to issue point releases
> (e.g. 4.3.1) for those versions that you're willing to backport security
> fixes to?

We have thought about it and thought about doing it as exception here,
but we ended up not doing it. For one, we really don't want people to
linger on old releases even more, and providing a stable will just
mean that we end up maintaining two branches and needing to do too many
backports. Additionally, if you look at testing.libreswan.org, you will
see a huge increase in tests passing. So we felt that even though a lot
of changes came along with the CVE, since it passed so many more test
cases, it would still be better to ship 4.6 than a 4.5.1.

> Obviously, as an external maintainer, i'm not in a position make a 4.3.1
> release on behalf of the project.  And I've already sent the necessary
> patch to the debian security team so that debian stable should be fixed
> shortly. So for this round i don't need it.  But if future
> vulnerabilities are discovered that apply to 4.3, and narrowly-targeted
> fixes are made available, i'd actually prefer to push upstream 4.3.x
> into debian stable.

I understand you desire. We will keep provding patches, but I don't
think we will end up doing such releases. If anything, we want to nudge
people to be a bit more modern than 1+ year old releases.

> I'd prefer that because i'd be happier knowing that the upstream
> build/test machinery was run against the particular combination of
> patches we ship, rather than manually applying specific patches and
> hoping that i've landed on the expected variant.

The CVE related patches are usually pretty minimal, as these are almost
always hitting a passert() or null pointer dereference. We tend to not
run a full test run on those ourselves.

> Alternately (or in addition?), i could try to replicate the upstream
> testing practices on the debian testing infrastructure, but I haven't
> figured out how to get debian's testing infrastructure to run all the
> complicated kvm- or docker-based stuff that i think y'all use upstream.

I'm sure there will be lots of output changes running the tests on
debian. We do our best to make it as agnostic as possible, but things do
creep up, for instance due to different kernel versions or iproute
versions. And then you have the issue of wanting to run the latest test
cases with the older version and having to weed through lots of false
positives. Where as if you run with the older version of tests, then you
might be missing things.

It's good to have these conversations, even if it does not result in any
changes, so thanks for bringing it up.

Paul