うわ、8bitには気付かなかった。 Thunderbirdってば 普通に復号＆検証するもんだから。


うまく参加登録出来ました。他の方もスムーズに参加出来るようにHPに秘密鍵も貼り付けておきました。
他のMUAを利用されている方も歓迎します。

ああ、これは Enigmail の 0.95.x と trunk の違いではなくて、Tb2 と Tb3 とで動作が違うためです。
…が、元をたどればこれも Patrick でした。

Bug 281252 – Disable conversion to 7bit on request で、アドオンが 8bit or quated-printable を要求できるように、Thunderbird 側に追加がされています。
そして Enigmail 側は暗号化等の際にその「8bit or quated-printable」を要求するようになりました。

が、Patrick が本体側に入れたパッチでは、アドオンが 8bit or quated-printable を要求しても効かない場合があります。(意図した挙動なのか、それとも単にミスなのかは不明です。こういうのはレビュー時にツッコミが入るべきなのですが、見落とされたようです。)
ISO-2022-JP を使った場合には「効かない場合」に当てはまるため、普通に 7bit となります。
これが Tb2 で Enigmail を使った場合の挙動です。

その後 trunk で Bug 232515 – S/MIME support not RFC2633 compliant: transfer-encoding problem - no transfer encoding applied when ascii msg body の修正の際に、「8bit or quoted-printable が要求された場合には 7bit を選択しない」という前提(というか普通に考えれば当然の話)で修正が行われています。
その結果、Patrick が入れた「8bit or quated-printable」要求が効くようになりました。
そして Enigmail は暗号化の際に「8bit or quated-printable」を要求しているため、ISO-2022-JP であっても 7bit が選択されません。
これが Tb3 で Enigmail を使った場合の挙動です。

Enigmail trunk-mod-{a,b} からさらに、「8bit or quated-printable」要求を削除すれば、Tb3 でも ISO-2022-JP 7bit にできます。
が、これを削除すると何がマズいのかは理解できてません。

