Slashdot Mirror
Crypto and IPSec Merged into 2.5
Corbet writes "Linus has just merged the new crypto API and IPSec implementation into his 2.5 BitKeeper tree. This is the first time that serious cryptographic code has made an appearance in the mainline kernel, and it will hopefully lead to more secure communications for all Linux users in the future."
somewhat, but from what I read bout a week and a half ago... the ipsec impmentation that they are putting in does not yet support ipv4 transport.... ie is useless unless you have hosts fully using ipv6 on both sides of the tunnel. Keep in mind, its not frees/wan, its from the linux ipv6 project.
With the atitude that the frees/wan project maintains, we will never see freeswan merged with mainstream kernel... hell... they still refuse to take patches from us citiziens and residents (that includes linus)
Also in 740.13, to, in part, take into account the "open source" approach to software development, unrestricted encryption source code not subject to an express agreement for the payment of a licensing fee or royalty for commercial production or sale of any product developed using the source code can, without review, be released from "EI" controls and exported and reexported under License Exception TSU.
Jon.
I only found this out recently, but the freeswan.org site lags behind the actual development of freeswan quite a lot. A nice friendly guy runs freeswan.ca, and keeps it chockablock with all the latest patches and stuff.
I've mirrored the downloads as they're so useful.
Get your own free personal location tracker
No, the whole kernel is about 32MB source. Binary is far smaller.
Don't compare a 43 MB binary download to a 32MB source download. That's apples to oranges.
FreeSWAN may be good for crypto, but bad for actually getting your work done. Regardless, the new IPSec code gets the hard part integrated, an ipv4 implementation should be trivial.
Sources themselves are huge compared to the bins they create especially considering source trees for projects like the kernel and X, which have support for many architectures. Much of the source code doesn't even get into the binary in the end.
Slashdot: Where people pretend to be twice as smart as they really are by behaving like children.
The bzip2 is 32MB. Get a real compression mechanism.
Unzipped only counts in terms of disc space. 160MB is small change for most machines. If its not, compile the kernel somewhere else and ship it over.
Still, it further proves my point, because that means we're goign from 160MB source to 10MB compiled code.
My whole point is people bitch about bloat when the kernel is anything but bloated. For all the stuff it contains (which is a lot), submitted by all those different people (which is a lot), its incredibly lean.
I agree! The linux kernel is at least 2 years behind in any IPsec implementation compared to OpenBSD or even FreeBSD. What's going on here? Does that make sense? Usually it's the Linux folks that are ahead of the game, but not this time.
I guess the Linux folks wanted to make EXTRA SURE they didn't leave any BSD code in the kernel without a copyright before they added it to CVS.
Go ahead... troll me! I dare you!
If you want to see bloat, take a look at the commercial UNIXes.
/stand/vmunix
For example, on a random HP 11.0 box here:
-rwxr-xr-x 1 root sys 18946872 May 9 08:43
That is a 19 megabyte binary kernel. It would be interesting to see how big the source is...
You'll be glad to know that the Cerberus/PlutoPlus implementations done by NIST are going to be more widely available in the near future. Specifically, I've been working on extending them to support large-scale configuration management of it. I ported the cerberus (read: ipsec) support to the 2.4 kernel, and am wrapping up the final details at the moment. The good news about it is that it's not done in the hacky way that freeswan did stuff. I'll be creating a sourceforge project for it within the week (I have a deadline to do it by next week), so look for it shortly.
I actually tried to approach the FreeSWAN folk to considering instrumenting their code with our policy-role-based configuration management support infrastructure, but they said "no US no way" and I didn't really have a choice if I wanted my patches rolled back into the project. The Cerberus and PlutoPlus developers, on the other hand, have been much more polite and helpful.
The next site to slashdot will be ready soon, but subscribers can beat the rush and start slashdotting it early!
Al Qaeda has ninjas!