Re: Freeze Please?

["Marcelo E. Magallon" <mmagallo@debian.org>]

On Fri, Feb 07, 2003 at 10:11:08AM -0500, Matt Zimmerman wrote:

 > >  The easiest way for archieving this is going thru all the DSAs,
 > >  checking the version they affect and checking the version in
 > >  testing, then checking the reported bugs and filing bugs tagged
 > >  "security, sarge" (or tagging existing ones) and setting the
 > >  severity to critical.

 > Please don't, unless these bugs will make a significant difference in
 > allowing the unstable packages to progress into testing.

 I don't follow you.  Is it your concern that making this information
 readly available (via the BTS) will make users of testing more
 suceptible to attacks or something like that?

 I don't really think it's hard to get this information.  You just need
 to have a look at the DSAs, a look at packages.debian.org and perhaps
 at the changelogs of the packages in testing and you are done.

 We seem to have the same intention: prevent accidentally releasing
 something with security bugs present.  My reasoning is that if the
 information is filed in the BTS it will be easier to fix the problems.
 The maintainer sees that the version in testing has a security problem,
 the version in unstable doesn't, he makes a security upload to testing,
 it gets autobuilded and installed.  If the version in unstable
 eventually makes it to testing, the maintainer can close the bug.  If
 it doesn't testing gets released with a fixed version.

 > I already have this information for all DSAs and many other bugs
 > which did not affect stable, but do affect testing or unstable.

 Good for you.  Why isn't it available on a visible place?

 > Also, Severity: critical is only appropriate for a strict subset of
 > security-related bugs.

 I was going from memory.  I see the developer's reference to the BTS
 defines two severities for security related stuff:

   critical
          makes unrelated software on the system (or the whole system)
          break, or causes serious data loss, or introduces a security
          hole on systems where you install the package.

   grave
          makes the package in question unusable or mostly so, or causes
          data loss, or introduces a security hole allowing access to the
          accounts of users who use the package.

-- 
Marcelo