Why you shoud never use your favorite password on News.YCombinator.com

Again: unless there are two Colin Percivals working on FreeBSD, you tried to remove Hyperthreading from FreeBSD to "save" your users from a crypto timing channel attack that has never been seen in the wild. Reconcile that with standing fast on format string apocrypha of the sort uncovered by "Month of XXX Bugs" fuzzers.

Are you sure you're still speaking as FreeBSD Security Officer? I may quote you on some of this in the future.

When you design software, you have all sorts of assets you'd like to protect, even for the simplest cases. Administrative access, general data, CPU cycles, workflow, network bandwidth, and maybe even passwords, secrets, etc. Your job (with a security design hat on) is to place the firmest obstacles you can between those assets and those you don't want to use them (usually prioritized by a combination of probable risk, severity of loss, and cost to protect).

Thinking in terms of assets you need to protect is a highly recommended way to design securely, regardless of whether you're talking about military, bodyguards, buildings, software, cryptography, or systems. You then proceed to put up your best obstacles and then reshore/rebuild/redesign those obstacles when they are known to be compromised or compromisable. All the while ensuring that the system operates as efficiently as you can reasonably manage.

Fixing "a buffer overflow" is just a method for repairing the software obstacles you already had in place. Sanitizing inputs is, indeed, adding an obstacle for attackers. "Proving code paths" takes into account that your obstacles remain in place to protect your data with certain assumptions about the systems involved.

If you're interested in security engineering in general, I recommend picking up some of the latest (last 5-10 years) literature on Threat Modeling as it really can change one's perspective on what security is all about. A lot of engineers I've worked with think of it in terms of "using the best string library", when it's more about designing systems to protect your assets as best as you can and still get your job done.

There are all sorts of practices, tools, fixes, libraries, etc that help improve existing "bricks" in your obstacles, but they're absolutely no replacement for actually understanding what you're trying to protect and having a strategy for preventing those from being compromised. The best security is designing such that you never put your assets at risk than that you use the right libraries to, for example, manage them during transit.

"if you have to explain to yourself what a "salt" is, or you can't spell "nonce", you shouldn't be designing security systems."

No, I don't have to explain to myself what a salt is, though my "Here's how I understand it" introduction probably mislead you into thinking that. The only reason I said "Here's how I understand it" is that initially I wanted to explain both what a salt is (a notion I certainly understand because I read about it and implemented it) and what a nonce is (a notion I probably don't understand because I didn't really read about it and didn't implement it).

I know I still have much to learn but at least I know what I don't know with respect to nonces, and I find it pretty lame that you're saying I shouldn't "design security systems" just because I can't spell a word properly for a technique I just admitted I "never used and can only make guesses [about]"

I've been working like crazy for the last 2 years to learn everything about Common Lisp and making websites and you're saying I should give up everything just because I still have things to learn?!

You can't judge someone's skills just by looking at a data point like that. The concepts of closures and macros are now completely automatic and obvious to me but I wouldn't call someone who never heard of it or has just a basic understanding of it "someone who should never program". Of course I'd point it out if they said they had a firm grasp of it while it was obvious that they didn't.

I just did a quick grep of /usr/src and counted 17 places where %n was used in a format string -- fairly equally split between printf and scanf. I don't know what sort of mutant you think I am, but I don't have that many fingers on my right hand.

And that's not even counting all of the 3rd party code which gets run on FreeBSD (including the 18000+ programs in the ports tree) which make the perfectly reasonable assumption that FreeBSD's printf(3) conforms to POSIX requirements.

you tried to remove Hyperthreading from FreeBSD

No, I didn't. I turned it off by default. There's a big difference.

Are you sure you're still speaking as FreeBSD Security Officer? I may quote you on some of this in the future.

Here's a quote for you: As FreeBSD Security Officer, I do not believe that POSIX-mandated features should be removed in an attempt to make foot-shooting harder. The printf and scanf family of functions are dangerous, and should NEVER be called with a format string provided by a potential attacker or constructed from data provided by a potential attacker.