 | SoftwareHi, Finally I decided to start learning iptables hence installed the 2.4.7 kernel along with the iptables. The version comes on 7.2 is 1.2.1a (yes the kernel is also 2.4.4) should not be there an offical update to iptables out of curiosity ? This is the reply from Roman Drahtmueller to the question given above. This reply is reprinted here with permission. (This mail has become somewhat lengthy, but I wanted to write down some thoughts on closely related topics that arise when I give the answer for this question. Everything that has nothing to do with the actual question above on this thread is written below the line "########", and it does not contribute to the half-technical question. I do not wish that there will be a discussion about the issues below on this list because it would generate an off-topic lengthy thread. It's just that some of the things below need to be said every once in a while in order to prevent misunderstandings from distorting the aspects and benefits of open source software.) The answer: Not quite: The iptables utility is only the setup tool, it can't easily be a security problem without messing up the rules during setup (You'd easily notice! :-). The actual work of the packet filter engine happens in the kernel, not in the ipchains utility. If your machine acts as a packet filter only, you can easily kill all running processes and run rm -rf / over it - it will continue to work until you try to reboot it. By consequence, the newer version fixes bugs that may be nasty in some way, but there are none that were security-related. The version of iptables that is on the CDs is installed on a few dozen thousand installations, and in use one some thousands, I guess. A new version is always different from the one before (this is why there is a new version in the first place): different functionality and different bugs as well. We cannot guarantee that the newer version works exatly like the one before, which is why we don't provide a newer version of the package (with iptables being just a simple example). Please look at the changelogs of single packages in the distribution, especially the core packages and libraries, and look at the patches that we include to fix bugs that we found during testing. In order to be taken seriously in the operating systems market, you have to be able to maintain a certain level of quality in your software. You make a tradeoff between the up-to-dateness (and security) and the reliability (and security) of your software. This implies that the functionality of a single package must be guaranteed over the updates. By consequence, the version stays the same: only those bugs are fixed that break the functionality of the package or impose a security risk. If your favourite email program crashes if you hit five keys together, then do not hit these five keys together. If it crashes when a strange email arrives, it may be security related: Write to security@suse.de, and use the pgp key to encrypt your text. New versions in update packages can only happen if the new version number is beneficial from the security standpoint, and if no other package relies/depends on the package to be updated. (Example: openssh. A user should be able to tell by the version number that the recently discovered security bugs are fixed.)
There is a specific set of reasons why we make a new distribution every once in a while (with a decreasing frequency): The opensource community needs to have a new base to build on (a distribution sets standards that are most important for the thing as a whole), and new features are desired on behalf of the usership. Free software is for free: You can download it from servers worldwide. But I wouldn't want someone else to do the job that we've accomplished with each distribution (7.3 is out in a few days): many thousands of hours of CPU-time have been used for compilation of code and for stresstests, many hundreds of CDs have been burned, network equipment and computer hardware has been bought just to test the software, and many millions of keys have been hit, not to mention the thousands of hours in long nights that developers at SuSE and the rest of the world have sat down to track down crashes, add improvements to performance, stability and security, provide a nicer, ergonomic interface and make it what it is: A secure, powerful, flexible and stable operating system, ready to use. It is what people expect from it (while everybody expects something different). If you want to give yourself a nice lesson: Play distributor! Install a SuSE-6.1, just a minimal package selection, then put away the CDs. Then, get KDE-2.2.1 running on it, with a few dozen applications that do all kinds of things from showing the time down to burning CDs and sending mails. Compile from the source tarball, not SuSE source rpms. Modularize the software that you have installed and keep an overview over it. Add icons, G/X, eye candy, sounds so that you like it more. Check it for bugs, identify crashes and find security problems. Deal with buggy hardware and BIOSes. Ensure consistency of the ready-to-install packages that you built. Make it possible to exchange parts of the system at full consistency. Communicate the bugs that you've found to the maintainers and authors of the software that you use (quite some people, many emails!). After you have found out that you need to exchange basically everything in your minimal system in order to be able to even compile the new stuff (not to mention running or testing!), you can abbreviate to a minimal SuSE-7.2 installation and restart from the beginning. After a few weeks without much fun you will find out that kdm behaves strangely under some obscure, but usual circumstances; watch out for race conditions and buffer overflows while you nail down the reason why all of your processes get nuked by SIGTERM sometimes. If you're there, invest some time to sit down with others and argue the technical reasons why you (lazily) added your docs to /opt/kde/docs instead of /usr/share/doc. Be sure to have a comprehensive result afterwards, so that your distribution follows the defined standards (SuSE is leading in terms of that). Then you change what doesn't match the standards, and recompile everything. Don't forget to write down how to use it for your grandma and your kids. SuSE employs the best people that the world has for many of the subsystems that a SuSE Linux distribution is built on. They are paid for doing their job and for refining the software they wrote to a thing that you can use. The software is still for free, the patches are for free (the distributors even share their additions), but the fact that you can easily install and use it is not! Provided you earn only Euro 2.50 an hour, you couldn't make it in time to be faster than 100 times the price of a Linux distribution (a SuSE in particular). If you buy all the software that is on the (filled up to the last byte) SuSE CDs from a commercial vendor, expect a bill of a few hundred thousand Euro. I've never ever paid a single buck for software, but if I didn't (proudly) work for SuSE, I'd pay significantly more. I would want new versions of single software packages every few months, but as you might know we're not forced to buy it either. It's just easier and less expensive. The price of a Linux distribution does not compare to the price of commercial software, but to the price your own time and your freedom. Thanks, Roman.
|
|
