Slashdot Mirror
FreeS/WAN Project Bows Out
V. Mole writes "After five years, the FreeS/WAN project has decided to end development. The main reason seems to be that although the project was technically successful, it was not making much progress with its political goals of encrypting a significant portion of all Internet communications, although one might guess that the selection of KAME for the standard Linux IPSEC implementation might also have influenced this decision. And don't panic, the software will remain available, and of course some other group is free to continue development."
And don't panic, the software will remain available, and of course some other group is free to continue development
this is probably one of the reason why OSS is A Good Thing.
How many commercial products are there that were started over five years ago that are still in current development? There are quite a handful still in current development--but vastly more that have been abandoned completely.
Both in the open source world and in the commercial world, the vast majority of projects die. The difference is that in the open source world, the dead projects can still be put to good use in a new reincarnation down the line.
Dlugar
Computer Go: Writing Software to Play the Ancient Game of Go
OE doesn't *need* DNSSEC.
It just benefits from it. Without it, you are vulnerable to *ACTIVE* attacks against the DNS. With DNSSEC, you are totally immune.
The real thing that bones up OE is that you need a static, public IP (since OE isn't defined for NAT'ed IPsec). If you want to do full OE, then you access to the reverse map too. How many have that? Well, if you don't, you probably don't have static IP or an AUP that even lets you sneeze.
But, it could be made to work with NAT'ed IPsec, and it could also do enrollment in the reverse map via DHCP.
You know what's funny? Recent Linksys VPN routers (ie: WRV54G) use FreeS/WAN for IPsec (they are built on the OpenRG platform).
So you might be using it anyways
to be learned here. The stated goal of the project was to increase the amount of traffic that is encrypted on the internet. While this does not directly conflict with the goal of making as much software as possible "free" (as in beer), it does set a different goal.
Why the hell am I bringing this up? Well, one of the problems with FreeS/WAN was that it would not work with low-bit encryption. This was done to promote their political goal. But it also had the side effect of inhibiting adoption at the places where for whatever reason people had to interoperate with low-bit encryption applications or setups. The last time I checked (which I have to admit was over 2 years ago) the FreeS/WAN project explicitly stated that they would refuse to cooperate with anyone who tried "subvert" the project by building-in interoperation with low-bit encryption.
So what is this lesson to be learned that I am talking about? When fighting an uphill battle (which a volunteer project challenging for-profit institutions always does), it may not be wise to make it more difficult for people on the sidelines to agree with your cause.
Linux was built on much better technology than Windows (nfs vs smb, ext vs fat, separate windowing subsystem vs windowing system as part of the kernel, etc), but it didn't gain in popularity because it decided it replace all the Windows boxen. The technical decision was made to cooperate with them. The fundamental decision on priorities was to hold interoperability above politics. FreeS/Wan took the other road.
Any guest worker system is indistinguishable from indentured servitude.
The 2.6 implementation is not as mature, but it has excellent success factors. It was written by an alpha kernel hacker, it's in the mainline, and it's open in the Linux tradition. An influx of former FreeS/WAN users may be just what it needs to work out the kinks. FreeS/WAN has done a great service, and is now doing another by throwing its momentum behind an implementation with better long-term prospects.
The evaluation of an action as 'practical' . . . depends on what it is that one wishes to practice.
I've been a Linux user for 10 years, and a Unix System Administrator for 3 years, but Freeswan was among the most challenging things I've ever installed. I found that nothing less than reading the documentation from cover to cover is sufficient to understand it. I'm not suprised that it never caught with any sort of mainstream. Don't get me wrong, I am all for the vision of a secure-by-default internet. But unfortunately, it's so tough to install that only die hard security buffs have the patience to figure it out. Where is the ncurses-based "kernel setup wizard" script with forward and backward buttons? A checklist-based helper to point out what is missing next in getting the damn thing installed properly? A webmin module? A gui based connection configurator, called, say, [g|k]freeswan-conf? ESR has it dead on: without a thick slathering of user friendliness, this sort of project cannot succeed on any widespread level. Them's the breaks. I wish things were diffrent, believe me.
... not making much progress with its political goals of encrypting a significant portion of all Internet communications ...
Part of the problem with the FreeS/WAN group was that they DIDN'T WANT TO INTEROPERATE. Their attitude toward single DES was that they refused to support it because it wasn't sufficiently secure. As I recall, they wouldn't even accept patches that provided it as an ifdef with the default turned off. So, they were a pain in the ass to use for any serious interoperative commercial development, which obviously requires stooping to single DES.
This quote from the FAQ at freeswan.org sums up their attitude regarding interoperability:
"As we see it, it is more important to deliver real security than to comply with a standard which has been subverted into allowing use of inadequate methods."
FreeS/WAN saw it wrong. Sure, single DES is not macho enough, but interoperating is pretty damned important, even if that means supporting a protocol that is beneath your 'leetness.