オープンソースのセキュリティツールで有名(?)なImmunityのDebuggerが結構話題になっている。他にもいろいろ紹介されているようですがeWeekの記事が分かりやすい。
http://www.eweek.com/article2/0,1895,2166829,00.asp
Debuggerはヒープやスタックメモリを自動的に解析して脆弱性を検出し、ほぼ自動的に攻撃コードを作成することもできるようです。攻撃コードの作成時間を50%削減できるとしています。
http://www.immunitysec.com/products-immdbg.shtml
一時的には0day攻撃が増える事が予想されますが脆弱性検査が容易になる、特に機械的検出できるような脆弱性検査が容易になる、のは良い事だと思います。
b2evolutionをいい加減アップグレードしておかないと問題があっても困るのでアップグレードしました。HTTP_ACCEPT_CHARET/HTTP_ACCEPT_LANGUAGE処理の不具合がまだなおっていないようです… 日本語のように単語区切りがない言語（または正規表現の文字エンコーディング設定）の不具合も直っていないようです。
昨日から今日までMac版のFirefoxなら正常に表示、Win版だとISO-8859-1になって文字化けしていました。（多分IEも同様だったはず）
文字列の比較はできるかぎり厳密に行う方が良いですがHTTP_ACCEPT_CHARSET/HTTP_ACCEPT_LANGUAGEの比較では大文字／小文字を無視した方が無難だと思います。Win版Firefoxがへんな値に設定しているとは思いますが、統計アプリなどでみるとかなり変わったエンコーディング名になっている場合もあるようです。
エンコーディングをUTF-8で統一しているなら
conf/_locales.phpを以下に設定し
$evo_charset=’utf-8′;
$force_io_charset_if_accepted=’utf-8′;
$db_config[‘connection_charset’]=’utf-8′;
$default_locale=’ja-JP’;
必要ないような気もしますがこのファイルに定義してあるlocaleでiso-8859-1エンコーディングは全てutf-8に変更しました。
inc/MODEL/settings/_locale.funcs.phpのinit_charset関数でなにもせずにreturn
function init_charset( $req_io_charset )
{
return;
すれば文字化けは解消します。
追記：
これでもISO-8859-1になって文字化けするケースがありますね… 時間がないので場当たり対処策としてindex.phpの最後に
header(‘text/html; charset=UTF-8′);
を追加しました。ロケールの処理にはいろいろ問題があるようです。どこかで無理矢理ISO-8859-1にするくらいならデフォルトUTF-8にしておけば良いと思います。
さらに追記：
上記の変更を行うとRSSフィードのXMLエンコーディングの部分が空になり、XMLエラーとなってRSSリーダが処理できない不具合が発生する事が分かりました。ソースを見れば一目瞭然で文字エンコーディングを指定する変数が空であることが原因でした。
conf/_basic_conf.phpに
$io_charset=’utf-8’;
を追加すると直ります。アップグレードマニュアルにはこのファイルは前のファイルで上書きするように、と書いてあったのですが追加設定が必要だったのかも。
新iMacのアナウンスと同時にMac miniのCPUがCore2Duoになる事が明らかになったようです。
新モデルは「Core 2 Duo」を搭載した。599ドルモデルは1.83GHzの「Core 2 Duo T5600」を、799ドルモデルは2.0GHzの「Core 2 Duo T7200」を搭載している。
OSは10.5はファミリーパックで買うのでリリースまで待つ必要ないし、これでやっとMac miniが買える :)
イギリスはこの手の統計が好きなのか、私がたまたまイギリスのこの手の統計情報を見かけているのか収入と満足度の調査結果によると81種に分けた業種中、IT技術者は満足度が66位だそうです。以前に見かけた統計でも同じような結果でした。
収入の平均は4万ポンドを超えるそうなので日本円にすると964万円（ http://quote.yahoo.co.jp/m5?a=40000&s=GBP&t=JPY ）だそうです。アメリカのプログラマの平均年収が8万ドルだったと思うので日本円にすると953万円（ http://quote.yahoo.co.jp/m5?a=80000&s=USD&t=JPY )と収入はほぼアメリカ並み（？）と言えるのかも知れません。
ちなみに日本のIT系は3Kらしく「きつい」「帰れない」「給料安い」とか言われてるようです。日本のIT技術者の平均収入はどれくらいなのでしょうね。
追記：
ということで調べてみました。2005年のデータではないかと思います。
http://ranking1.nobody.jp/salary2-gyoushu.html
システムコンサルタントは割と上位(?)なようですが、平均と言う意味ではアメリカ、イギリスに全く及びません…
以下のリンクを見れば違いは一目瞭然です。
http://www.chikawatanabe.com/blog/2006/03/post_4.html
日本の状況はIT Proの記事が非常に参考になります。
http://itpro.nikkeibp.co.jp/free/ITPro/OPINION/20040110/1/
日本の場合、かなり給料が下がってきていたのですね… 2004年から2006年にかけてどう変化しているのか気になったので調べてみると
http://doda.jp/guide/heikin/hei_003_01/index.html
となってます。
IPAのドキュメントでは大規模開発にはJava, .NETをお勧めしているようですがTomcatのページにはこのような記載も。
Apache Tomcat 3.x and 4.x, we strongly encourage users to use the latest stable version of Apache Tomcat whenever possible. We recognize that upgrading across major version may not be a trivial task, and some support is still offered on the mailing list for users of old versions. However, because of the community-driven support approach, the older your version the less people would be interested or able to support you.
http://tomcat.apache.org/
つまり3.x, 4.xユーザは早く6.xに乗り換えてねと言う事です。PHP4の状況と同じですね。
そして現行の3.3.xの最新版に未パッチ(私が見た情報には詳しい記述がなかったので詳細は分かりません。もうすぐパッチはリリースされるのかな?)のXSS脆弱性があるようです。IPA的にはJavaは良いけどTomcatは大規模開発には使うなと言う事なのかな?
MoPBの邦訳をしていたので「例えば大規模開発にPHPは使用しない」（IPAのページが見つけられなかったので正確な言い回しでは無いかもしれません）と言う表現に一役買っているとも言えますが、私としてはどうもドングリの背比べに見えるのですけどね…
機会がある毎に、言語やフレームワークでより安全なWebサイトが作りやすくはなっても、言語やフレームワークで安全性を保証できない、と言っています。「○○言語利用しているので安全です」とか「○○フレームワークを利用して構築しているので安全です」とは言えないことは明らかです。バージョンアップについても状況は違っても似たような状態だと思います。
WindowsServer 2003にCanon iP7500が接続されLPDサーバのプリンタとして利用しています。LinuxからはiP7500用のSRPMをちょっと手直しして無理矢理ビルドしたドライバで普通に印刷できています。
# リンクしたがるライブラリが古すぎるので無理矢理新しいライブラリと
# リンクさせてますが私の使用方法だと困った事はないです。
さすがに印刷できないのは非常に困るので、OSX用のドライバをCanon iP7500のCanonのホームページ
http://cweb.canon.jp/drv-upd/bj/ip-series.html
をダウンロードしインストールしました。しかしCUPSのドライバ選択のドロップダウンに表示されません。調べる時間も無いのでサポートに電話してみました。ドライバのインストールはUSB接続しプリンタの電源を入れて行ってください、とのこと。USB接続ならプリンタが見え印刷できる状態になりました。
しかし、CUPS/gimp printの一覧にプリンタがでてきません。そこでもう一度サポートに電話をかけると折り返し詳しい方から電話してもらう事になりました。電話はすぐにかかってきたのですがUSB以外の印刷はサポートしていないとの回答でした。
印刷できないと困るのでサポートしてくれないならLinuxのPPDファイルとOSXのUSB接続用のPPDファイルを適当に合わせて印刷できる様にしようと試みました。しかし、フィルタがUSB専用(?)なのかエラーで印刷できません。ここでも調べる時間が無いので直ぐに諦めLinuxで昔使っていた方法で印刷しています。BJ7000のドライバ（Gimp PrintのBJ7000用のPPDファイル）を使ってDPIを600×600、色をグレイスケールに設定すると概ね普通に印刷できます…
PPDファイルだけなら時間をかければ自分で作れると思いますが、CanonさんGimp Print/CUPSどちらでも良いので普通に印刷できるPPDファイル/ドライバ作ってください… USB接続だけで印刷できれば良いって、このネットワーク時代にありでしょうか? 困っている人も多いと思うのですが…
# もしかしてサポートの方が知らない簡単な接続方法があるのかな？
ところでドライバパッケージの中身にはヘッドクリーニングやインクカートリッジの状態確認などが行えるユーティリティ(Canon IJ Printer Utility)が入っていました。実際に使えますがドライバのインストーラはアプリケーションとしてインストールしてくれないようです。欲しい方はドライバのパッケージファイルの中身を探すと見つかります。
最近メイン環境をOSXに変えたのでMacをよく使っています。LinuxとOSXが半々くらいになっています。今までOSXのセキュリティアップデートを注意して見てこなかったのですが、このセキュリティアップデートを見ると「なんだかな…」と思ってしまいました。
bzip2 CVE-ID: CVE-2005-0758
gnuzip CVE-ID: CVE-2005-0758
この脆弱性はgunzip -Nで展開した場合の問題のようななのでそれほど危険ではないようです。しかし、2005年の脆弱性なのでこれはさすがに古すぎでは… 確かにアーカイバの脆弱性修正が忘れられている事例は多く見られます。アンチウィルス製品がLHA、GZIP, BZIP等の脆弱性が直っていなくて（それも古いもの）脆弱性としてレポートされているケースはかなり多いです。だれも気にしていなかったにしても長期間放置されすぎだと思います。
PHPもアップグレードされていました。確かにテストなどで時間が必要なのは分かります。特にPHPはアップグレードするのが非常に難しいのは分かりますが、このアップデートでやっと4.4.7になりました。PHP 4.4.4ってなぜ？と思っていました。自分でビルドして5.2を使っているので気にしていませんでしたが。Appleだけが遅いのではなく、確信犯でアップデートを出していないディストリビュータも多いですけど。
普通の人が普通に安全にコンピュータが使えるようになるのはまだまだ長い道のりが必要ですね。
# 普通の人（コンピュータに詳しくない人）はgunzip, bzip2は使わないか
詳しくはリンク先を見て頂くとして、XSSは
と言う点着目してスクリプトにサインを付けクライアント側でもXSSを検出しようと言う話です。フェイルセーフ対策としては有用だと思います。Flash, PDF, Javaなどのオブジェクトにもサインすればより良いと思います。サインさえ付けておけばあとは決まったJavaScriptコードを全てのページに追加するだけなのでそれほど難しい対策ではありません。