本家インタビュー： OpenBSD開発者Theo de Raadt
「スラッシュドットはLinuxの話題に偏りがちなので、BSDも」というお声をいただいたので、以下の通り、本家掲載のOpenBSD開発者Theo de Raadt氏のインタビューを翻訳してみました。しかしながら、如何せんちょっと古い記事なので、お詳しい方は、事情が変わっているところなど、コメントでご教示ください。
さて、いつもの通り、たくさんの方々のご協力で翻訳が仕上がりましたことを感謝いたします。1) コード監査についての書籍は？
LizardKingによるあなた、もしくは他のOpenBSD開発者の方が（あるいは共著とか）セキュアでバグフリーなコード作成と監査についての書籍を書くつもりはありますか？ ほとんどのプログラミングの本には教育目的のサンプルコードが載っています。ほとんどの場合、そんなコードはセキュアなコードのあるべき形とは正反対に、ただ動くだけのもので、多くのプログラマの知識に欠陥を残していきます。コードの監査やコーディング時にセキュリティ上の落し穴を回避する方法についての本はあなたがたの生活を楽にするでしょう――OpenBSD用に監査するコードの量を減らし、素敵な新機能に集中する時間を増やすという形でも！
テオ君：
提案してくれた2つの話題にはたぶん隔たりがある。一つは、原作者がセキュアにコードを書く方法としての、セキュアなコーディング。もう一つは、監査、つまり部外者（あるいは関係者のうち誰か）が後になってコードに残っているごみくちゃをきれいにしようとする過程。問題の一部はたぶん、この2つの間に大きな違いがあるということだ。でも結局、そんな話題について扱った本では、徹頭徹尾、2パラグラフ毎に、同じことをくり返し書く必要があるだろう：
いまコーディングしているインターフェイスを理解しろ！
いまコーディングしているインターフェイスを理解しろ！ と。
俺達がソース・ツリーから監査であぶり出したほとんどのセキュリティ上の問題（あるいはただのバグも）はそこから来ている。問題となったコードを書いたプログラマは不注意なのろまで、自分が使っているインターフェイスに注意を払わなかったのだ。ソース・ツリーのそこらじゅうから繰り返し同じ種類のバグが出て来るという現実から俺達は、ほとんどのプログラマが（間違った）用例でコーディングを学んだのだということを知った。堅固なシステムを作るには「動くんだからいいじゃん」という土台で取り組んではいけない。にもかかわらず、何度も何度も、ほとんどの人々がそういうやりかたをするのを目にしてきた。連中は良いソフトウェアには関心がなく、「仕様通り動く」ソフトウェアにしか興味がない。だからプログラマ達はそんな失敗をし続けられるのだ。そんなわけで、俺は単に悪魔が潜んでいる場所を詳細に教えるだけの本を書くことにはそんなに興味を持てない。今になってもその場所を知らないのなら、他の仕事（きっと引き起こすであろう損害が小さいやつ）を探すべきだ。
2) それ以外もセキュアに
squiggleslashによるOpenBSDは「独創的」なセキュリティと、組み込まれたツール群がありうべき形の中で最もセキュアであるということについて、なるべくして好評です。しかし、portsシステムはセキュアなアプローチが現在制限されている例でしょう――OpenBSDをインストールして、INN（InterNetNews: http://www.isc.org/products/INN/）のようなポピュラーなサードパーティのソフトを使う場合、INN（あるいは、そういうサードパーティのソフト）を監査するのはBSDの領域から外れるので、そのていどのセキュリティにしかなりえません。
聞きたいのは、OpenBSDチームとして「セキュアなports」ツリー、もしくは何か同様のシステム、を作るにはどうしたらいいか調べるように依頼をされたことがあるかどうかです。そうすることで、OpenBSDのようにセキュアなプラットフォームを運用したいと考えている人々がプラットフォームと同様に多くのアプリケーションに信頼を寄せることが確かなものとなるでしょう。
テオ君：
俺達は、およそ300MBほどになったメインソースツリーで新しいアイディアについて調べたりするのでもう手一杯だね。他にも、ちょっと前に、あるコンポーネントについてXFree86とちょっと関わったりした。これ以上に他のコンポーネントを監査するなんてちょっと非現実的だね。問題を困難にしているのは、コードの分量そのものだけでなく、他にもあるね。いろんな理由で、こういう外部パッケージのメンテナとのコミュニケーションが困難だったりするし。人によっては、俺達がLinuxって言わないからって聞く耳を持たなかったりするんだよ。移植されてくるソフトウェアパッケージの中には、でかすぎて、標準的なシステムとしての品質から本質的に程遠いものもある。
でも一番大事なことなんだが、俺達だって人間で、楽しく人生過ごそうとしているし、いつもいつも心がはやってて吐き気がするようなサイテーなプログラマのゴミに、動かさなければそれで済むのに、突然800時間もムダにするようなことはない。
俺達の監査者がコードを見て、「おや、こいつぁひどい」って言って使うのを避けてしまうということはしょっちゅうあると思う。このやり方が気分のいいものじゃないだろうというのは分かっているが、んじゃ、なんて言ったらいいんだい……
3) OpenBSD，セキュリティ，その他
jdによるSGIのB1コードのリリースや、多くのUNIXがケーパビリティ、ACL（Access Control List[アクセス制御リスト]）等々によってその内容物をセキュアにしようとする試みがありますが、OpenBSDでは、資源制御の課題にどう取り組んでいるのでしょうか？
余談ですが、OpenBSDが分散型カーネル（distributed kernel）の方向に進むということはあるのでしょうか？ もしそうならば、セキュリティや資源管理はどのように維持されるのでしょうか？ （これは集中型カーネルのシステム[central kernel system]でも十分に難しいことです。）
テオ君：
最初の質問について、オレンジブックの世界に対して大きな誤解があるようだ。多くの人は、オレンジブックをセキュリティについての規定だと思っているが、それは違う。その大部分は、脅威にさらされた場合の説明責任（accountability）についてのものだ。つまり、実はシステムをセキュアにすることについての話じゃない。システムのセキュリティがいつ破られたかを知ることについての話だ。全然違う話なのだ。口角泡を飛ばして「すごい」なんて騒ぐ前に、商業的に展開され、実業務に使われているCや、Bや、さらにはAのシステムがどれくらいあるか数えてみることだ。一方で、オレンジブックに描かれていた世界の一部が、現実のシステムに、実際に使われるのを徐々に見ることになるだろうと思う。ところで、ACLが挙げられているのには驚いたよ。なんせ、それは実際のところB1システムには何の関係もないものだから。
二つ目の質問について、私は分散型カーネルが何なのかまるで分からないし、そういった類のものがシステムのセキュリティや品質を向上させるなんて思わないよ。
（※訳註： オレンジブックとは米国防総省のTCSEC（Trusted Computer System Evaluation Criteria [信頼できるコンピューターシステムの評価基準]）のこと。表紙がオレンジだったのでその名がある。レベルの高い方から順にA, B, C, ... とレベル分けをして、それぞれのレベルをさらに1, 2, 3, ... と細分化した。B1というのは大分類Bレベルの小分類1レベルという意味。）
4) フォークと協調
PapaZitによるOpenBSDはNetBSDからフォークし、いまだに、この2つのグループ間にはかなりの敵意が存在することは多くの人に知られています。個人的な考えですが、その競合は、双方のグループに役立っているのではと思っています。（例えば、現在ではNetBSDでもオープンなサービスはかなり少なくなっています。）
エゴというものはデリケートなものですが、将来には大規模な協調が行われる機会があるとお考えでしょうか？ それとも、さらなるフォークや分裂は避けられないものでしょうか？
テオ君：
考えてみろよ。NetBSDは、OpenBSDプロジェクトのネットワークに4年程もブラック・ホール・ルートを続けてやがるくせに、どうやったら高いレベルでの協調なんていうもんができるのか、おれは理解できないね。
まあ、被っているプロジェクトに首を突っ込んでいるデベロッパもいるな。いろんなグループとのトラブルのことで文句を言っていた奴もいたけれども、
このところは、ちょっとは落ち着いてきたようだよ。最近じゃ、デベロッパの結びつきってものは、政治的なことで決まるものじゃないのだね。
Linuxの世界じゃ、金銭的な問題でプロジェクトにフォークが起こるようだよ。BSDの世界では、ほんと純粋に政治的な問題でフォークが起ったみたいなんだけどもね。今後何が起こるかなんか、俺にはわからないよ。かれこれ、BSDキャンプでは5年もフォークが起きてないしね。しかし、何であんたらはそうフォークにこだわるんだ？ あんたらは、皆に同じ政党に投票させたいとでも言うのかね？
5) カーネル設計
laertesによる私は当面の間だけOpenBSDを使っているだけなので、間違った仮定で質問しているなら許してください。
OpenBSDのカーネル設計はモノリシックの類に入ると思います。OpenVMSとNTは2つともマイクロカーネル・アーキテクチャを用いた素晴らしいオペレーティング・システムですね。私にはマイクロカーネル設計というのは、特権的なコード部分が少ないため、本質的により安全なものに思えます。さらに複数のサーバ部の1つが危険な状態になっても、損害は最小化されるのです。
私の質問はこうです。OpenBSDの設計は本質的に安全なのでしょうか？ それとも基本的には欠点のある設計だけど、うまくつくろった実現例にすぎないのでしょうか？
テオ君：
それで何が違ってくるってぇのか、さっぱりわからねぇな。あんたのコンピュータの先生って、80年代に書かれた本で教えてたんじゃねえのか？ あの頃はマイクロカーネルって言葉だけで、未来のユートピアだったんだぜ。NTがマイクロカーネルだなんて嘘だろう。OpenVMSもそうだって、あんたほんとに信じているのかい。マイクロカーネルってのは、ローダブル・モジュールで仕事をするカーネルじゃねぇんだがなぁ。まぁな、システムがするべき仕事をちゃんとやってるんなら、そこになんか違いがあるってのがわかんねぇなぁ。
6) コード監査の訓練はどこで学びましたか？
EXTomarによるコードを監査する原動力は、必要性によるものでしょうか、それともBSDの設計から来たのでしょうか？ あるいはもとより思いつきなんでしょうか？ 何より、どこでそれを学んだのでしょうか？ 共に見ている「先達」がいらっしゃるのは、めりはりのある設計のためなのでしょうか？ あなた方チームの圧倒されるようなコードのレビューには、感服せざるを得ません…自分にもあれほどの精細なコーディングの素質があれば良いのですが。
テオ君：
監査過程は、自分たちのOSの質を向上させようという欲求から生まれた。最初にそれを始めたときは、魅惑的で、楽しくて、そしてかなり狂信的に近いものがあった。約10人がその共同作業に携わって、原則としてお互いに教えあいながら事を進めてきた。「ホール」や「バグ」といったものより、ソース・コードにおけるプログラマの基本的な誤りや杜撰な点を探した。ずぼらな点を見つけるたびにソース・ツリーを繰り返したどるということを、ずっとやっていたのだ。プログラマが犯した誤りを見つけるたびに（たとえばmktemp(3)を使ってファイルシステム競合が起こるような場合）、ソース・ツリーを最初から最後までたどって、それら「すべて」を修正する。そうやって一つ直すと、他にも基本的な誤りを見つけるだろう。そうしたらまた「すべて」を修正する。そう、大変手間のかかる作業だ。でもとてもただならぬ見返りがある。ボーイングの技術者が、発生した配線の不具合を「すべて」は直さなかったらどうなるかなんて想像できる？ 少なくとも、ソフトウェアも同じようにやるように試みましょう。
7) Firewall/NAT box
yamlaによるLinuxには、FreeSCO（フリースコ）という、3.5インチ・フロッピーに入る、ルータやNAT（ネットワーク・アドレス変換==rfc1631）として使えるものがあります。私はいつもOpenBSDにもこういうものがあったらいいなと思っていました。というのも、こういった（NATやルータとしての）用途には、LinuxよりOpenBSDの方が信頼できるからです。
こういうものを作る計画はありますか？ もっと簡素なユーザ・インタフェイスで素早く容易に設定できるようなものはどうでしょう。OpenBSDは大好きだし、手で設定したいけど、忙しくて。
テオ君：
まず言っとくけど、フロッピー・ルータとか好きじゃないんだよね。基本的に、あんたは一番信頼ならねぇ記憶装置を使おうとしてんだぜ、さらにその上にセキュリティの基盤を築こうとしてる。容量の小さいハードディスクでも買えよ。CDと、（フロッピーじゃなくて）ちゃんとした記憶装置を使ってやるんだったらまだまともだろうよ。でも、頼むから、フロッピーはやめてくれよ。madなの？
8) コード監査
ATによるコードを監査するに当たって、何かアドバイスをいただけませんか。今までバグを見つけてきた経験から有用だったtipsや方法に関して教えていただけるとありがたいです。出来立ての若いコードの場合は、まずどこを探りますか？ 古いコードの場合は？
テオ君：
一番のtipsは、今よりももっと良いプログラマになる、ってことかな。特に、対象のプログラムがどんな関数を使っているのか調べることと、そしてその関数の決まりごとをきっちりと守って使っているか確かめることが重要だ。これを読む人の中の果たして何人が、libcのすべての関数の完全で正しいセマンティクスを知っているんだろう。全部と言わずに、今監査しているプログラムの中で使っているlibcの関数についてだけでも、ちゃんと分かっている人はどれだけいるんだろうね。（どういうことかって言うと、今までソース・ツリー全部を調べてきて、strncat()やstrncpy()の呼び出しのだいたい半分は微妙に間違っていて、一文字余計にコピーしちゃってヌル終端しなくなるだけだとしても、それはやっぱりいい具合じゃないってこと。）
APIを完全に身に付けた時に、簡単にバグを見つけることができるようになるだろう。勤勉さが必要な他の仕事と一緒だと思うよ。注意深くあって欲しい。人は前例から学ぶものなのに、依然としてソフトウェアプログラミングの世界では、その途方もない複雑さが見つけにくいバグを生み、それはさらに新しいコードにコピーされているんだ。関数を間違って定義したマニュアルを見つけたことすらあるんだけれど、その時には多くのプログラマが、間違ったマニュアルに重ねて間違ったプログラムを書いていた…。
9) デュアルプロセッサ対応
dragonfly_blueによるOpenBSDを2CPUや4CPUのマシンで動かすことに興味があるという意見が散見されますが、こういったことをするために必要な情報も、手を挙げる人も少なすぎるようにみえます。私はOpenBSDをwebサーバに使用していますが、この点については全くといってエキスパートではありません。でも、それでもなお興味津々なんです。
聞くところによると、マルチプロセッサ対応は、特に競合状態をはじめとして多くのexploitを引き起こす可能性があるので、実装にかなりトリッキーなことをしなきゃいけないそうですね。OSの全体の整合性に妥協することなしにSMPのためにコード・ベースの多くを書き直すのはものすごい量の時間と労力が必要になることも理解しています。
以上を念頭に置いて、2CPUや4CPU対応に本腰を入れるためにどういったリソースが必要になりますか？ それから、そういったリソースが無尽蔵に使えるとして、-stableリリースが出せるようになるまでにどれぐらいの期間がかかるでしょうか。将来、マルチプロセッサに対応するのが本当に楽しみにしています。もちろん、現在開発チームが十分忙しいということも分かっています。
テオ君：
今のところ、俺達はSMP対応の作業はしてない。こいつは、ものすごく手がかかるし、俺達はそれほど興味がないんだよ。わるいね。
（※訳註： 「OpenBSD SMPプロジェクトで、作業は継続中ですが、まだ、現時点では使用可能なマシンは何もありませんし、OpenBSDのSMPサポートのスケジュールも出せる状況ではありません。ほとんどのプラットフォームで、OpenBSDはSMPマシン上でも動きはするでしょうが、ひとつのプロセッサしか利用できません。」faqの8.12（日本語版）参照。ソース・ツリーに初めてSMPタグが打たれたのは2000年2月12日のこと。SMP Projectのページ。）
10) タイム・ワープ
rhoによるテオの業績に感謝を。私は、OpenBSDをワークステーションとして、またファイアウォールとして毎日使っています。警官がスクリプト小僧を追っかけている柄のTシャツも最高ですね。
もし、時間をOpenBSD開発の始めに戻せて、そこに至った主義主張の話を無視したとすると、何か違ったことをしたいですか？ 商業版に焦点をおいたでしょうか？ SMPの開発を、もっと早く進めましたか？ それとも、両手を振り回しながら、ぐるぐると駆け回りますか？
もう一つ質問は、OpenBSDの商業利用に関してどのように感じているか。つまり、支持しているか、我慢しているかとかの話です。もうちょっと良い例だと、私がOpenBSDの走るセットトップ・ボックスを作ったとして、OSに機能Xを果たしてもらいたいとします。で、あなたに電話して「テオ、OpenBSDでXをサポートして欲しいんだが」と言ったとします。どんな答えが返ってくるんでしょうか？ 「あっち行け」？ 「自分で書けよ」？ それとも「金払えばOpenBSDチームでやるよ」なんでしょうか？
テオ君：
俺達のコードのライセンスはごく単純だ。俺達は、ベンダーにコードを使って貰いたいと思っている。商用OSにOpenSSHを載せて出荷して欲しいと思っている。SSHの類を載せずに出荷するのは悲劇をもたらすし、それはSSHの終りの時だ。
同じことがOpenBSDでも言える。ある会社が商用ネットワーク機器を組み上げるのなら、一から書き上げた独自OSを使うよりは、OpenBSDを使ってもらう方が好ましい。たいていの場合、それらの会社は問題をアプリケーション空間で悠々と解決している。たとえ、それらの会社で汚い独自OSの歴史があったとしても、同時にもっと酷いアプリケーションの歴史もあるもんだ。
ルータ、ファイアウォール、電話交換機、ファイルサーバおよびその他もろもろの機器において、信頼でき、それらに感心をもつ人達によって設計された構成要素を使えば、もっと状況はよかっただろうに。
だから、どんどんやってくれ。OpenBSDのどの部分でも、商用システムに組み込んで構わんさ。
11) 完全な情報開示とバージョン番号付け
Effugasによるまず最初に、OpenBSDの構築に費したあなたの労力に感謝します。OpenBSDは、本当に良いパッケージだと思います。
OpenBSDにおけるほとんどのセキュリティ強化は、ソース・コードから安全じゃないライブララリ呼び出しを洗いだす作業にすっぽりと覆われているわけです。しかし、この作業はもちろんありがたいのですが、最近になって、こういった変更は必ずしも文書化されてないし、アプリケーションやユーティリティのバージョン番号に確実に反映されていないという事実が、だんだん気になり始めています。
バージョン番号は、コード・ベースの存在期間の中で特定のスナップショットを反映するものです。それらは、安全ではない版を参照したり、特に安定版を参照するのに用います。番号のメジャー番号は分岐を示し、マイナー番号はコードの特定の状態を表します。それが、ユーザや管理者がバージョン番号を見た時に期待するものです。バージョン管理に粒度を与えなければ、その番号を信用する／しないの理由がなくなります。個人的にソースを検査して、最終的には自分流のバージョン番号を与えることになるでしょう。
あなたとチームは、コード検査の主幹です。安全な構築物用の変更コードとオリジナルコード（さらに敷衍すれば、あなたの安全なコードと多くの無名の配布者による「とりあえずコンパイルできるようにした」改変物）とを区別できなくして名前空間を汚染するのではなくて、改変したすべてのパッケージに関して名前の拡張をし、完全な情報開示の意図の下に、そこに含まれる妥当な変更履歴を提供するのがスジではないでしょうか？
テオ君：
OpenBSDのすべての構成要素に、二つの番号がある。一つは、どのリリースに含まれるかを示す番号で、例えば2.8とかだ。
もう一つは、構築に使われたすべてのソースファイルが持つ番号がある。その番号は、それらから構築されたバイナリにも含まれている。どのバージョンのソースファイルからそれぞれのバイナリができているかは、what（マニュアルセクション1）コマンドを使えばわかる。
オリジナルに関しておっしゃっているが、オリジナルというのは存在しない。OpenBSDは、独自の構成要素をもっている。あなたがどのパッケージを意図しているか私にはわからない。catはcatだし、ftpdはftpd、tarはtarだ。特定のリリースに関して言えば、一つしかない。系統だったアプローチだと、他のグループのやっているバージョン番号付けは、不正な場合がある。なぜなら、ライブラリなどの部分全部を、一つの構図にまとめてしまっているからだ。
この間乗った飛行機の前輪が、バージョン2.7だったか2.9だったか？ 気にしないだろ？ それでもだ。それが完全なことを保証するために「系統だったアプローチ」とやらが使われていることを気にしているわけだ。そして、OpenBSDの場合は、それは特定のバージョンを選び、パッチを当てるということを意味する。
これ以上を望むのならば、俺達により多くの作業をバージョン管理を費して、それだけシステムそれ自体にかける時間を減らすことを望んでいることになるんだが。
12) お金はどこへ？
MrSparklerによるリリース毎のCD売り上げが10000枚近くになるというレポートを見ました。Tシャツやポスターの売り上げ、寄付金をあわせるとある程度まとまった金額がOpenBSDの周りを流れていることでしょう。このことと、小切手の宛名がde Raadt氏であるという事実を考えあわせると、資金がどのように扱われているのか、疑問を感じます。不正が行われているなどというつもりはありません、ただ誰がお金に責任を持っているか、OpenBSDプロジェクトが非営利組織（NPO）として登録されているのかどうか（もしそうなら、小切手はその団体に振り出されるべきではないか、CDイメージはその団体の著作物とされるべきではないか）ということを知りたいのです。また、ユーザが自分たちのお金がどこへ行ったのか分かるような簡単な財務レポート（アルバータのNPOであれば要求されるであろうもの）を見たいのです。加えて、リリース毎に何枚のCDが売れたのか正確に知りたいのです。
OpenBSDプロジェクトの開発者達が注ぎこんだ業績に感謝していますし、この質問への答えに関わらず、これからもOpenBSDを使い、購入し、寄付し続ける（そして技術的スキルが身につけば参加する）つもりでいます：本当のところ、お金はどこへ消えるのですか？
テオ君：
俺達はリリースあたり10000枚のCDを売り上げたことはない。もうすぐそうなるだろうけど。プロジェクトは、最終的にはCD売り上げ収入の50%よりわずかに少ないくらいのお金を得る。Tシャツ事業はうまくいっているけど、布地を売ったところで儲けはほんのささやかなものだ。ポスターでは差し引きゼロからわずかに上ってところだ。そりゃいくらかはWebで売れるけど、ほとんどは数多くのカンファレンスで無料配布される。それが俺の計画したポスターの使われ方だ。
俺達はNPO化については検討したことがあるけど、あまりいいアイディアじゃない。全く何の現実的な利益も――あなた方に対して、ということだけど−もたらさない。特にカナダでは、NPO化にはコストと重大な責任が要求される。多くの自由を手放さなきゃならないし、繁雑な経理のために誰かを雇わなきゃいけない。それに、多くの寄付金がカナダ国外から寄せられているから、あなた方に課税対象となるような利益も生み出してやれない。（そして俺はあなた方に尋ねることになる、本当の寄付でなく、税金控除の対象になる金額しか寄付してくれないとは、あんたたちはなんてケチンボなんだ？ ってね。実際、そんなのはフリだけだと分かっている。）
プロジェクトから得られるお金はいろんなことに消えていく。第1に、お金は俺がフルタイムでOpenBSDのために働くことができ、他の仕事をしなくてもいいと保証してくれる。フルタイムOpenBSDのために働くことに興味があると言ってくれている、プロジェクトの他の開発者たちにも同じようにしてやりたい。第2に、多少汚れた、面白くもない、そして重要な開発作業では開発者達のポケットに少しのお金が入る。OpenSSHの作業のいくつかは、OpenBSDの資金のうちVanDykeからの寄付金に見合う金額によって賄われている。第3に、プロジェクトで妥当な量のハードウェアを購入している。PowerPCだけだが、今年は4台のマシンを購入した。第4に、カンファレンスへの出荷コストがときどき売り上げ収入を上回ることがある。最後に、開発者がハッキングのために集まるとき、プロジェクトの資金がいろいろなことに支払われる、例えば航空券、滞在費、時にはビール代にも。ビールはアイディアに化け、アイディアは新しいコードに化ける。