パスワードを忘れた? アカウント作成
326999 journal

Claybirdの日記: 公開情報の扱い 1

日記 by Claybird

「公開されている情報をまとめるのは自由で、責任も問われない」とでも言い換えられるような言動を見かけた。
「誰でも見られる情報なんだから」というのが理由である。
そんな訳あるかと。

モヤモヤしたので理由を考えてみた。

「公開されている情報を見られても文句は言うな」、なら正しいと思う。
しかし、「公開されている情報をまとめた者に文句を言うな」、には違和感を覚える。

正確には、まとめ作成は自由だと思う。
が、まとめを作ること(まとめかたなど)に責任が伴わないという発想はおかしい。

# 「まとめ対象の情報を出した側」の責任についてはここでは言及しない

情報発信においては、「ある情報を発信することの責任(の少なくとも一部)は、それを作成・公開した者にある」のが原則だ。
だから、「公開されている情報を見られても文句は言うな」は正しい。

# 情報を受け取った者の責任は「嘘を嘘と~」の名言通り。

しかし、世の中には大量の情報が公開されている。その中から有用な情報を見つけ出すのは容易ではない。そこで情報を取捨選択し、「情報がどこにあるかを示す行為」に価値が認められる。検索エンジンやニュースサイトは、これで食っているわけで。

つまり「情報がどこにあるか」も情報である。まとめ作成における「情報がどこにあるかを示す」ことや「情報を組み合わせて公開する」ことも情報の発信であり、当然責任がある。
まとめ作成においては、人が作業する以上、編集者の個人的な主観も紛れ込む。しかも、並べ方次第で文脈を作り上げ、悪意を持って印象操作を行うことも可能だ。だからこそ、まとめ作成には(一次情報発信者より少ないとしても)責任が伴うことを意識する必要がある。

まとめただけだから、僅かな責任すらない、というのは受け入れがたい。

278530 journal

Claybirdの日記: new design? 2

日記 by Claybird

[背景]
ここのところWindows環境は64bitと32bitの環境が混在している。この状況はまだしばらくは続きそうだ。
32bitは資産が豊富だが、64bitネイティブなプログラムのパフォーマンスも欲しい。

ここで統合アーカイバAPI仕様について考えると、各種DLLは32bit用だ。
将来的には統合アーカイバフロントエンドは64bitネイティブになっていくだろうと思う。
しかしWindows上で32bit-64bitのThunkは無いようなので、フロントエンドとバックエンドは全部64bitか全部32bitで統一しないといけない。
とはいえ、古いプログラム/アルゴリズムだと64bit化を考えていないものもあるだろうし、いずれにしても移植が済むまで時間がかかるだろうから、しばらく統一は無理そうだ。

統合アーカイバ仕様はいずれ64bit化しなければいけないが、どうせ64bit化するなら、この機会に仕様を変更してもいいのではないかと思って、そのたたき台を考えてみた。
誰かやってみませんか?

[やりたいこと]
・32bitの資源と64bitのパフォーマンスの恩恵を受けたい。
・万人にとって、できるだけ32bit->64bitの移行を楽に、混乱無く行いたい。
・仕様を変更するついでに、コマンドなどを統一してプログラムしやすくしたい。

[提案]
・従来通り、フロントエンドとバックエンドの組み合わせとする
・バックエンドはGUIを持たず、完全なエンジンに徹する
    →GUIはフロントエンドの役目
・バックエンド、フロントエンドともに単体の実行ファイルとする
    →exeに特定のコマンドラインを与えたときのみバックエンドモード、それ以外はどんな挙動でもかまわない
・バックエンドとフロントエンドの通信はOS標準のパイプとする
    →HTTP通信を参考に?
・一つのバックエンドを同時に複数実行するときは、複数のプロセスとして起動する
    →バックエンドに対してマルチスレッド処理の制約がない
・バックエンド操作はすべて文字列コマンドで行う。コマンドはすべて規格化(基本/拡張Lv.など)しておく
    →基本的には1回1コマンド。コマンドラインの解析を可能な限り単純化する。
    →バックエンドはステートを持ち、OpenGLのglEnable()のように個別のコマンドで1回の呼び出しにつき1つのステートを変更する。
    →バイナリデータの送信は別パイプ(名前付きがよいか?)を開く。手順的には
        (Front)データ送信 to data pipe→
            (Front)完了通知 from cmd pipe→
                (Back)読み込み from data pipe→
                    (Back)完了通知 to cmd pipe
・通信に使う文字列は少なくともUTF-16を扱えることを必須とする
    →アーカイブ中ファイル名文字コードを制約するものではない
    →当面大丈夫だと思うが、文字コードを変更できるようにしておくべき
    →正規化や非UTF-16に変換するときの規格外文字置き換えのルールも設定できるようにする
・空白や記号('"','\'等)を含む文字列のエスケープ方法を規定する
    →現行の統合アーカイバ仕様におけるパスワード設定の混乱を避けたい
・バックエンドは自分の持つ能力を詳細に返答する
    →*QueryFunctionList()よりも詳細に
    →アーカイブ名や形式名を与えて、扱える文字コードや複数ファイルの格納可能性などを文字列として返答する
・フロントエンドが全ての入出力を行う
    →メモリからの直接圧縮/展開などの利用を念頭に
    →おそらくファイルポインタのシークのためのコマンドが必要になる
    →ただしバックエンドが部分的または全ての入出力を行っても良い
    →モード切替でこの動作を変更できるようにする
・他に考えたいこと
    →言語ロケールの影響排除
    →バックエンドに割り振るスレッド数を設定できるようになるとうれしい

[メリット]
バックエンドを単体のExeとすることで、通常のコマンドラインツールと統合アーカイババックエンドを共通化することもできる。
    →特定のコマンドを与えたときのみ統合アーカイババックエンドとして動作するため

また、伝統的なコマンドライン(人間用)と統一されたコマンド(フロントエンド用)が無理なく共存できるため、両者の利点を享受できる。
最終的には従来仕様と比べて単純化できると思われる。

フロントエンドとバックエンドのbit数が一致しなくても良くなる。
32bit/64bitの混在が可能になるほか、要求ランタイムのバージョン違いに起因するトラブルを回避できる。
(.Net CLRにこの種の問題があった気がする。http://blogs.msdn.com/b/oldnewthing/archive/2006/12/18/1317290.aspx)

バックエンドとフロントエンドのプロセスが分離されることで、メモリ空間が保護される。
バックエンドをプロセスにすることで、バックエンド側でマルチスレッド対応などを考える必要なく並行処理が可能となり、バックエンドが簡略化される。

標準的なOSに実装されているパイプを用いて通信を行うことにより、OSの違いによる影響を最小限にできる。
他のOS用の実装も可能だろうし、フロントエンドをスクリプト言語で仕上げる事もできるだろう。

さらにバックエンドがフロントエンドと同じマシンで実行される必要がない。
つまり、理論上は(十分な帯域を持つ)ネットワーク上のマシンに圧縮作業を丸投げする事もできる。

[デメリット]
統合アーカイバプロジェクトの資産があまり生かせない
    →多少無理はあるが、統合アーカイバDLLにラッパをかぶせるとよいかもしれない
フロントエンドの処理が複雑になる
    →ラッパライブラリをかぶせることで対応可能(データベース用のラッパに近い感じになる)
DLLと比べてパフォーマンスが悪化するかも

[コマンド案]
凡例:
> command from frontend

> process.initialize
< 120 Hello
> process.setmode compress        <-圧縮モード
< 100 OK                          <-バックエンドからの返答;コードは仮
> process.method tar+xz           <-圧縮メソッド
< 100 OK
> process.option level 6
< 100 OK
> output.mode file
< 100 OK
> output.filename C:\temp\test.tar.xz     <-ファイル名エンコードは未定
< 100 OK
> input.mode pipe
< 100 OK
> input.pipe FOO   <-入出力に使うパイプ名
< 100 OK
> process.begin
< 100 OK
> input.item.time.create 123456789.01   <-epochからの経過秒数;GMT
< 100 OK
> input.item.time.upadte 123456789.01
< 100 OK
> input.item.attribute readonly         <-ファイル属性(仮);パーミッションは?
< 100 OK
> input.beginitem data0.txt
< 100 OK
(ここでFOOにデータ送信)
> input.sent 3271        <-送信バイト数
< 200 3271 Received      <-返答コード+受信バイト数+メッセージ
> input.enditem
< 400 1621 Compressed    <-現在の圧縮後ファイルサイズ
> input.item.time.create 123456789.01
< 100 OK
> input.item.time.upadte 123456789.01
< 100 OK
> input.item.attribute readonly system
< 100 OK
> input.beginitem video.bin
< 100 OK
(データ送信)
> input.sent 40960                <-複数回の送信
< 200 40960 Received
< 400 27330 Compressed
(データ送信)
> input.sent 40960
< 200 40960 Received
> output.state
< 400 57658 Compressed
< 410 85191 Received
> input.enditem
< 400 57658 Compressed
> process.end
< 100 OK
> process.finish
< 110 Bye

エラー例

> process.initialize
< 120 Hello
> process.setmode compress
< 100 OK
> process.method invalid-method-name
< 500 error unknown method
> process.method tar+some-method
< 100 OK
> process.option level 6
< 510 error option not supported
> output.mode file
< 100 OK
> output.filename C:\temp\test.tar.xz
< 600 error access denied
> input.mode pipe
< 100 OK
> input.pipe FOO
< 700 error already exists
> input.pipe BAR
< 100 OK
> process.begin
< 100 OK
> input.beginitem data0.txt
< 800 warning supplemental information missing       <-更新日時などの設定前にbeginitemを呼び出した
> input.item.time.create 123456789.01
< 810 warning supplemental information ignored    <-enditemとbeginitemの間に呼び出す必要がある
(データ送信)
> input.sent 3271
< 820 3200 error unexpected end of data      <-一部受信できていない
> process.abort
< 100 OK
> process.finish
< 110 Bye

232659 journal

Claybirdの日記: LZH形式への個人的な擁護 5

日記 by Claybird

Micco氏はLZH形式に対し、いくつか(後方互換性をある程度保ちつつ)拡張を行っている。
その結果、2006年頃からLZH形式は、
・UNICODEファイル名への対応(2006年3月、Unlha32.dll Ver 2.39 α)
・4GB以上の大容量ファイルの格納(2001年6月、Unlha32.dll Ver 1.56)
にも対応している。[Unlha32.dll添付のドキュメントを参照]

将来的に実装される予定だったのか、暗号化のためのヘッダ領域も予約されていた。

ZIPにおいてUNICODEがサポートされたのは2008年のWinZIP 11.22006年9月のPKZIP(ZIP仕様書 Ver.6.3.0)であり、LZHが半年以上先行している。

4GB越えの大容量ファイルがサポートされたのは2001年8月のPKZIP 4.52004年のWinZip 9.0であり、LZHが若干先行しつつZIPもほぼ同時期に対応している。

こうしてみると、LZHはZIPと比較して決して劣っていたわけではない。優れた技術が広く使われるとは限らないが、逆に広まった技術が優れているとも限らないのだ。
LZHはマイナーな"ガラパゴス規格"だから駄目な規格だと決めつける人には、果たして本当にそうなのか一度考え直して貰いたい。

232658 journal

Claybirdの日記: 「アンチウィルスソフトがLZHを検査しない脆弱性」続報

日記 by Claybird

「アンチウィルスソフトがLZHを検査しない脆弱性」について、ニュースサイトで話題になったが、それより後の動きについてまとめる。

・おさらい
私の前回の日記 http://srad.jp/~Claybird/journal/508709 および掲載された記事 http://srad.jp/security/article.pl?sid=10/06/07/0335205 参照。

    Unlha32.dll(*1)作者のMicco氏、細工を施したLZHファイルがアンチウィルスのチェックを逃れる脆弱性を発見
→原理的に同じ物だが、ZIP/CAB/7z等は脆弱性として受理、 LZHは非受理
→対ZIP等については修正された脆弱性が、対LZHでは残ったままに
→アンチウィルスにLZHの検査ができない脆弱性があり、このままでは悪用されてしまう
→LZHの使用停止呼びかけ

一部で誤解があったため強調しておく。これはLZH形式やUnlha32.dllの脆弱性ではない。アンチウィルスの脆弱性である。

*1: Unlha32.dll = Windows上でLZH形式を扱うための事実上の標準ライブラリ

・アンチウィルスの脆弱性に関連する前後の流れ
2010年 4月: アンチウィルスがLZHを検査しない脆弱性をJVNに報告
2010年 6月 2日: JVNから不受理との返答
2010年 6月 ~5日: Micco氏によるLZH使用停止の呼びかけ
2010年 6月 6日~: 各ニュースサイトで話題に
2010年 6月 7日: Micco氏、同氏の日記にて「なにやら微妙に趣旨が追加・変更されて JVNVU#545953 の追加情報として扱う形に落ち着いたようです」との追加情報を発表。
2010年 6月24日: JVNVU#545953にJPCERT/CC からの補足情報が追加される。 以下に、JVNVU#545953への追加内容を引用する。

本件は、アンチウイルス製品の脆弱性であり、圧縮アーカイバ製品や圧縮形式の脆弱性ではありません。
なお、CERT-FI のアドバイザリには、発見者が本脆弱性を発見した際に調査を行った圧縮形式として、ZIP, CAB, GZIP, 7Z および RAR が記載されていますが、これら 5形式のみならず LZH や ACE など、他の圧縮形式でも同じ問題が発生する可能性があります。

同日、Micco氏は日記にてコメントを発表。以下にコメント内容を引用する。

あの一文を載せることが「JVNVU#545953 の追加情報として扱う」ということだと言うのであれば, はっきり言って必要ありませんので削除して下さい。 あれでは「脆弱性があるかもしれないね」という方向で受け取る方のほうが圧倒的に多いでしょうから, ないほうが よほどマシです。

・個人的な意見
Micco氏が各種アンチウィルスにおいて検査すり抜けの脆弱性を確認しているので、可能性がある、という弱い記述ではなく、せめて「報告されている」等としておいた方がよいのではないかと思う。
今のままでは注意喚起として不十分である。
本来なら、脆弱性発生条件の確認や追試を行い、問題発生の有無を断言すべきであろう。不正確な情報は混乱を招くだけである。

・Unlha32.dll関連の情報
2010年 6月 2日: Micco氏、Unlha32.dll開発(新型・新機能追加)停止を発表
2010年 6月 7日: Micco氏、Unlha32.dllの64bit版は開発続行と追記。64bit版は既に開発を約束していたため。

[お詫び]前回のタレコミ時タイトルを「Unlha32.dll等開発停止、LHA書庫の使用中止呼びかけ」としてしまいました。このため、多数の人に「LZH形式/Unlha32.dllに脆弱性があるのか?」との誤解を与えてしまい、誤った情報が一部で広まってしまった事をお詫び申し上げます。

226400 journal

Claybirdの日記: Unlha32.dll等開発停止、LHA書庫の使用中止呼びかけ 215

日記 by Claybird

ratbetaさんの日記 http://d.hatena.ne.jp/ratbeta/20100605 経由。

Unlha32.dllの開発が停止された。バグ対応などは当面続けられる模様だが、http://www2.nsknet.or.jp/~micco/notes/ann.htm にて、LZH(LHA)形式の使用中止が呼びかけられている。

経緯について、作者であるMicco氏のページから、自分の理解できる範囲で簡単にまとめてみる。間違いがあったら指摘して欲しい。
また、詳しい情報はMicco氏のページ http://www2.nsknet.or.jp/~micco/micindex.html を参照して欲しい。

・背景
LZH形式は国際的にはマイナーな形式である。しかし日本国内ではパソコン通信時代から広く使われており、今でも多くのLZH書庫が存在する。また、今なお新規にLZH書庫が作られているため、当面はLZH書庫を扱う場面があると思われる。

・簡単にまとめると
    圧縮ファイルがアンチウィルスのチェックを逃れる脆弱性が見つかる
→原理的に同じ物だが、ZIP/CAB/7z等は脆弱性として受理、LZHは非受理
→アンチウィルスにLZHの検査ができない脆弱性があるため、LZHは使うべきではない

・もう少し詳しく
2006年 http://www2.nsknet.or.jp/~micco/notes/headerBOF.htm
2010年 http://www2.nsknet.or.jp/~micco/vul/2010/mhvi20100425.htm

脆弱性1.(バッファオーバーフロー)
いくつかのソフトウェアについて、大きなヘッダを持つLZH書庫(仕様上は正しい)を読み込むとバッファオーバーフローが発生する脆弱性が見つかる。

脆弱性2.(検疫通過)
上記のバッファオーバーフローが起こらないソフトウェアの中には、大きなヘッダを持つ書庫ないし格納ファイルを無視するものがある。
アンチウィルス製品等の中にも問題書庫を無視するものがある。このためセキュリティ対策をすり抜ける書庫が作成可能であると報告される。

このことをもって、Micco氏から
「上記の例を組み合わせるだけでも, 『多くの対策ソフトの検疫をすり抜ける, バッファーオーバーフローと格納ファイルによる二通りの攻略方法を施した書庫』が出来上がってしまいます。」
と報告されている。

この脆弱性2.(検疫通過)について、同様の脆弱性は、LZH形式以外にもARJ形式やZIP形式等についても発生しうる。
ZIP/CAB/7z形式等についてはCVE-2010-0098をはじめ、脆弱性として認識された。しかし、LZH形式については脆弱性報告は不受理であった。

アンチウィルス製品は2006年の報告以降対応されず、JVN / IPAが脆弱性として(なぜか)受理しなかったため、今後も対応される見込みは薄い。
したがって、今後も各種アンチウィルス製品にはLZHが検査できない脆弱性があるため、Micco氏はLZHの使用中止を呼びかける。
加えて、Unlha32.dll/UNARJ32.DLL/LHMeltの開発中止に至る。

[追記]
10:22 June.06: 表記修正

199109 journal

Claybirdの日記: IContextMenu::GetCommandString()

日記 by Claybird

Windowsのシェル拡張による右クリックメニューについて、追加したはずのメニューが表示されないバグがあった。これまでIContextMenu::QueryContextMenu()内で問題があると考え、InsertMenuItem()の呼び方が悪いのか、とか、OSの仕様なのか、とかいろいろ試していた。

が、http://blogs.msdn.com/oldnewthing/archive/2004/10/06/238630.aspxを読んでいて、QueryContextMenu()は正常で、GetCommandString()に問題があった事に気づいた。

ドキュメントなどを読むと、どうやら、GetCommandString()がメニューの存在確認も行っているらしい、と言うか、このメソッドで前に追加された古いメニューを消して良い物かどうかの判定をしているらしい。メソッドの名前からは想像しにくい機能だ。

GetCommandString()呼び出し時のフラグに GCS_VALIDATEA / GCS_VALIDATEW があると、存在確認らしいので、適当にS_OKなどを返しておかないと勝手にメニューが消されてしまう。

このあたりのコードを修正すると、今まで動かなかったコードが動くようになった。

115798 journal

Claybirdの日記: .xz/.lzma

日記 by Claybird

ここしばらくTar32.DLLに関して作業中である(作者氏には連絡済み)。

最近GNU TarがLZMA方式の圧縮に対応したらしいので調べてみた。
どうやらフォーマットとして.lzmaと.xzがあるらしい。しかも.xzは.lzmaの後継だとか。
よく知らないけど、.lzmaってそんなにメジャーだったのかな。

間違ってるところとかあれば突っ込みをお願いします。コメント等もご遠慮なくどうぞ。

---
tukaani.orgはXZ UtilsとLZMA Utilsを作っている
    - XZ Utilsは.xzを吐く
    - LZMA Utilsは.lzmaを吐く

・.lzmaを吐くコードにはLZMA Utils以外に本家LZMA SDK(7-zip.org)がある

・LZMA UtilsはXZ Utilsに移行した

・XZ Utilsは2009/7/1現在 ベータ版
    - .xzフォーマット自体はほぼ安定状態(非ベータの意味か)にあるらしい(http://tukaani.org/xz/xz-file-format.txt)
    - このフォーマットの仕様書は2009/01/29に公開された

・XZ Utilsは最初に安定版を出すときにコードをPublic Domainにする予定
    - 現状はLGPL

・.lzmaは.xzとは違う形式
    - 仕様書を見る限り、少なくともヘッダは違う

http://www.gnu.org/software/tar/tar.html#releasesによると
    - GNU Tarは1.20から.lzmaをサポートしていた
    - GNU Tarは1.22から.xzをサポートした
    - 1.21でショートカットとしてオプション"-J"に.lzmaを割り当て
    - 1.22で"-J"は.xzに割り当て変更

・今後.xzを(.lzmaの置き換えとして)主流にする予定
    - これから作成するときは.lzmaよりは.xzにした方がいいのか?(疑問)

・「LZMA方式(もしくはその派生)」は.lzmaと.xzの両方で使われている圧縮アルゴリズム
    - .7zでも使われる
    - .lzma/.xzにとっての「LZMA方式」は、.zip/.gzにとっての「Deflate方式」と同じような位置づけか?(確証無し)

・Cygwin上で試したところ、ツールの「xz」は.lzmaを展開できるようだ
    - 置き換えを狙う以上、互換性は保ったということか?(確証無し)

---
.xz/.lzmaのファイル自体がまだそれほど出回っていない上に、.xz自体登場してまだ間もない形式なので、様子見になりそうな感じ。
こちらのコードで書くならXZ Utilsのベータが取れるのを待つ感じになるかもしれない。うまくいけばXZ Utilsが.lzma/.xzの両方をサポートしてくれるかもしれない。

68514 journal

Claybirdの日記: 私信

日記 by Claybird
さて、HAL君について。
黙っておくのはよくないし、かといって内容が個人的すぎてメーリングリストで回すほどではない。でもきっとHAL君も見るであろうここに書かせてもらう。

---
HAL君。君はいつも逃げているけど、次はないよ。もしかしたら今回でもうアウトかもしれない。誰が手を下すにせよ、次はインターネット上の騒ぎだけで収まるとは思わないことだ。
二十歳過ぎてるんだから、もう自分の行動が起こす結果についてぐらい考えられないとだめだ。君一人が影響を受けるならまだしも、周りの人間まで迷惑を受けるのだから、同じ大学の人間としてこれぐらい言わせてもらう。

君のこれまでの様子からすると、今度もしばらくしたらどこかで名前を変えて出てくるつもりだろう。少なくとも隠れてプログラムを公開している(いた)ぐらいだから、自己顕示欲は強いはずだ。
そんな君のこれまでの挙動を見ていると、まるで遊びのかくれんぼだ。ブログには検索で引っかかるようなキーワードを並べ、隠れたいのか見つかりたいのか、むしろ見つけてほしがっているようにさえ見えた。
そんな君が名前を変えてみたところで、言動から遅かれ早かれ特定されるだろう。

過去を完全に清算してやり直すか、完全に手を引くか、あるいは言葉の上で"引退"して今までのようにぬるく名前だけ変えてその場だけしのぐか。君次第だが、せめて覚悟を決めてからやるように。隠れるなら二度と出てくるな。

最後に。
君は私を嫌っているかもしれないが、私自身は君について特に感情を持っているわけではない。ただ、学内MLで君が見せた逃避行動には呆れていると付け加えておく。
463949 journal

Claybirdの日記: CUDA(nvcc)とVCを仲良くする

日記 by Claybird

だいぶん前にTwitterで書いたことだけど、そのまま埋もれて消えていってしまいそうなので、改めて書き留めておく。

大学でCUDAを使っていたのだが、IDEをVC2005にして作業していた。で、よくコンパイルエラーを起こすわけだが、エラーが起きたときVC2005はnvccの行番号を理解できないらしく、エラーメッセージをクリックしてもジャンプしない。
これでは不便きわまりないので、sedを使って出力を変換してやるようにした。

nvcc.exe %* 2>&1 | sed -e "s/\"\(.*\)\", line \([0-9]*\)/\1(\2)/g"

こんな感じのコマンドをnvccl.batなんて名前にしておいてパスの通ったところに置いておく。

元ネタ:http://blogs.dion.ne.jp/satojun/archives/4004468.html

あと、VC2005のエディタ設定で拡張子CUとCUHにMicrosoft Visual C++のエディタを割り当てておくとインテリセンスが効くようになる模様。

#しかしすっごい久しぶりの日記だな…

typodupeerror

※ただしPHPを除く -- あるAdmin

読み込み中...