Kernel Trap Interview with Theo de Raadt

An anonymous reader writes "KernelTrap has an insightful interview with Theo de Raadt, creator of OpenBSD. The wide-ranging interview focuses first on the past few years of OpenBSD development, then moves on to the recently released OpenBSD 3.9. De Raadt talks about how binary blobs threaten free software, and how OpenBSD developers work to reverse engineer them. He also talks about the future of OpenBSD, his views on Linux, and why developing truly free software is so important to him."

Comments

Theo

[Anonymous Coward]

Weird... was Theo having a bad day? He's always seemed like such a nice guy, but in this interview he really comes off like a total a-hole... very un-Theo-ish.

Re:Theo

[grub]

He's always been cordial when I've had dealings with him. In fact recently on the misc@ list I mentioned problems with getting both cores on an AMD64X2 going with 3.9, pasted dmesgs, etc. and he wrote me off-list suggesting I compile up to -current. His suggestion worked and saved my sanity.

Re:Theo

[MerlynEmrys67]

Here is the problem with Theo. He is smart and opinionated. Having these two things in common make him a very difficult person to get along with if you are either Smart, but hold a different opinion because you come from a different set of assumptions - but especially if you are NOT smart and opinionated.

I have had discussions with Theo about trying to get my current employer (at the time) to open up documentation so OpenBSD could write drivers for our hardware. Lets just say I failed (Sorry Theo - I really tried, to the point that my annual raise was affected by it). However I found Theo to be very supportive and personally agreeable to me - I assume he realized I was trying to help and doing the best I could.

I can imagine people that are fighting against things he is trying to do could see him in a negative light - but again... I see the same kinds of things said about all of the great ones.

Re:Theo

[ArbitraryConstant]

I've witnessed him being an asshole.

Having to deal with him regularly might not be fun, but sometimes it takes assholes to get things done because they're prepared to piss people off to do what needs doing. If the goal were to make OpenBSD into another Ubuntu or Gentoo, his attitude probably wouldn't be that helpful, but for the goals they have it seems to work.

Re:Theo

[jo42]

Thank Gawd he's not a limp-wristed, touchy-feely, mamby-pamby, pear-shaped, wet noodle.

Re:Theo

[laffer1]

You got to be kidding me. Theo's got a serious attitude problem. He told me if he ever met me, he'd kick my ass because I didn't know who he was when I first got into FREEBSD! I had a confrontation with him on freebsd-questions early on. Granted I didn't know what the hell i was talking about at the time, but he went on another bsd's mailing list and insulted their users. Intelligence has nothing to do with knowing about a specific thing. I wasn't up on bsd history then. I've met many smart people doing IT work that couldn't read their email. I don't think they are automatically stupid as a result. (Doctors, lawyers, etc)

If you need further proof of Theo's attitude, look up the history behind him leaving NetBSD. You'll find that he co-founded NetBSD, had a fight with the rest of the core team and ended up fork()ing OpenBSD. I don't think he was completely in the wrong, but he didn't handle it very well either. I'm sure there was more too it than that. I don't blame theo for controlling OpenBSD the way he does. He got burned once and Linus has a firm grip on the Linux kernel as well. Even FreeBSD has a rough track record with developers, look at Matt Dillon's situation and his DragonFly fork.

I think most open source developers can be real dick heads. We are often opinionated and think we are always right. We also love attention.. hell its free software, what else will we get out of it. (except the people who write books to profit...) I'm including myself in this group. It takes arrogance to create/fork an operating system or develop a programming language. (Larry Wall, Theo, Linus, etc)

FCC Rules

[jusdisgi]

I sure wish he had taken a better position on the wifi "FCC Rules require Binary Blobs" issue. He basically agreed that the FCC does require that the consumer not be able to change the frequency, but claimed that it should be dealt with in hardware, not the driver. This line is particularly poorly thought out: "Let the FCC go after the vendors who made the flawed devices."

See, here's the thing...the people he needs to convince here are the hardware manufacturers. You aren't going to get them to release open drivers by suggesting that the FCC should "go after" them. In fact, it serves to reinforce their binary-blobs-only position; after all, that's their current protection. But worse, by tacitly agreeing with their position about the FCC rules, he cedes the important part of the argument...the part where he could have won it. That's because while the FCC does indeed require that the consumer not be able to change the frequency to licensed spectrum, they have never taken the position that changing the source code is normal consumer operation. After all, consumers can change the frequency on many other chipsets (even in Windows) with binary patches. This is simpler than changing source code and recompiling it. I have never heard anything from the FCC that says you can't distribute source code with this functionality. Which is good, because the current mainline Linux kernel does distribute code that does this. If FCC rules actually forbade this (as the hardware companies are claiming) then it would be illegal to distribute the Linux (and presumably OpenBSD) kernel in the USA.

