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

Re: security in testing


On Tuesday, May 13, 2003, at 05:20 PM, Matt Zimmerman wrote:
Please get this OFF of debian-private and onto -devel. Quote me anywhere. 

Redirected thread to debian-devel.


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). 





	1) People don't run testing, and hence we lose a large portion of
	our testing process
	2) There is more incentive to move to another distribution entirely


"Market share" arguments don't tend to carry much weight in Debian.
Developers in general don't stand to lose anything at all if Debian has
fewer users.
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. 


- If a security vulnerability is found in a 'testing' package, then an
announcement is made (perhaps a testing-security-announce list?)
- The package it is immediately withdrawn from the testing distribution. 
- If no fixed package is available, an empty 'placeholder' package is
installed into testing along with a debconf message to inform the user
that the package will be removed for security reasons.  The message
should also indicate what the problem is, and what actions are required 
to get a new version into testing.  As an alternative, a downgraded
version could be provided....
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...
Another example might be to just replace the package with another version that has a very, very loud debconf warning that it has known security problems and asking if the user really wants to install it.
It's more of a policy issue first. Once thats worked out, then we can worry about the how. 


I think this process would provide the following advantages:

- It would remove the security risk for _all_ testing users
Perhaps, but there are far easier ways for users to eliminate this risk, such as running stable, or upgrading problematic packages to the unstable 
versions.
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 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.
- It would provide strong incentive for people to help out in fixing RC bugs or patching packages in order to get the missing package back into 
testing.
If the package is not fixed by release time, it will be removed anyway. It is the maintainer's responsibility to work toward having the most releasable 
versions of his packages in 'testing'.
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.
The maintainer can then work towards getting their package back into testing.
*shrug* I'm just trying to open a bit of reasonable discussion. I'll summarize so that people replying have less to quote:
- 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. - 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. 

Regards,
Chris

Attachment: PGP.sig
Description: This is a digitally signed message part

Reply to: