松尾です。

> gpg -d は途中で復号化が失敗した旨のメッセージが出ていたようです。

そうでしたか。それなら納得です。

> epg-encrypt-stringの結果はバイナリじゃないでしょうか。
> この理解が正しいとすると変換されてしまうのは改行コードというより文字コードだと思います。
> これはOSには依存せず、Unixでも同じです。Linux上で問題がおきないのはなぜか、私にもわかりません。

epg-encrypt-stringの結果はバイナリ(unibyte string)です。
なので文字コードの自動認識で特定文字コードと誤認識される
可能性はむしろ低いと思います。

改行コードならLFが0x0A、CRが0x0Dで、暗号化後のバイナリに現れる
可能性は十分あります。恐らくepg-encrypt-string中にLFがあって、
それがWindows用にCRLF(0x0D 0x0A)に変換されてしまっていたのでしょう。

Emacs23(Cygwin)でのcoding-system SJISの属性では
EOL type: Automatic selection from:
  [japanese-shift-jis-unix japanese-shift-jis-dos japanese-shift-jis-mac]
となってました。これのdosが選択されたんじゃないでしょうか。


> パッチはLinuxでは試していませんので、commit前の確認をお願いしたいです。

Linux上でEmacs23を使える環境はないのでCygwinのEmacs23でEasyPGを
使って試してみましたが問題ありませんでした。他の環境でも
問題ないでしょう。

> また、当方は EasyPG の部分しか調べておりませんので、alpaca についても確認いただければと思います。

alpacaの方では暗号化前のデータを入れた一時ファイルを作って
それをgpgで変換しているので暗号化時にEmacsとgpgの間でバイナリ
のやりとりがありません。なので改行が変換されても復号できなく
なることはありませんが、一応暗号化対象のbyte列を完全に保つ
という意味で同様の対処をしておきました。

> > commitしたいのですが、ChangeLog上のお名前はSakumaで良いで
> > しょうか。
> 
> はい結構です。

了解です。commitしました。ご確認ください。

---
松尾 直志 <t...@mymail.twin.jp>

------------------------------------------------------------------------------
Gaining the trust of online customers is vital for the success of any company
that requires sensitive data to be transmitted over the Web.   Learn how to 
best implement a security strategy that keeps consumers' information secure 
and instills the confidence they need to proceed with transactions.
http://p.sf.net/sfu/oracle-sfdevnl 
_______________________________________________
twmode-users mailing list
twmode-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/twmode-users

メールによる返信