On Sun, 21 Jun 2009 21:44:25 -0400 Michael S. Gilbert wrote: > On Sat, 20 Jun 2009 00:35:28 +0200 Francesco Poli wrote: > > You seem to say: "since testing is not officially supported, there's no > > reason to do *anything* that would improve its security". > > What's next step, then? Intentionally introduce vulnerabilities into > > testing, since it's not officially supported anyway?!? ;-) > > not really what i was saying; my point is that security fixes will > automatically propagate from unstable, it just takes time -- but it will > happen. and since the security team's time is a scarce resource, it is > folly to duplicate effort on both testing and unstable when the changes > in unstable will shortly overwrite all the work previously done on > testing. I acknowledge that, when there's lack of manpower, DTSAs cannot be easily prepared. But I would *not* call them a "folly": the infrastructure is there *exactly* because, in a significant number of cases, fixes won't migrate from unstable to testing in just a couple of days, but will take more time (e.g.: when fixed packages are waiting for a transition to happen, and so forth). That's why I am trying to figure out how the manpower issue can be solved: because I would love to see DTSAs and all the full security support for Debian testing, even when it is apparently harder (i.e.: immediately after a release). [...] > > Even *some* DTSAs are better than *no* DTSAs. > > Even *some* efforts from the Testing Security team, are better than > > *nothing*. > > time is scarce, and there is already a clear policy statement about > expectations for testing security. The goal of the Debian Testing Security team is exactly to make this statement false (and eventually change it, of course). At least, this is how I understand the goal of the Testing Security team, as stated in http://testing-security.debian.net/ : | The Debian testing security team is a group of Debian developers and | users who are working to keep Debian's testing branch in good shape | with respect to security > see the "Limitations" section at > http://secure-testing-master.debian.net. Indeed, but I don't see a "Do not use testing unless we are a few weeks from next release" warning. And I think that there should *not* be such a warning and that the reasons for such a warning should be fought and defeated by the Testing Security team. If users don't use Debian testing, no one will report bugs for packages in testing, and bugs won't be discovered until a new release is out, that is to say, until it's too late... > > > Make no mistake, I am *not* saying that the Testing Security team is > > doing nothing. > > As I told in this same thread, I was happy to see a pair of DTSAs and I > > am pretty sure that many other actions are taken (in a less visible > > way) to make sure that important security-related fixes are applied to > > unstable and migrate from unstable to testing as fast as possible. > > This is *greatly* appreciated, especially if lack of manpower is taken > > into account! > > right, DTSAs are happening at a low-level, which is at least something > (and will likely continue at a similar rate until the squeeze freeze). > however, a better user-side policy is to not use testing if you are > concerned about full security support because that is not happening > (and does not need to happen) so far away from a release. maybe > something like this should be issued as an official statement from the > secure-testing team? As I explained above, I disagree that full security support "does not need to happen so far away from a release". It *should* happen as soon as possible. [...] > > and, at the same time, an automatic > > mechanism to re-use some DSAs as DTSAs which would be useful, > > especially early after a stable release, i.e. when it is apparently > > more difficult to provide good Debian testing security support... > > like i've already described, there is an existing solution. maybe it > needs to be more user-friendly and documented, but it's available now. I think it should be done automatically at archive level. An automatic stable-update --> testing,unstable migration mechanism is already in place for point releases, as stated by Nico Golde in http://lists.debian.org/debian-security-tracker/2009/06/msg00009.html A similar automatic stable-security --> testing-security migration mechanism should be implemented, IMHO. BTW, since a point release was issued yesterday, I've just seen the stable-update --> testing,unstable migration happen for a number of packages (including linux-2.6). This caused a number of new "same versions, different status" inconsistencies in the tracker: http://security-tracker.debian.net/tracker/CVE-2009-0028 http://security-tracker.debian.net/tracker/CVE-2009-0146 http://security-tracker.debian.net/tracker/CVE-2009-0147 http://security-tracker.debian.net/tracker/CVE-2009-0165 http://security-tracker.debian.net/tracker/CVE-2009-0166 http://security-tracker.debian.net/tracker/CVE-2009-0195 http://security-tracker.debian.net/tracker/CVE-2009-0799 http://security-tracker.debian.net/tracker/CVE-2009-0800 http://security-tracker.debian.net/tracker/CVE-2009-0834 http://security-tracker.debian.net/tracker/CVE-2009-0835 http://security-tracker.debian.net/tracker/CVE-2009-1046 http://security-tracker.debian.net/tracker/CVE-2009-1072 http://security-tracker.debian.net/tracker/CVE-2009-1179 http://security-tracker.debian.net/tracker/CVE-2009-1180 http://security-tracker.debian.net/tracker/CVE-2009-1181 http://security-tracker.debian.net/tracker/CVE-2009-1182 http://security-tracker.debian.net/tracker/CVE-2009-1183 http://security-tracker.debian.net/tracker/CVE-2009-1184 http://security-tracker.debian.net/tracker/CVE-2009-1192 http://security-tracker.debian.net/tracker/CVE-2009-1242 http://security-tracker.debian.net/tracker/CVE-2009-1265 http://security-tracker.debian.net/tracker/CVE-2009-1337 http://security-tracker.debian.net/tracker/CVE-2009-1338 http://security-tracker.debian.net/tracker/CVE-2009-1392 http://security-tracker.debian.net/tracker/CVE-2009-1439 http://security-tracker.debian.net/tracker/CVE-2009-1630 http://security-tracker.debian.net/tracker/CVE-2009-1633 http://security-tracker.debian.net/tracker/CVE-2009-1758 http://security-tracker.debian.net/tracker/CVE-2009-1832 http://security-tracker.debian.net/tracker/CVE-2009-1833 http://security-tracker.debian.net/tracker/CVE-2009-1834 http://security-tracker.debian.net/tracker/CVE-2009-1835 http://security-tracker.debian.net/tracker/CVE-2009-1836 http://security-tracker.debian.net/tracker/CVE-2009-1837 http://security-tracker.debian.net/tracker/CVE-2009-1838 http://security-tracker.debian.net/tracker/CVE-2009-1839 http://security-tracker.debian.net/tracker/CVE-2009-1840 http://security-tracker.debian.net/tracker/CVE-2009-1841 Please fix these inconsistencies. -- New location for my website! Update your bookmarks! http://www.inventati.org/frx ..................................................... Francesco Poli . GnuPG key fpr == C979 F34B 27CE 5CD8 DC12 31B5 78F4 279B DD6D FCF4
Attachment:
pgpBRiKtK4SoF.pgp
Description: PGP signature