There was a wonderful discussion of this on the LKML recently in context of Intel's binary blob driver.

Re:FCC Rules

[Homology]

See, here's the thing...the people he needs to convince here are the hardware manufacturers. You aren't going to get them to release open drivers by suggesting that the FCC should "go after" them.

You did not really read that article, did you? OpenBSD wants hardware documentation, and besides, why should I as an EU citizen care about FCC regulations?

Re:FCC Rules

[TigerNut]

As a current and past employee of several companies that make wireless transceivers subject to FCC licensing, I can tell you that there is no cost effective way to limit a device to FCC restrictions purely in hardware. Example: A cellular radio or any other modern RF link uses a synthesizer to set the transmit frequency. The output frequency of the synthesizer is a function of the reference frequency and the programmed divide ratio, and the total span of achievable output frequencies is dependent on the VCO that the synth is controlling. The maker of the synthesizer is not usually in a position to dictate the exact reference frequency, nor the VCO that it's hooked up to. The VCO vendor doesn't dictate the type of system that it will be installed into, and therefore can't strictly limit the frequency that it will tune to - and even if they did know exactly where it was going to go, then production tolerances dictate that you have some tuning margin in the design to allow all parts to hit the specified span. That means that individual parts will be tunable outside of the specified span on either the high or low side, and if the micro that controls the synthesizer commands a frequency outside the FCC limits, a lot of the time the hardware will have no problem doing it.

The same thing applies generally to power output levels. Sophisticated radios have some spare margin in the transmitter power output, and the actual output power level is calibrated at manufacturing time and then set in a FLASH based lookup table. The output power is then controlled using the embedded micro, driving a DAC. In this system, having open code on the embedded micro means that an uncaring individual could just crank the power output without regard for the FCC requirements.

You can say what you want about the motivations and ethics of the OpenBSD team members - if the source is out there, there will be others that take advantage of any "gains" they could make by tweaking some tuning parameters beyond the design or regulatory limits.

Ask Theo de Raadt how long it took him to get from his buffer-overrun Sun console hacking days to where he is now - almost everyone goes through a phase where "Just because I can" is sufficient justification to do poorly thought out things.

Re:FCC Rules

[jusdisgi]

You did not really read that article, did you? OpenBSD wants hardware documentation...

I did indeed read the article...I just recognized the larger issue that was not explicitly stated therein. Yes, what he really wants is documentation, although I'm sure he would be just as happy if they simply released the source to their binary blob. In any case, the reason he wants documentation is so that FOSS developers can write a completely open source driver for their hardware. The reason the hardware manufacturers refuse is ostensibly that it would violate FCC rules. The argument for that is that the FCC prohibits devices that the consumer can change to a licensed frequency. TFA actually discusses this.

...and besides, why should I as an EU citizen care about FCC regulations?

Surely you are just making a joke, and are not so utterly naive. You'll note that Theo is Canadian, but he obviously seems to care. When you find a wifi chipset that isn't sold in the USA at all, let me know. Until then, the restrictions placed on hardware and software manufacturers by the US government will continue to have a strong impact on FOSS users, regardless of where they live. This is an excellent example; you aren't under FCC jurisdiction, but you're still stuck with binary blob drivers from companies that claim it's their only method of FCC compliance.

Re:FCC Rules

[jusdisgi]

Now damn it, this is completely wrong. Read my other reply to your previous, identical statement, which I posted before you posted this. Our laws impact you because the hardware manufacturers want to sell their stuff here. So you are stuck with FCC compliant products, regardless of whether you are under FCC jurisdiction.

Re:FCC Rules

[drinkypoo]

That would limit the possible frequencies but do nothing for the power levels. The FCC not only limits which frequencies you're supposed to be able to use in the US, but also total output power levels which depend on the antenna fitted. For instance if you use a primestar dish with a coffee can, and have super high gain, you are required to turn down your transmission power to be within FCC regs. Also, it would require additional hardware, which would cost money.

Re:FCC Rules

[TigerNut]

