[Swan-dev] idea for libreswan LTS

Paul Wouters paul at nohats.ca
Sun Jan 13 02:37:36 EET 2013

On Sat, 12 Jan 2013, Harald Jenny wrote:

> as I consider myself involved in both upstream and Debian libreswan
> activities I want to propose something which I think will be a very
> valuable addon to current libreswan development: The creation of an LTS
> branch. The previous main problem of openswan was that certain bug and
> security fixes were introduced by new upstream releases which needed to
> be backported to the versions shipped in the various stable Linux
> distributions. My idea would be to create a Long Term Support branch
> which would be guaranteed to get bug and security fixes (maybe also
> smaller feature enhancements) with as little code changes as possible.
> The main objective here would be on one hand minimizing the maintaince
> overhead for the package maintainers of the various Distributions while
> on the other hand allowing their users an easy installation of a stable
> and secure software (for some people using RedHat or Ubuntu LTS it may
> just not be an alternative to upgrade IPSec to the newest available
> version while some newbie linux user may not even know how to compile a
> software from source). I know this may be a very controversial issue so
> I want to put this to discussion on this list, so I ask everybody to
> share his/her opinion on this matter.

This is what "we" tried to do with openswan 2.4 and 2.6. But we ended up

- 2.4.x being too old 
- 2.6.x being too much bleeding edge
- stable versions in distros (debian, RHEL) being too old

and people ended up with various 2.6 versions, 5 to 10 releases old

Part of the problem was regressing caused by the UML testing suite no
longer being operational. With the new KVM testing suite, we should
be able to guarantee there will be no regression between versions,
and any change of behaviour being adjustable by configuration options.

That said, I will face the same problem as I am upstream and the libreswan
maintainer in RHEL. What I want to avoid doing is shipping a version
called 3.4 that is really 3.6 with all or most of the fixes backported,
just because of the "LTS" idea that upgrades are bad.

So, I understand your problem, but I am not sure I know how to deal with
the situation properly. Usually people doing IPsec want (or need) the
latest version to interop with other vendors, such as when the android
phones introduced the IKE negotiation bug in android 4.0 ICS.

I was also thinking of maintaining a repository on download.libreswan.org,
so people who want can add that to always get the bleeding edge version,
as opposed to their vendor version, but ideally the vendor ships both
stable and feature rich versions.....

So I am not sure really what to do here.


More information about the Swan-dev mailing list