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. -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
