日々のメモ書き
Debian Developerが綴るメモ
H2A F14
だんだんと安心して見ていられるようになってきてなによりである。
微妙な空模様だったためいまいち映えない映像であった。
F14はSRBやLE-5Bの改善がされているようです。空中着火もいろいろややこしいやりかたでやってますな。
JPCERTからお手紙
今年も来ました、SSLクライアント証明書申請様式。
JVNに登録されているので毎年出しているが、まともに使ったことが全然ない。中の人にも存在意義がよくわからんと直接文句言ったことがあるが、中の人も悩んでいるらしい。
あれ、返信封筒の切手自分で貼るの？去年までそうだったけ？
ホストRAIDのLinux対応
3年ぐらい前にPCを買ったときにPromiseのホストRAID(SATA RAID)がついていた。そのころはいろいろドキュメントを調べた結果、かなり苦労しないとダメだろうという結論が出た。
dmraidで何するんじゃという話があったりしたが。3年経って、今調べてみたら結構対応しているんですねえ。http://linux-ata.org/driver-status.html を見てみるといろいろ対応している。性能がいまいちという話もあるけど、なかなか面白そうである。今さら自分のPCのディスク構成をいじるのは無理だけど…。
Adaptecの14xxシリーズなんかが面白そうなんだろうか？
vitoolsをDebianに
頑張って、というほどでもないが移植。
普通にコンパイルができるのでちょこちょこと修正するだけなので難しさはなく。init.dをどうしようかと考えたぐらい。initramfsをちょいちょい試行錯誤してみたらきちんとvi tools enableで動く。わーい、migrationができる。driverが2.6.18までは大丈夫だからEtchはOKなんだよな〜。その先がな〜。
linux/workqueue.h
2.6.19以降でいろんなマクロの仕様が変わったぽいな。
DECLARE_WORKとかINIT_WORKとかの引数の数が違うのでコンパイルできないモジュールがあった。変更がめんどくさそうだ。ドキュメントがないのがなあ…。単純に変更かけていいのか迷うよ。他のソースを見てみた。
- btrfsを見ると INIT_WORK -> INIT_DEＬＡＹＥＤ_WORK のようだ。
- ほかも2.6.18以前と以降で条件付きコンパイルになっている。結構ややこしそうだなあ。
btrfs-0.12
btrfs-0.12をためしてみる。
Debianのコンパイル済みのモジュールが0.11でツールが0.12だったので気付くまでマウントできないなあとはまった。自分でモジュールをコンパイルしなおして成功。
0.9から変わったと感じたのはsubvolumeの扱い。そのままマウントするとsubvolumeの親ディレクトリがマウントされたが、default subvolumeがマウントされるようになった。-o subvol=. で一覧がマウントされる。
ちなみにbonnieにかけたら途中でエラーになった。
Bonnie: drastic I/O error (write(2)): No such file or directory
日本(1-1)北朝鮮
あまりにもひどすぎる。
全てが消えた。オフザボールの動きも、ダイレクトパスの展開も、大きな展開も。守備もどこでチェックしているんだかさっぱりわからない状態。勝敗云々より内容が崩壊してしまっている。お先真っ暗。
久しぶり大勝軒
なんとなく行ってみた。前に行ったのいつだろう？1年以上前か？
多いかなあと思いつつもつけめん大盛りを注文。やっぱり多いかなあ、こんなことならお菓子食べなきゃよかったと思いつつ完食。あとにくる麺だぜ。
ライブラリのSSL証明書検証について
気になったのでざっと調べてみる。いろいろな言語のHTTPSを扱うライブラリで期限切れのSSL証明書を使っているサイトにアクセスしてみる。
- Ruby - open-uriを使ったら OpenSSL::SSL::SSLError: certificate verify failed となった
- Python - urllibを使ったらそのままスルー
- PHP5 - cURLを使ったら curl_execが FALSEを返すようだ。他のcURLも同じかな？
CAS認証について
どこぞで使っているCAS(Central Authentication Service)認証を使ったサービスをちょっと使ったので前から気になっていることをまとめて書く。
- クライアントとアプリケーションの参照しているDNSが両方乗っ取らられたら死ぬよね。認証サーバが変なとこ挿していても気付かない。
- さてアプリ側のDNSのみ乗っ取られたとする。偽CASサーバーを立ててアプリ側からそっちを見るようにする。偽CASサーバーは通常は透過的に本物のCASサーバーに接続させているとする。CASの手続として認証が終わったことにするとGETでチケットをアプリに渡して、アプリはチケットの検証を偽CASに問い合わせる。通常ならチケットは使い捨てのランダムな文字列なので、手動で適当にチケットを生成するなどの横取りは難しい。が、偽CASが偽チケットを許可したらどうなるか…。
- SSL証明書でサーバーの信頼性を確保？EV SSLじゃなかったら最近のSSL証明書なんてどこまで信用できるのやらという見方もできるよね。大体アプリのコードの中でSSL証明書の検証していますか？
- さて、この推測に誤りはあるのだろうか？
- さて、正しいものとして進める。確かにDNSを外部から乗っ取るのは楽ではないかもしれないが、DNSの管理者はアプリの管理者と同一とは限らない中でDNSの信頼性に頼るやりかたでいいのだろうか。脆弱性とはではいかんけどさ。SSL証明書がどこまで信用できるかがポイントかなあ。
- ところでせっかくのポータル上で動いてないのはなぜだろう。