Re: security in testing
On Wed, May 14, 2003 at 10:07:16AM +0300, Chris Leishman wrote:
>
> On Tuesday, May 13, 2003, at 05:20 PM, Matt Zimmerman wrote:
> >If you want to see security updates for 'testing', then start preparing
> >security updates for 'testing'. It does not help to describe in detail
> >what you hope that someone else will do. The best (and often only) way
> >for you to promote your agenda is to start doing the work.
>
> Actually - I didn't suggest this. I suggested there should be some
> consensus on what to do about security problems in testing - my main
> suggestion is that packages should be simply removed and the user notified
> of what actions they can do to get it back (such as upgrading to an
> unstable version, downgrading to a stable version, or fixing the bugs).
I think that users would react rather negatively to having packages (ones
that they use) effectively disappear from their system, but the only way to
be certain is to experiment with the process. You can easily simulate this
by providing dummy packages in a private repository.
> >> 1) People don't run testing, and hence we lose a large portion of
> >> our testing process
> [...]
> The important point was the first one. The 2nd one was just another
> effect of not doing anything about the issue which some people might
> care about.
We didn't even have testing until quite recently, and it is likely that
unstable users still provide the majority of our testing. IMHO, it is only
particularly valuable for users to run testing when a release is
approaching (at which point security updates and removals take place en
masse).
> >If you do not accept the arguments against this, then start doing it, and
> >see whether it is worthwhile.
>
> I can't just start doing it. For one this is the sort of issue that needs
> a bit of consensus and input from the people actually in charge of the
> process. It's not like just submitting a patch or uploading a new
> package. I also clearly stated it's just an example of what could be
> done, but I think there may be better ways...
You can be in charge of the process if you are willing to make the effort.
It is a lot like uploading a new package, only outside of the Debian
archive.
> It's more of a policy issue first. Once thats worked out, then we can
> worry about the how.
Debian policy seems to be formed as a result of consensus, to reflect what
is already known to work, and usually not as a means to effect widespread
change. "Debian developers in general should start to do X" is often the
very last step in the process, not the first.
> Yes, there are. But all of these loose one of the main reasons I feel we
> even have a testing distribution - to have people testing it.
If testing were to do nothing more than ensure consistency in dependencies,
architectures and source/binary relationships, then it would still be very
much worthwhile.
> >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.
> Again I agree. All I think is that removal of security issues should
> be done before it even gets into testing. My suggested policy was that
> nothing with a security bug should go into testing - and anything with
> a security bug should be removed via an empty upgrade (and the user
> informed). Of course there's may be other ways that have the same
> basic effect.
If packages in 'testing' were constantly disappearing without warning, this
would seem to make it significantly less attractive to users (which you
would seem to want to avoid).
> - 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 think there should be some consideration of how to alter the
> process of installing (or removing) packages from testing in order to
> encourage the people in the first group to keep using it. And if thats
> not the general consensus, then a very clear statement about the total
> lack of security in testing should be made.
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>>>.
(emphasis added)
http://www.debian.org/security/faq
Q: How is security handled for testing and unstable?
A: The short answer is: it's not. Testing and unstable are rapidly moving
targets and the security team does not have the resources needed to properly
support those. If you want to have a secure (and stable) server you are
strongly encouraged to stay with stable. However, the security secretaries
will try to fix problems in testing and unstable after they are fixed in the
stable release.
--
- mdz
Reply to: