This is a rather difficult question in that the poor security package upgrades are poor compared to what?
Stable? Yes it is not as good.
Sid? Depends on the package. The package maintainer does the security work on their packages. Some will be better at this than others as far as timing goes.
The security team handles the security upgrades for testing. Obviously their top priority is going to be Stable and Old Stable. Then testing will get its upgrades.
I run Sid and testing on 2 installs sharing a common /home partition. I find that this dev cycle (Jessie) on my hardware that Sid runs a bit better so I am pretty much using Sid. In the Wheezy-testing cycle Wheezy, for most of the time, ran better than Sid. This is on my hardware and yours may be very different.
Ubuntu bases their LTS versions on testing. They base their other releases on Sid.
Until the Debian testing version on which the Ubuntu LTS release is based, like the current 14.04 LTS, they are pretty much dependent on Debian testing security releases. They seem to think this is fine.
The same goes with their "regular" releases. Think of all the versions of Ubuntu that are still supported and are still based on the Sid repo. This seems fine to them.
We got extremely good security support, and continue to, for the bash vulnerablility in all supported versions of Debian. That was pretty much an emergency responce. Most security upgrades are possible exploits that folks spot and they are patched long before they become a problem.
All your base distros and the kernel folks are watching for such problems. They get patches out pretty fast and share information constantly on potential and current security problems.
When we choose to use an unstable version of any distro we are signing on for cutting edge packages. These packages are going to have bugs and that should be our main worry. While there are a lot of us using unstable versions it is small compared to those using stable versions.
Therefore there is sort of a security lag for sure but also a lag on the part of potential attackers. No one would use an unstable version for critical information.
I have hardened versions of Squeeze and Wheezy on here too. If I need security for something I use one of them.
Here are a couple of links that may help you out;
https://wiki.debian.org/DebianTesting
That one discusses security in testing.
https://www.debian.org/releases/testing/
That one may also be of interest for general information.]
As for security when we go into freeze. I don't think that there is any change in the policies or priorities of the security team for that period. That said; the security should be some what easier to handle as the packages are supposedly at the final version or very close to it. All that is supposed to be going on is bug fixes. I would think this would make the security a bit better in testing but that is only what my opinion is.
Another thing you could compare security in Debian testing to would be the supported versions of Windows. They don't generally get security upgrades until the shit has hit the fan.
I think Linux does a bit better than that the vast majority of the time. I also think that the base distros do too with packages specific to them. The GNU folks do a fine job too. We as unstable version users have to realize that the number of folks looking at the code is a lot smaller for our packages than with packages used in Stable version.
I use testing and Sid because stable versions are boring.
Businesses, and probably people that are stable themselves, use stable versions because they are boring and really well watched over. We need to realize that the purpose of Debian testing is to build the next Stable. It is not supposed to be anything else. That to an extent includes secure. Obviously when Jessie is released it will be as secure as they can make it at that time but it can't be the first priority during the building process. The packages have to work first.
This is what the manual has to say about testing;
Quote:
6.5 What does the testing distribution contain?
Packages are installed into the `testing' directory after they have undergone some degree of testing in unstable.
They must be in sync on all architectures where they have been built and mustn't have dependencies that make them uninstallable; they also have to have fewer release-critical bugs than the versions currently in testing. This way, we hope that `testing' is always close to being a release candidate.
More information about the status of "testing" in general and the individual packages is available at http://www.debian.org/devel/testing.
6.5.1 What about "testing"? How is it `frozen'?
When the "testing" distribution is mature enough, the release manager starts `freezing' it. The normal propagation delays are increased to ensure that as little as possible new bugs from "unstable" enter "testing".
After a while, the "testing" distribution becomes truly `frozen'. This means that all new packages that are to propagate to the "testing" are held back, unless they include release-critical bug fixes. The "testing" distribution can also remain in such a deep freeze during the so-called `test cycles', when the release is imminent.
When a "testing" release becomes `frozen', "unstable" tends to partially freeze as well. This is because developers are reluctant to upload radically new software to unstable, in case the frozen software in testing needs minor updates and to fix release critical bugs which keep testing from becoming "stable".
We keep a record of bugs in the "testing" distribution that can hold off a package from being released, or bugs that can hold back the whole release. For details, please see current testing release information.
Once that bug count lowers to maximum acceptable values, the frozen "testing" distribution is declared "stable" and released with a version number.
The most important bug count is the "Release Critical" bug count, which can be followed in the Release-critical bug status page. A common release goal is NoRCBugs which means that the distribution should not have any bugs of severity critical, grave or serious. The full list of issues considered critical can be found in the RC policy document.
With each new release, the previous "stable" distribution becomes obsolete and moves to the archive. For more information please see Debian archive.
|
There is, I believe a link to that in the second link above. Most of the manuals are available as packages and if installed get upgraded when there are changes. If you like to have some reading material for times when you are off line that is some handy stuff.