On Wed, Apr 23, 2014 at 04:36:05PM -0700, Charles Swiger wrote: > On Apr 23, 2014, at 1:21 PM, Erik Cederstrand <[email protected]> wrote: > [ ... ] > >> Not only are both of these shorter and they pass clang's static analyzer without a warning, I'd argue that the second version is noticeably cleaner. > > > > I don't disagree with you, but rewriting 1000 if-else cases in single-threaded userland programs just so the analyzer understands them is 1) tedious and 2) bound to accidentally introduce at least 50 new bugs, since most real-life examples are considerably more complicated than the minimal example I posted. > > > Any change comes with some risk. > > If you want to say that fixing minor issues like not free()ing memory or explicitly close()ing a FD rather than just exit()ing and letting the system clean up afterwards is not worth bothering in something like cal or some other utility that isn't running root or setuid, doesn't listen on the network, doesn't process untrusted data, etc...well, OK-- by themselves, such things probably are harmless. > > However, being sloppy about fixing warnings from the compiler or code analyzers seems to be habit-forming. > > And as you start moving towards software which does run with elevated permissions, or acts as a network server, or processes random multimedia files from untrusted web pages (I'm thinking a codec like VP8), much less is used to provide transport layer security for credit card and banking transactions, well, you also move from harmless to Heartbleed. Compiler warnings and static code analysis are a small part of a secure programming mentality/methodology, and in and of themselves are fairly useless. I doubt either would have caught Heartbleed. We've been warned about SQL injection and other related flaws for years, and yet people STILL don't do proper validation of untrusted input. Until we get the basics correct, the rest doesn't really matter. e.g. it doesn't really matter if your code passes gcc -Wall -Werror when you can still take input from the wire and pass it straight to a SQL statement, or use it to calculate how much data to send back to the client, when the data requested can exceed the maximum valid response size by several orders of magnitude. Even worse when the protocol design allows for such a request in the first place. Too many programs think it's fine to replace the system malloc/free functions with their own versions because of performance or other reasons, potentially removing yet more layers of protection, or at minimum introducing more points of failure that need to be examined and tested. I also think we're getting off topic. Any concrete steps people are willing to take to make FreeBSD more secure? Gary _______________________________________________ [email protected] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-security To unsubscribe, send any mail to "[email protected]"