This points to a seriously broken process.
This points to a seriously broken process.
In my opinion, the fact that someone bothered to comb through 2.3.x and 3.0.x to find exploits similar to the last one points to a very good process, not a broken one.
The issue is that similar projects, with similar success, with a similar number of developers looking at them, have fewer severe vulnerabilities.
The simplest explanation is that one project has more vulnerabilities lying dormant.
When a particular bit of code gets audited, you tend to find a bunch of holes. And any time you find a conceptual mistake that was made once in code, odds are that a careful audit will find it repeated.
Everyone thinks that they are different, until it happens to them.
http://www.hnsearch.com/search#request/submissions&q=dja...
Django has had its fair share of patches. This is no reflection on the quality of the project, as it shouldn't be for any sufficiently complicated framework (like Rails).
I also think the vulnerabilities are similar enough to suggest that the first one gave valid reason to ensure the same issue doesn't occur elsewhere. Rather than dusting these issues under the rug or silently fixing them, they're being responsibly reported with patches and updates provided at the same time.
This doesn't seem like broken process to me.
http://www.cvedetails.com/vulnerability-list/vendor_id-12043...
http://www.cvedetails.com/vulnerability-list/vendor_id-10199...
Django has 16 vulnerabilities of the DoS, XSS, and CSRF variety.
Rails has 37. In addition to DoS, XSS, and CSRF, it has SQL injection and code execution.
That we keep seeing similar vulnerabilities suggests the problem is systemic.
Giving them praise for not sweeping these under the rug is giving someone praise for not being a sociopath.
Not all Django vulnerabilities have been discovered or reported yet. Just because no one has found or reported a vulnerability, doesn't mean that it it doesn't exist.