Freeswan in Debian, or: Why I am such a bad maintainer

[Rene Mayrhofer <rene.mayrhofer@gibraltar.at>]

Dear all,

[I am CC'ing debian-devel here because it might affect freeswan users in 
Debian. Please CC me in replies, I am currently not subscribed to this 
list.]

I have been bad (at least when it comes to my duties as freeswan 
maintainer.....). I am completely aware that the list of bugs on the 
freeswan package(s) is too long and I have been trying to cut it down 
significantly. Obviously, with limited success. Although I am a lot 
happier with the freeswan package now than I have been a year ago (it 
works at least out-of-the-box with standard Debian kernels, which is 
good(TM)), I am still unable to fix all possible combinations of 
freeswan and kernels. Right now, it is not possible to use the 
freeswan-modules-source package with a kernel source (yes, the 
kernel-headers package is not enough for the freeswan KLIPS 
compilation....) that does not already have the NAT patch applied. This 
is bad, because vanilla kernels will not work out of the box. I have 
added the freeswan-modules-source package as an alternative to the 
kernel-patch-freeswan package to make it easier for users, now it's more 
complicated.
As the situation is not going to resolve itself, I currently see 3 
options for working on that:
1. Keep the freeswan package as it is, but remove the NAT patch so that 
module compilation will again work with patched (i.e. Debian) as well as 
unpatched (i.e. vanilla) kernel sources. Currently, I can not remove the 
NAT patch for only the module compilation and leave it in the others 
because a) it will break interoperability with the NAT-patched userspace 
pluto and b) the NAT patch is right now integrated with the X.509 patch, 
and I definitely can't remove that one. Splitting the patches again 
might require lots of effort and I would probably need some help with it 
(as I am very busy with real life stuff right now).
2. Add freeswan-nat, kernel-patch-freeswan-nat and 
freeswan-modules-source-nat packages which have the patch and remove the 
patch from the current packages. This is a) ugly and pollutes the 
package pool and b) would also require to split the patches.
3. Drop freeswan from Debian. As some might already guess, this is my 
preferred solution. Why ? We already have openswan and at the current 
state of development, I see no reason to support both. openswan is a 
direct spin-off of freeswan and is based on the current 2.04 freeswan 
code base. It includes the X.509 _and_ NAT patches and more features 
that are missing in the current freeswan package (e.g. XAUTH support). 
And openswan has been reported to work by a number of users with both 
Debian and non-Debian kernels, with 2.4 IPSec (KLIPS) and 2.6 IPSec 
(native in kernel). Unfortunately, openswan currently does not have the 
alg patch and thus no AES etc. But in the development tree (2.2.x), AES 
is already included, so it is only a matter of time. Please note that 
all those patches are included in _upstream_, unlike freeswan where I 
have been maintaining a sometimes 10+ patch farm inside the debian/ dir 
in the source package. Different crypto algorithms will probably not be 
implemented in the openswan KLIPS because they are already in the kernel 
crypto API and can be used with 2.6 IPSec (with the 2.2.x tree).
But they are currently agile and openswan development is quick: 
http://wiki.openswan.org/index.php/ToDo . I am also in contact with 
openswan upstream and the debian packaging will get integrated into 
upstream very soon now (2.1.4 upstream already included most of it).

So I would like to hear from current freeswan users if they could switch 
to openswan right now and if not, what is missing. freeswan is dead, we 
need to face it. Supporting it in Debian would mean to maintain a 
private source tree (to fix security issue etc.) and there are already 
two different followup projects.
The case with strongswan: I really don't like the split into openswan 
and strongswan and, in my role as the Debian maintainer of freeswan, 
already contacted both teams and tried to get them to unify again. No 
chance, not even a reaction to my email. Currently, the advantages of 
strongswan over openswan are: newer X.509 patch with OCSP (it's clear 
why) and the alg patch. The former is being worked on (X.509 is in the 
openswan patch queue) and latter is at least partially dealt with by the 
development tree (not in the KLIPS code, but for the native IPSec 
stack). I have been asked to also maintain strongswan. Besides the alg 
patch, I currently don't really see a reason for doing it. If some 
feature that is present in strongswan is needed, in my opinion it would 
be better to have it ported to openswan than to have both, which are 
very similar. One "good" freeswan-based IPSec Debian package is better 
than two maintained with only half the time.
Maintaining openswan will be a lot less of a headache than maintaining 
freeswan, i.e. I will be able to make updates quicker (promised) - 
simply because I don't need any "real" patch right now and it seems that 
new features will be integrated rather quickly into openswan upstream.

So please tell me what you think. If there's no real compelling reason 
to keep both, I'd really like to drop freeswan in favor of openswan.

best regards,
Rene