Namazu-devel-ja(旧)

[Tadamasa Teranishi <yw3t-trns@xxxxxxxxxxxxxxx>]

寺西です。

Yukio USUDA wrote:
> 
> Tadamasa Teranishi wrote:
> > 1行文字列出力部分で、改行コードや nul 文字が入っていても、そのまま
> > 出力してしまう問題を回避するために以下の修正を考えています。
> > (以下の修正では改行コード、nul 文字以降を捨てるようにしています。)
> 厳密に改行以下を捨てなくても改行コード、nul文字だけ空白
> に置き換えるか捨てるかしてつないでしまえば良いのではな
> いでしょうか？

文字列の途中に nul 文字あるいは 改行コード が挿入されているのか、
有効な文字列(nul あるいは改行コードまで)の後に余計なものが付いて
いるのか判断ができません。
通常はありえないので、後ろにゴミを追加して何らかの攻撃(?) をしている
とも考えられますので、ばっさり削除した方が良いでしょうということ
です。
# その攻撃(?)がどんな危険性があるのかとかは、あまり考えていません。

そもそも、mailnews.pl は複数行にまたがる Subject: には対応して
いないですしね。途中でぶった切ることに抵抗はないでしょう。
 
> NMZ.field.uriは他の情報より重要なので意識して別扱いにする
> のは良いと思いますが、NMZ.field.uri に制御コードが入る可
> 能性として、どんな環境を想定されているのでしょうか？
> uriエンコードされれば制御コードはないはずですし

これはデコード済みの場合です。

> sjis、euc-jp、utf-8ならば非ASCIIのマルチバイト文字には
> 制御コードは入っていなかったのではないかと思います。

JIS もあるかというぐらいの話です。
(実際、JIS の uri が生成可能かどうかまでは確認していませんが、
現状 eucJP に統一されているわけではないので、仮定できません。
早々に eucJP に統一したいものです。)

が、ファイル名に制御文字を入れている場合は、漢字コードに関係なく
制御文字が出てくるので、やっぱり削除するわけにはいかないかも
しれませんね。むむむ。

> > # 推奨バージョンは nkf 1.71 に戻っちゃいましたね。
> 新らしめのディストリビューションによってはnkf1.7の導入も
> 困難でしょうから修正済みの2.0.13をリリースしてnkf2.02も
> 非推奨とならないようにしたいです。

NKF 2.X の問題ですから、NKF を修正するのが筋でしょう。
NKF のパッチをどなかたに作ってもらうのがよろしいかと。

NKF 2.X の新しいバージョンがリリースされないのであれば、
Namazu としては、nkf を捨てて別のプログラムを使うという選択肢は
ありえますが、nkf2.02 をそのまま使うのはダメでしょ。
(いったいどんな変換を行っているのかわからないので、Namazu 側で
対処するのは本質的に無理なはずです。対処療法的に nul 文字を
削除するとかはできますが、現在表面化していない別の問題が生じる
可能性もありますから、nkf2.02を使うのはおすすめできません。)

# で、例の Subject: は ISO-2022-JP-2 ってことなんだろうか。
-- 
=====================================================================
寺西 忠勝(TADAMASA TERANISHI)  yw3t-trns@xxxxxxxxxxxxxxx
http://www.asahi-net.or.jp/~yw3t-trns/index.htm
Key fingerprint =  474E 4D93 8E97 11F6 662D  8A42 17F5 52F4 10E7 D14E