* Helmut Toplitzer: > Hi! > > Just a few remarks:
Same here. > << Use unstable or testing, and apply security fixes yourself. Over > > To my opinion this is a bad suggestion. It's the only approach that will result in timely fixes of the bugs that are important to *you*. Any vendor team will work within very tight constraints (time/budget, architecture support, backporting policy). Sometimes, this results in considerable sacrifices. I doubt that there's a single large software vendor which hasn't dealt with a severe security bug in a not-yet-end-of-line-ed piece of software by declaring that fixing that bug is the wrong trade-off. Just after the release, using stable and applying upstream fixes is a viable approach as well, but late in the release cycle, upstream usually does not support the version in stable anymore. > Maybe my last mail was a bit unclear about this. As security is a > process rather than a state, your systems will hardly ever have all > the available security-patches. "Security is a process"? Sounds a bit like "faith is a verb". > (Not to note that it's not possible to keep up with this job > if you are alone with it, which will be the fact if you do it by > hand for testing/unstable.) If there's a patch which actually applies to Debian's version, it's rather straightforward to apply it to the package and rebuild it, especially if you are a bit familiar with Debian's major source packaging environments. If there isn't a patch, the necessary changes are often very complex and beyond what a security team can do. Since Debian has no way to assign real developers remotely familiar with the code to work on a port to the relevant version, such security updates never happen. Some Debian users will rather live with known vulnerabilities than the risks complex changes pose. Obviously, this depends a lot on the user and the scope of the vulnerability. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
