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

Re: security in testing



On Wed, May 14, 2003 at 10:19:08AM -0400, Matt Zimmerman wrote:

> > >If unstable has a fix for the bug, then it is a waste of time to work on
> > >testing because users can just upgrade.  If unstable does not have a fix
> > >for the bug, then it is still a waste of time because unstable needs to
> > >be fixed anyway, and that package will replace the one in testing once it
> > >has survived in unstable.

> > I don't disagree.  Thats why I didn't suggest a policy of creating 
> > patched versions for testing.  Instead, simply remove and inform the 
> > user that it's a problem.

> What value does this provide for the users?  It may incite them to complain
> to the maintainer, who might (if they are active) try to get a fixed version
> into testing, and disrupt their work, but this is not a good way to motivate
> maintainers.  As for the user's security, this is like amputating a limb as
> treatment for a fracture.

*My* primary goals are to protect Debian's (and the maintainer's)
reputation, and to fulfill my civic duty to not increase the number of
compromised machines in the world being used to clog the Internet.  The
needs of people trying to use testing for production use contrary to
all admonitions are secondary, IMHO; and by the sound of things, making
testing less suitable for the casual user in the process might be a
benefit, not a detriment.

 > - I believe that people who are willing to run the testing distribution 
> > are happy to assume the risk of problematic packages and broken 
> > packaging - and are in usually happy to contribute bug reports where 
> > appropriate.
> > - I also believe that the majority of these people are NOT willing to 
> > accept this risk when it comes to known security issues.  They're happy 
> > to deal with packages not working right, or the inability to install 
> > something for various reasons, but they're not willing to have their 
> > box compromised.

> The people I know who run testing do it on single-user or trusted-users-only
> machines, on rather tightly controlled local networks.  They do not notice
> or care about security problems for the most part.

> We can both hypothesize about testing users in general, but our guesses
> don't carry much weight unless they are backed up by real data from a
> significant number of real users.

I am not hypothesizing.  I am getting reports from and about people who
are running the version of Samba from testing, whose machines have been
compromized because they were exposed to the Internet.  Given that the
only users of testing I know are those I hear about through such
reports, if I *were* to extrapolate, my conclusions about testing's
userbase would be quite different from yours; but the real point is that
there is a non-zero number of users who have been compromised by the
Samba vulnerability, that I cannot turn around to and say "you should
have known better" in good conscience because we as a community are
sending mixed signals to our users about testing's suitability.  It
makes no difference to me personally *which* way we clarify the matter,
but I think the lack of consensus is a serious problem.

> There are already very clear statements about this.

> http://www.debian.org/releases/

> testing
>     The ``testing'' distribution contains packages that haven't been
> accepted into a ``stable'' release yet, but they are in the queue for that.
> The main advantage of using this distribution is that it has more recent
> versions of software, and the main disadvantage is that it's not completely
> tested and <<<has no official support from Debian security team>>>.

Out of curiosity, what *un*official support does testing receive from
the Debian security team?  This statement on the website does a rather
weak job of capturing the true state of affairs, IMHO, if maintainers
offering to prepare testing security uploads for their packages are
being turned away.

-- 
Steve Langasek
postmodern programmer

Attachment: pgpZAyvDKkJEQ.pgp
Description: PGP signature


Reply to: