django/trunk/django/core/files/base.py -- File, why not a subclass of file ?
Hi ! It might be a stupid question, but is there a reason why `django.trunk.django.core.files.base.File` is not a subclass of `file` ? I ask this because after debugging my code - some urllib2 handler (http://dpaste.com/437031/), based on a snippet I found somewhere - I figured out that posted files were not handled like I wanted to ... just because they were not `file` objects ... Wouldn't it be cleaner that they would actually be `file` objects ? Cheers, Sébastien -- 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 django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: django/trunk/django/core/files/base.py -- File, why not a subclass of file ?
On Mon, Feb 21, 2011 at 8:55 AM, sebastien piquemal wrote: > Hi ! > > It might be a stupid question, but is there a reason why > `django.trunk.django.core.files.base.File` is not a subclass of > `file` ? > I ask this because after debugging my code - some urllib2 handler > (http://dpaste.com/437031/), based on a snippet I found somewhere - I > figured out that posted files were not handled like I wanted to ... > just because they were not `file` objects ... Wouldn't it be cleaner > that they would actually be `file` objects ? Inheriting file may produce behavioral side effects in your class that are hard to predict. The normal way in Python to do this is just replicate the interface and substitute (duck typing). If the snippet you have explicitly checks for inheritance (with isinstance, for example), I'd say the snippet is not very pythonic. I suggest asking how to fix it in django-users, posting a copy/link of the snippet Regards, D. -- 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 django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Pluggable encryption for django auth (design proposal)
Russ, Carl, thanks for your feedback. Russ, I understand what you say about not wanting to adopt crypto code because of the additional responsibility. Unfortunately, there aren't very good options. Django contrib.auth already makes the recommendation of SHA1 which we all agree is less than ideal. There is simply no acceptable choice in the python standard library. I also agree with Carl that PBKDF2 is probably the most conservative option that qualifies as sufficient. It seems like the canonical implementation of PBKDF2 in python is Dwayne Litzenberger's. I think it is simple enough to audit for flaws and stable enough not to cause too much trouble maintaining: http://www.dlitz.net/software/python-pbkdf2/ http://ftp.dlitz.net/pub/dlitz/crypto/pkcs5-pbkdf2/1.2/PBKDF2.py http://en.wikipedia.org/wiki/PBKDF2 I understand that everyone has their hands full with the 1.3 release so I've gone ahead and opened a new ticket to track contributions to this issue off-list. Anyone interested can track contributions there: http://code.djangoproject.com/ticket/15367 Perhaps once the authentication methods are decoupled from the User object as you plan it becomes sufficiently easy for third party libraries to replace the hashing algorithm. If that happens, then this default hashing can be ported to that technique. I do think it is important to make it "easy enough" for a developer to upgrade to a different library of choice. For now though, I'm ok with working on a conservative (but improved) default for Django 1.4. -Paul -- 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 django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Pluggable encryption for django auth (design proposal)
On Mon, Feb 21, 2011 at 3:23 PM, poswald wrote: > Russ, Carl, thanks for your feedback. Russ, I understand what you say > about not wanting to adopt crypto code because of the additional > responsibility. Unfortunately, there aren't very good options. Django > contrib.auth already makes the recommendation of SHA1 which we all > agree is less than ideal. There is simply no acceptable choice in the > python standard library. I also agree with Carl that PBKDF2 is > probably the most conservative option that qualifies as sufficient. I've been desperately trying to get up to speed on this stuff over the past few weeks. Crypto's very far from my strong suit, but I think I know enough now to agree. It seems to me we need two things: 1. A new, updated default for Django's password hashing. PBKDF2, perhaps, but whatever as long as it meets some basic requirements. 2. A mechanism to make swapping this hashing algorithm out easy(-ier). Again, details don't matter, requirements do. #1's a blocker for 1.4, I think, but if for some reason #2 can't be figured out I think it's ok to punt there for a bit longer. Ideally though they'd both go in at once. Now, I want to make very explicit my requirements here since we've gone 'round on this one a few times, so I'll lay out exactly what I'm going to want to see to get on board with any proposal. So: Requirements for a new password hash: * As little crypto code in Django as possible. We're not security experts, and we shouldn't try to be. Ideally would be something that leaves all of the dangerous parts to the stdlib. Perhaps we relax our dependency policy (we need to some day, I think, but that's a bigger argument maybe we shouldn't have now). * Any code we distribute gets audited by people who know what they're talking about. * Those people have reputations sufficient to convince me (or other core devs) that they know what they're doing. This is sorta a "who watches the watchers" moment, but we can't just trust someone who says they're a crypto expert; we have to believe them, too. Requirements for pluggable hashing algorithms: * The big one is cross-installation password compatibility. If I upgrade from Python 2.4 to 2.7 my passwords have to keep working. If I install django-bcrypt my old passwords have to keep working. If I then decide to switch to pbkdf2 my bcrypt passwords have to keep working. We already have an in-place upgrade mechanism for md5; we probably need something similar as a generic thing. * Failures need to be clear - I shouldn't get mysterious login failures if I accidentally uninstall bcrypt (i.e. I should get a loud, clear, failure quickly). * We need an internal upgrade path that *we* can use when a few years from now everyone starts complaining that PBKDF2 is fundamentally flawed and that we're total idiots for clinging to it. [It occurs to me that, with the right mentor, this would make a fantastic SoC project...] Jacob -- 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 django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Your thoughts on the Secure Web Application Framework Manifesto
Django devs, I wanted to thank you for a truly awesome framework. Programming with Python, and web app dev in Django, is truly a pleasure. Our company, Security Compass, uses Django quite substantially internally. We put together a document called the Secure Web Application Framework Manifesto for the Open Web Application Security Project (OWASP) - see: http://www.owasp.org/index.php/Projects/OWASP_Secure_Web_Application_Framework_Manifesto/Releases/Current/Manifesto I would love to get your feedback about this project. How much of this is realistic and how much of it is pie in the sky? Is it relevant for you? If not, how does this document need to change to become relevant? Clearly, Django takes security seriously which is a major reason we use it. Please feel free to be candid - if you think the document sucks and could never be used, it's important you let us know that too. Thanks in advance, Rohit Sethi @rksethi -- 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 django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Suggestion: a new "nature" field in Trac
Hello, I was wondering if others would find it useful to introduce a new field in Trac to characterise the nature of a ticket, allowing to choose from at least: "bug report", "feature request", or "optimisation". I think this would help bring the right focus during alpha and beta stages, and also help people looking for tickets when, for example, they're in the mood for fixing bugs. I believe the Keywords field has been used in an ad hoc way for this before, but it feels that something more structured would be more helpful. Cheers, Julien -- 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 django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Suggestion: a new "nature" field in Trac
On Mon, Feb 21, 2011 at 3:05 PM, Julien Phalip wrote: > Hello, > > I was wondering if others would find it useful to introduce a new > field in Trac to characterise the nature of a ticket, allowing to > choose from at least: "bug report", "feature request", or > "optimisation". Trac already has a "type" field. Default values are "defect" "enhancement" and "task", but that can be changed. I'm not very convinced that people will use it and that it will help, but it's so wasy to add that I guess there's no harm in configuring it. D. -- 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 django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Your thoughts on the Secure Web Application Framework Manifesto
One more point - if any of you have questions for somebody who leaves and breathes web application security every day, please feel free to fire them off to me: rohit at securitycompass.com On Feb 21, 10:21 am, Rohit Sethi wrote: > Django devs, I wanted to thank you for a truly awesome framework. > Programming with Python, and web app dev in Django, is truly a > pleasure. Our company, Security Compass, uses Django quite > substantially internally. > > We put together a document called the Secure Web Application Framework > Manifesto for the Open Web Application Security Project (OWASP) - > see:http://www.owasp.org/index.php/Projects/OWASP_Secure_Web_Application_... > > I would love to get your feedback about this project. How much of this > is realistic and how much of it is pie in the sky? Is it relevant for > you? If not, how does this document need to change to become relevant? > Clearly, Django takes security seriously which is a major reason we > use it. Please feel free to be candid - if you think the document > sucks and could never be used, it's important you let us know that > too. > > Thanks in advance, > > Rohit Sethi > @rksethi -- 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 django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
render_to_* vs Template.render
After hunting down a very elusive bug, I found the cause to be due to the fact that render_to_string leaves the context in a different state than it started (due to the context stack being pushed before rendering, and then not popped). This behavior differs from a standard Template.render call and it seemed like a straight forward enough inconsistency so I committed [1] which changed render_to_string to leave the context how it found it. Being an idiot, I did my full test-suite pass against the wrong branch and therefore failed to heed some warning bells of the impact of this :( I've since fixed the test-suite failures [2] (there's still one outstanding issue [3] although that has an easy enough solution). Anyway, the change in [1] is backwards incompatible, due to the fact that people may be relying on the render_to_string (or render_to_response which uses this method) method leaving the context stack 'unresolved'. Option A is that the change is reverted and the inconsistency between Template.render and the render_to_* methods is documented. Option B is that the change remains and the backwards incompatibility is documented in the 1.3 changelog. (PS: the fixes in [2] are a good addition independent to the outcome of the decision of backwards incompatible change - and actually necessary to avoid the impact of the original problem) [1] http://code.djangoproject.com/changeset/15591 [2] http://code.djangoproject.com/changeset/15618 [3] http://code.djangoproject.com/ticket/15368 -- 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 django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Suggestion: a new "nature" field in Trac
On Tue, Feb 22, 2011 at 2:05 AM, Julien Phalip wrote: > Hello, > > I was wondering if others would find it useful to introduce a new > field in Trac to characterise the nature of a ticket, allowing to > choose from at least: "bug report", "feature request", or > "optimisation". I think this would help bring the right focus during > alpha and beta stages, and also help people looking for tickets when, > for example, they're in the mood for fixing bugs. I believe the > Keywords field has been used in an ad hoc way for this before, but it > feels that something more structured would be more helpful. Back in the dim, dark past, we actually *did* have a 'feature' flag. The problem we had was data integrity. Experience showed that reporters were very bad at differentiating between a "bug" and a"feature". The most common mode of failure was people reporting "Django, can't do X -- this is a bug", and then trying to convince them that lack of features isn't a bug. So, we removed the feature flag. Oh, the good old days :-) However, I agree that this is worth revisiting. Our community is now larger, we have more people to help with the Trac gardening, and there are less "obvious features" that are missing that could be misconstrued as a bug. Most importantly, since our process hinges on a "feature freeze", it is silly that we can't easily differentiate bugs from features in our issue tracker. There's another todo pending in Trac regarding the introduction of a 'needs feedback' state; we should probably roll the reintroduction of a feature flag into this. Russ %-) -- 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 django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Suggestion: a new "nature" field in Trac
On Mon, Feb 21, 2011 at 6:36 PM, Russell Keith-Magee < russ...@keith-magee.com> wrote: > On Tue, Feb 22, 2011 at 2:05 AM, Julien Phalip wrote: > > Hello, > > > > I was wondering if others would find it useful to introduce a new > > field in Trac to characterise the nature of a ticket, allowing to > > choose from at least: "bug report", "feature request", or > > "optimisation". I think this would help bring the right focus during > > alpha and beta stages, and also help people looking for tickets when, > > for example, they're in the mood for fixing bugs. I believe the > > Keywords field has been used in an ad hoc way for this before, but it > > feels that something more structured would be more helpful. > > Back in the dim, dark past, we actually *did* have a 'feature' flag. > The problem we had was data integrity. Experience showed that > reporters were very bad at differentiating between a "bug" and > a"feature". The most common mode of failure was people reporting > "Django, can't do X -- this is a bug", and then trying to convince > them that lack of features isn't a bug. So, we removed the feature > flag. Oh, the good old days :-) > > However, I agree that this is worth revisiting. Our community is now > larger, we have more people to help with the Trac gardening, and there > are less "obvious features" that are missing that could be > misconstrued as a bug. Most importantly, since our process hinges on a > "feature freeze", it is silly that we can't easily differentiate bugs > from features in our issue tracker. There's another todo pending in > Trac regarding the introduction of a 'needs feedback' state; we should > probably roll the reintroduction of a feature flag into this. > > Russ %-) > > -- > 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 > django-developers+unsubscr...@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/django-developers?hl=en. > > I don't think there's much work that needs to be done, it'd take about 20 seconds to do from the web interface if we decide its a good idea. Alex -- "I disapprove of what you say, but I will defend to the death your right to say it." -- Evelyn Beatrice Hall (summarizing Voltaire) "The people's good is the highest law." -- Cicero -- 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 django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Suggestion: a new "nature" field in Trac
I'm still in favor of adding the "needsinfo" resolution and would love to see that happen... I guess technically I could even do that one myself via Trac's web admin if we're all agreed on it. I'm ambivalent about adding the "ticket type" field back in, though. It can be useful, but it *is* an extra item to keep managed and argue about... My bigger concern, though, is the 1700+ existing tickets which will be uncategorized. It would end up meaning that using that flag for queries in Trac wouldn't give you a complete picture (at least not for a very long time while things catch up). All the best, - Gabriel -- 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 django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Your thoughts on the Secure Web Application Framework Manifesto
On Mon, Feb 21, 2011 at 11:21 PM, Rohit Sethi wrote: > Django devs, I wanted to thank you for a truly awesome framework. > Programming with Python, and web app dev in Django, is truly a > pleasure. Our company, Security Compass, uses Django quite > substantially internally. > > We put together a document called the Secure Web Application Framework > Manifesto for the Open Web Application Security Project (OWASP) - see: > http://www.owasp.org/index.php/Projects/OWASP_Secure_Web_Application_Framework_Manifesto/Releases/Current/Manifesto > > I would love to get your feedback about this project. How much of this > is realistic and how much of it is pie in the sky? Is it relevant for > you? If not, how does this document need to change to become relevant? > Clearly, Django takes security seriously which is a major reason we > use it. Please feel free to be candid - if you think the document > sucks and could never be used, it's important you let us know that > too. Hi Rohit, A lot of effort has clearly gone into this document. I haven't gone through it with a fine-toothed comb, but it seems like a reasonably thorough discussion of security issues affecting web frameworks. However, if you're looking for frank feedback, here goes: Who exactly is the intended audience for this document? What is/are the action item(s) stemming from it? More broadly, what it is you are hoping to achieve by writing this document? Reading between the lines, I'm guessing you would like to see every web framework in the world adhering to best practices, with no obvious and know security vulnerabilities. This is a laudable goal, and I certainly share this aspiration. But there are two ways to achieve this goal. The first is to sit in a tower, passing down Solomonic judgements on "the way it should be". The second is to actually get involved and help make the change you want to see in the world. Writing manifestos may give you a sense of personal satisfaction at the volume of material you have generated, but it doesn't actually change the world at all. It merely provides the reference material that others may be able to use to inform the changes that they are making. This is a useful resource, but it isn't *in itself* a catalyst for change. I'm not suggesting that you should spend all your time being a Django developer (although I certainly wouldn't turn away the extra help). My point is that in volunteer open source communities, the only way to actually bring about change is to actively engage a developer community. Become a known, trusted voice -- in this case, on security issues. For example, the Django-dev list has just recently gone through a series of discussions about our default password hashing policies. Some of these discussions have hinged on interpretations of what constitutes best practice in these areas. This would be a golden opportunity for someone with relevant experience and knowledge to speak up, offer advice gleaned from experience with other frameworks, and generally establish topic expertise. There are other examples of people doing this very effectively. Graham Dumpleton is the developer of mod_wsgi. He's isn't a member of the Django core team, but he is *very* well known to the Django community because he is actively involved in our mailing lists, issue tracker, and so on. If a WSGI/Apache configuration related issue arises, Graham is usually there giving advice. And he doesn't just do this for Django -- he lurks in a similar way on other Python frameworks. He is actively involved across the Python web framework community, pushing an agenda that he is passionate about -- the WSGI interface to Apache. OWASP already maintains a list of vulnerabilities, threat and attacks. These are very well documented and explained analyses of individual potential problems, and as a whole, serves as a magnificent reference resource. Compiling this list (or a subset of that list) into a monolithic "manifesto" doesn't improve the quality or prescience of the information. A manifesto is a lovely document that I might read once, perhaps bookmark or tweet, and then move on. That doesn't actually help bring about any change. What *would* help bring about change is having someone with expertise actually getting involved -- participating in discussions, starting new discussions, raising tickets, auditing code when new problems are identified, and so on. tl;dr -- You won't get any argument out of me that the goals of OWASP are important. There are things that are on OWASP's lists that Django could do better. Sometimes this is out of ignorance, sometimes it's a matter of history, and sometimes there are other concerns. But writing long documents describing what other people should do doesn't help change anything -- we need people to actually get involved and engage us in a specific discussions about what we could be doing better. Yours, Russ Magee %-) -- You received this message because you are subscribed to the Google Gro
Re: Your thoughts on the Secure Web Application Framework Manifesto
Russell, awesome feedback. Thanks for being candid. We are on the same page that the manifesto is really not all that important in and of itself: The document piece is really only designed to give frameworks a platform to say "hey, these are what we support" so that web app developers building security-sensitive apps get an idea of how much help they'll get from various framework. I didn't want to bring this up until I got at least one response, but my team is busy seeing which manifesto requirements are: a) Already being fulfilled by Django (great- no more work to be done!) b) Have been fulfilled elsewhere (e.g. OWASP ESAPI for Python) and could be built into Django c) Have not yet been done We'll be looking to address b) and c) by either porting or building ourselves. We hope we can get your feedback on why some things aren't being implemented (if we can't find a pre-existing discussion in existing tickets and/or this group). The manifesto is designed to only a starting point: it's taking several vulnerabilities, beyond the OWASP top 10, into something targeted specifically for frameworks. It's definitely not intended to be implemented by every framework in the world - nor should it be. So, we (myself and at least four of our developers) will be working closely with the Django community. I will be watching the list closely and providing feedback when I can. Looking forward to working with you Cheers, Rohit On Feb 21, 7:42 pm, Russell Keith-Magee wrote: > On Mon, Feb 21, 2011 at 11:21 PM, Rohit Sethi wrote: > > Django devs, I wanted to thank you for a truly awesome framework. > > Programming with Python, and web app dev in Django, is truly a > > pleasure. Our company, Security Compass, uses Django quite > > substantially internally. > > > We put together a document called the Secure Web Application Framework > > Manifesto for the Open Web Application Security Project (OWASP) - see: > >http://www.owasp.org/index.php/Projects/OWASP_Secure_Web_Application_... > > > I would love to get your feedback about this project. How much of this > > is realistic and how much of it is pie in the sky? Is it relevant for > > you? If not, how does this document need to change to become relevant? > > Clearly, Django takes security seriously which is a major reason we > > use it. Please feel free to be candid - if you think the document > > sucks and could never be used, it's important you let us know that > > too. > > Hi Rohit, > > A lot of effort has clearly gone into this document. I haven't gone > through it with a fine-toothed comb, but it seems like a reasonably > thorough discussion of security issues affecting web frameworks. > > However, if you're looking for frank feedback, here goes: > > Who exactly is the intended audience for this document? What is/are > the action item(s) stemming from it? > > More broadly, what it is you are hoping to achieve by writing this document? > > Reading between the lines, I'm guessing you would like to see every > web framework in the world adhering to best practices, with no obvious > and know security vulnerabilities. This is a laudable goal, and I > certainly share this aspiration. > > But there are two ways to achieve this goal. The first is to sit in a > tower, passing down Solomonic judgements on "the way it should be". > The second is to actually get involved and help make the change you > want to see in the world. > > Writing manifestos may give you a sense of personal satisfaction at > the volume of material you have generated, but it doesn't actually > change the world at all. It merely provides the reference material > that others may be able to use to inform the changes that they are > making. This is a useful resource, but it isn't *in itself* a catalyst > for change. > > I'm not suggesting that you should spend all your time being a Django > developer (although I certainly wouldn't turn away the extra help). My > point is that in volunteer open source communities, the only way to > actually bring about change is to actively engage a developer > community. Become a known, trusted voice -- in this case, on security > issues. > > For example, the Django-dev list has just recently gone through a > series of discussions about our default password hashing policies. > Some of these discussions have hinged on interpretations of what > constitutes best practice in these areas. This would be a golden > opportunity for someone with relevant experience and knowledge to > speak up, offer advice gleaned from experience with other frameworks, > and generally establish topic expertise. > > There are other examples of people doing this very effectively. Graham > Dumpleton is the developer of mod_wsgi. He's isn't a member of the > Django core team, but he is *very* well known to the Django community > because he is actively involved in our mailing lists, issue tracker, > and so on. If a WSGI/Apache configuration related issue arises, Graham > is usually there giving advice. An
Re: Your thoughts on the Secure Web Application Framework Manifesto
I've got one bit of feedback to offer on the document (which I did bookmark for future reference): Monolithic documents present a huge problem for finding, using and retaining information. A very useful and interesting extension of this type of project would be to work with people who have experience with information architecture and data visualization to find new ways of presenting this information. An interface that was simple, clear, interactive, layered and multi-faceted would make your manifesto into a drastically more valuable tool. I would love to be able to sit down with an interface to all the information you've gathered and "explore it". Ideally it would allow me to visually follow threads of commonalities in vulnerabilities, see clusters of the most common problem areas, and zoom in to the level of detail you've gathered on any individual item if I so choose. Either way, thank you for providing an interesting resource. All the best, - Gabriel Hurley On Feb 21, 5:09 pm, Rohit Sethi wrote: > Russell, awesome feedback. Thanks for being candid. We are on the same > page that the manifesto is really not all that important in and of > itself: The document piece is really only designed to give frameworks > a platform to say "hey, these are what we support" so that web app > developers building security-sensitive apps get an idea of how much > help they'll get from various framework. > > I didn't want to bring this up until I got at least one response, but > my team is busy seeing which manifesto requirements are: > > a) Already being fulfilled by Django (great- no more work to be done!) > b) Have been fulfilled elsewhere (e.g. OWASP ESAPI for Python) and > could be built into Django > c) Have not yet been done > > We'll be looking to address b) and c) by either porting or building > ourselves. We hope we can get your feedback on why some things aren't > being implemented (if we can't find a pre-existing discussion in > existing tickets and/or this group). > > The manifesto is designed to only a starting point: it's taking > several vulnerabilities, beyond the OWASP top 10, into something > targeted specifically for frameworks. It's definitely not intended to > be implemented by every framework in the world - nor should it be. > > So, we (myself and at least four of our developers) will be working > closely with the Django community. I will be watching the list closely > and providing feedback when I can. > > Looking forward to working with you > > Cheers, > > Rohit > > On Feb 21, 7:42 pm, Russell Keith-Magee > wrote: > > > > > > > > > On Mon, Feb 21, 2011 at 11:21 PM, Rohit Sethi wrote: > > > Django devs, I wanted to thank you for a truly awesome framework. > > > Programming with Python, and web app dev in Django, is truly a > > > pleasure. Our company, Security Compass, uses Django quite > > > substantially internally. > > > > We put together a document called the Secure Web Application Framework > > > Manifesto for the Open Web Application Security Project (OWASP) - see: > > >http://www.owasp.org/index.php/Projects/OWASP_Secure_Web_Application_... > > > > I would love to get your feedback about this project. How much of this > > > is realistic and how much of it is pie in the sky? Is it relevant for > > > you? If not, how does this document need to change to become relevant? > > > Clearly, Django takes security seriously which is a major reason we > > > use it. Please feel free to be candid - if you think the document > > > sucks and could never be used, it's important you let us know that > > > too. > > > Hi Rohit, > > > A lot of effort has clearly gone into this document. I haven't gone > > through it with a fine-toothed comb, but it seems like a reasonably > > thorough discussion of security issues affecting web frameworks. > > > However, if you're looking for frank feedback, here goes: > > > Who exactly is the intended audience for this document? What is/are > > the action item(s) stemming from it? > > > More broadly, what it is you are hoping to achieve by writing this document? > > > Reading between the lines, I'm guessing you would like to see every > > web framework in the world adhering to best practices, with no obvious > > and know security vulnerabilities. This is a laudable goal, and I > > certainly share this aspiration. > > > But there are two ways to achieve this goal. The first is to sit in a > > tower, passing down Solomonic judgements on "the way it should be". > > The second is to actually get involved and help make the change you > > want to see in the world. > > > Writing manifestos may give you a sense of personal satisfaction at > > the volume of material you have generated, but it doesn't actually > > change the world at all. It merely provides the reference material > > that others may be able to use to inform the changes that they are > > making. This is a useful resource, but it isn't *in itself* a catalyst > > for change. > > > I'm not suggesting that you sh
