yohgaki's blog

  • iPod税に反対のパブコメを出そう

    mixiで「iPod税に反対のパブコメを出そう」

    07/28のJASRACの表明にもある様に悪の7団体はコピペの嵐で何が何でもiPodなどに課金しようとしています。それに対抗する為には、やはり、9月に行われるパブリックコメントで自分の意見を提出して、量的にも質的にも賛成側を上回らなければ簡単にiPod税は通ってしまうでしょう。
    ここでは、どういう風にパブコメを出せば良いのか？、Blogやサイトを持っている人はトラバを張ったり、情報交換や収集、その他色々と提案をして行きたいと思います。＞パブコメが終る迄の期間限定コミュです。

    検索用Word
    iPod iPod税 私的録音録画補償金問題 JASRAC

    と言うコミュニティを見付けました。8月31日に作成されています。もっと前の新聞で文化庁の役人も私的録音保証金制度はもう時代遅れの制度なので…　と書いてあったのですが、もしかして利権団体からの巻き返しがあったのでしょうか? HDDからは取らないがiPodからは取る?詳細はよく解ってません。時間があるときに勉強します。

    個人的にはDVDもCDもデータ記録媒体としてしか使っていないのですが何故か保証金付きのメディアを使っていたりします。店頭に保証金が無いメディアが無かったりするからです。IT関係者に限らず、仕事でDVD、CDを使っている方は不必要に保証金を払っているケースは非常に多いのでは無いでしょうか?

    追記：
    パブリックコメントの締め切りは10/7のようです。今から勉強しても間に合う?!
    http://www.mext.go.jp/b_menu/public/2005/05090803.htm

    ここが詳しい
    http://tontonsblog.seesaa.net/

    無償でパンフレットももらえるらしい（5. 私的録音録画と著作権）
    http://www.cric.or.jp/mushou/mushou.html

    東京にいるなら9/16に「複写と著作権メーリングリストオープンフォーラム」も
    http://d.hatena.ne.jp/copyright/20050905/p1

    これが騒動の原因です
    http://plusd.itmedia.co.jp/lifestyle/articles/0504/28/news097.html
    http://plusd.itmedia.co.jp/lifestyle/articles/0507/28/news106.html

    韓国では音楽配信で定額制もあるようですね
    http://nikkeibp.jp/netbiz/interview/050906_oricon2/

  • network.enableIDN=false

    最新版のFirefoxのIDN（国際化ドメイン名）に深刻な脆弱性が見つかっていますが簡単に対策できます。ここに書いても良かったのですが元のエントリに追加しています。
    # 最初から対策を書いておけば良かったのですが..
    # 前にIDNに問題が見つかった時にFirefoxプロジェクトとして
    # デフォルトではIDN無効に設定しておいてくれればよかったの
    # ですが..

  • DBMSの機能比較

    ・Firebird 1.5.2
    ・Ingres r3 3.0.1
    ・MaxDB 7.5.0.23
    ・MySQL 4.1.10
    ・PostgreSQL 8.0.1

    の機能比較。（英語）

  • Firefoxに未パッチの脆弱性

    ドメインに0xADが含まれているとヒープオーバーフローが発生するそうです。
    個人的にはIDNは不必要と考えていますが、IDN関係のコードかな? IDN以外でこんなバグがあるとは思えない。

    IDNはレジストラだけが儲かる仕組だと思います。一般ユーザやサイト運営に関わる人には全く利益無し、とまでは言いませんが不利益の方が利益を遥かに上回ると思います。IDNサポートは駆逐されて欲しい機能の一つですね。

    追記：
    http://security-protocols.com/modules.php?name=News&file=article&sid=2910

    Technical Details:
    The problem seems to be when a hostname which has all dashes causes the NormalizeIDN
    call in nsStandardURL::BuildNormalizedSpec to return true, but is sets encHost to an
    empty string. Meaning, Firefox appends 0 to approxLen and then appends the long
    string of dashes to the buffer instead. The following HTML code below will reproduce
    this issue:

    A HREF=https:———————————————

    Simple, huh? ;-]

    パッチはここから
    https://bugzilla.mozilla.org/show_bug.cgi?id=307259
    というかこれに書いたときにはパッチは有りましたね。広くリリースされてはいませんが。IDNは手動で無効に設定しておいても良いかも。

    network.enableIDN=false

    回避策として公開されていますね。
    https://addons.mozilla.org/messages/307259.html

    XPIでインストールしなくても about:config をアドレスバーに入力して network.enableIDN=false に設定すればOKです。

  • gooの辞書検索がPHPに

    少し前の事になりますがgoo.ne.jpの辞書サービスがCGIバイナリ(?)からPHPに変更されました。

    具体的にはURLが

    http://dictionary.goo.ne.jp/cgi-bin/dict_search.cgi

    から

    http://dictionary.goo.ne.jp/search.php

    に変更されました。たいした事ではないですが気が付いたので。

  • PostgreSQL 8.1のパフォーマンス

    PostgreSQLのパフォーマンスはpostgresql.confに大きく影響されるので、速くなったかどうか判りづらい場合も多いです。しかし、8.1では確実に速くなっているようです。現在8.1はbeta1ですが少しだけ比較してみました。

    詳しくはWikiのページを見ていただくとして以下の様にpgbenchで計測すると

    ./pgbench -v -h 192.168.100.204 -U yohgaki -c 20 -t 200

    PostgreSQL 8.0.3

    tps = 4683.835265 (excluding connections establishing) (Select only)
    tps = 1032.798585 (excluding connections establishing) (Update 省略）
    tps = 423.926137 (excluding connections establishing)

    PostgreSQL 8.1beta1

    tps = 5985.801678 (excluding connections establishing)　（Select only)
    tps = 1428.605103 (excluding connections establishing)（Update省略）
    tps = 533.005286 (excluding connections establishing)

    という感じの結果になりました。
    postgresql.confの設定は多少チューニングした物を使っています。postgresql.confもWikiのページに添付してあります。

  • pthread版pgbenchの拡張

    実はpthread版pgbenchの作成には別の目的もあります。オリジナル版pgbenchのコードを見ると分かるのですが、非同期クエリを使用しているので送信するクエリのカスタマイズが面倒です。pthread版pgbenchの別の目的、と言うより本来の目的、はpostmasterが書き出したログから自動的にクエリを収集し、再生するベンチマークを簡単に行いたいので作る、と言う事にあります。

    今の所こんな感じで実装するつもりです。

    postgresql.confのログ設定が

    log_line_prefix = ‘%r’
    log_statement = true

    で出力されたログから自動的に各クライアントのクエリを出力し設定されたスレッド数（クライアント数）でベンチマーク出来るようにする予定です。

    今のコードだとログの読み取りとクエリ保存を行えるようにして、各スレッドがクエリを実行するように変更すれば良いだけです。簡単なのでそのうち変更します。

  • PHP 5.0.5リリース

    PHP 5.0.5がリリースされました。XMLRPCのセキュリティフィックスが含まれています。

    他のディストリビューションも同じとは思いますが、Momonga LinuxのXMLRPCは現行リリース（5.0.4-6m）でもセキュリティ対策済みです。

  • coMomongaのススメ

    遅ればせながら初めてcoLinuxのMomonga版であるcoMomonga2+（今のところ非公開です。8月のコミケで販売していたそうです。私はプロジェクトメンバーなのでscpでサーバから拾ってきました。）を使ってみました。非常に便利かつ思っていたよりレスポンスも良いです。

    coLinuxは初めてだったので一番最初はcoMomongaでは無くcoLinuxのインストーラから選択できるDebianをルートファイルシステムを使ってみました。このルートファイルシステムには本当に最小限のパッケージしかインストールされていないようでした。viもemacsも無い状態でした。ネットワーク経由でapt-getすれば良いのかも知れませんがviさえ無くて戸惑いました。Gentooのルートファイルシステムも選択できます。こちらはもう少し多くのパッケージがインストールされているのかも知れませんが試しませんでした。

    次にcoMomongaのISOイメージを試す事にしました。coMomongaのISOにはcoLinuxとXming（Xディスクプレイサーバ）インストール方法や設定に必要な全てのファイルが含まれています。WindowsのCDドライブにCDを挿入すると自動的にインストールマニュアルが表示されます。Xmingのバイナリも付いていてX Window環境も直ぐに構築できます。このマニュアル通りに設定するだけで簡単にセットアップできました。

    # ただし、このノートPCがWindowServerのドメインメンバー
    # であった為、ICS（インターネット接続の共有）がグループ
    # ポリシーで無効に設定されていたのでネットワークが使え
    # ませんでした。ドメインからワークグループに変えてネット
    #ワークを使えるようにしました。

    ブートが非常に速いのは助かります。同じノートPCのパーティションにインストールしたMomongaLinuxを起動するより随分速いです。Xも普通にストレスの無いパフォーマンスで動作します。コーディングなどの用途向け十分なレベルです。

    私のノートPC
    -PentiumM 1.3Ghz
    -768MB RAM
    -80GB 5200rpm HDD
    -WindowsXP Pro SP2

    スクリーンショット
    coMomonga
    （coMomongaをWindows上で実行し、coMomonga上のXクライアントに、Windowsで実行しているXmingからXDMCPでcoMomongaのXを起動している画面。正確に書くと長いですね… 説明は面倒ですがインストールは非常に簡単）

    今までノートPCのWindows環境でUNIXライクな環境が必要な場合にはcygwinを、Emacsが使いたい時はMewを使っていましたが今後はcoMomongaを使う事にします。ノートPCにもMomongaLinuxをインストールしていますが、諸事情によりWindowsがメインOSになっています。雑誌などの評価で非常に便利とは思っていたのですが食わず嫌い（嫌いではなかったですが）で今まで損をしていました。

    このcoMomonga2+ですが、Momonga Projectから今度のOSCで売りに出るそうです。是非購入(寄付?）しましょう :)

  • オンライン取引を安全に実行する方法

    先日のPHP関西セミナーで、管理者権限で動作しているスパイウェアなどがインストールされたPC上で、Web上のログインやフォーム送信の安全性を保障する方法は(説明した方法では）無いと言いましたがこれは変わりがありません。時間があまり無かったので補足しておいた方が良いと思える点を補足します。

    まずパスワードですが、パスワードが盗まれても大丈夫な仕組みは昔からあります。ワンタイムパスワードと呼ばれる方法です。ログインするコンピュータでパスワード生成プログラムを実行するとパスワードの安全性が損なわれる為、通常液晶が埋め込まれたカード型のパスワード生成機等のデバイスを使います。ワンタイムパスワードを利用している場合パスワードが盗まれる事はありません。他のコンピュータからログインされてアカウントを不正に利用される危険性はほとんど無くなります。

    ワンタイムパスワードを使えば安全か考えるとまだ安全とは言えません。正規のユーザがコンピュータを利用中にスパイウェア等がデータを書き換えてしまう危険性が排除されている事をWebサイト側では保障できません。現実的な脅威かは別として、例えば銀行のフォーム送信等でデジタル署名などを行っても安全性を保障する事はできません。管理者権限で動作しているスパイウェアがインストールされているコンピュータだけでトランザクションを行うと、スパイウェアが任意の時点でデータのすり替えを行い、本来送信しようとしている送信先とは別の送信先にお金を送信する、等の危険性はなくなりません。そもそも署名に必要な秘密鍵がコンピュータにインストールされている場合、スパイウェアは秘密鍵を盗む事が可能です。USBデバイス等で秘密鍵が絶対に読み取られないようなデバイスの場合、秘密鍵が盗まれる事はないかもしれませんが、液晶などの表示機能が無いと署名した取引情報が意図しているものかユーザは判別できません。

    信頼できないデバイス、スパイウェアがインストールされたPC等、だけを使用して信頼できるオンライン取引を行う事は技術的には不可能なはずです、安全に使えない、と言うのでは困るのでより安全に取引を行う方法を考えて見ます。安全に取引を行うにはトランザクションを行うデバイス、通信が信用できる必要があります。今の環境であれば、携帯電話に取引情報を送信して、携帯電話上で取引情報を表示・確認してから直接送信するか、署名してからPCで送信する方法が考えられます。携帯電話は信頼できる、と言う前提が必要です。別に携帯電話でなくても信頼できるデバイスで取引情報を確認し、取引情報改ざんを防ぐ署名ができる仕組みであれば何でも良いです。USBで接続された表示機能付き署名デバイス等でもOKです。ワンタイムパスワードの仕組みを知っている方なら思い浮かぶアイデアと思います。

    スパイウェアがオンライン取引の最中に取引データを改ざんし、表示された取引情報とは別の取引を行うリスクには対処できませんが、別のPCからの不正な取引を十分なほど防ぐには暗号表を使うのが良いと思います。セミナーでは暗号表は繰り返し暗号表を利用した取引を見ることによって解読できるので安全ではないと言いました。確かに暗号表の解読は、暗号表が固定的であれば、難しくありません。「固定的であれば」と条件が付くので「動的であれば」安全になります。ここでも信頼できるデバイスが必要になりますが、携帯電話メールが信頼できるとすると取引の度に新しい暗号表を携帯電話にメールで送信すればかなり安全といえます。頻繁に携帯電話に暗号表を送信する方法は現実的かつ実用的と思います。既に何処かで利用されているかな?

  • Advanced Bash-Scripting Guide

    名前の通りBASH専用リファレンス。ざっと見たところ結構便利そうなのでメモ。

  • PHP関西セミナーの資料

    9月3日にPHP関西のセミナー講師をさせていただきました。プレゼンテーションファイル作成の時間が足りなかった為、予定していたより内容が薄い資料になってしまいました。話を聞いて頂いた方以外にはよく分からないかも知れませんが、最近のオープンソースのPHPアプリケーション脆弱性レポートからどのように脆弱性が作られたか考察しました。

    セミナーを聞いて頂いた方向けに、その時のプレゼンファイル（PowerPoint形式）を公開します。

  • pgbenchのpthread版

    （やはりバグを発見したので修正）

    JPUG広報Blogに「pgbenchのpthread版が欲しい」と書いていましたが、先週末にPHP関西のセミナー講師を引き受けていたのでその移動時間中にテキトーに作ってみました。テキトーに作ったので勘違いしてバグを入れていました。今度はたぶん正しい結果になっていると思います。

    サーバ環境
    Athlon64 3200/3GB Memory/SATA2 HDD/Momonga Linux x86_64
    PostgreSQL 8.0.3(64bit)（全てのSQL文をホスト/ポート付きで記録。他はほぼデフォルト。）

    クライアント環境
    AthlonXP 2500+/2GB Memory

    pthread版pgbench

    [yohgaki@dev pgbench]$ time ./pgbench -v -h 192.168.100.204 -U yohgaki -c 10 -t 100
    starting vacuum…end.
    starting full vacuum…end.
    Warming up 15 seconds…
    Start benchmarking…
    End benchmarking….. (4.96586 seconds)
    transaction type: TPC-B (sort of)
    scaling factor: 10
    number of clients: 10
    number of transactions per client: 100
    total number of transactions processed: 1000
    tps = 235.404176 (excluding connections establishing)

    real 0m25.739s
    user 0m0.214s
    sys 0m0.313s
    [yohgaki@dev pgbench]$

    こんな感じです。

    何だか遅くなってしまたのでコードをもう少し効率化してみました。
    今度はオリジナル版よりは速くなりました。

    pthread版pgbench

    [yohgaki@dev pgbench]$ time ./pgbench -v -h 192.168.100.204 -U yohgaki -c 50 -t 10
    starting vacuum…end.
    starting full vacuum…end.
    Warming up 0 seconds…
    Start benchmarking…
    End benchmarking….. (1.16363 seconds)
    transaction type: TPC-B (sort of)
    scaling factor: 1
    number of clients: 50
    number of transactions per client: 10
    total number of transactions processed: 500
    tps = 429.689481 (excluding connections establishing)

    real 0m2.655s
    user 0m0.047s
    sys 0m0.088s

    オリジナル版

    [yohgaki@dev pgbench]$ time pgbench -v -h 192.168.100.204 -U yohgaki -c 50 -t 10
    starting vacuum…end.
    starting full vacuum…end.
    transaction type: TPC-B (sort of)
    scaling factor: 1
    number of clients: 50
    number of transactions per client: 10
    number of transactions actually processed: 500/500
    tps = 337.674248 (including connections establishing)
    tps = 379.093451 (excluding connections establishing)

    real 0m1.615s
    user 0m0.043s
    sys 0m0.210s

    と、多少スレッド版の方が速いです。今度は繰り返し実行してみてもスレッド版の方が速い傾向は変わりませんでした(汗

    ベンチマークを開始する前にウォーミングアップの時間を設定したかった事、クエリ実行間隔をランダムに設定したかった事もpthread版が欲しかった他の理由でした。そこで

    -w ウォームアップ時間（秒）
    -r ランダム遅延（マイクロ秒）

    も設定できるようにしました。よくあることですがサーバに負荷をかけた直後は良い性能がでるためウォームアップ時間は設定できた方が便利です。

    ウォームアップ時間を5秒に設定した場合

    [yohgaki@dev pgbench]$ time ./pgbench -v -h 192.168.100.204 -U yohgaki -c 50 -t 10 -w 5
    starting vacuum…end.
    starting full vacuum…end.
    Warming up 5 seconds…
    Start benchmarking…
    End benchmarking….. (1.48874 seconds)
    transaction type: TPC-B (sort of)
    scaling factor: 1
    number of clients: 50
    number of transactions per client: 10
    total number of transactions processed: 500
    tps = 335.854481 (excluding connections establishing)

    real 0m6.671s
    user 0m0.124s
    sys 0m0.260s

    とこの様な感じです。オリジナル版にウォームアップ時間オプションを追加して欲しいな、と書いておいたら石井さんが追加してくれるはず :)

    ソースは
    http://www.ohgaki.net/wiki/index.php?PostgreSQL%2Fppgbench
    からダウンロードできます。変更するかもしれないので日付を入れておきました。日付が入っていないソースは古いソースです。もし古いソースをお持ちの場合、新しいソースを使ってください。古い物にはバグがあります。

  • グラフィックテキストも安全ではない

    昨日に引き続き「絶対安全」と誤解されているかもしれないセキュリティ対策の話です。

    CSRF(クロスサイトリクエストフォージェリ）対策、アカウント作成ボット対策としてグラフィック上に書かれたテキストを読み取らせるサイトが多くあります。普通のOCRで読み取れるような簡単なグラフィックテキストでもコメントスパムなどのボット対策としては（今のところ）十分有効ですが、認証用のグラフィックテキストを生成するプログラムにはCAPTCHAが有名です。

    単純なグラフィックテキストだとOCRで機械的に読み取られてしまう事は明白です。昨日、IRCで話をしていてOCR技術はかなり向上してきており単純な物は100%認識できてしまうようなってしまっている事を知りました。この分野はあまり気にかけていなかったので昨日PWNTHAと言うCAPTCHAなどで作成されたグラフィックテキストを読み取るツールを知りました。リンク先を見ると分かりますが、今では結構OCRで読み取りが難しいと思われるようなグラフィックでもかなりの高確率で読み取れるようです。

    仕掛けは多少大掛かりになりますが、グラフィックテキスト情報を人間に読ませる攻撃方法も考案されています。例えば、こんな感じです。

    前準備：音楽、映画、アダルトコンテンツなど多くのネットユーザが参照したくなるWebサイト（以下、「解読サイト」）を用意する。

    1. プログラムで攻撃対象のWebサイトのグラフィックテキスト付きページを開きページを保存する。
    2. グラフィックテキストを解読サイトのコンテンツダウンロードの認証キーとしてユーザに解読させる。
    3. ユーザが解読してくれたテキストを攻撃対象のWebサイトの認証キーとして利用する。

    このような手法を用いられた場合、グラフィック上に記述されたテキストや写真情報を使った防御策も完全とは言えません。

  • JPUGでスタッフ募集中です

    どこでも状況は似ているとは思いますが、JPUGの活動を支えてくださるスタッフを募集中です。東京近郊の方は是非ご協力下さい。