Filters limit the frequencies that a system can broadcast or receive, but they also have an insertion loss penalty. This reduces the efficiency of the system significantly - if a given filter has 1 dB insertion loss (which would be pretty good, implying that the filter probably costs a decent amount of money) then it would impart a 20 percent reduction in power output. Therefore it would cost you 20 percent more current, at least, to get the same RF range. That would (a) decrease the battery life and (b) increase the heat load in your system.

Wireless system designers use filters already to limit out-of-band emissions, but the problem is that no practical filter has a 'brick-wall' response where the passband ends exactly at the edge of the allowed spectrum. In a typical 2.4 GHz wireless network system you could probably go outside the band by 10 MHz before the filter rolloff became significant. With that freedom, an enterprising wireless LAN operator could set up his own little playing area away from everyone else's interference - but he'd be tromping on some unsuspecting folks.

Re:FCC Rules

[jusdisgi]

In the article he mentions open source drivers written under NDA that are essensially unmaintainable, whence of dubious quality.

No he doesn't. He says "Some Linux (and recently FreeBSD too) developers are willing to sign NDAs so that a few people get the documentation, and I believe that this is the largest problem facing the kernel side of the open source community today." Now, you'd have to ask him to clarify to be certain, but I would say the chances are extremely slim that he's talking about people writing open source drivers under NDA. Mostly I say the chances are slim because that's a totally ridiculous idea that no hardware company would consider; if you're going to let somebody write an open driver, what's the point of an NDA? On the other hand, I am familiar with at least one case (madwifi) where a developer (Sam Leffler) signed an NDA in order to produce a binary blob and an open-source interface component for a chipset (atheros) which had no driver available. I think it is extremely likely that these situations are the ones to which Theo referred.

As for FCC regulations and me as an EU citizen: I don't have to comply with FCC regulations while not in USA. The same goes for strong encryption. In this sense I don't care about FCC regulations. That US based companies think that I should care about FCC just means I go elsewhere with my money.

Your ignorance and lack of thought are astonishing. "US based companies" have nothing to do with it...where else are you going to go with your money? Every wifi chipset manufacturer sells its products in the US, and thus abides by FCC rules. The manufacturers in question here are mostly Taiwanese. The issue here is that, regardless of where a company is based or chooses to make its products, it invariably wants to sell those products in the US. Thus the manufacturer must comply with US regulations. So it doesn't matter whether you have to abide by US regulations...the people who make the products you use do. And once again, this is a great example. You can't have a certain driver, because it doesn't exist, because (ostensibly) of US regulations. Therefore US regulations impact you. Period.

Re:FCC Rules

[jusdisgi]

See, you're missing the point here. It's not whether a consumer might be able to violate FCC regulations. It's the fact that manufacture of a device that allows the consumer to transmit in a licensed band is itself a violation.

In other words, the manufacturers are prohibited by FCC rules from making a device that a consumer can run in a licensed band or at a higher-than-allowed output power. However, the part the manufacturers are ignoring is that the FCC seems to mean this in the context of the normal consumer-level interfaces, which doesn't include the source code. Changing the source code would be abnormal activity not sanctioned by the manufacturer and outside of normal use.

Re:FCC Rules

[LWATCDR]

Maybe but then that hardware could only work in one market so it would cost more.
Also if you put in a hardware filter it would "absorb" some of the power that they device uses to transmit. So you would get a weaker signal or have less battery life. Also it wouldn't limit the power of the transmitter.
In short if you put the limits in hardware the produce would cost more, have a smaller market, and use more power. It just wouldn't be as good as a card that does everything is software.
It would fail on the market because as a product it would suck. It could have open source drivers with the current FCC rules but it would still not be a good wi-fi card.

I think a better solution is a stable binary driver interface for Linux and BSD. Just like the video card situation the current system of trying to "force" hardware manufactures to open source their drivers has not worked.

Re:FCC Rules

[HardCase]

FCC rules does not apply to me, so why should I care about those restrictions? This is similar to use of strong encryption and US regulations.

EU rules don't apply to me, but I care about RoHS restrictions because manufacturers tend to design to the most restrictive set of regulations that will apply to a product. Same deal with FCC regulations, in a broad sense.

-h-

Re:FCC Rules

[Kadin2048]

I'm not sure if you're being intentionally thick or what. FCC regulations cover more than just how a device can be used, they affect every stage of its design, and the market that's controlled by the FCC is a pretty big one. You over in Europe may think that what the FCC does isn't relevant to you, but I can guarantee you if you turn over a few peripherals you have on your desktop, that you'll see "Tested to Comply with FCC Standards: For Home or Office Use."

