On Tuesday, March 6, 2012 at 7:11 PM, Russell Keith-Magee wrote: > > On 07/03/2012, at 7:55 AM, Joey Espinosa wrote: > > > I agree with you on some of your points. Security can be improved if people > > would email the support team INSTEAD OF filing a bug report (this goes for > > any project), so that the teams know about security bugs before anybody > > else finds them. > > > > However, if there's a default setting or commonly set configuration choice > > that may be questionable for security, the best course of action would be > > to educate the Django developers and site maintainers on why it is or is > > not a good idea to implement. The Rails community has mentioned the Homakov > > vulnerability to the Rails team, to which their stance has been > > configuration over convention (you're responsible for your own security). > > > > If there's a similar situation with the Django code, and it's something > > that's been put in intentionally by the Django team, then why not educate > > people about this? Better to have a resource somewhere where at least one > > Django developer on a team might have read a good security tip and share it > > with his team, than to have a potential attacker figure it out and exploit > > all of the Django sites that may have overlooked it. To put it in real life > > terms, you don't combat identity theft by not talking about it, you combat > > it by providing resources to educate the general public about how to > > protect themselves. > > Completely agreed that then education is key. However, the key statement in > your reply is "something that's been put in intentionally by the Django > team". > > All I'm asking is before anyone starts broadcasting details about a > "vulnerability", that they take the time to contact the core team on > secur...@djangoproject.com (mailto:secur...@djangoproject.com) to determine > whether the code and it's side effects actually *are* intentional. You > *might* have discovered something that has been done intentionally, with full > knowledge of the consequences. It *might* be a case where we need to rely on > education -- improve Django's own docs, and encourage people like yourself to > blog about how to "do it right". However, it might also be a case where we > hadn't fully considered all the consequences, in which case, we'd like the > opportunity to address the problem before it becomes widespread public > knowledge. > > In short -- err on the side of caution. It costs nothing to mail > secur...@djangoproject.com (mailto:secur...@djangoproject.com). If you have > found a serious problem, we'll give credit where it's due. If not, we'll let > you know you can start educating the world about what they're doing wrong. > > Yours, > Russ Magee %-) > > -- > You received this message because you are subscribed to the Google Groups > "Django users" group. > To post to this group, send email to django-users@googlegroups.com > (mailto:django-users@googlegroups.com). > To unsubscribe from this group, send email to > django-users+unsubscr...@googlegroups.com > (mailto:django-users+unsubscr...@googlegroups.com). > For more options, visit this group at > http://groups.google.com/group/django-users?hl=en. > >
For what it's worth in the context of the Homakov exploit, this has been a well known vulnerability by the rails core for years that they've basically said "not our problem, configure your app better" the entire time. I think that situation is the one that Joey was referring too. -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
