The following comment will likely be deemed controversial—but also critical to understanding how the open source community operates with respect to security issues.

Recognise that a lot of hype and circus has built up around around the field of ICT security. Linus made a very public and passionate argument in mid 2008 on the topic. Some sample quotes:

So I personally consider security bugs to be just "normal bugs". I don't
cover them up, but I also don't have any reason what-so-ever to think it's
a good idea to track them and announce them as something special.
...
To me, security is important. But it's no less important than everything
*else* that is also important!

―Linus Torvalds[1]

Part of Linus’ argument stems from the bazaar[2] model for developing software. A separate security ecosystem that works in secret and controls the distribution of source code is a throwback to the cathedral[2] model. Linux continues to be a success because it does not use the cathedral model.

Linux development occurs in the open amongst many selfish parties that sit anywhere on the scale between not caring at all about security to being paranoid about security at the exclusion of all other interests. In the middle of this disorder is someone like Linus who is trusted by the community to balance interests. On one side of the debate is PaX/grsecurity (or similar projects) lobbying for more controls and security features in the kernel. This party is generally happier to trade off factors such as performance and ease of kernel maintenance to gain additional security. The other side of the debate may be supercomputing users or embedded platforms who are not willing to trade off performance.

The security hype and circus around security-related bugs can be very dangerous to the ongoing health of open source software projects. I will use the personal example of Mantis Bug Tracker—a project I have contributed to for the past few years. Many of the contributions I have made to the project are security related—XSS, CSRF, access control, cryptography and more[3]. The CSRF protection in particular is a disgrace within Mantis Bug Tracker—for reasons unrelated to security. A few years ago, some forms within MantisBT were protected by CSRF nonces. Obviously this is not a good situation—every form which results in changes to state or data should be protected. I went through every form (grep -PRn "<form") and added nonces. Great! MantisBT was secure. But it was also very much broken. Numerous users started complaining about security error messages informing them of invalid tokens and the the incorrect possibility that they submitted a form twice. The cause? PHP session time-outs were invalidating CSRF nonces and not only prevented users from submitting lengthy bug reports and comments but also led to the loss of that user supplied information. The trade-off between security and usability was (and sadly, still is) broken.

When usability is broken to the detriment of security, the natural and completely understandable user decision may be to disable form CSRF security altogether or switch to another piece of bug tracking software that is less secure—but also more usable. This is a security failure worth being concerned over.

The bazaar model calls for these issues to be thrown out in public on project mailing lists, bug trackers and source code repositories in the hope that a maximum number of eyes will look over the issue and feel a compulsion to assist with patches in the shortest period of time. Hopefully usability issues about any proposed patches are considered as part of this process, preventing the problem I mentioned above with CSRF nonce time-outs. The cathedral model on the other hand prefers to keep these issues secret amongst a select group of self-titled “experts” (core developers or otherwise). The chance of a quick resolution amongst this small group is smaller than if the issue was public with hundreds of eyes looking upon it. There is also a much greater chance that a small highly biased group will fail to correctly consider all the trade-offs.

In summary,

* Recognise that security is a trade-off against other factors and a balance needs to be struck. Bruce Schneier has been repeating this statement for over a decade on his blog. Linus has been proclaiming it on the Kernel mailing list. It is important.

* Know what the bazaar model of software development is, how it works and why the concept of secret walled-garden development communities in a much larger open source project can be considered offensive.

* Software developers have many “most important” problems to deal with at any time and are often volunteering their time. A bad, demanding attitude from a security researcher will not help.

* Security patches do not warrant a Millennium Prize any more-so than a patch to resolve a severe performance regression, data loss bug or major usability issue. Standing on top of a security pedestal in the sky is the antithesis to gaining respect from open source communities.

* Study the work of programmers who are well respected for their knowledge and experience with creating secure software. Some examples are Daniel J. Bernstein (djbdns amongst numerous other projects), Chris Evans (vsftpd), Timo Sirainen (Dovecot), Wietse Venema (Postfix) and Igor Sysoev (Nginx). If you want to make a contribution to ICT security there is no better way of doing it than creating your own secure-by-design software that is relied upon by billions of Internet users each day. The adversarial mindset is important but is not worth much without an ability to practically implement constructive changes.

[1] http://kerneltrap.org/Linux/Security_Bugs_and_Full_Disclosur...

[2] http://www.catb.org/~esr/writings/cathedral-bazaar/cathedral...

[3] Refer to oss-security@lists.openwall.com, mantisbt-dev@lists.sourceforge.net, http://www.mantisbt.org/bugs/search.php?project_id=0&cat...