[Swan-dev] idea for libreswan LTS

[Harald Jenny]

Hi Paul

first thanks for taking the time to discuss this in detail :-)

On Sat, Jan 12, 2013 at 07:37:36PM -0500, Paul Wouters wrote:
> 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
> with:
> 
> - 2.4.x being too old - 2.6.x being too much bleeding edge
> - stable versions in distros (debian, RHEL) being too old

Yes this is rather annoying but what is extremly annoying is that 2.4.9
is still in poduction use on Ubtuntu 8.04 LTS...

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

No very good too

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

Well I guess Debian and Ubuntu would really appreciate if this tests
could be easily run on their platforms but I guess that will just come
down to somebody doing the necessary modifications :-).

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

I agree that this is not a good idea 

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

Yes but for me this would rather be a fix than a feature and would fit
in a stable release as a minimal patch - my idea for stable vs
development would be to now focus on getting libreswan in a good
condition codewise, then creating a 3.1 branch which would continue the
development of big features and keep 3.0 as the stable branch. By
keeping git commits small it should then be manageable to cherry-pick
commits from the development branch selectivly and apply them to the
stable branch. Whenever great new features are tested well enough the
dev and the stable branch could be increased (from 3.1 to 3.3 and 3.0 to
3.2) and the game could continue. Perhaps this view is also to biased
this is why I'm requesting comments from as many people as possible...

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

At least for Debian this won't be really needed: stable can get a better
version (if needed) by means of backports (which I already did for
Squeeze) and experimental could be used for really bleeding edge
development versions which people may need for special interop issues
etc...

> 
> So I am not sure really what to do here.

Well first I think we should try to get in touch with the maintainers of
other distribs, aka SuSE, Slackware, Gentoo etc and discuss this
together, I think by coordinating this work over distribution borders we
all will have benefits.

> 
> Paul

Kind regards
Harald