On Tuesday 17 Nov 2009 8:46:31 am Mike Ramirez wrote: > On Monday 16 November 2009 18:08:35 Kenneth Gonsalves wrote: > > On Monday 16 Nov 2009 10:44:27 pm Mike Ramirez wrote: > > > > it is precisely this assumption that does not seem logical to me. But > > > > frankly I do not know how to counter it ;-) > > > > > > How is it not logical? Product A is widely used, Product B is used > > > less. Bad Guy A. is smart enough to realize that product A if broken > > > can be used to gain him more presents because more users have it. > > > > > > so if we follow your logic to the inevitable conclusion, the moment the > > bad guys train their weapons on django it is going to be shot as full of > > holes as drupal (or even phpbb). > > No, I did say 'product A if broken' -- keyword being if. > > But Bad Guy A will try everything to put holes in django, and whats worse > is that he'll have a different perspective than you or I and might see > something that we didn't or someone else didn't and walla, we have a > hole. We all know there is potential for security problems in well > established software that aren't discovered today, because of this and > human error in future revisions and changes. Now am I saying the django > devs are lazy or incompetent? If I really believed that I would be using > something else and calling you all idiots for using a badly developed > piece of software. No, I'm calling them human, if they aren't human, then > well aliens are finally proven. > > > In which case why are the devels focussing so > > much of their time trying to make the app safe and secure? > > Should they not > > be better of lighting candles in the rain and praying that the bad guys > > radar doesn't function? > > I personally am of the opinion that constant > > harping on safe practices and not doing silly things like permitting > > code inside html (for example) will create an inherently safer app - and > > the bad guys will congregate elsewhere. After all bitbucket is big enough > > to be on their radar - and it got hosed - although I hear that was an > > amazon problem, not a django issue (could be wrong). > > > > Open source helps this a lot, lets not forget this. > > PHP application problems that we see are bad coding techniques, mostly in > older software that's been coded since php4 and updated for later versions > of php, which says to me that they didn't take into account half of the > known vulns today because they weren't known yesterday. > > We also have to take into account all the ways a user might try to use our > software, because they are lazy and not always vigilent, which is the main > area that bad guys prey on. For example, redirecting after a login to > break the back button so the next user can't get the login form details. > It's hard to speculate everything a person will do, too many individuals > with different view points. Even using large test groups it's hard be > 100% correct 100% of the time. > > > In the end all you can do is prevent what is known today, hope that you've > covered for tomorrow. >
anyway, in pitching for django (in particular), python and postgresql in general, I put safe code as number one in the list. And I personally am confident (after seeing the work done in the last 5 years in django, python and postgresql) that this will remain. Holes will appear - but I have a feeling they will be few and far between and patched fast too. This is what I tell people. -- regards Kenneth Gonsalves Senior Project Officer NRC-FOSS http://nrcfosshelpline.in/web/ -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-us...@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=.
