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. > You seem to reason as if security were an all-or-nothing, > black-or-white thing. > I think that there are several gray scales between an ideal 100 % > secure system (which is unfortunately impossible to obtain in the real > world) and a miserable (security) failure. > As a consequence, I think that *anything* that could be done to push > Debian testing in the direction of a more secure system, is worth doing. > 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. see the "Limitations" section at http://secure-testing-master.debian.net. > 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? > I just think that the goal of the Debian Testing Security team should > be to officially support Debian testing *always*, and not only for a > few months before a stable release. again, time is scarce, and this is not necessarily the best use of manpower. > That's why I was wondering what could be done to improve the situation: > a new call for help perhaps, even if there were more help (which i'm sure would be appreciated), it would likely be directed toward stable and unstable since it makes little sense to duplicate effort. > 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. mike -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
