It really is a shame that browsers have such a terrible UI for HTTP auth.

I don't totally agree with this (HTTP digest auth, while silly, is still better than the crazy Javascript hashing schemes), but the logic is, it is difficult to "log out" and manage sessions with HTTP auth.

Speaking as FreeBSD Security Officer: Several of the top security firms provide ratings which reflect the quality of their checklists more than the quality of the security in the systems they're assessing. The FreeBSD security team recently dealt with a case of "if you don't fix this, people using FreeBSD will lose marks on PCI audits" -- and our answer was "screw the auditors, this isn't a security issue and we're not going to send out a bogus security advisory just to keep some idiotic auditors happy".

Second, seperate PCI auditors out from security audits (though Hacker News readers should be familiar with both). I agree with your sentiment regarding PCI auditors. (PCI, for those who don't know, is the Payment Card Industry standard you get audited against if your application accepts credit cards).

Third: like it or not, when you get dinged on a report like that, you can lose a sale. "Hah-hah!", Colin says. "Screw the auditors!" But Colin, and FreeBSD at large, loses nothing from failing an audit. Want some horror stories about people who do lose?

I'd elaborate, but I don't know the context of the finding you were dealing with. If it was, "FreeBSD needs to get rid of the %n token", the auditor was right, and you were wrong. I'd be surprised if it was that simple, though.

It wasn't that simple; but in any event, do you seriously think that FreeBSD should stop supporting a feature which (a) people have been using for two decades, and (b) is required by POSIX?

If I was going to make FreeBSD more secure by removing features, I'd start by removing the boot loader -- which would render the system utterly useless, yet very secure. If someone wants to shoot themselves in the foot by using a feature incorrectly, we're not going to stop him -- but we will do our best to make sure that the gun doesn't explode if someone looks at it oddly. (I think the X11 people called this the "tools, not policy" approach.)

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.

OpenBSD made vast, sweeping changes to their code to minimize and mitigate security problems. Have you read privsep SSH?

How much third-party code links to your unsafe libc? How could you know? You think it's more sound to rely on every undereducated third-party developer to make the right choices about using your libraries, than to simply scrub out the seventeen (17. really.) places in your own code that use an apocryphal and dangerous printf feature, so you can eliminate it?

You're way out of step with the rest of your peer group, which appears to have learned not to trust random developers to use C libraries safely.

I love that argument. "Bad programming? Use good programming. Not our fault." By that logic, there's no security benefit to writing web apps in Python over C.

Go back and read what I wrote. There are 17 places in the FreeBSD base system where %n is used in a format string. I have no clue how many times it's used in code in the FreeBSD ports tree, or in 3rd party code which isn't in the ports tree -- and I'm not going to go and break lots of perfectly good code just because someone might shoot themself in the foot.

Anyways, this is a tangent. It's amusing that you can stick up (in some sense) for clientside Javascript security, which is at least 0.0001% more secure than plaintext, but at the same time conduct protected arguments in the mailing lists about why CPU features should be turned off, lest someone ever figure out a way to make an attack you helped research become feasible.

I don't understand the all-or-none attitude that appears to be prevalent in the security industry. For all the discussion spent on search spaces, and maximizing attack effort, there doesn't seem to be much acceptance for "good enough" security. There appears to be this attitude that -- to use wireless security as one example -- "WEP is broken, so you might as well just run a totally open network."

I see that when you say that anybody that can sniff traffic for stupid JavaScript hashes can also necessarily inject traffic to alter the negotiation between the host and the client. While in theory that's correct, in practice it ignores the difference in the number of people that know enough to execute either attack.

It makes sense to say, "If you're going to do password encryption, you might as well do it right", but I don't think it follows that even a stupid JavaScript MD5 hashing scheme is as insecure as plain-text password transmission.