|
|
||
Erlang愛好者のパーティをErloungeという.いわゆるlightning talkなんかが前置きとしてあって,その後は宴会になだれこむ,というのが典型的なErloungeの進め方らしい.といっても,世界各地それぞれの流儀で行っていることなので,特に決まりはないようだ.でも,Erloungeでの話は,一般の飲み会同様秘密だとか :)
Erlang User Conference 2009の写真はこんな感じだ.
http://www.flickr.com/photos/erlang-consulting/4119700138/
ところで,日本でも来月12月末には id:cooldaemon 主催の第1回 Erlang 基礎勉強会,そして来年の2月(3月になるかも)には第4回Erlang分散システム勉強会(aka Tokyo Erlang Workshop #4)が開かれるようだ.これらの勉強会の後には多分Tokyo Erloungeが開かれるだろう.興味のある人はぜひ参加を.
Erlangの文法は他の言語と違って独特なので,CやJavaの文法に慣れた人には読みにくいようです.しかし,コツをつかんでしまえば,案外早く読めます.
厳密ではありませんが,大まかなヒントとして
というのがあります.
もちろんcaseやtry/catch/throw,fun(...) -> ... endなど,必ずしもこの規則に厳密に従わない文法はありますが,少なくとも . (period) に関する原則は徹底しています.このような句読点の打ち方は,英語やフランス語,ドイツ語など,複文や同格表現を多用する言語と同様であると考えれば良いでしょう.一方,形式的なブロック構造にこだわっていると,読みにくいままかもしれません.
以上,最近コードを読み進めていた時の雑感でした.
DNSはインターネットの各種基本プロトコルの中で最も扱いにくいもののひとつ.本当に高速な処理(=100kqueries/sec or faster)が要求される局面では,たぶんErlangのように一度VMが間に入る言語システムでは間に合わない.しかし,Erlangは並行処理が書き易いという利点は,DNSの各種サブシステムでは役立つと思う.ちょっとしたキャッシュサーバ,コンテンツサーバなどには向いているだろうし.もしErlangで何かDNS関連のアプリケーションを作るなら,yawsやMochiwebみたいなものを目指すべきだろうと思う.
DNSの研究開発というのは実は非常に難しくて,
などの問題がある.
そして,日本でDNSの研究開発を本気でやるなら,
という,実はコーディングよりも,運用のスタミナが要求される非常に厳しい道以外にないんだろうと思う.残念ながら,私は上記のどれにも関われない状態のまま,挫折したけど.
個人であれば,神明達哉さんのように渡米してISCでBINDの開発にかかわる,という直球勝負をする方法もある.しかしこれはこれで生活を賭けなければいけないことで,そう簡単に誰でもできるわけではない.
ただ,DNSは研究開発だけじゃなくて運用や解釈も難しいので,DNS自身に関する知識や技はインターネットで何かやろうとする限りはついてまわるし,覚えておいて損はないと思う.Erlang R13B01なら,まず lib/kernel/src/inet_dns.erl を読むことから始めるべきだろう.
そして,DNS自身は,実装は今とは大きく変わる可能性があるけど,世界からドメイン名が消えてなくなる時が来るまでは残るシステムだろうと思う.
以上,つらつらとTwitterに書いたことをこちらにも.
20年前Cを勉強していたころに比べると,コーディング以外の雑事がどうしても増える.ろくに時間が取れていない.
そんなことを理由にしてはいけないのだが,Erlangの学習とコード書きが上達しない.正直,焦っている.id:Voluntas や id:kuenishi や id:cooldaemon (はてなidのみなさんは敬称略)そしてたけまるさんやMikageさんのコードにはとてもとても及ばない.
もう1年半もやっているのだから,もうすこしマシなものが書けても良さそうなものである.できない理由はいくらでも考えつくが,そんなことを議論している暇があったら少しでも手を動かさなければ.
…そんなことを思いながら,夏が終わるのと戦っている.
R13B01のssh_transport.erlを見るとわかりますが,ストリームの暗号化は3des-cbcにしか対応していないのですね.RFC4253 Section 6.3では3des-cbcはREQUIRED,aes128-cbcはRECOMMENDEDとなっています.
すでにAESが2001年にNIST標準 FIPS-197になって8年も経過しているのに,Erlangのssh moduleでサポートされていないのは単純に悲しいと思い,コードを書いて対応できるようにしました.すでにAES CBCモードの基本的な関数はcrypto moduleにありますし,ssl moduleを見てみるとAESのCBCモードが使われています.
この作業でハマったのは,ssh_transport:unpack/3という関数が,MAC以外の内容がなくなった時点でIV抽出用の関数に<<>>(ヌルバイナリ)を渡そうとするため,その関数で落ちるという問題があったためです.RFC4253 Section 6のBinary Packet Formatを見るとわかりますが,padding lengthがゼロというパケットも当然あり得るため,その時のエラー処理が不十分だったものと思います.以下で変更したのは"case SshLength of"の部分だけですが,これで無事処理できるようになりました.
%% Erlang R13B01 lib/ssh/src/ssh_transport.erl より該当する関数だけ抽出 unpack(EncodedSoFar, ReminingLenght, #ssh{recv_mac_size = MacSize} = Ssh0) -> SshLength = ReminingLenght - MacSize, %%?dbg(?DBG_CRYPTO, %% "unpack: EncodedsoFar=~p SshLength=~p ReminingLenght=~p MacSize=~p ~n", %% [EncodedSoFar, SshLength, ReminingLenght, MacSize]), {NoMac, Mac, Rest} = case MacSize of 0 -> <<NoMac0:SshLength/binary, Rest0/binary>> = EncodedSoFar, {NoMac0, <<>>, Rest0}; _ -> <<NoMac0:SshLength/binary, Mac0:MacSize/binary, Rest0/binary>> = EncodedSoFar, {NoMac0, Mac0, Rest0} end, %%?dbg(?DBG_CRYPTO, "unpack: NoMac=~p Mac=~p Rest=~p ~n", %% [NoMac, Mac, Rest]), {Ssh1, DecData, <<>>} = case SshLength of %% この部分でハマる可能性がある 0 -> %% 解読するものがないときは {Ssh0, <<>>, <<>>}; %% ヌルバイナリを返すようにした _ -> ssh_transport:decrypt_blocks(NoMac, SshLength, Ssh0) end, %%?dbg(?DBG_CRYPTO, "unpack: Ssh1=~p DecData=~p Rest=~p Mac=~p ~n", %% [Ssh1, DecData, Rest, Mac]), {Ssh1, DecData, Rest, Mac}.
あとはcrypto moduleにAESのIV抽出用関数を1つ,そしてssh moduleにaes128-cbc用の処理コードを書き加えればOKです.この方法で他の暗号方式にも対応できるでしょう.
パッチの詳細については
http://www.erlang.org/cgi-bin/ezmlm-cgi?3:mss:449:200908:jocpkoflfkoikpmnfcnj
を参照してください.
自分は力武さんに電離層のネタがいつか触れる日を夢見てますw
私は、erlang + ssl なんてサッパリ解りませんよ orz
僕もErlangに注目し始めてそろそろ2年になるのですが、もうすこしマシなものが書けてもよさそうだろ、とか、他の人のコードを見て溜め息をついていたりします:'(