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."
how does exportation work with this? i thought people weren't allowed to export code w/ serious type crypto in it.
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)
Too bad that full ipsec, such as provided by
Freeswan is still not in the kernel. I find it a
bit sad that Dave Miller and John Gilmore can't
figure out a proper way to resolve their problem
(John wants no US hands on the code, Dave wants
no code he can't touch in the kernel)
But at least the beginning is there, and if the
USAGI ipsec gets in, it should learn to talk to the userland tools, such as Freeswan, because Freeswan has extra features that "stock ipsec" doesn't have, such as Opportunistic Encryption.
With kernel modules you don't need to have the stuff loaded *in* the kernel all the time. All the distros I've used recently only have the stuff essential to run in the kernel image in /boot - the rest is all modules.
Oolite: Elite-like game. For Mac, Linux and Windows
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
Due to kernel modules and the fact that you can "roll your own," the kernel can be as bloated as you want, the only downside is the size of the download. The current installation procedure works well enough for this, though the only feature it really lacks imho is querying dependencies satisfied by an entry.
Really though, kernels can and will always fit on teeny floppies, providing they're trimmed down enough. Regarding your comment about the end user getting the kitchen sink, have you ever looked at how distros handle this?
Most make a generic trimmed down kernel cross-compiled for the architecture and build all the modules. It may be the case that the distro copies hoards of modules, but that still isn't going to be as big a package as, say, glibc. If "joe-shmoe" doesn't have Bluetooth or scsi hardware, the corresponding modules won't get loaded, and as a result the bloatedness of the /lib/modules// directory won't bleed into the performance of the actual running kernel.
Slashdot: Where people pretend to be twice as smart as they really are by behaving like children.
In my experience, Windows 2000's support for IPSec is one reason why it has snared a foothold in many businesses. Having IPSec in mainstream Linux distributions would let us cut Bill off at the pass.
I hope we're not far from seeing adoption of Linux in places like the financial services industry. If the distributors can make IPSec painless to configure, Linux will make inroads in such industries very quickly.
"I am root. Bow before me." To this I say, "You are root, and you bear the sins of the world upon your shoulders."
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.
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.
Freedom of speech also implies freedom of anonymous, or even encrypted speech, a concept that politicians have destroyed completely with "campaign reform."
The IPCC has purposely engineered a massive scientific fraud.
Well, seeing as this isn't FreeSWAN, maybe you want to restate your objections? I mean, complaining about FreeSWAN when talking about putting ipsec in the kernel, doesn't make much sense if it isn't FreeSWAN that they are using...
But on the other hand, who wants to read the article when you can, instead, spout off and look like an idiot?
Why no fork yet?
Because it's a large project, it's really complex, and it's a bitch to keep up with things.
I should know - I'm the author of Super FreeS/WAN, a pseudo fork with includes alot of patches (NAT-T, X.509 Certs, AES/Blowfish/etc... ) @ http://www.freeswan.ca/code/super-freeswan
It takes a few hours a day to stay on top of things. One the major ones is user support. IPSec is not easy to configure currently, especially once you introduce X.509 certs & MS Windows clients using any number of clients. So there's hundred of questions about configs, how tos, etc...
If you want to fork it, please, go ahead. Just remember that a fork isn't just the code - you take users with you.
One man's bloat is another man's features.
Hypothetical: I can't believe OpenOffice is so bloated compared to EDLIN from MS-DOS!
Maybe it's "feature loaded" instead of bloated? While it is true that you can use OpenOffice to duplicate tasks that you might have done in EDLIN, it is capable of so much more.
There is another kind of bloat which is not caused by features. This kind of bloat does not appear to be present in Linux. The kind of bloat I'm talking about is caused by "optimization". I don't mean optimizing for fast code or small code, but optimizing for "release date". Hey Mr. Customer, would take that new spreadsheet upgrade six months sooner if it required 25% more computing resources to run? All consumers I know would answer Yes. So this is a type of optimization. Optimizing for development time instead of optimizing for computer resources. Given the current low and decreasing cost of computer resources, there is some balance of this that makes sense. Just as once upon a time the "bloat" and value of high level programming languages was hugely debated. Now everyone uses high level languages to optimize for development time. The fact that I could spend six extra months doing it smaller and faster in assembler doesn't matter. Well, today it's the same thing. I don't mean that bad code is written on purpose, just that development time is valued above comptuer resources and machine optimizations, profiling, etc. Again, Linux does not appear to "suffer" from this type of "optimization".
Another type of bloat is just from plain bad programming. It was not a purposeful decision to optimize development time, it was just the the program is badly written. Linux does not appear to suffer from this kind of bloat either.
I'll see your senator, and I'll raise you two judges.