Follow Slashdot blog updates by subscribing to our blog RSS feed

 


Forgot your password?
Close
typodupeerror
×
Linux Software

Crypto and IPSec Merged into 2.5 229

Posted by Hemos from the gettin-it-on dept.
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."
This discussion has been archived. No new comments can be posted.

Crypto and IPSec Merged into 2.5 More

Crypto and IPSec Merged into 2.5

Comments Filter:

  • Wow! (Score:2, Interesting)

    by Cyph ( 240321 )
    I really like the way the 2.5 kernel is progressing, a lot of the patches that I've been applying manually to the 2.4 tree have already been merged into the main tree of the 2.5 kernel.

    Can't wait until release, this thing is going to rock. :)

  • Excellent - no more FreeSWAN patches (Score:3, Insightful)

    by JKR ( 198165 ) on Wednesday October 30, 2002 @09:31AM (#4563983)
    This should make VPN-in-a-box simpler to set up, particularly for distros that use their own kernel packaging scripts.

    Jon.

    • Re:Excellent - no more FreeSWAN patches (Score:5, Informative)

      by LWolenczak ( 10527 ) <julia@evilcow.org> on Wednesday October 30, 2002 @09:36AM (#4564031) Homepage Journal
      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)
      • If frees/wan won't take contributions from the US why doesn't someone in the US fork it? Isn't this the way OSS is supposed to deal with stubborn maintainers that have different ideals than a large number of developers?
        • Thats a question I really can't answer. I should have thought about it many months ago when I found routing bugs in frees/wan internal routing table.... when they refused to hear anything about it and claimed it must have been a configuration error..... but I've been using frees/wan for years... since frees/wan 1.3 i think..... I know it inside and out. Perhaps it is time to fork... or wait till FreeS/WAN 2, and fork it. You are right.... it is time to fork it.

        • Re:Excellent - no more FreeSWAN patches (Score:5, Insightful)

          by velkro ( 11 ) on Wednesday October 30, 2002 @10:46AM (#4564631) Homepage
          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 of the major problems with frees/wan is the documentation. "Oh, you might be able to do this, we dont know.." When it has been posted to the mailing lists, and discussed "oh, Here is how you do it".

            I was going to use your fork, but I lost my job. :( Perhaps I should write a patch that allows for more then one type of network interface so it is easier to sue ospf..... and changing the internal routing table so its more kind to other things such as routing protocols.
            • 2.00 + snapshots, and forthcoming 1.99 have vastly improved docs, and a way better inter-op doc.

              I run OSPF + BGP over FreeS/WAN using GRE, which seems to be the simplest way to do it - there's been alot of dicussion lately on the lists about doing this.

              Sorry to hear about the job loss, but when you get back on your feet and want to continue, just flip me a note and I'll give you a CVS repository if you want to start with.

              ken@freeswan.ca
        • I believe that's kind of what the article is announcing. A fork and Linus likes it enough to include it in his kernel.
      • 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)

        Considering the US's asinine stance on crypto export, that's just good sense.

        That said, there's no reason the frees/wan code couldn't go into the kernel in a stable form, but still be maintained separately overseas.

      • >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)

        Not to mention they refuse to include support for the faster [freeswan.org] (but less secure) type of IPSec, thereby causing me to run Win2k on my router for a short while. I believe they even say it's fully valid to use IPSec in this manner (in fact it's part of the spec, so without it they shouldn't be calling it IPSec, IMHO), but they just don't want to support it in the faq, 100% due to attitude.

        Developers may have a right to any attitude they desire, but they should understand their software is just going to be replaced (in the mainstream) by software from someone with less attitude. Let's hope that's what happens with freeswan. I think we don't need another OSS [4front-tech.com]-style crippled set of kernel software. (Did they move to ALSA [alsa-project.org] yet? I hope so!)

        Just my 2 cents.
        • Not 100% due to the attitude more than anything else. They by default choose not to allow single DES to protect users/organizations from themselves. Tell me a legitimate reason why, with today's hardware, you need only single DES? It is really not that secure in this day and age? In any case, when I set up FreeS/WAN on a system, two sets of patches immediately go on, x509 cetificataes (ala http://www.strongsec.com), and cipher plugins (http://www.irrigacion.gov.ar/juanjo/ipsec/). I usually do AES when going to other patched FreeS/WAN, and use the enhanced 3DES from that suite when dealing with implementation lacking AES...

          AES is truly the way to go. There are a number of aspects of FreeS/WAN where they felt things the standards required to be available were too weak to be secure. They are mostly compliant with the specs, but I agree with them that certain things really have no use in security except to make things easier on organizations like the NSA...

    • Simpler setups for important security features are great and definitely do depend on this infrastructure being in the default kernel distributions. (I kind of like the idea of cryptographic filesystems enabled by default on laptop computers that could stolen.)

      But, as we all know, that's not enough.

      That simple setup has to be exceedingly well-designed so that 2-minute Click-through VPN installations are not left vulnerable due to some trade-off for more convenience.

      Everyone knows and has deservedly berated Microsoft for making poor choices in this matter; let's not have widely-deployed commercial Linux distributions make the same mistake.

      "Everything should be made as simple as possible, but not simpler."

      -- Albert Einstein

  • exportation issues? (Score:5, Interesting)

    by kochsr ( 144988 ) on Wednesday October 30, 2002 @09:32AM (#4563998) Homepage
    how does exportation work with this? i thought people weren't allowed to export code w/ serious type crypto in it.

    • Re:exportation issues? (Score:5, Funny)

      by Angry White Guy ( 521337 ) <CaptainBurly[AT]goodbadmovies.com> on Wednesday October 30, 2002 @09:36AM (#4564041)
      I think that this would be the same as not letting Stephen Hawking leave the country because he knows too much

    • Re:exportation issues? (Score:5, Informative)

      by JKR ( 198165 ) on Wednesday October 30, 2002 @09:37AM (#4564046)
      The requirements have been relaxed recently; see here [epic.org] for more details. In particular:

      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.

      • Great. . . (Score:2, Funny)

        by mntgomery ( 620581 )
        so we can't sell encryption to our enemies, but giving it to them is fine? ;)

      • Re:exportation issues? (Score:5, Interesting)

        by leto ( 8058 ) on Wednesday October 30, 2002 @10:13AM (#4564337) Homepage
        If you had followed the entire debate, you know
        that these "relaxations" are declarations (yes,
        those like a King makes), and can be withdrawn by Bush at any time, without any democratic process.
        That's why Gilmore and Daniel are taking the stance they are taking.

        Crypto is your fundamental right, not a fluffy
        allowance from your Emperor.
        • If that's the case, the inclusion of the crypto code in the kernel is a good thing.

          An awful lot of people use the kernel, and interfering with its distribution would generate lots of waves, interfere with lots of businesses, anger lots of tech journalists, etc.

          Politically, I just don't see how they could muck with it.
        • There are no such things as fundamental rights. nowhere, never. Have a nice day.:{)||
          • There is also no such thing as reputation, money or birthdays.

            If enough people believe that something is a fundamental right then it is. The poster was just trying to convince more people to believe in his version of fundamental rights which happens to include encryption. You are trying to convince more people to believe that they have no way to affect what our society considers to be fundamental rights and give up in despair.

            Good luck to both of you.
        • If you had followed the entire debate, you know that these "relaxations" are declarations (yes, those like a King makes), and can be withdrawn by Bush at any time, without any democratic process.

          Yes, but it was exactly the same kind of executive decree that made crypto illegal to export to begin with. There is no law in the US that states that crypto is a munition or that it can't be exported.

          At this point, it really just doesn't make sense to hold off on adopting crytpo out of fear that the US is going to surprise everybody and yank our crypto rights out from under us. The cat, as they say, is out of the bag. It won't go back in. The government is welcome to try to re-regulate crypto export, but it won't work. (They actually tried this briefly after 9/11, and the proposals died silently.)

          This news about crypto in the Linux kernel is wonderful. The more crypto is out there, integrated into our daily lives, the harder it will be for somebody to try to take it away from us.

          noah

      • The requirements have been relaxed recently

        If only the people [cypherspace.org] who got [cypherspace.org] those Perl RSA tattoos [cypherspace.org] could have known...

        -B

    • Re:exportation issues? (Score:5, Funny)

      by Skirwan ( 244615 ) <skerwin.mac@com> on Wednesday October 30, 2002 @10:45AM (#4564611) Homepage
      exportation
      Is anyone else subtly annoyed that 'exportation' is a word?

      It sounds like something completifically inventorated, but sure enough the dictionary verificates its existification. I am extremifically annoyarated to be denyified this oppurtunitization to drop a Bush joke.

      --
      Damn the Emperor!
    • Crypto export laws were always kind of a joke anyway. It seems like the only difference was in the number of bits, like 1024-bit was prohibited but 128-bit was not. What's keeping people from just extending the code a little bit? Can someone who knows more about this please comment?

  • Too bad it's not Freeswan (Score:5, Interesting)

    by leto ( 8058 ) on Wednesday October 30, 2002 @09:36AM (#4564042) Homepage
    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.

    • Re:Too bad it's not Freeswan (Score:3, Informative)

      by Anonymous Coward
      Uh, calling FreeSWAN a "full" implementation is very misleading. Its IKE does not support Aggressive Mode which is pretty much a requirement for virtually every Hardware IPSEC VPN out there.

      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.

      • According to the FreeS/WAN documentation [freeswan.org], Aggressive Mode is not required for an IPSEC implementation, as long as you support Main Mode. Fix those hardware boxes, I'd say. If they don't support Main Mode, are they still IPSEC compliant?

        The only reason I can think of why you want this, is when you have a dynamic IP address and you want to use a Preshared key. Get a fixed IP or start using X.509 certs.

        Aggressive Mode exposes some information, plus it might make DDoS easier to do.

        • >The only reason I can think of why you want this, is when you have a dynamic IP address and you want to use a Preshared key.

          So I see. Basically any home user using an ISP shouldn't expect to ever have any kind of crypto at all because it is slightly weak.

          Next up: Master quits making front door locks. States that most homes have windows and therefore their locks are ineffective, so they will quit selling them altogether.

          A lack of Agressive Mode (among other things) is the _only_ reason my previous ISP didn't support Linux. In fact, they wanted to support Linux, and eventually switched over to a non-encrypted system and released a Linux client for it.

          So, who really wins in the end? Nobody. Ho hum.

    • Re:Too bad it's not Freeswan (Score:5, Insightful)

      by The Pim ( 140414 ) on Wednesday October 30, 2002 @10:30AM (#4564502)
      While I appreciate all the work that freeswan has done for us, I am much more confident for the long term in work done by the core Linux networking hackers. The freeswan guys seem much more concerned with making it work (in typical situations) than making it right, with the result that the implementation is horribly klugy.

      Two examples are the need for a "nexthop" parameter, when the kernel already has this information in its routing tables; and the need to turn off route filtering. Both make it clear that freeswan is not properly integrated (and if you look at the freeswan docs, you'll see that this general problem been on the "to fix" list for a long time).

      • Ummm, not so, I have not ever specified nexthop in any of my configuration. Same with route filtering, I leave it on, without consequence....

        I've seen these complaints about the non-integration of FreeS/WAN before, but usually because people fail to understand the system. They make recommendations so you know exactly what is going on and give the ability to override certain settings just in case, but most of the time the extremely verbose ways of dealing with the parameters as recommended in many howtos is overkill, and could be omitted...
      • 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.

  • Kernel bloat ? (Score:4, Insightful)

    by MosesJones ( 55544 ) on Wednesday October 30, 2002 @09:37AM (#4564050) Homepage
    This is great that these things are comming as standard in the kernel, but so many things are "standard" now its getting pretty large for joe-schmo average user who will get a full kitchen sink kernel with their distro.

    This is also great for creating products like VPN gateways et al, but is it time to consider a different structure for kernel builds, with modules being seperately managed with a smarter installation procedure.

    • Re:Kernel bloat ? (Score:5, Insightful)

      by Alioth ( 221270 ) <no@spam> on Wednesday October 30, 2002 @09:43AM (#4564092) Journal
      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.

    • Re:Kernel bloat ? (Score:4, Insightful)

      by LordHunter317 ( 90225 ) <{askutt} {at} {gmail.com}> on Wednesday October 30, 2002 @09:44AM (#4564104)
      I can't believe everyone calles 32MB of source "bloat". 32 MB is small compared to soemthings on your system, like X, KDE, GNOME sources. And in a lot of way, the Kernel is a lot more featureful than any of those. X for example, has a lot of "bloat" due to its build system.

      Joe-Schmo is goign to use the binary kernel supplied by his Distribution anyway, and probably never upgrade it, until he goes and downloads a whole new ISO image. The actual running kernel stays really small due to the use of such things as MODULES, allowing only what is needed to be running at any given moment to run.

      Bitch Bitch Bitch. Stop bitchin' about stuff you really don't have any idea about. The kernel is for all intents and purposes, small, and is indcredibly featureful for its size. So deal.

      • Re:Kernel bloat ? (Score:3, Interesting)

        by rmadmin ( 532701 )
        Just for clarification.. thats 36~ meg compressed!

        [KungFu] rmadmin:~$ ls -sh linux-2.5.44.tar.gz
        36M linux-2.5.44.tar.gz
        [KungFu] rmadmin:~$ gunzip linux-2.5.44.tar.gz
        [KungFu] rmadmin:~$ ls -sh linux-2.5.44.tar
        160M linux-2.5.44.tar
        [KungFu] rmadmin:~$

        Wanna rephrase your statement?

        • Re:Kernel bloat ? (Score:3, Informative)

          by LordHunter317 ( 90225 )
          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 can't believe everyone calles 32MB of source "bloat". 32 MB is small compared to soemthings on your system, like X, KDE, GNOME sources. And in a lot of way, the Kernel is a lot more featureful than any of those. X for example, has a lot of "bloat" due to its build system.''
        I'm sorry. This really doesn't make sense. Just because the kernel is smaller than some other package doesn't mean it can't be bloated. When I download the kernel source, I get sources not only for my build platform but also for a myriad of other architectures that I don't have. This _is_ bloat. It's good that Linux runs on so many architectures, it's good that the kernel has so many featurs, but anyone saying that all this source code they get but never use is bloat is just correct.

        In my opinion, GNOME, X, and KDE come with a lot of bloat that I don't want to cope with. I don't use GNOME or KDE, but I do use X, because I lack a better alternative. The Linux kernel is a fantastic piece of software, exactly because it offers so many features (that many don't need). The source download is pretty huge (and unnecessarily so), but once compiled it's greatly efficient. Any new features is a win, and if you don't want it, you can disable it at configure time.

    • Re:Kernel bloat ? (Score:5, Interesting)

      by GreyWolf3000 ( 468618 ) on Wednesday October 30, 2002 @09:49AM (#4564143) Journal

      This is great that these things are comming as standard in the kernel, but so many things are "standard" now its getting pretty large for joe-schmo average user who will get a full kitchen sink kernel with their distro.

      This is also great for creating products like VPN gateways et al, but is it time to consider a different structure for kernel builds, with modules being seperately managed with a smarter installation procedure.

      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.

    • Re:Kernel bloat ? (Score:2, Insightful)

      by Gheesh ( 191858 )

      This is great that these things are comming as standard in the kernel, but so many things are "standard" now its getting pretty large for joe-schmo average user who will get a full kitchen sink kernel with their distro.

      1. Joe Average will continue to buy larger and larger PCs just to be able to run Windows XP, and prices will lower due to that trend
      2. Although everything is included in the kernel *SOURCE* you don't have to compile and load into memory every module
      3. You may have noticed that lately even home needs are quite broad: from 3D and multimedia to routing to allow more than one PC to be using the Internet at a time, so it's a good thing all these capabilities are available if needed

    • Three kinds of bloat (Score:5, Insightful)

      by DickBreath ( 207180 ) on Wednesday October 30, 2002 @11:00AM (#4564749) Homepage
      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.

      • bloat (Score:4, Insightful)

        by budalite ( 454527 ) on Wednesday October 30, 2002 @12:03PM (#4565268)
        My un-favorite types of Bloat:
        - In Apps, Games, whatever, it would be a lot nicer to be able to add features, rather than have the whole bloated thing copied/downloaded/installed onto your drive. (Cygwin has a nice setup.exe program that actually lets the user *pick* what he wants *before* the download. Very nice.)
        - Programs that say "Standby while we figure out what system you are running" and then copy every bloated driver for every type system, and its various peripherals, that ever existed onto your hard drive, anyway. Maybe this is not a problem anymore with the huge disks that exists these days, but it does signify sloppy development work that is usually mirrored in the app. :{)||

    • Re:Kernel bloat ? (Score:4, Informative)

      by jim3e8 ( 458859 ) on Wednesday October 30, 2002 @11:07AM (#4564811) Homepage
      If you want to see bloat, take a look at the commercial UNIXes.
      For example, on a random HP 11.0 box here:

      -rwxr-xr-x 1 root sys 18946872 May 9 08:43 /stand/vmunix

      That is a 19 megabyte binary kernel. It would be interesting to see how big the source is...
    • that's funny... I bet I can still fit the kernel on a floppy. along with a filesystem and apps to make a firewall...

      1.4 meg for a functional system is bloat? what do you call Microsoft then?

      the kernel CANT get bloated... that's the great part of only using what you want and the rest doesnt exist.

  • What about... (Score:2, Interesting)

    by WhyDoubt ( 472635 )
    countries with harsh import/export restrictions on crypto code? What will the impacts on
    developers and users in those places be?

  • Looking for FreeSWAN? Try freeswan.ca (Score:5, Informative)

    by caluml ( 551744 ) <slashdotNO@SPAMspamgoeshere.calum.org> on Wednesday October 30, 2002 @09:48AM (#4564135) Homepage
    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 [umtstrial.co.uk] as they're so useful.

  • IPSec lets us get Win2k from the flank (Score:5, Insightful)

    by GreatDave ( 620927 ) on Wednesday October 30, 2002 @09:50AM (#4564150)
    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.

    • Re:IPSec lets us get Win2k from the flank (Score:5, Interesting)

      by LWolenczak ( 10527 ) <julia@evilcow.org> on Wednesday October 30, 2002 @09:59AM (#4564240) Homepage Journal
      In all honesty, Win2k's IPSec impmentation sucks. It dosen't seem to be able to keep track of time... and it forgets esp tunnels like crazy. Linux is already being used quite a bit for the hidden thins in business. The firewalls.. The proxy servers, the VPN Routers. Linux makes a very good box to sit in the corner w/o a monitor, and run a few hundred ipsec tunnels with lets say OSPF [lwolenczak.net] on top of it all.

      Many of the non-us distribuions ship with ipsec, but the big problem is creating some very easy way that can allow elmer fud to create a host to host or a subnet to host or a subnet to subnet ipsec tunnel in under 10 minutes. Preferably 2 minutes.

      What is going to start shifting many businesses to linux is seeing applications such as AutoCAD run on linux. Seeing APIs for controling PLCs on factory floors. If we are able to woo the design and engineering firms to linux.... we will have a powerful foothold on the market.

    • Re:IPSec lets us get Win2k from the flank (Score:5, Insightful)

      by phorm ( 591458 ) on Wednesday October 30, 2002 @10:45AM (#4564619) Journal
      Forget the "linux Vs windows" attitude for a moment, and lets just hope that the new linux kernel works nicely with the windows (bad or otherwise) implementation of IPSec for VPN, etc.

      You'll probably snag a lot more users by showing cross-OS compatability as opposed to desktop replacement. As in most cases, it would likely be linux server, windows desktop, with VPN being a nice communication feature in both.I know that I would like my VPN's to work properly between OS's, without the half-baked configurations in FreeSwan.

  • Mergint trends (Score:3, Funny)

    by VitrosChemistryAnaly ( 616952 ) on Wednesday October 30, 2002 @09:51AM (#4564167) Journal
    Oh man...

    First ICQ and AIM merge.

    Then Crypto and IPSec merge.

    Next you're gonna tell me that cats and dogs have merged.

    What's the world coming to?

    • Re:Mergint trends (Score:4, Funny)

      by anshil ( 302405 ) on Wednesday October 30, 2002 @10:18AM (#4564387) Homepage
      KDE and GNOME merge, finally a common desktop for all.

      Redhat and SuSE merge, and bring yast to redhat.

      BSD and LINUX will merge.

      The vim and emacs teams join together and will bring out a new editor together in teamwork.

      Linus agrees on using CVS.

      The english world will make a big grammar reform, enabling a polyphonic script again.

      Star Wars will meet Star Treck.

      America decides to officaly use the metric system.

      The brits drive on the right side of the road. ...

  • Export Ramifications? (Score:4, Insightful)

    by nurb432 ( 527695 ) on Wednesday October 30, 2002 @09:52AM (#4564174) Homepage Journal
    Does this create any export ramifications since Linus ( and i assume the code he reviews/packages )is now located here in the states?

    Just curious.. i know how hard of a time everyone else ( like BSD ) has with this garbage.

    Information should never be restricted on the basis of governmental boundries. Phfft.

  • Banned in the USA (Score:2, Funny)

    by Anonymous Coward
    Imagine if some legislator somewhere decided that this new crypto API (though it's for legitimate reasons) is somehow to be classified as a munitions and thus is a crime to export to other countries. He circulates a letter which his trusting co-legislators sign blindly. A week after its passing Linus gets locked up for anti-American activities. Alan Cox gets shipped to Guantanamo. Somewhere in Redmond a bowl-cut, bespectacled man cackles gleefully.

  • VPN w/Firewall (Score:2, Interesting)

    by gotvim ( 610753 )
    Anyone know if this will support VPN's using IPSEC wjhere either peer may be behind 1 or more firewalls? Right now, this has become an issue for a project I'm working on, and we're havin all sorts of issues. Thanks
  • Ive been using Freeswan for the last few months (1.98b) + quite a few patches (found them at www.freeswan.ca ) to get the results I need. How does this factor in to this equation? Is this a stupid-simple implementation that will also need lots of patches to be able to do what I need it to do (ie x509 certs, NAT transversal, DHCP over VPN) ?

  • Watching kernel dev out-of-band (Score:3, Interesting)

    by dcowart ( 13321 ) <`dzcowart' `at' `gmail.com'> on Wednesday October 30, 2002 @11:26AM (#4564951) Homepage Journal
    Linus has yet to post a message to linux-kernel since his return, but he continues to merge patches at a high rate.

    What's cool about this is that people are watching kernel development without having to read the lkml or being on irc or whatever. People can now just watch the patches flow into the bk system. I think that's kind of cool. It's like a Kernel News Network.

  • Crypto Export Regulations (Score:3, Insightful)

    by man_ls ( 248470 ) on Wednesday October 30, 2002 @11:36AM (#4565021)
    Wouldn't this run afoul of many of the U.S. Cryptography export regulations? U.S. DoD prohibits exporting of any product containing mathematically "strong" cryptography (usually, 128-bit) to a lot of places.

    That, and the DMCA which prohibits reversing of any of the encryption that would be found in the new kernel, would create a risk for many of the users downloading the software if they were from anywhere outside the US (and, for US users downloading the software, because it couldn't be explained to them.)

    I'm sure the U.S. government is going to have a lot of fun with this...

  • we love crypto (Score:3, Funny)

    by shren ( 134692 ) on Wednesday October 30, 2002 @11:51AM (#4565138) Homepage Journal

    ...it will hopefully lead to more secure communications for all Linux users in the future.

    Or the banning of Linux in several countries. Whichever comes first, you know.

  • More Pervasive Insecurities? (Score:4, Insightful)

    by brandido ( 612020 ) on Wednesday October 30, 2002 @12:18PM (#4565405) Homepage Journal

    I am not very knowledgeable about security issues, but I am curious if the inclusion of security modules in the kernel will provide for a single point of failure. In other words, as more programs become dependent on the kernel module for security, if an exploit becomes available, will all these dependent programs become exploitable?

    I ask this specifically because of the problem the IE ran into, where it depended on security APIs from Windows, the Windows API had an exploitable bug, and ta-da, IE had an exploitable bug.

Slashdot Top Deals

The trouble with being punctual is that nobody's there to appreciate it. -- Franklin P. Jones

Close