NARUSE, Yui
narus****@airem*****
2006年 1月 31日 (火) 12:32:43 JST
成瀬です。 Tadamasa Teranishi wrote: >>1. 脆弱性の範囲 >>ふと思ったのですが、この脆弱性情報を見直すと、 >>これって任意のUCSからの多対一変換全てが問題になりませんか。 > > > 全ての多対一の問題ということではありません。 例えば、 U+301C U+FF5E という名前のファイルが存在したとき、 EUC-JP等に変換した後にUnicodeに戻すと、 マッピングに関わらず、U+301C U+301C または U+FF5E U+FF5E という名前に化けるかと思いますが、 そのような使い方はnamazuではしていないということですかね。 >>Unicodeで渡されたパスをEUC-JPに変換して格納し、 >>Shift_JISに変換してWin32APIに渡す、なんてことをしている場合は、 >>どこまでが問題になるのかわからないのですが・・・。 > > > ここの話について言えば、 > US-ASCII 外から US-ASCII に変換されるのは全て問題ということ > になります。 > US-ASCII の範囲に特殊な意味を持たせてキャラがありますから。 > > となると、その変換を抑止するオプションがあれば良いということ > になりますかね? eucJP-msのマッピングに関わらず、 CP932を似た用途で使いたいケースもあるでしょうから、 そういうオプションはあったほうがいいかもしれませんね。 悩むのはオプション名ですか。 --disable-ascii-conversion はなんか違うし、 --enable-ascii-blocker も微妙かなぁ。 >>JVCの変換規則にない変換は全て削除、という手もありますが、 >>U+301Cのマッピング等は利便性を考えると残しておきたい気もして。。 > > > 具体的にはどのような利便性でしょう。 もともとUnicodeにする際にどのようなマッピングを用いたか忘れた場合や、 最初からUnicodeファイルを変換する場合には、 多少ルーズなほうが便利だとは感じます。 -- NARUSE, Yui <narus****@airem*****> DBDB A476 FDBD 9450 02CD 0EFC BCE3 C388 472E C1EA
Fork