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

security in testing



My 2c worth....

Security should be important in the testing distribution. I think it's fine to say that testing is not guaranteed to be stable, that bugs in packages may very well be present and that you shouldn't run testing if your not willing to accept that risk. I think it's another thing entirely to say that there may be known security problems in testing that we're not going to fix in a timely fashion.

Here's my rationale:

People want to run testing, but aren't willing to accept a overwhelming security risk. They run testing to not only get the latest packages, but also to contribute to debian by reporting bugs and _testing_ the new distribution. These people form a pretty significant part of debians testing process.

Whilst I think these people are more than happy to put up with weird packaging bugs and broken software, if we indicate that running testing will almost certainly expose you to security vulnerabilities I believe these people are going to be a lot less likely to want to run the testing distribution. Which will result in 2 things:

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

With this in mind, I think we MUST avoid making this statement of insecurity and do our best to avoid this situation.

As a proposal to remedy this, I think the following actions would be appropriate (although I'm sure others may propose even better schemes):

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

I think this process would provide the following advantages:

- It would remove the security risk for _all_ testing users
- 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.

Obviously there needs to be some more thought put into exactly how the withdrawal/replacement of packages occurs, and I think others out there will have a better idea of how that could work than I.

Regards,
Chris Leishman

Attachment: PGP.sig
Description: Binary data


Reply to: