Kernel Modules in Fedora -x

[Paul Wouters]

On Fri, 3 Aug 2007, Jesse Keating wrote:

> Which is again not helpful in Fedora as we jump major numbers all the
> time.  The very crux of my argument is that if it's good enough to be
> in Fedora, it's good enough to be in the kernel package.  And if it's
> not, it's not.

I disagree. Take the KLIPS openswan kernel module. Most openswan users
want it because without the kernel module's ipsecX interfaces, sysadmins
find it too hard to configure their firewals properly (especially with NAT
added to the mix, and NETKEY's odd packet flow you can't tcpdump properly).

There are valid reasons for this code not to be included in the kernel,
and we wishewe could restart a dialog with kernel developers to phase
out the dual stack issues. The Openswan project now loses most of its
time by playing catch up to massive changes in 2.6.2x kernels.

But there is really no valid reasons for not including it in Fedora,
since the code has proven to be rock solid for 5+ years, is widely used
and widely prefered over the NETKEY code by those sysadmins involved.

The reason why I haven't submitted a kmod package for KLIPS, is that for
it to work properly with NAT, one small patch to udp.c is needed (two if
you want to add support for clashing IP's in transport mode IPsec required
for running a more then one-user L2TP server), and my attempt years ago
to get that patch in (even disabled so people would have to rpmbuild it
but no other people could possible be affected) was unsuccessful.

openswan klips has been in the ATrpms kernel since they started.
Debian provides klips kernel module packages. Distributions like Fedora
should enable such choice.

Paul
ps. if there are redhat/linux kernel develpors following this thread, I'm
more then happy to talk about our extensive work done to gut KLIPS of its
own crypto and pfkey code and make it call ESP() and cryptoapi, and about
the whole acrypto vs OCF requirements and implementations to move things
to a unified stack everyone can be happy with.