Hello Luke and others, On Jun 13, 2012, at 1:16 AM, Luke Plant wrote: > On django-core we've been discussing an issue that was security related. > However, we decided it wasn't urgent enough to warrant a security > release, and so we're moving the discussion here (especially because we > couldn't agree on what to do).
Especially after seeing Jessica McKellar's keynote at Djangocon EU, on the experience of novice developers when using Django, I strongly feel we should not leave the situation as it is. Although this risk and it's mitigations may be obvious to people on this list, a more novice developer using Django is much more likely to overlook this issue. Many have made valid points that option two, three, or any other, may be seen as difficult for the developer. And that may motivate developers to use any of the mentioned Python one-liners to revert functionality back to the existing situation. However, with any system we devise to make anything secure, there are lazy shortcuts to break that security. But if we do nothing, everyone will be exposed to this risk. If we tighten security, and some projects will use methods to revert this security improvement, all the others are still more secure than before. Obviously, it's also our role to make sure we provide proper example code in the documentation. Basically, even if every existing Django project would, being lazy, use these one-liners in their existing forms and therefore receive no security benefit from this change, we would still be making an improvement for all the new projects to be started. Having said that, there's the question of option two or three. If most forms we use in our Django apps already exclude one or more fields today, there is little to no extra effort in option 3 compared to option 2 - as those forms would require the same work when Meta.exclude is dropped. If the effort for both options is equal (for the developers), then I figure option 3 would be best. Looking at my own projects, all editing of data in ModelForms is tied to authentication, with a FK to the user. Which means all my ModelForms use Meta.exclude already. Therefore, there is no difference in effort between option 2 or 3 for those apps. But my apps are just a small sample. Summary: I feel we should tighten this. The fact that this will be worked around by some, is not a reason for me to simply do nothing. When considering option 2 vs 3, we should, probably, also consider the actual impact: how often do we create ModelForms with neither Meta.fields nor Meta.exclude today? cheers, Erik -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
