Nick Coghlan, 11.05.2014 01:01: > As you point out, most language development teams do very little to try to > educate their users about security issues. The consequences of that are > clearly visible in the world around us: when security is treated as an > optional afterthought, you get widespread deployment of insecure software. > > At this point, we have two options: > > * continue with the same model as everyone else, and treat security as an > optional extra users should feel free to ignore (or treat as an advanced > topic only specialists need to worry about) > > * change our documentation practices to try to encourage the growth of a > security aware development community around Python, trusting that our users > will recognise that the security issues we're discussing are inherent in > the way computers work, rather than being specific to Python. > > I'm obviously a strong advocate for the second path. Users aren't stupid, > they'll figure out that almost all the security concerns we're warning > about are inherent in the problem being solved, rather than being a > Python-specific issue. Even if I know the problematic parts of a certain corner of software development or just of a specific tool, I prefer reading in the documentation that the authors of that tool are also aware of the (potential) problems. Makes me feel more comfortable with trusting the software. Total +1 on keeping these little bits around. Stefan
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4