On Thu, 2006-10-19 at 08:09 -0600, Greg Knaddison - GVS wrote:
On 10/19/06, inkfree press <inkfree@gmail.com> wrote:
Any methods suggested for determining which modules will break is appreciated.
Well, in Heine's original message he linked to:
Converting 4.6.9 modules to 4.6.10 <http://drupal.org/node/90004> Converting 4.7.3 modules to 4.7.4 <http://drupal.org/node/89999>
Converting 4.6.x themes to 4.6.10 <http://drupal.org/node/90021> Converting 4.7.x themes to 4.7.4 <http://drupal.org/node/90024>
If you read those they show code that will break on an updated site. If you browse through your modules and theme for some of those pieces of code and they don't look right - you need to update them.
I believe a list of affected modules is coming from the security team soon.
Regards, Greg
dopry@bbox:~/public_html/drupal-4-7/public_html/sites/default/modules$ cat */*.module */*.inc | wc 15672 55392 508132 You mean browse through 15K lines of code? It's crazy to expect that of a site administrator. Remember we are developing for non-developers. This is the second security update the breaks things in the process of fixing them. Which isn't so good in my opinion. We need to take more time reviewing our security updates and testing them. If we are going to change core in a way that will break modules, the affected modules need to be identified and their maintainers notified so a concerted effort can be made to provide end-users a real security fix, not just a partial. It is unfair to expected administrators and end-users to edit a module file. If module X is a key element of my site, and the bug fix breaks it... You have just publicly disclosed a vulnerability in my site that I cannot address. If I am a simple site administrator and not a developer, what boat am I in now? I can fret until my required module is updated. That is about it. This kind of information also provides a targeting vector for script kiddies. drupal sites running module X are unlinkely to have applied patch y google: Drupal + Module X (or select css classes and ids from Module X) I think a reasonable order of disclosure would be --security team - analyze problems, determine scope of change and its impact --distro maintainters & module maintainers - give a set period for updates (1-2 days?) --public disclosure - release with notice of error - example of how to exploit - solution, and reasoning behind solution - links to patches and tar balls - parts affected by bug - parts affected by fix ----------------------------------------------------- I really appreciate the work you guys on the security team do. I'm just offering these as a suggestion for improvement. debian's older policy is a fairly good one, I'm not sure if its still current in their camp. http://lists.debian.org/debian-devel/1999/08/msg01933.html