Derek Buitenhuis <derek.buitenh...@gmail.com> writes: > On 8/16/2014 11:27 PM, wm4 wrote:
>> That is very valuable advice. We'll get to work right away. > I've added it to my TODO: > * Don't write bugs. That's a really bad way of avoiding security bugs. I'm sure you know that and are just being flippant, but I have to say that, as an outsider to the project who would like to use the software but who cares a lot about not introducing security weaknesses, it's hard to shake the feeling that this dismissive attitude is part of the problem. There were earlier responses in the thread along the same lines, arguing that the nature of FFmpeg means it will just inevitably have a bunch of security bugs. This sort of learned helplessness is really off-putting. Thankfully, I get the impression from other research that I was doing that it's *not* typical of FFmpeg as a whole, and that you all are, in fact, doing exactly the sorts of things that I would recommend. So this is probably just one of those pointless Internet arguments where everyone says things more aggressively than they actually mean them, and much heat is created with little light. But, for the record, what I was actually getting at is that the way to avoid a bunch of security bugs is not to stop writing bugs, because no one is going to achieve that. It's to put in place supporting infrastructure that makes it easier to write secure code and harder to write code where bugs create security problems. Trying to be closer to perfect in the code you write is a horrible way to achieve security. It doesn't work. Adding surrounding protective structure to the code so that the bugs do not compromise security, and putting systems in place that let the computer do lots more security sanity checking for you, are how other projects with similar challenges have achieved considerable improvements in security bug rates. In case there's anyone reading this who doesn't have a feel for what this looks like, the process the LibreSSL project is going through (regardless of one's opinion on the desirability of an OpenSSL fork) is very interesting. I've personally learned quite a bit from it, have now introduced reallocarray in my own code, and am planning on introducing strtonum. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/> -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/871tsg81dc....@hope.eyrie.org