
Security process for Open Source Projects - craigkerstiens
http://alexgaynor.net/2013/oct/19/security-process-open-source-projects/
======
einhverfr
It's a good article. What we have done for LedgerSMB is to try to have a 48
hour immediate response guarantee, a 7 day reproduction guarantee, and a 30
day fix or workaround. Usually things have moved much faster (and unless the
problem is complex, we usually have a fix within 7 days).

The big problem we have been facing is that after our initial efforts to
secure the application, we have run into fewer and fewer classes of
vulnerabilities that we have to worry about and these are more and more
complex to exploit. Our new code is verifiably SQL injection free with only a
few areas requiring periodic manual review, and SQL injections even if they
could occur, would be far more limited in scope than they were in previous
versions.

Consequently, it is easy to let things fall through the cracks particularly as
security gets very good. We have, truth be told, had problems there.

We periodically review CVE's for related software to see if we missed
something that might have otherwise been missed. We have found items that have
fallen through the cracks in this way.

But regarding why folks should care, if you look at

[http://secunia.com/advisories/product/11786/?task=advisories](http://secunia.com/advisories/product/11786/?task=advisories)

and compare with

[http://secunia.com/advisories/product/11926/?task=advisories](http://secunia.com/advisories/product/11926/?task=advisories)

Which will you choose for your business?

------
yeukhon
This is probably a response to the node.js vulnerability fix this weekend.
Major projects should do that already.

~~~
w0rd-driven
"In the case of yesterday's Node.JS release, which did not practice complete
disclosure, and did put the fix in a larger patch, this did not prevent
interested individuals from finding out the attack, it took me about five
minutes to do so, and any serious individual could have done it much faster."

I'd say you're spot on. I'm sure this wouldn't be the last "this is how you
should _really disclose_ " posts either. I prefer that approach to just
lamenting about how terrible it was and fortunately there are many great
examples to draw from.

~~~
einhverfr
There have been cases in LedgerSMB where we have had to do something like
that. The SQL injection fixes in 1.2.0 were too numerous to backport without
extensive beta testing, and the new permissions management system in 1.3.0
could not be backported for similar reasons. In both cases, the same
workarounds were suggested.

However, those really should be rare cases.

It is worth noting that while we could not backport our anti-CRSF measures to
1.2, we did provide separate fixes to the most severe CRSF vectors (like those
which could lead to account takeover).

