[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: stable vs. testing: same versions, different status



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


Reply to: