カテゴリー: System Admin

浮動少数問題 Java版 CVE-2010-4476

清水 文行

どっかで見たことのある数字のような気がしますが(表記されている1個の値だけではなく範囲になります。DoS仕掛けてくれちゃってる人検出用シグナチャを作る方はこちらやそこから参照されているOpenJDKのBTSですがこちらを。少数をパースする場面って何気に多いですね)。さっそくfp87な機械のEclipseにコピペして自動的に文法チェックされた日にはそのままEclipseハングするので半べそです。2011/2/15に(日本では15日深夜にJava SE 6 Update 24登場しました)6u24が出るまではJava SE Floating Point Updater Toolでしのぎましょうということなので管理者権限でunzipしたjarを実行したら、一生懸命ランタイムライブラリをばらかしてからアーカイブし直してるようでした。インストール先の空き容量がぎりぎりな人はちょっと注意かも。

IPv4無くなりました

清水 文行

枯渇時計を表示させていた方はお気づきのことでしょうが、IANAから通常の分配が終了し、Two /8s allocated to APNIC from IANA や 【速報】IANAからAPNICへ、二つの/8ブロックが割り振られました によると近日中に最後の/8の5ブロックを5つのRIRに割り振って完全終了になるそうです。v4.fullbogons.cymru.com は今年から来年にかけて bogons.cymru.com との違いがほとんどなくなるはずです。(Bogons vs. Fullbogons – what’s that all about?) とはいえまだあるっちゃあるわけですが…

2011/4/16 追記:APNICにも通常割り振りの在庫が無くなったそうです。

2011/2/5 参考追加

DNSSEC始めました

清水 文行

祝ルートからJPへのチェイン。弊社が利用しているドメイン(co.jp jp ch me es be dk com net org…)もすべてDNSSECおよびDANE/TLSA対応完了。DNSSECが有効でTLSA RR,CAA RRにも対応したセカンダリDNSサーバ,DANE,TLSA,DMARC,DKIM,SPFに関するご相談は弊社へどうぞ。と宣伝をしたところで以下は設定を確認するためのリンク集と自分で確認する手順。

続きを読む →

タイムゾーンのオフセット+09:18:59 はて、18:59はなんぞや?

清水 文行

いろいろ検索したつもりでしたが、実は :18:59 timezone と検索することで先人の方々のサイトがヒットし、Google先生がいれば誰でも天才ということで表題の件は簡単に速攻で解決できたことがわかりました。しかしせっかく書いたので恥ずかしながら公開しておきます…

続きを読む →

devel/libltdl22 (port directory error)

清水 文行

portupgrade中

毎度おなじみ/usr/ports/UPDATING を見ると、バージョン付きでなくなったものがいろいろあるようです。

か

で置き換えるように指示されていますが、多くの人がビルド専用でしょうから

で十分かも。

PDF -> e-mail添付 -> FAX送信でペーパレス 続爆速インストールHylaFAX

清水 文行

FAX受信 -> e-mailに引き続き今度は送信側。不適切な設定で勝手に使われるなどして莫大な電話代請求されても責任は取れませんので、細心のご注意を。HylaFAXクライアントを使用すればキューの制御もできて便利ですが、いろいろなOSで使えるような良いものを探すのも面倒です。今回はHylaFAX付属のfaxmailをPostfix経由で使用します。メールを読んでlatin1テキストならばそのまま、MIMEならば引っぺがして変換可能であれば変換してsendfaxに送り込んでくれます。

あて先の電話番号は [email protected] (Postfix master.cfで${user}使用) でも [email protected] (${extension}使用) でも良いですが、今回は簡単のために後者にします。まかり間違っても認証もなしに普通にインターネットから到達できる構成にしてはいけないです。

適切に設定されて動作している内部向け専用Postfixの etc/postrix/master.cf に

を追加。ここで指定したfaxという名のサービスに [email protected] で到達させるために、etc/postfix/transports(etc/postfix/main.cfでtransport_maps=regexp: で指定されている場合)に、

を、引っかかるような位置に追加。local_recipient_mapsが/etc/aliases.dbと指定されている場合はreject_unlisted_recipientが使えるように/etc/aliasesに hoge: root とでも追加してnewaliasesしておきます。etc/postfix/main.cfのmydestinationに@のドメイン部分であるfax.testを追加すればPostfixの設定終了でPostfix再起動。

HylaFAXのサーバはデフォルトでIPv6の*:4559をlistenしていて、クライアントはデフォルトでlocalhostのサーバにアクセスします。/etc/hostsで::1がlocalhostではなくてlocalhost-v6である場合には/usr/local/lib/fax/hyla.confに

を追加。パスワード無しでサーバにアクセスするために/var/spool/hylafax/etc/hosts.hfaxdに

を追加。この時点で

faxstatコマンドが認証無しで実行できてしまうようになります。続いて/usr/local/lib/fax/faxmail.confに

などをお好みで追加。/var/spool/hylafax/bin/notifyの内容を見ながら、お好みで/var/spool/hylafax/etc/FaxNotify作成。

hfaxd(hylafax)再起動。ここまでで [email protected] 宛e-mailにPDFやPostScriptを添付しするとFAXとして送信されるようになりました。残念なことにfaxmailはMIMEではないメールの扱いがlatin1のみでtyperulesも効かないので修正が必要です。時間が取れたらパッチ作成。万が一電話番号を間違えたら自力でfaxstatしてfaxrmするのが手間ですが、PDF添付でFAXが送れるだけでも十分実用的。

p5-Compress-Zlib, p5-IO-Compress-Base, p5-IO-Compress-Zlib, p5-IO-Compress-Bzip2 -> p5-Compress

清水 文行

Perl5.8のFreeBSDマシンにて

/usr/ports/UPDATING を見ると、p5-Compress-Zlibとp5-IO-Compress-* が p5-IO-Compressにまとめて置き換わったそうな。perl5.10以降の人はデフォルトのライブラリなので関係ないと。いつものように

で依存しているものたちをメモ。

で置き換え完了したら

か

あたりで処理。

HTTPS Everywhere – 自分で任意に指定したサイトで自動的にhttpsになるようにする – Force-TLSをやめたときの覚え書き

清水 文行

自動的にhttpsにするといえば、HSTSをFirefoxも4にて実装、とかのサーバ側で何かしないといけない仕組みの話題ばかりで、ブラウザ側に能動的に設定するための情報が探しにくくなったようです(Firesheepのおかげでまたそうでもなくなったようですが…)。かくて、自分で登録したサイトでhttpsを強制するFirefoxプラグイン Force-TLS

と、PC引っ越し用に覚え書きしましたが、あろうことか引っ越し先PCではサイトが追加できなかった(すごいところに設定ファイルがあったりするのだろうか)ので、問題の検証もせずにさくっと方針転換でhttps://addons.mozilla.org/firefox/tag/httpsを眺めてHTTPS Everyehereを試しました。https://www.eff.org/https-everywhere/rulesetsに従って簡単な正規表現を含むシンプルなXMLを作成。(2010/11/25追記: 自動更新版だと0.9.0よりtargetで1次フィルタするようになりました。targetが無いと気づかないうちにルール全体が無視されているので注意です。要エラーコンソールでの確認)

書かれている場所に保管してFirefox再起動。さくっと動作。設定ダイアログにも指定したものたちがちゃんと登場。ファイル作る手間があるけどルールが汎用的に作れるのでこっちの方が便利かも。

2010/11/25追記: 一部であらかじめ登録されたサイトにしか使えないと受け取れる説明がされているようですが、HTTPS Everywhereは説明や上記のとおり、自分の好きなサイトを指定できます。

2010/11/25追記: 同じく一部で家庭用の無線LANでは不要と受け取れる記述もありますが、家庭用無線LANでも暗号化無しであったり弱い暗号でtap可能であれば同じこと(パスワード漏れ & セッションハイジャックされる可能性のある状態)です。モニタポートのある有線LANのスイッチングハブや、買うのが難しいでしょうがリピータハブにアクセス可能である状況もまた同じことです。Firesheepを相手に対策するのではなく、平文パスワードと、そしてセッションハイジャック対策としてクッキーを秘匿するためにHTTPSを使用すると考えなければいけないです。URLがhttps://で始まっていても、secure無しcookieで内容にHTTPが混在していたりJavaScriptでHTTPでアクセスしにいってしまっては元も子もないじゃん、というサイトもあり、今に始まった問題では全然ないですが、script kiddieでもFiresheepで簡単にセッションハイジャックできるようになったという状況のおかげでそのようなサイトが改善されるチャンスでもあります。

HSTSはSSL/TLSが有効なコンテキストにて、Apache HTTPDならば一番簡単な使い方で

とするだけです。

Windows で sockstat (lsof)

清水 文行

fport(XP以前)とかの3rdパーティーのコマンドを使わずに素のWindowsだけでsockstat -46(lsof -i)したい時。

とか

netstatに-oなるオプションがあったり、find(fgrep)で””が必ず必要(command.comゆずりでcmd.exeも処理していないのか、はたまた処理してさらに”を渡しているのか…)だったり。

LibClamAV Error: cli_dbgets: Line too long for provided buffer – bytecode.cvd: version: 71

清水 文行

bytecode.cvd: version: 71, sigs: 10, f-level: 53, builder: edwin で LibClamAV Error: cli_dbgets: Line too long for provided buffer が出るようになったようです(–bytecode=noでは起きません)。手元ではFreeBSD 8.1と7.1のClamAV 0.96.2で確認されていますが、0.96.3でも他のOSでも起きているようです。bytecode.cvdが修正されるまでエラー通知をどうにかしないと…といってるうちに修正されました。bytecode.cld: version: 72, sigs: 10, f-level: 53, builder: edwin で修正済みです。ありがたやありがたや。

ある日ソフトエラーを目の当たりにする

清水 文行

アプリケーションの計算結果のテストのためにDBで大量の検索、挿入、更新、そして照合用も含めてファイルも大量に新規作成、削除、読み込みを何日も連続で繰り返さなければならないことがあります。連続で読み続けたり書き出し続けたりするのでディスクキャッシュを数百メガバイトに設定したところで効く由もなく、連続稼動用を謳っているハードディスクを3,4台のストライピングで使用しても負荷が激しすぎで3,4週間程度でお亡くなりになるのでどんだけひどい仕打ちをしてるんだろうと思ってしまいます。古いflash SSDだったら即死するかもしれません。ハードディスク交換していてはエコじゃないので使用量を減らすとすると、DBのデータを最初にRAMディスクにコピーし、一時ファイルもRAMディスク上というのが良さげですが、いっそOSごとDRAMのRAMディスクにして物理ディスクレスにしてしまおう、ということで1年ほど前にRAMディスク化しました。

マニュアルとOEM元Q&Aは良い(しかしどちらも日本語訳はすごすぎ)のですが、なぜかそれらと輸入代理店のFAQがいい感じに違っている某商品、DDR2メモリを積めるものです。1年たった今になって、実はunbuffered ECC対応、さらにunbuffered non-ECCでもジャンパーを刺せば容量の1/9使ってをECCエミュレーションをしてくれる(ハミング符号だとすると比率から64ビットバス+8冗長ビットのエミュレーションですね)という結構優秀な機能を持っていることがわかりました(輸入代理店はECC非サポートと明記している)。コストパフォーマンスからはunbuffered non-ECCのメモリを使ってECCエミュレーションするのが一番良さそうです。

しかしインストール時はそんなことには気づいてなかったのでnon-ECCメモリでECCエミュレーションも使わずに1年近くたった先日、その日はきました。演算結果の検証エラー。

正解 検証対象
.19;5 .1995

正解は数値であるはずだったので、すぐに正解の方がおかしいことに気づくことができるのが不幸中の幸いです。別途ハードディスク上に圧縮して保管されている検証用データと比較すると、検証対象の値で正しいことがわかりました。面白いのでこのファイルの文字セットUS-ASCIIでのコードポイントを調べてみます。

9 ;
hex 3 9 3 b
bin 0011 1001 0011 1011

その他の1GB程度の正解ファイルの検証、さらにOSとports部分はTripwireしているので検証したところ違いは検出されず()、RAMディスク起動時のデータも同様、そしてその後このようなエラーも起きずにいるのでソフトエラーということで間違いないようです。ビット反転によく見える形で遭遇してしまいました。機材近辺でのノイズであればエラーが頻発してもおかしくないような気がするので日常の宇宙線か、太陽フレアか、などと空のかなたに思いをはせていたところ、こんな記事がありました。

Google: Computer memory flakier than expected　(邦訳 – なぜか思い入れがえらく強いタイトルになってます…)

周辺の状況などもあるでしょうから場所、そして何の作業をしているところか、などの条件をどうしているのかちょっとわかりませんが、温度なんかどーっちゅうこともない、ハードエラーの方がソフトエラーよりcommonである(ECC前提での話?)、など面白いです。温度が経年変化に与える影響なんかも調べられてるんでしょうか。時間ができたら元の論文読むべしです。

さらに温度といえばグーグルの最新のデータセンターは非常識なほど進化しているだそうで、自宅サーバなんて昔から室温50度超えになっちゃうようなところで並んで動いていたわけで進化なのかどうかは置いておくとして、かつて大学のコンピュータがある場所では壁一面にウルトラマンに出てくるような巨大なテープが回ってる箱が並んでいてエアコンがガンガンに効いている、なんてのはいったい何の話?ってなもんですね。

何よりも実感したのは、サーバだけじゃなくてテスト機にもECC使わないとだめじゃん、ということです。考えれば当たり前な話ですが、それを言い始めるとnon-ECCで良い仕事ってあるんだろうか…

追記: bitsquatting面白い!

ClamAV 0.96.2 on FreeBSD 7.1

清水 文行

ClamAV 0.96.2のソケットがFreeBSD 7.1でchokeする問題

ありがたいことに既にports tree更新されてる(PORTREVISION=2なので0.96.2_2以降)ので、

したら

とか

で解決ですね。ありがたやありがたや。

server does not support RFC 5746, see CVE-2009-3555 (was: potentially vulnerable to CVE-2009-3555) Apache HTTPD + OpenSSLでRFC5746リネゴシエーション対応

清水 文行

CVE-2011-0411 Plaintext command injection in STARTTLSはこちら

Bug 549641の変更をここのタイトルにも入れてみました(2010/9/14) 。元々「潜在的に脆弱」という微妙なメッセージから書き起こしたエントリなので、文章のつながりが悪くなったかもしれません。

CVE-2009-3555はDescriptionによればSSL3.0(とおそらくそれより前)とTLSプロトコルにおいて、”renegotioation”でMITM攻撃者がデータを挿入可能である、というものになり、去年の11月に業界(?)を震撼(?)させたものです。

この問題を解決するべくIETFのTLSな方たちは世のため他人のため、ものすごい勢いで”secure renegotiation”(安全な再ネゴシエーション)を定義して本年2月までにRFC5746にしてくれました。

表題のメッセージはFirefoxがhttps://なサイトにアクセスした場合や、ThunderbirdがSSL,TLSでPOP3, IMAP4, SMTPアクセスした場合などなどでエラーコンソールにログされるものですが、mozilla wiki Security:Renegotiationを超訳すると、「まだ問題があるwebサーバだらけで、今よく見えるように警告してしまうとそれを無視しましょうとのたまう人が出てきて、ユーザは似たような警告も含めて無視する習慣が付いてしまうだけで世の中が幸せにならない。だから潜在的に問題のあるサーバはそっとエラーコンソールにログするだけ」とのことです。実際にはRFC5746を実装していないwebサーバとのTLS/SSL使用時に表示されるので、webサーバ側にrenegotiationを全て無効にする形でのパッチが適用されている場合、webサーバとしてはCVE-2009-3555に対して脆弱でなくでもそれを通信中のフラグ(RFC5746対応している場合にはServerHelloのextentionのrenegotiation_infoが付いてくる)では検知できないのでFirefoxのエラーコンソールに表題のメッセージがログされます。

表題のメッセージを消す==webサーバをRFC5746のsecure renegotiationに対応させるためにすることをざっくり書くと、OpenSSLとApache HTTPD(mod_ssl)2.2系列の場合、

  • 対象のwebサーバにhttps://で接続してFirefoxのエラーコンソールに表題のログが表示されることを確認。
  • 先にOpenSSLを0.9.8m以降にアップデート。(2014/4/8現在1.0.1g以降をお勧め)
  • 次にApache HTTPD 2.2系列の場合2.2.15以降(2010/9/14現在2.2.16以降をお勧め)にアップデートかリビルド。
  • 再度https://で接続してFirefoxのエラーコンソールに表題のログが表示されなくなったことを確認。

となります。(悲しいことにrenegotiationしないと続行できない状況の場合、いまだRFC5746非対応であるIE(←末尾に追記)RFC5746非対応ブラウザなどで問題になり、わざわざmod_sslにSSLInsecureRenegotiationディレクティブを使用して古いrenegotiationを有効にせざるをえなくて困っているサーバ管理者の方も多いです)

その他にもご自分のwebサーバがインターネット上にあればQualys SSL LabsのSSL Server Testにて、SSL,TLS全般の確認ができます(表示されているように、別のURLで流れさるまでの何時間かURLと結果がさらされます(その後指定すればさらされないようになりました)。さらに上位と下位は別枠で表示してくれます)。結果のMiscellaneousのRenegotiationの項に、安全なのか古いリネゴが使えてしまう状態か、などが表示されます。

クライアントのRFC5746対応も必要ですが、表題のログがエラーコンソールに出ている時点で当然古いrenegotiationを問題視しているwebブラウザを使用していることになるのでここでは考えないことにします。webブラウザのRFC5746対応はmozilla wiki Security:Renegotiationに書かれているようにhttps://ssltls.de/で確認できます(←末尾にちょっと追記)。有るべき姿はwebブラウザ、webサーバに限らず、「SSL,TLSを用いた全てのクライアントとサーバがRFC5746に対応していること」になります。

ではwebサーバとしてはCVE-2009-3555に対して脆弱でなくてもログされる場合(薦められた状態ではないですが)はというと…

例えばOpenSSLのChangeLogを見ると、

となっていて、またFreeBSD Security Advisoriesの2009/12/3 FreeBSD-SA-09:15.sslでは

となっています。ソースレポジトリを見ると2010/6/15現在-CURRENTとRELENG_8(-STABLE), RELENG_8_1がOpenSSL 0.9.8nであり、他は OpenSSL 0.9.8eとかkとか + SA-09:15 ということになるようです。

さらにApache HTTPD 2.2.15のChangeLogでは、

となっているので、Apache HTTPD(mod_ssl) 2.2.15以降の2.2系列をOpenSSL 0.9.8m以降のライブラリでコンパイル、リンクすることでRFC5746のsecure renegotiation対応になります。

Apache HTTPDにSSLInsecureRenegotiation指定をしない前提でまとめていくと2010/6/15現在

FreeBSD 8.1(現在ベータ1,7月リリース予定)のOpenSSLは0.9.8nなのでRFC5746対応。したがってCVE-2009-3555に対しては脆弱ではない。

FreeBSD 8.0, 7.3, 7.1各セキュリティブランチを最新の状態にしている人のOpenSSLは0.9.8? + SA-09:15なのでRFC5746は対応していないが、renegotiationを全部無効にすることでCVE-2009-3555に対しては脆弱ではない。

OpenSSL 0.9.8l
あるいはFreeBSD 8.0, 7.3, 7.1各セキュリティブランチのOpenSSL(0.9.8? + SA-09:15)
 + Apache HTTPD(mod_ssl) 2.2系列全部
の場合は

  • 表題のエラーコンソールログは表示される(RFC5746非対応)
  • CVE-2009-3555についてwebサーバは脆弱ではない(ただしrenegotiationがすべて無効)

OpenSSL 0.9.8m以降(2010/6/15現在OpenSSL 1.0.0a以降をお勧めします)
 + Apache HTTPD(mod_ssl) 2.2.15以降の2.2系列
の場合は

     

  • 表題のエラーコンソールログは表示されない(RFC5746対応)
  • CVE-2009-3555についてwebサーバは脆弱ではない(RFC5746対応)

要注意なのは、Apache HTTPD 2.2.15にしただけで安心してしまう次のパターンでしょうか。現実的にMITM攻撃が成立するかは考えずにChangeLogからだけ言うとするとCVE-2009-3555に対してwebサーバは脆弱です。
OpenSSL 0.9.8k以下(FreeBSDの場合は0.9.8k以下かつSA-09:15のアップデートがされていない場合)
 + Apache HTTPD 2.2.15以降の2.2系列、
    あるいは2.2.14 + http://www.apache.org/dist/httpd/patches/apply_to_2.2.14/CVE-2009-3555-2.2.patch
の場合は、

     

  • 表題のエラーコンソールログは当然表示される(RFC5746非対応)
  • CVE-2009-3555に対しては * 脆弱である *
          (クライアントがinitiateした場合のrenegotiationを拒否しているだけ)

