On 8/11/06, e <[EMAIL PROTECTED]> wrote: > Even partial disclosure > would have helped a lot (and it was definitely a possibility, since > exploiting the flaw requires a combination of unrelated parts of the > application stack).
For what's worth, my 0.02 cents about this part. The good thing about partial/full disclosure is that it gives server admins more choices, because they have more information. I know zero about Rails, the patch, or the security hole. But I'll be damned if there weren't several ways to mitigate the vulnerability without applying the patches, something that doesn't happen instantly on a production environment. From minimal servers running only RoR and the database on another machine with a firewall filtering packages, to Apache/Ruby permissions, logs, and backups, up to disabling some application features while the patch is tested, leaving users without their lovely screens for 30 minutes but preventing server damages, there's a lot that can be done when you have more information. I just hope that, when a security hole is found on Django (not IF. When), we get a good overview of the problem. There are occasions when the official patch is not even worth to apply, because it will break features and there's another way around to fix it. There's a lot of smart folks out there, believe in that :) -- Julio Nobrega - http://www.inerciasensorial.com.br --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers -~----------~----~----~----~------~----~------~--~---
