Correction on that: A "static package" is never for "security reasons". It's for "administration" reasons. Please don't confuse the two.
If someone was truly looking at the "security reasons", then they would try to stick with newer software - especially in the F/OSS world - since it nearly always fixes the older security issues (or at worse propagates them), usually gets the fixes faster, and even though it might introduce new issues, those issues are likely unknown to any. Yes, the 'static package' issue is nice for administrators that don't want to upgrade software very often. But that really is not very good practice security wise. Unfortunately, those same administrators are usually left without a choice as they are running other software that doesn't work with the newer software - whether it is something in-house or third-party. F/OSS usually overcomes that limitation a lot faster -- especially in the Gentoo world -- since software gets updated more often. If it's not the 'without a choice' issue, then its just laziness on their part since upgrading the software would benefit them in many respects. RHEL/SLES are targeted more at the people that need that static packaging b/c of third party apps - not security. As Kerin mentioned - those static packages may not get those security updates. In fact, they will likely miss a lot of updates - bug fixes (whether security or not) or minor security updates (that could be major!) that the static package vendor does not deem worthy enough to port. Worse yet, those static packages may have their own security flaws that are not in the main package due to those backports or other vendor mistakes. For example - the recent OpenSSL debacle on Debian. My primary point here is that "static packages" are not for security reasons. Never has been and never will be. And anyone saying such is flat out lieing to you (knowingly or not) or at best propogating false information. Now, the only real issue that you do raise is that yes, SLES/RHEL and others may for some be better because they provide a full compliment of already compiled libraries against a given compiler set; so you may not run into the _compilation_ side of the house that upgrading a compiler or library could run into. However, I would argue that that is likely a rare issue in the Gentoo world if you use the right profile, are careful of what you unmask, and you follow the recommended guidelines for using Gentoo on a production system - e.g. having your own portage mirror, and stage to a non-production system, and then after verification on the non-production system pushing to production. Those guidelines should be followed any way in a well designed production environment. Ben ----- Original Message ---- From: Robert Bridge <[EMAIL PROTECTED]> To: gentoo-server@lists.gentoo.org Sent: Wednesday, October 1, 2008 10:34:04 AM Subject: Re: [gentoo-server] Server Packages for Gentoo On Wed, 1 Oct 2008 11:55:21 +0100 "Kerin Millar" <[EMAIL PROTECTED]> wrote: > Well, this post turned out to be a lot longer than I had anticipated. > But I've seen so many comments that allude to Gentoo somehow being > unfit for purpose because it doesn't freeze off a so-called "stable" > tree so many times that, frankly, I get fed up with it and figured > that something had to be said. Gentoo, whilst certainly having its > fair share of foibles, doesn't get enough credit for the things that > it does well and the things that it does right. If one doesn't like > the way that Gentoo does things then there are surely other distros > out there that will meet one's expectations, such as they are. Right, imagine a live server getting hit by the expat problem, or a major gcc/glibc change? They hurt, they seriously hurt. That's what the "static package" people are referring to. A server that can be set up, and once running should need minimal updating, for security reasons. You can't do that safely in Gentoo. Some people are happy with regularly changing packages, restarting services every month because a new version of the server is in tree, dealing with the breakage induced by things like python upgrades, bash upgrades, portage upgrades, gcc upgrades, ... But for a 24/7 uptime on a high load server, most people consider those to be unacceptable. Now Gentoo can be got to not do those, but as anyone will tell you, updating a Gentoo box after a year is painful, and when you have to update to cover a critical security hole? Now try updating a Debian box after a year? Don't mistake one awkward piece of software which is not supported in the other distros for the general properties of those distros. Gentoo is good for tweaking, it's good for doing "Your own thing", that does not make it automagically better than Debian or RHEL, or SLES in the high-stability stakes. And, sorry to say this, one nice anecdote doesn't either. YMMV Rob.