Because hardware and device manufacturers don't want to have to make multiple versions of their product if they can avoid it, chances are they're going to make it compliant to the largest number of regulatory bodies that they possibly can. Hence why my mouse is manufactured in China but approved according to regulations in the U.S., Canada, Germany, the E.U. (separate from Germany), and a bunch of Asian ones I can't read. And that's without even counting the non-governmental certifications (UL, CE, etc.).

An FCC regulation that changes something fundamental about how electronic devices have to be made is almost sure to affect people everywhere in the world, just like the E.U. RoHS rules are going to change the stuff I buy here in the U.S., even if we as a country didn't give a damn about how much hazardous substances were in our electronics. (We do, we're just taking our time about it.)

So while the FCC doesn't have any direct authority outside of the U.S., it affects how lots of things which end up on the world market are made, and you'd have to be pretty naive to just ignore that.

Financing?

[AltGrendel]

...I swear I will never get over how incredibly much money a University acting as a middle man between DARPA and us can bleed the flow of financing.

Any idea who he's refering to?

Re:Financing?

[kevin_conaway]

About 15% of the funding, awarded in mid-2000, had remained unspent, de Raadt said. According to de Raadt, two days before the funding was cut off, Jonathan Smith, the computer science professor in charge of the project at the University of Pennsylvania, phoned de Raadt. Smith told de Raadt that several people at the university and DARPA were uncomfortable with de Raadt's antiwar comments, which appeared in The Globe and Mail of Toronto in early April.

Source

Re:Financing?

[Anonymous Coward]

All of them. In grant financing, the institution will often take a percentage of the gross, as large as 48%, or more in some cases. It's justified under a multitude reasons, e.g., management, common facilities, name, reputation, goodwill, etc.

Sometimes these funds get funneled back through deans to dept. chairs and, yes, the even PI as a salary bonus, thereby allowing them to write a larger salary number in the next grant.

I'm not saying it's right but that is the way it is.

Re:Financing?

[Arandir]

...but i still think that OpenSSH funding should be more important than such political quarrels.

So how come no one's blaming Theo then? If it is true that his attitude lost him his funding (which isn't demonstrated, btw), then let's blame the attitude. You don't tell someone to fuck off and then expect them to fund you.

Department of Redundancy Dept.

[scottennis]

I thought "blob" stood for "binary large object."

So isn't it redundant to say "binary blob"?

Re:Blobs eh

[A Boy and His Blob]

Indeed, I can confirm this.

We don't buy hardware that OpenBSD doesn't support

[linuxbaby]

Though we only use OpenBSD on a few of our servers (we have about 150 servers) - we NEVER buy hardware that OpenBSD doesn't support, because to us that's a good test of whether this hardware is going to last or not.

If a hardware company is so proprietary or secretive or locked-down that OpenBSD can't (or chooses not to) support it, I don't believe that company will last in the long run.

Great Interview...

[link915]

This was an excellent interview and Theo seemed fairly down-to-earth. I actually agree with many of Theo's POV's but don't always agree with how he conveys them. This interview seemed to show his *softer* side :)

Honestly though, he is right...the big Linux vendors really needed to step up and donate to the project. I am a FreeBSD user and certainly understand the need for funding to keep these projects going. OpenSSH is an amazing piece of software that we all use quite a bit. I can't say that I give all of my money to these projects but I do purchase CD sets and can only hope that the rest of you do as well.

I guess sometimes we are all dicks when we really believe in something. Although Theo can come across as a dick sometimes he really does stand for a good cause. Software should be free!

Re:NDAs are a big problem?

[drinkypoo]

