Re: Security Support by the Security-Team
* 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.
Reply to: