[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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

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,

Reply to: