On Wed, 10 Jun 2009 16:40:38 -0400 Michael S. Gilbert wrote: > On Wed, 10 Jun 2009 20:22:39 +0200, Francesco Poli wrote: [...] > > Moreover, the security-tracker would not be aware of this possibility > > and would thus go on considering those vulnerabilities as unfixed for > > testing. > > the web tracker shouldn't be the definitive source for the security of > your particular configuration. use debsecan. it takes into account the > specific versions of the packages you have installed. The security tracker is not useful to assess the security of a particular box, but I think it's (or it should be) useful as a sort of (auxiliary) to-do list for the security teams, telling which vulnerabilities should be addressed with the greatest urgency and which vulnerabilities are already fixed. Or am I completely off-track? > > > On the other hand, my proposed automatic stable-security -> > > testing-security migration mechanism would fix a number of > > vulnerabilities (especially in the first post-release times) for all > > Debian testing end-users, in a "gratuitous" manner (from a Debian > > Testing Security team point of view, since it would re-use the Debian > > Stable Security team effort). > > if you are interested in this feature, then by all means, volunteer > and implement it. As far as I understand it, this feature should be implemented in the security.debian.org archive management tools: I am really ignorant about their internals (see? I don't even know their names...). I am afraid that the experts of the matter would waste more time in explaining things to me and in assisting me for the implementation of the feature, than in implementing the feature directly... :-( [...] > however, i think that the feature is here now (via stable-security), and > i personally don't see the need to implement this harder solution > (especially since testing is not currently considered security > supported anyway). This reasoning sounds strange to me: "since testing is not currently supported security-wise, let's refrain from doing something that would improve its security in a 'gratuitous' manner!" When I say 'gratuitous', I mean that it would re-use the work done on stable security, whenever this is possible. > > based on the track record for lenny, you can probably expect full > testing security support sometime within 6 months to a year before > squeeze's release (i.e. around 18 months after lenny's release or over a > year from now). Debian sarge was released in June 2005. I remember seeing the first DTSAs for etch in September 2005, if not before (OK, that could not be considered as full security support for testing, but it was better than nothing). Debian etch was released in April 2007. I remember seeing the first DTSA for lenny in May 2007. Debian lenny was released in February 2009. As of now (June 2009), I still have to see the first DTSA for squeeze. It seems to me that things are going worse for squeeze than for lenny... There's lack of manpower, I know: but was there more manpower while lenny was testing and etch was stable? -- 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:
pgpTe3M3hAsnb.pgp
Description: PGP signature