このあたり、きちんと調べたことがありませんでしたので、頑張って RFC を読んでみました(^^;

まず、クリアテキスト署名の場合ですが、


という記述からすると、クリアテキスト署名の場合は「行末のスペースはあってもなくても同じ」らしいです。

実際、 Becky! + BkGnuPG で作成した

• 行末スペースを含むメッセージに対してクリアテキスト署名したメッセージ
• 「行末スペースを含むメッセージに対してクリアテキスト署名したメッセージ」から行末スペースを削除したメッセージ(改ざんされた署名メッセージ)
• 行末スペースを含まないメッセージに対してクリアテキスト署名したメッセージ
• 「行末スペースを含まないメッセージに対してクリアテキスト署名したメッセージ」に行末スペースを追加したメッセージ(改ざんされた署名メッセージ)

を Thunderbird + Enigmail に送信したところ、いずれも署名の検証に成功しました。改ざんされているはずの2番目と4番目についても検証に成功しました。(もちろん、 Becky! + BkGnuPG 自身による検証でも、全て成功しました。)

なお、 Thunderbird + Enigmail でクリアテキスト署名を行う場合は、“-- ”を含め、行末スペースが削除されるらしく、行末スペースを含むメッセージを作成できなかったため、

• 行末スペースを含まないメッセージに対してクリアテキスト署名したメッセージ
• 「行末スペースを含まないメッセージに対してクリアテキスト署名したメッセージ」に行末スペースを追加したメッセージ(改ざんされた署名メッセージ)

のみを作成し、 Becky! + BkGnuPG に送信・検証しましたが、同様に検証に成功しました。(もちろん、 Thunderbird + Enigmail 自身による検証でも、全て成功しました。)

感覚的には気持ち悪いんですが、まあ、仕様に従った実装になっている、ということなのでしょう(^^;

で、次に PGP/MIME の場合ですが、



の記述からすると、

• 実装は、 MIME エンコーディングが適用された後、行末スペースがないことを確認しなければならない。行末スペースを保護したいなら、適切な MIME エンコーディング(quoted-printable や Base64)を施す必要がある。
• しかし、暗号化だけなら、対象が 8bit 文字を含もうと行末スペースを含もうと、 7bit に変換する必要や行末スペースを削除する必要はない。

ということでいいのかな?

この認識で間違いないとすると、 RFC3156 的には Becky! + BkGnuPG で PGP/MIME 署名を行う際に行末スペースを含んだままにしてしまう(quoted-printable や Base64 を施さずに 7bit のままにしてしまう)ことが間違いなのでしょうね。

Thunderbird + Enigmail 側は、(quoted-printable や Base64 が施されていない 7bit メッセージの被署名パート中には)含まれるはずのない行末スペースを削除した上で検証するため、結果として署名の検証に失敗してしまう、と。


でいうところの「厳密には対応していない」部分というのが、もしかすると、この行末スペースの処理のことだったのかもしれません。

あさん、ありがとうございます

まず、Patrickはこんなことを言ってます。Enigmail v0.96.0の送信機能を書き換えた。
古いバージョンのEnigmailは、Thunderbirdの文字セット変換の問題点に対処するために標準のThunderbirdの暗号化送信機構に密着した機能を一部変更していたものだった。
内部インターフェースや他の拡張との互換性に邪魔にならないようにするために、今後はもうしない。（Enigmailは今は標準のThunderbirdメッセージ送信機能を利用する）
メール送信処理の適切に登録された仕掛けをEnigmailが利用可能にすること、そしてThunderbird 3から変更を移植するために変更するだけだ。
OpenPGPに準拠するために、PGP/MIME標準を乱してしまうから、ISO-2022-JP文字セットは使えない。
Given that I don't modify the message sending function anymore, I cannot force Thunderbird to not convert to ISO-2022-JP anymore.
最後の1行はまだ訳し切れていないです。最後はイヤだって言ってるんでしょうね。

へぇ～　ここまでにBug 281252とかBug 232515とか、検討されてきたんですね。こういう話しに英語の解る日本人が居ないといつも日本語処理にとって都合の悪い方に転がるみたいですね。RFCも同じらしいです。
しかし、中味がiso-2022-jpで判ってるのに「8bit or quated-printable」要求出さないで欲しいですね。

えーっと、試してみたくなりました。お願いしても良いですか？　って思いっきりお願いしてますが。

でも、Patrickはもう お願いを聞いてくれそうも無さげな感じなので、ビルドツールとか一式をCaiさんにバトンタッチしていただいて、今後は日本版Enigmailでも良いかなぁ


って、ここまで書いてメールチェックしてみたら誰か他の人が何か言ってます。
誰でも良いから助けてくれ～　って感じです。

要は「これまでは workaround として自前でエンコードの処理してたけど、他のアドオンとバッティングする危険性もあるしこれからは Thunderbird 本体に丸投げするよー。そんでもって、ISO-2022-JP は PGP/MIME に反してるから使わないよー」ってことのようです。


む、これも Patrick か。
作る側にすれば問答無用で 8bit or quoted-printable にしたほうが楽なのはわかりますが、使う側のことを考えてほしいなぁ。


ひっかかるのはここです。
そもそも論として ISO-2022-JP は 7bit なんで quoted-printable にする必要性がないはずなんですよねぇ。
RFC 的には PGP/MIME で 7bit では OK です。
PGP/MIME で使っていいのは "7bit か quoted-printable" なので、一律 quoted-printable でも間違いではないけど。


むぅ、リリース版出るたびに ISO-2022-JP → UTF-8 強制変換その他諸々を除去すればいいので不可能ではないですが、できればやりたくないなぁ……
最後の最後の手段です。

_________________
[Desktop] Windows 10 Pro 22H2 (64bit) / Intel Core i7-2600 / Nvidia GeForce GTX 1650 GDDR6 / 32 GB Memory
[Laptop] Windows 10 Pro 22H2 (64bit) / Intel Core i5-520M vPro / Intel HD Graphics / 8 GB Memory
[Android] Android 13.0 (arm64) / Xperia 5 III (XQ-BQ42)
常用環境: Firefox ベータ版、リリース版 (Win64 x86-64, Android), Thunderbird ベータ版、リリース版 (Win64 x86-64)
テスト環境: Firefox (ESR, Nightly, Win64 x86-64, Android)
Cai/1.0 (Homo sapiens; N; Homo sapiens chemist; male; rv:0.0.4.1+)
-- いつまでたっても nightly

有っても無視しなさいってことですよね。当時のPGPは無視しなかったというバグが有ったんじゃなかったっけかな。（という薄ら覚え）

こっちは「MIME エンコーディングが適用された後」じゃなくて「前」に行末スペースを取り払うと言う風に．．．（薄ら覚え）
意味的には同じなんでしょうか。「後に有ってはいけない＝前に取り除いておく」？

Caiさんのバグレポートはこれとは別件ですよね。英文だったはずだしBecky!じゃなくて外国のかな。　でもRFC4880だけとういうのが　...？

これは「手で消そう！」ってことで終わったんでしょうね、たぶん。
でも、BkGnuPGは そのうちコードを書き換えるようなことを言っていたような気がします。

そういえば作者さんは何処に行ったんでしょう、こっちのフォーラムへは着いてきて見てるのかな？

結構時間かかって訳したんですけど、えらく簡単に要約していただいて　ありがと。

この人は「ISO-2022-JP は PGP/MIME に反してるから使わないよー」ってところにピクッと来たらしいですね。
公式にサポートされているiso-2022-jp（間違ってiso-2022-cpになってるけど）を独断で外すとは如何に？　って感じですかね。
もっと言って欲しいなぁ

まぁ、今じゃquoted-printableでも問題無いMUAしか無いんですが、
たとえば、携帯端末でクリア署名のメールを読めたり、PGP/MIMEの本文パートを読めたり出来る方が嬉しいです。
なので、せめてiso-2022-jpそのままとか、PGPツール無しでMIMEパートが読みやすい形の方が希望ですね。　いや、単にquoted-printableが好きじゃないだけなんですけど。
もしかしてUTF-8/quoted-printableのほうが携帯端末には良かったりするかも。
とにかく大勢（と言っても絶対数が少なすぎ）側の処理に合わせたいってだけか。

おや？　冗談だったんですけど。
やるとすれば、細かいバージョンアップには追従する必要無しです。今の機能で充分だと思います。

＃ 鍵のダブル添付のバグが無くなってから、ですね。
Patrickにバグを報告して、ついでにiso-2022-jpゴニョゴニョとお願いしたら良いかも

で、取り敢えず ISO-2022-JP 7bit版が出来てから Caiさんの障害の確認からやりますか。
なんとなく、Enigmail側で対処するような問題じゃないような気がしていますけど。

trunk-mod-c(trunk-mod-a からの差分): trunk-mod-a をベースに、「8bit or quated-printable」要求を削除

PGP/MIME じゃない場合に、8bit になってしまっていたのは 7bit になりました。

PGP/MIME の場合にまだ qutoted-printable になってしまいますが、なんでそうなるのかがまだ発見できていません。
とりあえず、一応間違いではなくなったからこれでもなんとかなるのかな？

あさん、ありがとうございます。
今からインストールして、MLでみなさんと試してみます。

まだ他の方々の確認メールは入っていませんが、MLから配信されたモノを自分で見る限り大丈夫だと思います。
この配信されたメールを他のMUAで取り込んだ結果はまた後で書きます。

PGP/MIMEで署名のみのメールの被署名パート（quoted-printableの）はiPhone（Gmail経由）でも普通に読めています。quoted-printableはiPhoneで処理しているのかGmailが処理して渡してくれているのかは全然わかりませんが。

ただ、気になったのはSubjectの改行が多いような気がします。
「[experiment-ml :624] trunk-mod-c 非 PGP/MIME 暗号＆署名」って書いてあるSubjectがですが改行が多いと思うのは気のせいでしょうか。3.0は行長が短くなった？
それと、送信した「非 PGP/MIME 暗号＆署名」には空白は入れていません。

----
環境：
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; ja; rv:1.9.1.1) Gecko/20090715 Thunderbird/3.0b3
X-Enigmail-Version: 0.97a (これはtrunk-mod-c)

設定：
--rfc2440
extensions.enigmail.warnIso2022jp=2


で、そんなことをやっている短い時間に、
前に書いた他の人のツッコミに対してPatrickがなにか答えているんですよね。まだよくわかりません。

頂きました。
ML での検証では、7bit になっていることが確認できました。
蛇足ですが、"warns the user if ISO-2022-JP is used" ありの mod-a ベースではなく mod-b ベースのほうが、細かい事情を知らない人には親切かなぁ、と思います。
あのダイアログをちゃんと読まずに Yes で答えてしまって直し方わからない！とかなりそうですし。

_________________
[Desktop] Windows 10 Pro 22H2 (64bit) / Intel Core i7-2600 / Nvidia GeForce GTX 1650 GDDR6 / 32 GB Memory
[Laptop] Windows 10 Pro 22H2 (64bit) / Intel Core i5-520M vPro / Intel HD Graphics / 8 GB Memory
[Android] Android 13.0 (arm64) / Xperia 5 III (XQ-BQ42)
常用環境: Firefox ベータ版、リリース版 (Win64 x86-64, Android), Thunderbird ベータ版、リリース版 (Win64 x86-64)
テスト環境: Firefox (ESR, Nightly, Win64 x86-64, Android)
Cai/1.0 (Homo sapiens; N; Homo sapiens chemist; male; rv:0.0.4.1+)
-- いつまでたっても nightly

私はSylpheedとQMAIL3しか持っていないですがOKでした。


私もそう思います。もう配布のことを考えて名前を考えた方が良いような気が．．．
それと、日本語の組み込みとか

作ってみました。
ついでに日本語リソース追加済み。
enigmail-trunk-tb-win32-trunk-20090809-0603-mod-bc-ja-JP.xpi
enigmailMsgComposeOverlay.patch

現在 ML のほうで検証していただいています。

_________________
[Desktop] Windows 10 Pro 22H2 (64bit) / Intel Core i7-2600 / Nvidia GeForce GTX 1650 GDDR6 / 32 GB Memory
[Laptop] Windows 10 Pro 22H2 (64bit) / Intel Core i5-520M vPro / Intel HD Graphics / 8 GB Memory
[Android] Android 13.0 (arm64) / Xperia 5 III (XQ-BQ42)
常用環境: Firefox ベータ版、リリース版 (Win64 x86-64, Android), Thunderbird ベータ版、リリース版 (Win64 x86-64)
テスト環境: Firefox (ESR, Nightly, Win64 x86-64, Android)
Cai/1.0 (Homo sapiens; N; Homo sapiens chemist; male; rv:0.0.4.1+)
-- いつまでたっても nightly

経過報告です。

https://www.mozdev.org/bugs/show_bug.cgi?id=18361 の元となった当時の署名付きのメールを戴いて検証してみると、
やはりThunderbird3.0beta3+Enigmail0.97a改造版でも検証に失敗します。
ところが、そのメールをQMAIL3に持って行くと署名の検証は成功します。
Enigmailで --rfc4880オプションのどういう影響を受けているのかは まだわかりません。（DSA, SHA-1の扱いの違いかと思ったんですが外れたようです）
当時のバージョンのものをインストールして確かめるという話も出ていますがQMAIL3で検証に成功してしまったので迷っています。

Enigmailは、あさんに作っていただいた改造版でテストしましたが、Becky!が生成する行末空白が存在するメール以外は検証に成功し、Thunderbirdからの署名付きあるいは暗号化されたメールは他のMUAでも検証＆復号に成功しています。
さらに、CaiさんにEnigmailの最新のnightly（20090809版）を基にしたバージョンをビルドしていただいたので以降はこれでテストを続けます。（これを書いている途中で発表がありました １つ前の記事）

それで上の --rfc4880オプションでの検証失敗の原因を突き止められたらEnigmailの修正を依頼するつもりでいます。
その内容は：
です。
このまま修正依頼するとPGP/MIME署名の場合はISO-2022-JP, quoted-printableになってしまいそうですが、都合が悪い、ダメだと言うような理由もない（検証への参加者が少なすぎて quoted-printableでもOKなMUAしか無い）ので このまま行きます。

あと、この検証の過程でQMAIL3での不都合や改善点などを報告し、善処していただいています。

＃ 始めてから延べ200通ほどの署名＆暗号メールのやり取りになっています。

この 2 つは現状のパッチでとりあえず実現できているかと思います。
最悪、ja-JP だけ enigmailMsgComposeOverlay.js をさらにオーバーレイとか……できましたっけ？


現状では quoted-printable の問題はスルーですかね。


ここでの検証が他のソフトに生かされているのであれば、いろいろと試した甲斐もあります。
なんとしても本丸を攻め落とさないと。

_________________
[Desktop] Windows 10 Pro 22H2 (64bit) / Intel Core i7-2600 / Nvidia GeForce GTX 1650 GDDR6 / 32 GB Memory
[Laptop] Windows 10 Pro 22H2 (64bit) / Intel Core i5-520M vPro / Intel HD Graphics / 8 GB Memory
[Android] Android 13.0 (arm64) / Xperia 5 III (XQ-BQ42)
常用環境: Firefox ベータ版、リリース版 (Win64 x86-64, Android), Thunderbird ベータ版、リリース版 (Win64 x86-64)
テスト環境: Firefox (ESR, Nightly, Win64 x86-64, Android)
Cai/1.0 (Homo sapiens; N; Homo sapiens chemist; male; rv:0.0.4.1+)
-- いつまでたっても nightly