Theo apparently feels (as I do) that the more we support vendors who refuse to just open up their specs, the less vendors will open them up. If Linux is taking over the server market (it is) and they need to open their device specs up to have them supported (they don't, if people will go NDA) then more companies will open up their specs so that they can be supported by linux - because companies like to minimize the variety of hardware in their organization for support reasons, and they are more likely to spec a single NIC that works in all situations (if available) than spec two different ones, one for Linux, and one for Windoze.

As long as people develop drivers for these products through reverse engineering or NDA, then these manufacturers will have no reason to release specs.

The reason companies do not open up their drivers

[Anonymous Coward]

The fundamental reason why companies do not open up their drivers is because the average end user considers it a Linux problem when Linux doesn't have proper support for a given proprietary piece of hardware, instead of a problem with the maker of the chipset in question.

I think one reason for this is because there are a zillion consumer devices out there and no real place to be able to look up a given piece of consumer hardware and see who is making the chips for said hardware, and whether the chipset in question has a Linux driver. More importantly, if a given chipset doesn't have a Linux driver, the documentation should tell us whether this is because the chipset in question is closed, or if it is because no one has had a chance to write a driver.

If this information is out there, when people give the usual "Linux sucks because it doesn't support X piece of hardware" flame, the reply can be "blame the makers of X piece of hardware, not Linux". If this mindset catches on, companies will start supporting Linux better. For example, I bought a Creative Zen Nano instead of an iPod Nano because the Zen had full Linux support; the iPod doesn't.

The problem with making this online database is that someone will need to be motivated to make such a database; this is a non-trivial task. The wiki model is perfect for something like this. Indeed, someone has a wiki-based database like this for IBM Thinkpad computers

Re:We don't buy hardware that OpenBSD doesn't supp

[idontgno]

If a hardware company is so proprietary or secretive or locked-down that OpenBSD can't (or chooses not to) support it, I don't believe that company will last in the long run.

OpenBSD confirms it. Adaptec is dying.

Re:So petulant and arrogant.

[Craig Davison]

Come on. He's asking for money, not code changes. On that level, GPL-licensed code and BSD-licensed code are the same. A company like Linksys could use the Linux kernel in their routers without giving a cent to Linus or the hundreds of others.

There's nothing wrong with _asking_ for contributions. He knows that nobody owes him anything, and that jackasses like you will give him nothing but hot air, probably all the while logged into an OpenSSH server somewhere.

Re:So petulant and arrogant.

[Anonymous Coward]

Oh my, you really don't have a fucking clue, do you?
The OpenBSD project's recent funding problems have absolutely nothing to do with licensing; zero, zip, nada. The problem is not companies (Linux vendors, Cisco, Sun, etc.) modifying OpenSSH and without releasing changes publicly. The OpenBSD/OpenSSH project doesn't care about that, they expect it to happen. The problem is with said vendors using, redistributing and profiting from OpenSSH without making even a modest monetary donation in return. Given this, please, enlighten me as to releasing OpenSSH under the GPL would have any impact on this? Where in the GPL does it state that all redistribution and/or modification requires supporting the software's developers financially?
You think expecting a little money for something you poured blood, sweat, and tears into is "arrogant"? How about including open source software in almost all of your products (Cisco, Sun), and not giving a penny back for being given the opportunity to do so? Of course you have no obligation, but given the fact you're profiting off of this software, wouldn't it be wise to donate something (money, hardware) to the developers so that the software you're profiting from can continue to be developed? Some companies/projects have: GoDaddy and the Mozilla foundation. And hopefully more will in the future.

Oh, and whoever modded the parent up as insightful needs to be hit with a cluestick.

Re:So petulant and arrogant.

[hahiss]

Agreed; this analogy is utterly awful! Not only is there this unhealthy response to prostitutes (someone needs to get some therapy. . .), the *ENTIRE* analogy doesn't work:

A prostitute is someone who gives what they otherwise wouldn't (sex) in exchange for cash. Theo gives his software away for free, to anyone, to use as they wish.

Now maybe you (GP) think the Free Software isn't a sound business strategy, and maybe you think Theo's a jackass---and heck, maybe you think he's getting what he deserved because he didn't demand that corporations leave their cash on the nightstand ahead of time [THAT'S how you make a prostitution reference!] but holy crap son could you find a way to say that without invoking repellant examples that contradict your point completely.

Re:So petulant and arrogant.

[mobby_6kl]

>A prostitute ... gives what they otherwise wouldn't ... for cash. Theo gives his software away for free, to anyone, to use as they wish.

So, he's a slut?

Re:NDAs are a big problem?

[J.R. Random]

The very fact that an NDA is used means that the manufacture knows that the writer of the driver needs facts that can not be determined by looking at the source of the driver itself. Typically this involves the use of various magic constants that must be loaded into device registers at appropriate times. The manufacturer knows what the magic constants mean. Hopefully the writer of the driver does too. But nobody else does, and the author of the device driver can't tell them. So if there's a bug (maybe because the magic constant wasn't quite the right one to use in certain circumstances) there's no way for another person to fix it. Likewise if there's a desire to expand the functionality of the driver there is again no way for a third party to know what the magic constants should be.

Overhead rates

[alexhmit01]

Universities have an overhead level, including salary fringe, etc., that then gets estimated. If the university's overhead rate is 65%, then for every $1 in grant money, 35 cents goes to cover DIRECT costs of the work, and 65 cents go to the University Overhead Income Account.

Basically, things like lab space may be direct or indirect (overhead) costs, depending on setups.

Given that they weren't on staff so there was no fringe (taxes, benefits, etc.), and they weren't using any school resources, maybe they got a discount and a 45% or 50% overhead rate.

Essentially, in grant accounting, you have to account for your direct expenditures (and get reimbursed from the grant issuer), but the overhead you keep. So the university wants as high an overhead rate as possible, as they keep that money. The researchers that "earned the grant" want the lowest rate possible, so more of the money goes into their accounts for their expenditures (you know, things like their salaries).

Also, if grant money is spent on not-aprroved things (let's say Theo calls 25% of his house his office, but the grant doesn't cover the home office, or he hires a project manager and that isn't approved for the grant), then the school won't be able to get reimbursed for those expenditures. Each organization's politics determines what happens when the school "eats" the costs (part of why they have such a high overhead, they cover over-runs, etc.), but in this case, it was an outside organization. I wonder how comfortable the University was cutting checks to Theo's personal account without knowing that they would get reimbursed, so they probably kept a high reserve that they wouldn't release, and a large overhead rate.

Ah, grant accounting...

Alex

Re:So petulant and arrogant.

[OttoM]

The problem is not the other open source projects. It's the commercial Linux and Unix vendors (and other as well) that use all the benefits of OpenSSH, but do nothing in return. To name a few: IBM, HP, Cisco.

Re:So petulant and arrogant.

[akpoff]

When Theo or the other OpenBSD folks complain about projects taking without giving they know what they're talking about. Theo knows for a fact whether Sun or other companies have donated to the OpenBSD project.

If you were minded to you could find out for yourself what Theo has contributed. Scan the source tree of just about any project the OpenBSD team ships and hunt for openbsd.org. If by chance you don't find anything then search again for "De Raadt" or some of the other developers' names. More likely than not you'll find code contributions.

If that's not enough, look at the number of companies Theo and his team and users have lobbied to release documentation thus helping all projects. Note also the Free Software Foundation and others respect and have honored Theo's work and contributions. In 2004 the Free Software Foundation presented Theo with the FSF Software award

For recognition as founder and project leader of the OpenBSD and OpenSSH projects, Theo de Raadt's work has also led to significant contributions to other BSD distributions and GNU/Linux. Of particular note is Theo's work on OpenSSH. Theo's leadership of OpenBSD, his selfless commitment to Free Software and his advancement of network security, were cited by this year's award committee.

Try google -- it's your friend when you have these kinds of questions.

no

[r00t]

Usually documentation does not exist. Under an NDA, the company can supply hardware design plans and Windows source code instead.

Re:You are a little confused.

[Homestar Breadmaker]

Unfortunately, its not so simple. Many of the optimizations required serious recoding of gcc, making it MUCH slower to compile code, even when you don't have any optimizations turned on. Notice how gcc3 is twice as slow as gcc2? Notice how gcc4 is even slower?

OpenBSD code auditing?

[raw-sewage]

TFA had a typical comment from Theo or any OpenBSD core team member: "As we become aware of more problems in the C language, we are trying to be very agressive to make the code cleaner. Just the standard OpenBSD proactive auditing process."

My question is this: what is the "standard OpenBSD proactive auditing process"? Before, I've lightly asked about this on the misc@ mailing list, but the answers weren't very helpful, generally paraphrased as (1) experience or (2) study the CVS diffs.

Well... that's nice, but I'd like to have a more straightforward "beginner's approach", something a little more accessible. I agree that only experience will make you a truly great secure and correct coder, but it would be nice to have a book that explained (and gave examples) of the kinds of things that the OpenBSD developers routinely look for in their code audits.

Put another way, I feel I have a good understanding of the fundamentals of secure C programming: generally prefer strncpy() (or strlcpy()) to strcpy(), know when to use memmove() or memcpy(), always check input parameters to make sure they are within the defined boundaries of the function, etc... but surely there's more than just these well-known general rules of thumb, right? It would be nice if core OpenBSD developers could have their secure C programming expertise dumped into a book!

Re:Compilers

[mccoma]

It seemed to me he was more concerned that the correctness of the generated code was being compromised by the optimizations. I would expect the would love a small, correct compiler that they could add various security enhancements (e.g. stack protection) in a straightforward manner.