まずサーバ側の古いrenegotiationの実装が一掃され(同時にメジャーwebブラウザが全部RFC5746対応するという壁も大きいようで)、そしてRFC5746実装が使用され、renegotiationの一部や全部を無効にしただけのパッチがおおよそ一掃されて、それからようやく表題のエラーコンソールのログが派手な警告なりエラーなりに格上げされることになると思われますが、まだまだかかりそうですね…
例:https://bugzilla.mozilla.org/show_bug.cgi?id=555952

FreeBSD 8.0, 7.3, 7.1 + Apache HTTPD(mod_ssl)で表題のエラーコンソールログが出なくなるようにする、つまりRFC5746対応にするには、2010/6/15現在SA-09:15ではOpenSSLのrenegotiationを全部無効にしているためApache HTTPD(mod_ssl)を2.2.15にするだけでは不十分であり、こどもの日にportsがOpenSSL 0.9.8mに対応された(2010/6/15現在1.0.0a対応)ので、これを使うのが早そうです。

最後の表示では、特に/usr/lib/や/lib/ではなくて、/usr/local/lib/libssl.so.*, /usr/local/lib/libcrypto.so.*であることを確認する必要があります。

あらかじめFirefoxでhttps://接続してエラーコンソールに表題のものがログされていることを確認した後、アップデート作業後にログされなくなればRFC5746対応完了です。

Windows関連ちょっとだけ追記(2010/9/14)。 2010年8月の月例(日本だと8/11あたり)のアップデート群に含まれていたKB980436: MS10-049: Vulnerabilities in SChannel could allow remote code executionによってWindowsのTLS/SSLスタックがRFC5746対応されましたが、それが使われるWindows XPのIEで https://ssltls.de/ のペンギンさんが表示されないのを確認しようとしてたこともあって時間がとれずに一月経ってしまいました。どうやらmod_nssを使った環境を作らないとちゃんと確認できなそうなので、先ほどざっと確認した現象だけ列挙しておきます。

  1. Opera,Firefoxは結構前からペンギンさんが表示される。
  2. KB980436が適用されたWindows Vistaではペンギンさんは表示される。
  3. KB980436が適用されていてもWindows XP, 2003ではIEのバージョンによらず、ClientHelloのextentionでもSCSVでもペンギンさんは表示されない。
  4. Windows XP(IE)のClientHelloのextentionにはtype 0xFF01(renegotiation_info)しかないが、Vista(IE)やOperaはそれに加えてserver_nameやstatus_requestなどがある。
  5. HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL にUseScsvForTlsという名前のDWORD値を作成して1をセットすると、Windows XP(IE)ではClientHelloのextentionが無くなる。Firefoxはserver_nameやstatus_requestなどがある。どちらもrenegotiatoin_infoは無く、cipher suiteに0x00FFが追加されている(SCSV)。

次はmod_nss環境を作成してnssのデバッグログを吐かせるところからになりますが、誰かとっくのとうに解決していたら教えてくださいませ。

なおWindows(IE,IISなど)で古いリネゴを拒否する方法はKB980436に書かれています。レジストリをいじって

で再起動すればサーバ(IISなど)が、そして

で再起動すればクライアント(IEなど)が古いリネゴを拒否するようになります(いろいろ使えなくなるものが出るようなので、まだ不便かもしれません)。

その他の参考リンク

** Port directory not found: math/libgmp4 からの～ ** Command failed [exit code 1]: /usr/bin/script -qa

清水 文行

/usr/ports/UPDATINGによるとportmaster使ってる人は

で更新、とのこと。portupgradeで許してと、

すると(as of 2010/5/10)、

あいたた。-oの時のconflictのチェックをするタイミングがおかしいような。原因を追究しなければいけないところですが、レポートはどんどんあがりそうだと言い訳をしてその場をしのぐべくUPDATINGに言われたとおりにportmaster使います。その前に念のためlibgmpに依存しているものを確認。

出てくるパッケージをメモ、

もしもメモしたパッケージがアップデートされない場合は

か

で解決。

全然関係ないですがLLVM全盛の世の中GCCのメッセージを眺めていて、一晩かけてSONYのNEWSでコンパイラをコンパイルしているところを眺めていた十数年前など思い出しつつ、GCCともお別れの季節が近づきつづあるようです。

http://llvm.org/demo/ VM自体はホストの時代に戻ってる気がしますが、CGIでコンパイルとか今風で最高に面白いデモです。