GnuTLS 対応
570 views
Skip to first unread message
Hiroki Sato
Jan 9, 2020, 7:44:51 PM1/9/20
to mew...@googlegroups.com
佐藤です。
libgnutls をリンクしている Emacs から TLS を使うためのパッチを
作っています。粗い部分が多々ありますが、
とりあえず動くようにはなったので、
みなさんの環境で動作するかどうか、試していただけないでしょうか?
v6.8 に添付のパッチをあててください。
設定は、mew-smtp-ssl や mew-imap-ssl を拡張して
(setq mew-imap-ssl 'native)
(setq mew-imap-ssl 'native-starttls)
という 2 つのシンボルを解釈するようにしてあります。
前者が TLS, 後者が STARTTLS です。もちろんポート番号も
指定してください。これで、Emacs 自身が TLS でコネクションを
張るようになるはずです。
クライアント証明書の指定方法と、mew-ssl-verify-level の評価モデルが、
現在の stunnel を使う実装と同じになっておらず、互換性を保つためには
もうちょっときちんとした対応が必要です。
後ほど細かな部分を修正しますが、クライアント認証をせずに
接続するだけであれば、上記の設定を入れるだけで試せると思います。
試験環境は今のところ FreeBSD 12 + Emacs 26.3 + GnuTLS 3.6.9 のみです。
他の環境で動作するかどうか、教えていただけると助かります。
-- Hiroki
libgnutls をリンクしている Emacs から TLS を使うためのパッチを
作っています。粗い部分が多々ありますが、
とりあえず動くようにはなったので、
みなさんの環境で動作するかどうか、試していただけないでしょうか?
v6.8 に添付のパッチをあててください。
設定は、mew-smtp-ssl や mew-imap-ssl を拡張して
(setq mew-imap-ssl 'native)
(setq mew-imap-ssl 'native-starttls)
という 2 つのシンボルを解釈するようにしてあります。
前者が TLS, 後者が STARTTLS です。もちろんポート番号も
指定してください。これで、Emacs 自身が TLS でコネクションを
張るようになるはずです。
クライアント証明書の指定方法と、mew-ssl-verify-level の評価モデルが、
現在の stunnel を使う実装と同じになっておらず、互換性を保つためには
もうちょっときちんとした対応が必要です。
後ほど細かな部分を修正しますが、クライアント認証をせずに
接続するだけであれば、上記の設定を入れるだけで試せると思います。
試験環境は今のところ FreeBSD 12 + Emacs 26.3 + GnuTLS 3.6.9 のみです。
他の環境で動作するかどうか、教えていただけると助かります。
-- Hiroki
Yasuhiro KIMURA
Jan 10, 2020, 4:56:17 PM1/10/20
to mew...@googlegroups.com
木村です。
From: Hiroki Sato <h...@allbsd.org>
Subject: [mew-ja] GnuTLS 対応
Date: Fri, 10 Jan 2020 09:41:31 +0900 (JST)
> libgnutls をリンクしている Emacs から TLS を使うためのパッチを
> 作っています。粗い部分が多々ありますが、
> とりあえず動くようにはなったので、
> みなさんの環境で動作するかどうか、試していただけないでしょうか?
早速以下の二組の環境で試してみました。
(a) FreeBSD 12.1-RELEASE + Emacs 26.3 + GnuTLS 3.6.11
(b) 64bit Window 10 1909 + IMEパッチを当ててMSYS2を使って自前ビルドし
たEmacs 26.3 + MSYS2から持ってきたGnuTLS 3.6.11
結果としては(a)ではメールの送受信(SMTP/IMAP with STARTTLS)が問題なく出
来ていますが、(b)では
* 「Creating SSL/TLS connection (GnuTLS, STARTTLS)...」というメッセー
ジが表示される
* その後で「Buffer " *stream buffer*" has a running process: kill it?
(yes or no)」というメッセージが表示される
* yesと入力すると「Cannot connect to the IMAP server」と表示される
といった感じでうまく動かないようです。mew-debugをtに設定してみましたが、
*Mew debug*バッファが作成されていませんでした。
一応(b)の環境でgnutls-available-pを実行すると
(ClientHello\ Padding Key\ Share Post\ Handshake\ Auth PSK\ Key\ Exchange\ Modes Cookie Supported\ Versions Early\ Data Pre\ Shared\ Key Session\ Ticket Record\ Size\ Limit Extended\ Master\ Secret Encrypt-then-MAC ...)
といった値を返すのでGnuTLSが有効になっているのだと思いますが、この環境
でGnuTLSを使ったことがないので、本当にGnuTLSが正常に動作するのかは判り
ません。
ところで、
> v6.8 に添付のパッチをあててください。
> 設定は、mew-smtp-ssl や mew-imap-ssl を拡張して
>
> (setq mew-imap-ssl 'native)
> (setq mew-imap-ssl 'native-starttls)
>
> という 2 つのシンボルを解釈するようにしてあります。
> 前者が TLS, 後者が STARTTLS です。もちろんポート番号も
> 指定してください。これで、Emacs 自身が TLS でコネクションを
> 張るようになるはずです。
これですが、stunnelを使う場合と同様に
* mew-imap-sslを'nativeに設定するとGnuTLSを使う
* TLSを使うかSTARTTLSを使うかは、mew-imap-ssl-portがmew-imap-portと同
じか違うかで決まる
というふうにしていただけないでしょうか。
---
木村 康浩
From: Hiroki Sato <h...@allbsd.org>
Subject: [mew-ja] GnuTLS 対応
Date: Fri, 10 Jan 2020 09:41:31 +0900 (JST)
> libgnutls をリンクしている Emacs から TLS を使うためのパッチを
> 作っています。粗い部分が多々ありますが、
> とりあえず動くようにはなったので、
> みなさんの環境で動作するかどうか、試していただけないでしょうか?
(a) FreeBSD 12.1-RELEASE + Emacs 26.3 + GnuTLS 3.6.11
(b) 64bit Window 10 1909 + IMEパッチを当ててMSYS2を使って自前ビルドし
たEmacs 26.3 + MSYS2から持ってきたGnuTLS 3.6.11
結果としては(a)ではメールの送受信(SMTP/IMAP with STARTTLS)が問題なく出
来ていますが、(b)では
* 「Creating SSL/TLS connection (GnuTLS, STARTTLS)...」というメッセー
ジが表示される
* その後で「Buffer " *stream buffer*" has a running process: kill it?
(yes or no)」というメッセージが表示される
* yesと入力すると「Cannot connect to the IMAP server」と表示される
といった感じでうまく動かないようです。mew-debugをtに設定してみましたが、
*Mew debug*バッファが作成されていませんでした。
一応(b)の環境でgnutls-available-pを実行すると
(ClientHello\ Padding Key\ Share Post\ Handshake\ Auth PSK\ Key\ Exchange\ Modes Cookie Supported\ Versions Early\ Data Pre\ Shared\ Key Session\ Ticket Record\ Size\ Limit Extended\ Master\ Secret Encrypt-then-MAC ...)
といった値を返すのでGnuTLSが有効になっているのだと思いますが、この環境
でGnuTLSを使ったことがないので、本当にGnuTLSが正常に動作するのかは判り
ません。
ところで、
> v6.8 に添付のパッチをあててください。
> 設定は、mew-smtp-ssl や mew-imap-ssl を拡張して
>
> (setq mew-imap-ssl 'native)
> (setq mew-imap-ssl 'native-starttls)
>
> という 2 つのシンボルを解釈するようにしてあります。
> 前者が TLS, 後者が STARTTLS です。もちろんポート番号も
> 指定してください。これで、Emacs 自身が TLS でコネクションを
> 張るようになるはずです。
* mew-imap-sslを'nativeに設定するとGnuTLSを使う
* TLSを使うかSTARTTLSを使うかは、mew-imap-ssl-portがmew-imap-portと同
じか違うかで決まる
というふうにしていただけないでしょうか。
---
木村 康浩
Yasuhiro KIMURA
Jan 10, 2020, 5:17:36 PM1/10/20
to mew...@googlegroups.com
木村です。
From: Yasuhiro KIMURA <ya...@utahime.org>
Subject: Re: [mew-ja] GnuTLS 対応
Date: Sat, 11 Jan 2020 06:55:30 +0900 (JST)
> 早速以下の二組の環境で試してみました。
>
> (a) FreeBSD 12.1-RELEASE + Emacs 26.3 + GnuTLS 3.6.11
> (b) 64bit Window 10 1909 + IMEパッチを当ててMSYS2を使って自前ビルドし
> たEmacs 26.3 + MSYS2から持ってきたGnuTLS 3.6.11
このパッチを当てるとstunnelを使う方が正常に動作しなくなるようです。
IMAPでメールを受信しようとすると「Communicating with the IMAP
server...」のところで暫く固まった後にタイムアウトが発生します。この症
状は(a)(b)いずれの環境でも発生します。
---
木村 康浩
From: Yasuhiro KIMURA <ya...@utahime.org>
Subject: Re: [mew-ja] GnuTLS 対応
Date: Sat, 11 Jan 2020 06:55:30 +0900 (JST)
> 早速以下の二組の環境で試してみました。
>
> (a) FreeBSD 12.1-RELEASE + Emacs 26.3 + GnuTLS 3.6.11
> (b) 64bit Window 10 1909 + IMEパッチを当ててMSYS2を使って自前ビルドし
> たEmacs 26.3 + MSYS2から持ってきたGnuTLS 3.6.11
IMAPでメールを受信しようとすると「Communicating with the IMAP
server...」のところで暫く固まった後にタイムアウトが発生します。この症
状は(a)(b)いずれの環境でも発生します。
---
木村 康浩
Hiroki Sato
Jan 11, 2020, 9:26:44 AM1/11/20
to ya...@utahime.org, mew...@googlegroups.com
佐藤です。
Yasuhiro KIMURA <ya...@utahime.org> wrote
in <20200111.065530.1666...@utahime.org>:
ya> (a) FreeBSD 12.1-RELEASE + Emacs 26.3 + GnuTLS 3.6.11
ya> (b) 64bit Window 10 1909 + IMEパッチを当ててMSYS2を使って自前ビルドし
ya> たEmacs 26.3 + MSYS2から持ってきたGnuTLS 3.6.11
ya>
ya> 結果としては(a)ではメールの送受信(SMTP/IMAP with STARTTLS)が問題なく出
ya> 来ていますが、(b)では
ya>
ya> * 「Creating SSL/TLS connection (GnuTLS, STARTTLS)...」というメッセー
ya> ジが表示される
ya> * その後で「Buffer " *stream buffer*" has a running process: kill it?
ya> (yes or no)」というメッセージが表示される
ya> * yesと入力すると「Cannot connect to the IMAP server」と表示される
ya>
ya> といった感じでうまく動かないようです。mew-debugをtに設定してみましたが、
ya> *Mew debug*バッファが作成されていませんでした。
どうもありがとうございます。手元でも Windows の環境をつくって
不具合を修正してみました。添付のパッチであれば、
Windows10 1909 + Emacs 26.3 + GnuTLS 3.6.0
(ftp.gnu.org で配布されているもの）で動作するようです。
これでいかがでしょう?
ya> これですが、stunnelを使う場合と同様に
ya>
ya> * mew-imap-sslを'nativeに設定するとGnuTLSを使う
ya> * TLSを使うかSTARTTLSを使うかは、mew-imap-ssl-portがmew-imap-portと同
ya> じか違うかで決まる
Yasuhiro KIMURA <ya...@utahime.org> wrote
in <20200111.071716.1317...@utahime.org>:
ya> このパッチを当てるとstunnelを使う方が正常に動作しなくなるようです。
了解です。この 2 点はまだ未対応ですので、対応できたら
再度パッチを送ります。
-- Hiroki
Yasuhiro KIMURA <ya...@utahime.org> wrote
in <20200111.065530.1666...@utahime.org>:
ya> (a) FreeBSD 12.1-RELEASE + Emacs 26.3 + GnuTLS 3.6.11
ya> (b) 64bit Window 10 1909 + IMEパッチを当ててMSYS2を使って自前ビルドし
ya> たEmacs 26.3 + MSYS2から持ってきたGnuTLS 3.6.11
ya>
ya> 結果としては(a)ではメールの送受信(SMTP/IMAP with STARTTLS)が問題なく出
ya> 来ていますが、(b)では
ya>
ya> * 「Creating SSL/TLS connection (GnuTLS, STARTTLS)...」というメッセー
ya> ジが表示される
ya> * その後で「Buffer " *stream buffer*" has a running process: kill it?
ya> (yes or no)」というメッセージが表示される
ya> * yesと入力すると「Cannot connect to the IMAP server」と表示される
ya>
ya> といった感じでうまく動かないようです。mew-debugをtに設定してみましたが、
ya> *Mew debug*バッファが作成されていませんでした。
どうもありがとうございます。手元でも Windows の環境をつくって
不具合を修正してみました。添付のパッチであれば、
Windows10 1909 + Emacs 26.3 + GnuTLS 3.6.0
(ftp.gnu.org で配布されているもの）で動作するようです。
これでいかがでしょう?
ya> これですが、stunnelを使う場合と同様に
ya>
ya> * mew-imap-sslを'nativeに設定するとGnuTLSを使う
ya> * TLSを使うかSTARTTLSを使うかは、mew-imap-ssl-portがmew-imap-portと同
ya> じか違うかで決まる
Yasuhiro KIMURA <ya...@utahime.org> wrote
in <20200111.071716.1317...@utahime.org>:
ya> このパッチを当てるとstunnelを使う方が正常に動作しなくなるようです。
了解です。この 2 点はまだ未対応ですので、対応できたら
再度パッチを送ります。
-- Hiroki
Yasuhiro KIMURA
Jan 11, 2020, 10:45:51 AM1/11/20
to mew...@googlegroups.com
Subject: Re: [mew-ja] GnuTLS 対応
Date: Sat, 11 Jan 2020 23:25:29 +0900 (JST)
> どうもありがとうございます。手元でも Windows の環境をつくって
> 不具合を修正してみました。添付のパッチであれば、
> Windows10 1909 + Emacs 26.3 + GnuTLS 3.6.0
> (ftp.gnu.org で配布されているもの）で動作するようです。
> これでいかがでしょう?
試してみたところ、(b)の環境でもSMTP/IMAP with STARTTLSでメールの送受信
> どうもありがとうございます。手元でも Windows の環境をつくって
> 不具合を修正してみました。添付のパッチであれば、
> Windows10 1909 + Emacs 26.3 + GnuTLS 3.6.0
> (ftp.gnu.org で配布されているもの）で動作するようです。
> これでいかがでしょう?
が出来るようになりました。
> 了解です。この 2 点はまだ未対応ですので、対応できたら
> 再度パッチを送ります。
---
木村 康浩
Hiroki Sato
Jan 12, 2020, 6:44:20 AM1/12/20
to mew...@googlegroups.com
in <20200112.004525.2115...@utahime.org>:
ya> > 了解です。この 2 点はまだ未対応ですので、対応できたら
ya> > 再度パッチを送ります。
ya>
ya> 了解しました。よろしくお願いします。
STARTTLS 有効/無効のロジックを合わせて、
ドキュメントも修正しました。
stunnel も動作することを確認しましたが、あまり
網羅的な試験はしていないため、もし動かないパターンが
あるようでしたら教えてください。
余計な変更をいくつか入れてあります。
- 465/tcp は RFC 8314 できちんと登録されたため、"no universal
consensus" というコメントを削りました。
- 接続がタイムアウトした時、何が起こっているのか
わかりづらかったため、次のようにタイムアウト値が何秒に
設定されているのかを表示するようにしました。
(defun mew-imap-timeout ()
+ (message (format "IMAP connection timed out (%d seconds)"
+ mew-imap-timeout-time))
(signal 'quit nil))
変更は、
https://github.com/hrs-allbsd/Mew
にも、gnutls というタグを打って置いてあります。
-- Hiroki
ya> > 了解です。この 2 点はまだ未対応ですので、対応できたら
ya> > 再度パッチを送ります。
ya>
ya> 了解しました。よろしくお願いします。
STARTTLS 有効/無効のロジックを合わせて、
ドキュメントも修正しました。
stunnel も動作することを確認しましたが、あまり
網羅的な試験はしていないため、もし動かないパターンが
あるようでしたら教えてください。
余計な変更をいくつか入れてあります。
- 465/tcp は RFC 8314 できちんと登録されたため、"no universal
consensus" というコメントを削りました。
- 接続がタイムアウトした時、何が起こっているのか
わかりづらかったため、次のようにタイムアウト値が何秒に
設定されているのかを表示するようにしました。
(defun mew-imap-timeout ()
+ (message (format "IMAP connection timed out (%d seconds)"
+ mew-imap-timeout-time))
(signal 'quit nil))
変更は、
https://github.com/hrs-allbsd/Mew
にも、gnutls というタグを打って置いてあります。
-- Hiroki
Yasuhiro KIMURA
Jan 12, 2020, 10:53:09 AM1/12/20
to mew...@googlegroups.com
Date: Sun, 12 Jan 2020 20:41:34 +0900 (JST)
> STARTTLS 有効/無効のロジックを合わせて、
> ドキュメントも修正しました。
>
> stunnel も動作することを確認しましたが、あまり
> 網羅的な試験はしていないため、もし動かないパターンが
> あるようでしたら教えてください。
(snip)
> STARTTLS 有効/無効のロジックを合わせて、
> ドキュメントも修正しました。
>
> stunnel も動作することを確認しましたが、あまり
> 網羅的な試験はしていないため、もし動かないパターンが
> あるようでしたら教えてください。
こちらをgit cloneして前述のWindows環境で試してみました。
(setq mew-imap-ssl 'native
mew-imap-ssl-port mew-imap-port
mew-smtp-ssl 'native
mew-smtp-ssl-port mew-smtp-port)
という設定でGnuTLSでのIMAP/SMTP with STARTTLSが成功することと、従来の
設定でStunnelでのIMAP/SMTP with STARTTLSが成功することを確認しました。
その一方で新たな問題がいくつか見つかりました。
1. GnuTLSのSTARTTLSを使わない設定で接続に失敗する
(setq mew-imap-ssl 'native
mew-imap-ssl-port "imaps"
mew-smtp-ssl 'native
mew-smtp-ssl-port "smtps")
の設定で試してみたのですが、
* 「Creating SSL/TLS connection (GnuTLS)...」というメッセージが表示される
* しばらくすると「make client process failed, Connection timed out」と
表示される
といった感じで接続に失敗しているようです。
2. GnuTLSのIMAP with STARTTLSでたまに接続が失敗する?
GnuTLSのSTARTTLSを使う設定で、IMAPフォルダで"s"を実行すると、たまにミ
ニバッファに「processp, nil」と表示されることがあります。これが発生す
る条件は不明です。
3. Biffを有効にするとミニバッファにメッセージが残る
GnuTLSのSTARTTLSを使う設定で、mew-use-biffをtに設定してBiffを有効にし
た状態でしばらく放置すると、(恐らく)Biffが動作した後ミニバッファに、
「Creating SSL/TLS connection (GnuTLS, STARTTLS)...」というメッセージ
が残ります。
---
木村 康浩
Hiroki Sato
Jan 13, 2020, 12:24:04 AM1/13/20
to mew...@googlegroups.com
in <20200113.005032.1650...@utahime.org>:
ya> 1. GnuTLSのSTARTTLSを使わない設定で接続に失敗する
ya>
ya> (setq mew-imap-ssl 'native
ya> mew-imap-ssl-port "imaps"
ya> mew-smtp-ssl 'native
ya> mew-smtp-ssl-port "smtps")
ya>
ya> の設定で試してみたのですが、
ya>
ya> * 「Creating SSL/TLS connection (GnuTLS)...」というメッセージが表示される
ya> * しばらくすると「make client process failed, Connection timed out」と
ya> 表示される
ya>
ya> といった感じで接続に失敗しているようです。
(setq gnutls-log-level 2)
を設定して、*Messages* に出るログを確認してみていただけますか?
また、*Mew debug* は空でしょうか?
ya> 2. GnuTLSのIMAP with STARTTLSでたまに接続が失敗する?
ya>
ya> GnuTLSのSTARTTLSを使う設定で、IMAPフォルダで"s"を実行すると、たまにミ
ya> ニバッファに「processp, nil」と表示されることがあります。これが発生す
ya> る条件は不明です。
こちらも接続試行が何らかの原因で失敗しているのだと思います。
gnutls-log-level を上げてあれば TLS 絡みのエラーはログに
出ると思いますので、もし正常接続時と何か違う表示が出ていたら教えてください。
ya> 3. Biffを有効にするとミニバッファにメッセージが残る
ya>
ya> GnuTLSのSTARTTLSを使う設定で、mew-use-biffをtに設定してBiffを有効にし
ya> た状態でしばらく放置すると、(恐らく)Biffが動作した後ミニバッファに、
ya> 「Creating SSL/TLS connection (GnuTLS, STARTTLS)...」というメッセージ
ya> が残ります。
こちらは 92e740c976affad4136e5ffa684c3dc91ae24d78 の commit で
対応しました。gnutls のタグもずらしてあります。
-- Hiroki
ya> 1. GnuTLSのSTARTTLSを使わない設定で接続に失敗する
ya>
ya> (setq mew-imap-ssl 'native
ya> mew-imap-ssl-port "imaps"
ya> mew-smtp-ssl 'native
ya> mew-smtp-ssl-port "smtps")
ya>
ya> の設定で試してみたのですが、
ya>
ya> * 「Creating SSL/TLS connection (GnuTLS)...」というメッセージが表示される
ya> * しばらくすると「make client process failed, Connection timed out」と
ya> 表示される
ya>
ya> といった感じで接続に失敗しているようです。
(setq gnutls-log-level 2)
を設定して、*Messages* に出るログを確認してみていただけますか?
また、*Mew debug* は空でしょうか?
ya> 2. GnuTLSのIMAP with STARTTLSでたまに接続が失敗する?
ya>
ya> GnuTLSのSTARTTLSを使う設定で、IMAPフォルダで"s"を実行すると、たまにミ
ya> ニバッファに「processp, nil」と表示されることがあります。これが発生す
ya> る条件は不明です。
こちらも接続試行が何らかの原因で失敗しているのだと思います。
gnutls-log-level を上げてあれば TLS 絡みのエラーはログに
出ると思いますので、もし正常接続時と何か違う表示が出ていたら教えてください。
ya> 3. Biffを有効にするとミニバッファにメッセージが残る
ya>
ya> GnuTLSのSTARTTLSを使う設定で、mew-use-biffをtに設定してBiffを有効にし
ya> た状態でしばらく放置すると、(恐らく)Biffが動作した後ミニバッファに、
ya> 「Creating SSL/TLS connection (GnuTLS, STARTTLS)...」というメッセージ
ya> が残ります。
こちらは 92e740c976affad4136e5ffa684c3dc91ae24d78 の commit で
対応しました。gnutls のタグもずらしてあります。
-- Hiroki
Yasuhiro KIMURA
Jan 13, 2020, 2:32:49 AM1/13/20
to mew...@googlegroups.com
Date: Mon, 13 Jan 2020 14:23:28 +0900 (JST)
>> 1. GnuTLSのSTARTTLSを使わない設定で接続に失敗する
----------------------------------------------------------------------
Connecting to the IMAP server...
この二行だけでした。gnutls-log-levelを4まで上げてみましたが、
*Messages*に出力されるメッセージは増えませんでした。またmew-debugをtに
してみたところ、*Mew debug*に以下のような行が追加されました。
----------------------------------------------------------------------
<TLS server=imap.gmail.com:imap>
nowait=nil, tlsparams=:priority NORMAL:%DUMBFW :hostname imap.gmail.com :loglevel 2 :min-prime-bits 2048 :trustfiles (NUL) :crlfiles nil :keylist nil :verify-flags nil :verify-error t :callbacks nil
----------------------------------------------------------------------
>> 2. GnuTLSのIMAP with STARTTLSでたまに接続が失敗する?
*Messages*には
----------------------------------------------------------------------
processp, nil
----------------------------------------------------------------------
の一行が追加されるだけです。あとmew-debugをtにすると、接続に失敗したと
き*Mew debug*に
----------------------------------------------------------------------
<IMAP SENTINEL>
connection broken by remote peer
----------------------------------------------------------------------
という行が追加されます。
それから正確な発生条件は相変わらず不明ですが、IMAPフォルダで"s" + RET
をひたすら繰り返していると、割と頻繁に発生するようです。
>> 3. Biffを有効にするとミニバッファにメッセージが残る
した。
---
木村 康浩
>> 1. GnuTLSのSTARTTLSを使わない設定で接続に失敗する
>
> (setq gnutls-log-level 2)
>
> を設定して、*Messages* に出るログを確認してみていただけますか?
> また、*Mew debug* は空でしょうか?
確認してみましたが、*Messages*には
> (setq gnutls-log-level 2)
>
> を設定して、*Messages* に出るログを確認してみていただけますか?
> また、*Mew debug* は空でしょうか?
----------------------------------------------------------------------
Connecting to the IMAP server...
make client process failed, Connection timed out
----------------------------------------------------------------------
この二行だけでした。gnutls-log-levelを4まで上げてみましたが、
*Messages*に出力されるメッセージは増えませんでした。またmew-debugをtに
してみたところ、*Mew debug*に以下のような行が追加されました。
----------------------------------------------------------------------
<TLS server=imap.gmail.com:imap>
nowait=nil, tlsparams=:priority NORMAL:%DUMBFW :hostname imap.gmail.com :loglevel 2 :min-prime-bits 2048 :trustfiles (NUL) :crlfiles nil :keylist nil :verify-flags nil :verify-error t :callbacks nil
----------------------------------------------------------------------
>> 2. GnuTLSのIMAP with STARTTLSでたまに接続が失敗する?
>
> こちらも接続試行が何らかの原因で失敗しているのだと思います。
> gnutls-log-level を上げてあれば TLS 絡みのエラーはログに
> 出ると思いますので、もし正常接続時と何か違う表示が出ていたら教えてください。
こちらもgnutls-log-levelを4まで上げてみたのですが、接続に失敗した時は
> こちらも接続試行が何らかの原因で失敗しているのだと思います。
> gnutls-log-level を上げてあれば TLS 絡みのエラーはログに
> 出ると思いますので、もし正常接続時と何か違う表示が出ていたら教えてください。
*Messages*には
----------------------------------------------------------------------
processp, nil
----------------------------------------------------------------------
の一行が追加されるだけです。あとmew-debugをtにすると、接続に失敗したと
き*Mew debug*に
----------------------------------------------------------------------
<IMAP SENTINEL>
connection broken by remote peer
----------------------------------------------------------------------
という行が追加されます。
それから正確な発生条件は相変わらず不明ですが、IMAPフォルダで"s" + RET
をひたすら繰り返していると、割と頻繁に発生するようです。
>> 3. Biffを有効にするとミニバッファにメッセージが残る
>
> こちらは 92e740c976affad4136e5ffa684c3dc91ae24d78 の commit で
> 対応しました。gnutls のタグもずらしてあります。
この問題に関しては、Biffが動作してもメッセージが残らないことを確認しま
> こちらは 92e740c976affad4136e5ffa684c3dc91ae24d78 の commit で
> 対応しました。gnutls のタグもずらしてあります。
した。
---
木村 康浩
Hiroki Sato
Jan 13, 2020, 4:10:02 AM1/13/20
to mew...@googlegroups.com
in <20200113.163136.1673...@utahime.org>:
ya> >> 1. GnuTLSのSTARTTLSを使わない設定で接続に失敗する
...
ya> この二行だけでした。gnutls-log-levelを4まで上げてみましたが、
ya> *Messages*に出力されるメッセージは増えませんでした。またmew-debugをtに
ya> してみたところ、*Mew debug*に以下のような行が追加されました。
ya>
ya> ----------------------------------------------------------------------
ya> <TLS server=imap.gmail.com:imap>
ya> nowait=nil, tlsparams=:priority NORMAL:%DUMBFW :hostname imap.gmail.com :loglevel 2 :min-prime-bits 2048 :trustfiles (NUL) :crlfiles nil :keylist nil :verify-flags nil :verify-error t :callbacks nil
ya> ----------------------------------------------------------------------
imap.gmail.com:imap と出るということは、
ポート番号が imaps ではなく imap になっていますね。
たぶん 143/tcp に TLS で接続しようとして
タイムアウトしているのだと思います。
(mew-imap-port) を評価すると imap,
(mew-imap-ssl-port) を評価すると imaps になっている状態でしょうか?
もしそれで上記の状態になるのであれば、動作がおかしいです。
原因がよくわからないので、デバッグ用の出力を追加してみます。
ya> >> 2. GnuTLSのIMAP with STARTTLSでたまに接続が失敗する?
ya> >
ya> > こちらも接続試行が何らかの原因で失敗しているのだと思います。
ya> > gnutls-log-level を上げてあれば TLS 絡みのエラーはログに
ya> > 出ると思いますので、もし正常接続時と何か違う表示が出ていたら教えてください。
ya>
ya> こちらもgnutls-log-levelを4まで上げてみたのですが、接続に失敗した時は
ya> *Messages*には
ya>
ya> ----------------------------------------------------------------------
ya> processp, nil
ya> ----------------------------------------------------------------------
ya>
ya> の一行が追加されるだけです。あとmew-debugをtにすると、接続に失敗したと
たとえば s + RET を連続で実行すると、*Messages* 次のような内容が
並ぶと思います。processp, nil が出るのは、どのタイミングでしょうか?
Creating SSL/TLS connection (GnuTLS, STARTTLS)...
Connecting to the IMAP server...done
...
また、これは「processp, nil が表示された後、どう操作しても
接続できなくなる」という話ではなく、
「s + RET を実行すると正常に接続できなかったり、
できたりする」という解釈で正しいでしょうか?
-- Hiroki
ya> >> 1. GnuTLSのSTARTTLSを使わない設定で接続に失敗する
...
ya> この二行だけでした。gnutls-log-levelを4まで上げてみましたが、
ya> *Messages*に出力されるメッセージは増えませんでした。またmew-debugをtに
ya> してみたところ、*Mew debug*に以下のような行が追加されました。
ya>
ya> ----------------------------------------------------------------------
ya> <TLS server=imap.gmail.com:imap>
ya> nowait=nil, tlsparams=:priority NORMAL:%DUMBFW :hostname imap.gmail.com :loglevel 2 :min-prime-bits 2048 :trustfiles (NUL) :crlfiles nil :keylist nil :verify-flags nil :verify-error t :callbacks nil
ya> ----------------------------------------------------------------------
imap.gmail.com:imap と出るということは、
ポート番号が imaps ではなく imap になっていますね。
たぶん 143/tcp に TLS で接続しようとして
タイムアウトしているのだと思います。
(mew-imap-port) を評価すると imap,
(mew-imap-ssl-port) を評価すると imaps になっている状態でしょうか?
もしそれで上記の状態になるのであれば、動作がおかしいです。
原因がよくわからないので、デバッグ用の出力を追加してみます。
ya> >> 2. GnuTLSのIMAP with STARTTLSでたまに接続が失敗する?
ya> >
ya> > gnutls-log-level を上げてあれば TLS 絡みのエラーはログに
ya> > 出ると思いますので、もし正常接続時と何か違う表示が出ていたら教えてください。
ya>
ya> こちらもgnutls-log-levelを4まで上げてみたのですが、接続に失敗した時は
ya> *Messages*には
ya>
ya> ----------------------------------------------------------------------
ya> processp, nil
ya> ----------------------------------------------------------------------
ya>
ya> の一行が追加されるだけです。あとmew-debugをtにすると、接続に失敗したと
たとえば s + RET を連続で実行すると、*Messages* 次のような内容が
並ぶと思います。processp, nil が出るのは、どのタイミングでしょうか?
Creating SSL/TLS connection (GnuTLS, STARTTLS)...
Communicating with the IMAP server...
No new messages [2 times]
Connecting to the IMAP server...
Creating SSL/TLS connection (GnuTLS, STARTTLS)...
Connecting to the IMAP server...done
Communicating with the IMAP server...
No new messages [2 times]
...
また、これは「processp, nil が表示された後、どう操作しても
接続できなくなる」という話ではなく、
「s + RET を実行すると正常に接続できなかったり、
できたりする」という解釈で正しいでしょうか?
-- Hiroki
Yasuhiro KIMURA
Jan 13, 2020, 4:36:06 AM1/13/20
to mew...@googlegroups.com
Date: Mon, 13 Jan 2020 18:04:34 +0900 (JST)
> imap.gmail.com:imap と出るということは、
> ポート番号が imaps ではなく imap になっていますね。
> たぶん 143/tcp に TLS で接続しようとして
> タイムアウトしているのだと思います。
>
> (mew-imap-port) を評価すると imap,
> (mew-imap-ssl-port) を評価すると imaps になっている状態でしょうか?
> もしそれで上記の状態になるのであれば、動作がおかしいです。
> 原因がよくわからないので、デバッグ用の出力を追加してみます。
mew-imap-portとmew-imap-ssl-portについては
> imap.gmail.com:imap と出るということは、
> ポート番号が imaps ではなく imap になっていますね。
> たぶん 143/tcp に TLS で接続しようとして
> タイムアウトしているのだと思います。
>
> (mew-imap-port) を評価すると imap,
> (mew-imap-ssl-port) を評価すると imaps になっている状態でしょうか?
> もしそれで上記の状態になるのであれば、動作がおかしいです。
> 原因がよくわからないので、デバッグ用の出力を追加してみます。
(setq mew-imap-ssl-port mew-imap-port)
と設定していて、mew-config-alistで
(mew-config-alist '(
(gmail.com
(imap-server "imap.gmail.com")
(imap-ssl-port "imaps")
)))
のようにGmailを使うときはimap-ssl-portが993番になるように指定していま
す。ひょっとしてcaseを使っている場合にのみ発生する問題だったりするので
しょか。
> たとえば s + RET を連続で実行すると、*Messages* 次のような内容が
> 並ぶと思います。processp, nil が出るのは、どのタイミングでしょうか?
>
> Creating SSL/TLS connection (GnuTLS, STARTTLS)...
> Connecting to the IMAP server...done
> Communicating with the IMAP server...
> No new messages [2 times]
> Connecting to the IMAP server...
> Creating SSL/TLS connection (GnuTLS, STARTTLS)...
> Connecting to the IMAP server...done
> Communicating with the IMAP server...
> No new messages [2 times]
> ...
ります。
----------------------------------------------------------------------
Creating SSL/TLS connection (GnuTLS, STARTTLS)...
gnutls.c: [1] (Emacs) non-fatal error: Resource temporarily unavailable, try again.
Connecting to the IMAP server...done
Communicating with the IMAP server...
No new messages
gnutls.c: [2] (Emacs) Deallocating x509 credentials
Communicating with the IMAP server...
No new messages
No new messages
Connecting to the IMAP server...
processp, nil
----------------------------------------------------------------------
> また、これは「processp, nil が表示された後、どう操作しても
> 接続できなくなる」という話ではなく、
> 「s + RET を実行すると正常に接続できなかったり、
> できたりする」という解釈で正しいでしょうか?
というだけで、連続しなければ発生しないという訳でもありません。10分くら
い放置してからs + RETしても発生することもあるので、どうも発生条件がよ
くわかりません。
---
木村 康浩
Hiroki Sato
Jan 13, 2020, 9:47:27 PM1/13/20
to mew...@googlegroups.com
in <20200113.183509.318...@utahime.org>:
ya> のようにGmailを使うときはimap-ssl-portが993番になるように指定していま
ya> す。ひょっとしてcaseを使っている場合にのみ発生する問題だったりするので
ya> しょか。
config-alist で指定されているものを読んでいなかったという
バグでした。あらためて修正した全体パッチを添付します（git repo も更新済みです）。
ya> > また、これは「processp, nil が表示された後、どう操作しても
ya> > 接続できなくなる」という話ではなく、
ya> > 「s + RET を実行すると正常に接続できなかったり、
ya> > できたりする」という解釈で正しいでしょうか?
ya>
ya> はい、その通りです。更に言うと、s + RETを連続すると問題が発生しやすい
ya> というだけで、連続しなければ発生しないという訳でもありません。10分くら
ya> い放置してからs + RETしても発生することもあるので、どうも発生条件がよ
ya> くわかりません。
こちらはまだ手元で再現できていないため、
もう少しいろいろ実験してみます。
ログから推測するに TLS 接続の確立に失敗していますので、
エラーをもう少し詳しく解析するようなコードを書いてみます。
-- Hiroki
ya> のようにGmailを使うときはimap-ssl-portが993番になるように指定していま
ya> す。ひょっとしてcaseを使っている場合にのみ発生する問題だったりするので
ya> しょか。
config-alist で指定されているものを読んでいなかったという
バグでした。あらためて修正した全体パッチを添付します（git repo も更新済みです）。
ya> > また、これは「processp, nil が表示された後、どう操作しても
ya> > 接続できなくなる」という話ではなく、
ya> > 「s + RET を実行すると正常に接続できなかったり、
ya> > できたりする」という解釈で正しいでしょうか?
ya>
ya> はい、その通りです。更に言うと、s + RETを連続すると問題が発生しやすい
ya> というだけで、連続しなければ発生しないという訳でもありません。10分くら
ya> い放置してからs + RETしても発生することもあるので、どうも発生条件がよ
ya> くわかりません。
こちらはまだ手元で再現できていないため、
もう少しいろいろ実験してみます。
ログから推測するに TLS 接続の確立に失敗していますので、
エラーをもう少し詳しく解析するようなコードを書いてみます。
-- Hiroki
Hiroki Sato
Jan 13, 2020, 9:52:09 PM1/13/20
to mew...@googlegroups.com
Hiroki Sato <h...@allbsd.org> wrote
in <20200114.114619.173...@allbsd.org>:
hr> 佐藤です。
hr>
hr> Yasuhiro KIMURA <ya...@utahime.org> wrote
hr> in <20200113.183509.318...@utahime.org>:
hr>
hr> ya> のようにGmailを使うときはimap-ssl-portが993番になるように指定していま
hr> ya> す。ひょっとしてcaseを使っている場合にのみ発生する問題だったりするので
hr> ya> しょか。
hr>
hr> config-alist で指定されているものを読んでいなかったという
hr> バグでした。あらためて修正した全体パッチを添付します（git repo も更新済みです）。
添付したパッチを間違えていました。このメールにあるものが正しいです。
-- Hiroki
in <20200114.114619.173...@allbsd.org>:
hr> 佐藤です。
hr>
hr> Yasuhiro KIMURA <ya...@utahime.org> wrote
hr> in <20200113.183509.318...@utahime.org>:
hr>
hr> ya> のようにGmailを使うときはimap-ssl-portが993番になるように指定していま
hr> ya> す。ひょっとしてcaseを使っている場合にのみ発生する問題だったりするので
hr> ya> しょか。
hr>
hr> config-alist で指定されているものを読んでいなかったという
hr> バグでした。あらためて修正した全体パッチを添付します（git repo も更新済みです）。
添付したパッチを間違えていました。このメールにあるものが正しいです。
-- Hiroki
Yasuhiro KIMURA
Jan 13, 2020, 11:42:24 PM1/13/20
to mew...@googlegroups.com
Date: Tue, 14 Jan 2020 11:46:19 +0900 (JST)
>> のようにGmailを使うときはimap-ssl-portが993番になるように指定していま
>> す。ひょっとしてcaseを使っている場合にのみ発生する問題だったりするので
で、SMTPの方についてはGmailについてもmew-smtp-ssl-port=mew-smtp-portだっ
たのですが、ふと思い立って
(smtp-server "smtp.gmail.com")
(smtp-ssl-port "smtps")
)))
としてみたところ、メールの送信時に「Cannot create to SSL/TLS (GnuTLS)
connection」と表示されて送信することが出来ませんでした。なので、caseに
関してIMAP以外の場合の処理でまだバグが残っているのかもしれません。
> こちらはまだ手元で再現できていないため、
> もう少しいろいろ実験してみます。
>
> ログから推測するに TLS 接続の確立に失敗していますので、
> エラーをもう少し詳しく解析するようなコードを書いてみます。
よろしくお願いします。こちらでも出来る範囲でいろいろ試してみます。
---
木村 康浩
>> のようにGmailを使うときはimap-ssl-portが993番になるように指定していま
>> す。ひょっとしてcaseを使っている場合にのみ発生する問題だったりするので
>> しょか。
> config-alist で指定されているものを読んでいなかったという
> バグでした。あらためて修正した全体パッチを添付します（git repo も更新済みです）。
Gitリポジトリを更新したところ、正常に受信出来るようになりました。
> config-alist で指定されているものを読んでいなかったという
> バグでした。あらためて修正した全体パッチを添付します（git repo も更新済みです）。
で、SMTPの方についてはGmailについてもmew-smtp-ssl-port=mew-smtp-portだっ
たのですが、ふと思い立って
(smtp-server "smtp.gmail.com")
(smtp-ssl-port "smtps")
)))
としてみたところ、メールの送信時に「Cannot create to SSL/TLS (GnuTLS)
connection」と表示されて送信することが出来ませんでした。なので、caseに
関してIMAP以外の場合の処理でまだバグが残っているのかもしれません。
> こちらはまだ手元で再現できていないため、
> もう少しいろいろ実験してみます。
>
> ログから推測するに TLS 接続の確立に失敗していますので、
> エラーをもう少し詳しく解析するようなコードを書いてみます。
---
木村 康浩
Hiroki Sato
Jan 14, 2020, 6:14:39 AM1/14/20
to mew...@googlegroups.com
Yasuhiro KIMURA <ya...@utahime.org> wrote
in <20200114.134131.316...@utahime.org>:
ya> 木村です。
ya>
ya> From: Hiroki Sato <h...@allbsd.org>
ya> Subject: Re: [mew-ja] GnuTLS 対応
ya> Date: Tue, 14 Jan 2020 11:46:19 +0900 (JST)
ya>
ya> > バグでした。あらためて修正した全体パッチを添付します（git repo も更新済みです）。
ya>
ya> Gitリポジトリを更新したところ、正常に受信出来るようになりました。
ya> で、SMTPの方についてはGmailについてもmew-smtp-ssl-port=mew-smtp-portだっ
ya> たのですが、ふと思い立って
ya>
ya> (mew-config-alist '(
ya> (gmail.com
ya> (imap-server "imap.gmail.com")
ya> (imap-ssl-port "imaps")
ya> (smtp-server "smtp.gmail.com")
ya> (smtp-ssl-port "smtps")
ya> )))
ya>
ya> としてみたところ、メールの送信時に「Cannot create to SSL/TLS (GnuTLS)
ya> connection」と表示されて送信することが出来ませんでした。なので、caseに
ya> 関してIMAP以外の場合の処理でまだバグが残っているのかもしれません。
SMTP についても試験してみましたが、
手元では再現できませんでした。
デバッグ出力をいくつか追加してみました。
接続がおかしい場合の *Messages* を調べてみて
いただけると助かります。
-- Hiroki
in <20200114.134131.316...@utahime.org>:
ya> 木村です。
ya>
ya> From: Hiroki Sato <h...@allbsd.org>
ya> Subject: Re: [mew-ja] GnuTLS 対応
ya> Date: Tue, 14 Jan 2020 11:46:19 +0900 (JST)
ya>
ya> >> のようにGmailを使うときはimap-ssl-portが993番になるように指定していま
ya> >> す。ひょっとしてcaseを使っている場合にのみ発生する問題だったりするので
ya> >> しょか。
ya> > config-alist で指定されているものを読んでいなかったという
ya> >> す。ひょっとしてcaseを使っている場合にのみ発生する問題だったりするので
ya> >> しょか。
ya> > バグでした。あらためて修正した全体パッチを添付します（git repo も更新済みです）。
ya>
ya> Gitリポジトリを更新したところ、正常に受信出来るようになりました。
ya> で、SMTPの方についてはGmailについてもmew-smtp-ssl-port=mew-smtp-portだっ
ya> たのですが、ふと思い立って
ya>
ya> (mew-config-alist '(
ya> (gmail.com
ya> (imap-server "imap.gmail.com")
ya> (imap-ssl-port "imaps")
ya> (smtp-server "smtp.gmail.com")
ya> (smtp-ssl-port "smtps")
ya> )))
ya>
ya> としてみたところ、メールの送信時に「Cannot create to SSL/TLS (GnuTLS)
ya> connection」と表示されて送信することが出来ませんでした。なので、caseに
ya> 関してIMAP以外の場合の処理でまだバグが残っているのかもしれません。
SMTP についても試験してみましたが、
手元では再現できませんでした。
デバッグ出力をいくつか追加してみました。
接続がおかしい場合の *Messages* を調べてみて
いただけると助かります。
-- Hiroki
Yasuhiro KIMURA
Jan 14, 2020, 10:40:46 AM1/14/20
to mew...@googlegroups.com
Subject: Re: [mew-ja] GnuTLS 対応
Date: Tue, 14 Jan 2020 20:13:27 +0900 (JST)
> SMTP についても試験してみましたが、
> 手元では再現できませんでした。
>
> デバッグ出力をいくつか追加してみました。
> 接続がおかしい場合の *Messages* を調べてみて
> いただけると助かります。
試してみたところ、*Messages*に以下のようなログが出力されていました。
Date: Tue, 14 Jan 2020 20:13:27 +0900 (JST)
> SMTP についても試験してみましたが、
> 手元では再現できませんでした。
>
> デバッグ出力をいくつか追加してみました。
> 接続がおかしい場合の *Messages* を調べてみて
> いただけると助かります。
----------------------------------------------------------------------
Connecting to the SMTP server...
DEBUG1: sslnp=t, starttlsp=nil, sprt=smtps
DEBUG2: sslnp=t, starttlsp=nil, port=smtps
smtp.gmail.com/smtps getaddrinfo error 10109, nil
Cannot create to the SSL/TLS (GnuTLS) connection
----------------------------------------------------------------------
getaddrinfoでエラーが発生しているようですが、STARTTLSが有効の場合には
正常に送信できているので、smtp.gmail.comの正引きは正常なはずです。そこ
で
(mew-config-alist '(
(gmail.com
(imap-server "imap.gmail.com")
(imap-ssl-port "imaps")
(smtp-server "smtp.gmail.com")
)))
としてみたところ、正常に送信できるようになりました。Windowsの
C:\Windows\System32\drivers\etc\servicesにはsmtpsはないので、どうもサー
ビス名→ポート番号の変換に失敗してエラーとなっているようです。ただ、
stunnelを使っている場合にはsmtpsで指定しても正常に送信できますし、
mew-net.elで定義されているmew-port-dbという変数に、smtpsの定義が含まれ
ているので、GnuTLSを使う場合に、mew-port-dbを参照する処理が抜けている
のではないでしょうか。
---
木村 康浩
Hiroki Sato
Jan 14, 2020, 5:21:16 PM1/14/20
to mew...@googlegroups.com
佐藤です。
Yasuhiro KIMURA <ya...@utahime.org> wrote
in <20200115.003957.2218...@utahime.org>:
ya> としてみたところ、正常に送信できるようになりました。Windowsの
ya> C:\Windows\System32\drivers\etc\servicesにはsmtpsはないので、どうもサー
ya> ビス名→ポート番号の変換に失敗してエラーとなっているようです。ただ、
ya> stunnelを使っている場合にはsmtpsで指定しても正常に送信できますし、
ya> mew-net.elで定義されているmew-port-dbという変数に、smtpsの定義が含まれ
ya> ているので、GnuTLSを使う場合に、mew-port-dbを参照する処理が抜けている
ya> のではないでしょうか。
修正しました。
本来は OS がサービス名を解決できない時にだけ mew-port-db を
参照するようにすべきかと思うのですが、やりかたが
ぱっと思いつかないので、とりあえず mew-open-ssl-stream と
同じ処理にしてあります。
-- Hiroki
Yasuhiro KIMURA <ya...@utahime.org> wrote
in <20200115.003957.2218...@utahime.org>:
ya> としてみたところ、正常に送信できるようになりました。Windowsの
ya> C:\Windows\System32\drivers\etc\servicesにはsmtpsはないので、どうもサー
ya> ビス名→ポート番号の変換に失敗してエラーとなっているようです。ただ、
ya> stunnelを使っている場合にはsmtpsで指定しても正常に送信できますし、
ya> mew-net.elで定義されているmew-port-dbという変数に、smtpsの定義が含まれ
ya> ているので、GnuTLSを使う場合に、mew-port-dbを参照する処理が抜けている
ya> のではないでしょうか。
修正しました。
本来は OS がサービス名を解決できない時にだけ mew-port-db を
参照するようにすべきかと思うのですが、やりかたが
ぱっと思いつかないので、とりあえず mew-open-ssl-stream と
同じ処理にしてあります。
-- Hiroki
Yasuhiro KIMURA
Jan 14, 2020, 7:36:11 PM1/14/20
to mew...@googlegroups.com
Date: Wed, 15 Jan 2020 07:20:33 +0900 (JST)
> 修正しました。
>
> 本来は OS がサービス名を解決できない時にだけ mew-port-db を
> 参照するようにすべきかと思うのですが、やりかたが
> ぱっと思いつかないので、とりあえず mew-open-ssl-stream と
> 同じ処理にしてあります。
smtp-ssl-portをsmtpsに設定して、正常にメールが送信できることを確認しま
> 修正しました。
>
> 本来は OS がサービス名を解決できない時にだけ mew-port-db を
> 参照するようにすべきかと思うのですが、やりかたが
> ぱっと思いつかないので、とりあえず mew-open-ssl-stream と
> 同じ処理にしてあります。
した。
---
木村 康浩
YASUOKA Masahiko
Jan 15, 2020, 3:02:10 AM1/15/20
to h...@allbsd.org, mew...@googlegroups.com
佐藤さん、
保岡です。
On Fri, 10 Jan 2020 09:41:31 +0900 (JST)
Hiroki Sato <h...@allbsd.org> wrote:
> 試験環境は今のところ FreeBSD 12 + Emacs 26.3 + GnuTLS 3.6.9 のみです。
> 他の環境で動作するかどうか、教えていただけると助かります。
OpenBSD 6.6 + Emacs 26.3 + GnuTLS 3.6.10
で、smtps:// と startls の両方を試しました。正常にメールが送信できました。
試したのは、
https://github.com/hrs-allbsd/Mew/commit/5b90f59387932450a33f44c94956038e534e8e01
です。
--
YASUOKA Masahiko http://yasuoka.net/~yasuoka/
mailto:yas...@yasuoka.net mobile:090-8801-1637
保岡です。
On Fri, 10 Jan 2020 09:41:31 +0900 (JST)
Hiroki Sato <h...@allbsd.org> wrote:
> 試験環境は今のところ FreeBSD 12 + Emacs 26.3 + GnuTLS 3.6.9 のみです。
> 他の環境で動作するかどうか、教えていただけると助かります。
で、smtps:// と startls の両方を試しました。正常にメールが送信できました。
試したのは、
https://github.com/hrs-allbsd/Mew/commit/5b90f59387932450a33f44c94956038e534e8e01
です。
--
YASUOKA Masahiko http://yasuoka.net/~yasuoka/
mailto:yas...@yasuoka.net mobile:090-8801-1637
Yasuhiro KIMURA
Jan 15, 2020, 11:14:41 AM1/15/20
to mew...@googlegroups.com
Subject: Re: [mew-ja] GnuTLS 対応
Date: Tue, 14 Jan 2020 13:41:31 +0900 (JST)
> よろしくお願いします。こちらでも出来る範囲でいろいろ試してみます。
「processp, nil」が表示されて接続に失敗する件ですが、比較として、同じ
サーバでSTARTTLSを使わない場合どうなるかを確認してみました。自宅のIMAP
サーバの設定を変更して、143番ポートと993番ポートの両方でアクセスできる
ようにした上で、mew-imap-ssl-portをimapsに設定して接続してみたのですが、
暫くs + RETを連打しても問題の症状は発生しませんでした。という訳ですの
で、この問題はSTARTTLSを使っている場合のみに発生するようです。
---
木村 康浩
Kan Sasaki
Jan 16, 2020, 9:44:59 AM1/16/20
to h...@allbsd.org, mew...@googlegroups.com
佐藤さん
From: Hiroki Sato <h...@allbsd.org>
Subject: [mew-ja] GnuTLS 対応
Date: Fri, 10 Jan 2020 09:41:31 +0900 (JST)
> 試験環境は今のところ FreeBSD 12 + Emacs 26.3 + GnuTLS 3.6.9 のみです。
> 他の環境で動作するかどうか、教えていただけると助かります。
FreeBSD 12.1 + Emacs 26.3 + GnuTLS 3.6.11
で、ほぼ同じ環境なので問題なく動作していますが、mew-ssl-verify-level
も case が使えるので、対応してもらえるとうれしいです。
--
佐々木 寛
From: Hiroki Sato <h...@allbsd.org>
Subject: [mew-ja] GnuTLS 対応
Date: Fri, 10 Jan 2020 09:41:31 +0900 (JST)
> 試験環境は今のところ FreeBSD 12 + Emacs 26.3 + GnuTLS 3.6.9 のみです。
> 他の環境で動作するかどうか、教えていただけると助かります。
で、ほぼ同じ環境なので問題なく動作していますが、mew-ssl-verify-level
も case が使えるので、対応してもらえるとうれしいです。
--
佐々木 寛
Hiroki Sato
Jan 17, 2020, 2:35:51 AM1/17/20
to mew...@googlegroups.com
Kan Sasaki <sas...@fcc.ad.jp> wrote
in <20200116.234351.12299...@fcc.ad.jp>:
sa> 佐藤さん
sa>
sa> From: Hiroki Sato <h...@allbsd.org>
sa> Subject: [mew-ja] GnuTLS 対応
sa> Date: Fri, 10 Jan 2020 09:41:31 +0900 (JST)
sa>
sa> > 試験環境は今のところ FreeBSD 12 + Emacs 26.3 + GnuTLS 3.6.9 のみです。
sa> > 他の環境で動作するかどうか、教えていただけると助かります。
sa>
sa> FreeBSD 12.1 + Emacs 26.3 + GnuTLS 3.6.11
sa>
sa> で、ほぼ同じ環境なので問題なく動作していますが、mew-ssl-verify-level
sa> も case が使えるので、対応してもらえるとうれしいです。
どうもありがとうございます。修正しました。
-- Hiroki
in <20200116.234351.12299...@fcc.ad.jp>:
sa> 佐藤さん
sa>
sa> From: Hiroki Sato <h...@allbsd.org>
sa> Subject: [mew-ja] GnuTLS 対応
sa> Date: Fri, 10 Jan 2020 09:41:31 +0900 (JST)
sa>
sa> > 試験環境は今のところ FreeBSD 12 + Emacs 26.3 + GnuTLS 3.6.9 のみです。
sa> > 他の環境で動作するかどうか、教えていただけると助かります。
sa>
sa> FreeBSD 12.1 + Emacs 26.3 + GnuTLS 3.6.11
sa>
sa> で、ほぼ同じ環境なので問題なく動作していますが、mew-ssl-verify-level
sa> も case が使えるので、対応してもらえるとうれしいです。
どうもありがとうございます。修正しました。
-- Hiroki
Hiroki Sato
Jan 17, 2020, 2:35:51 AM1/17/20
to mew...@googlegroups.com
佐藤です。
YASUOKA Masahiko <yas...@yasuoka.net> wrote
in <20200115.170205.14762...@yasuoka.net>:
ya> On Fri, 10 Jan 2020 09:41:31 +0900 (JST)
ya> Hiroki Sato <h...@allbsd.org> wrote:
ya> > 試験環境は今のところ FreeBSD 12 + Emacs 26.3 + GnuTLS 3.6.9 のみです。
ya> > 他の環境で動作するかどうか、教えていただけると助かります。
ya>
ya> OpenBSD 6.6 + Emacs 26.3 + GnuTLS 3.6.10
ya>
ya> で、smtps:// と startls の両方を試しました。正常にメールが送信できました。
ya>
ya> 試したのは、
ya>
ya> https://github.com/hrs-allbsd/Mew/commit/5b90f59387932450a33f44c94956038e534e8e01
ya> です。
了解です。どうもありがとうございます。
-- Hiroki
YASUOKA Masahiko <yas...@yasuoka.net> wrote
in <20200115.170205.14762...@yasuoka.net>:
ya> On Fri, 10 Jan 2020 09:41:31 +0900 (JST)
ya> Hiroki Sato <h...@allbsd.org> wrote:
ya> > 試験環境は今のところ FreeBSD 12 + Emacs 26.3 + GnuTLS 3.6.9 のみです。
ya> > 他の環境で動作するかどうか、教えていただけると助かります。
ya>
ya> OpenBSD 6.6 + Emacs 26.3 + GnuTLS 3.6.10
ya>
ya> で、smtps:// と startls の両方を試しました。正常にメールが送信できました。
ya>
ya> 試したのは、
ya>
ya> https://github.com/hrs-allbsd/Mew/commit/5b90f59387932450a33f44c94956038e534e8e01
ya> です。
了解です。どうもありがとうございます。
-- Hiroki
Tatsuya Kinoshita
Jan 23, 2020, 7:55:07 AM1/23/20
to mew...@googlegroups.com
On January 17, 2020 at 4:23PM +0900, hrs (at allbsd.org) wrote:
> @item mew-smtp-ssl
> -SMTP over SSL を使うか否か。
> +SMTP over SSL を使うか否か。@samp{'native} は GnuTLS
> +を使った TLS/SSL 接続、@samp{'tunnel} は stunnel
> +を使った TLS/SSL トンネル接続を意味する。
> @item mew-smtp-ssl-port
> SMTP over SSL のポート番号。
> @item mew-smtp-user
> @@ -11739,6 +11753,8 @@ The name of SSH server which forwards the SMTP port.
> If non-nil, SMTP connections are made over SSL.
> @item mew-smtp-ssl-port
> The port for SMTP over SSL.
> +@samp{'native} enables GnuTLS for native TLS connection
> +and @samp{'tunnel} uses stunnel to establish a TLS tunnel.
英語の方だけ誤ってmew-smtp-sslでなくmew-smtp-ssl-portについて変更
してしまっているようです。
> diff --git a/mew-nntp.el b/mew-nntp.el
> @@ -423,6 +428,11 @@
> (sshsrv (mew-nntp-ssh-server case))
> (sslp (mew-nntp-ssl case))
> (sslport (mew-nntp-ssl-port case))
> + (sslnp (mew-ssl-native-p (mew-imap-ssl case)))
> diff --git a/mew-nntp2.el b/mew-nntp2.el
> @@ -213,25 +218,33 @@
> (sshsrv (mew-nntp-ssh-server case))
> (sslp (mew-nntp-ssl case))
> (sslport (mew-nntp-ssl-port case))
> + (sslnp (mew-ssl-native-p (mew-imap-ssl case)))
mew-imap-sslでなくmew-nntp-ssl?
ところで、mew-pop-ssl, mew-imap-ssl, mew-nntp-ssl, mew-smtp-sslは
従来通りbooleanにしておいて、設定値tのまま移行できるように、
native対応には別の変数を新設してはどうでしょうか。
現時点でnativeを試す際にも、将来的にnativeの方をデフォルトにする際
にも、別変数の方が都合がよさそうに思います。
--
木下達也
> @item mew-smtp-ssl
> -SMTP over SSL を使うか否か。
> +SMTP over SSL を使うか否か。@samp{'native} は GnuTLS
> +を使った TLS/SSL 接続、@samp{'tunnel} は stunnel
> +を使った TLS/SSL トンネル接続を意味する。
> @item mew-smtp-ssl-port
> SMTP over SSL のポート番号。
> @item mew-smtp-user
> @@ -11739,6 +11753,8 @@ The name of SSH server which forwards the SMTP port.
> If non-nil, SMTP connections are made over SSL.
> @item mew-smtp-ssl-port
> The port for SMTP over SSL.
> +@samp{'native} enables GnuTLS for native TLS connection
> +and @samp{'tunnel} uses stunnel to establish a TLS tunnel.
英語の方だけ誤ってmew-smtp-sslでなくmew-smtp-ssl-portについて変更
してしまっているようです。
> diff --git a/mew-nntp.el b/mew-nntp.el
> @@ -423,6 +428,11 @@
> (sshsrv (mew-nntp-ssh-server case))
> (sslp (mew-nntp-ssl case))
> (sslport (mew-nntp-ssl-port case))
> + (sslnp (mew-ssl-native-p (mew-imap-ssl case)))
> diff --git a/mew-nntp2.el b/mew-nntp2.el
> @@ -213,25 +218,33 @@
> (sshsrv (mew-nntp-ssh-server case))
> (sslp (mew-nntp-ssl case))
> (sslport (mew-nntp-ssl-port case))
> + (sslnp (mew-ssl-native-p (mew-imap-ssl case)))
mew-imap-sslでなくmew-nntp-ssl?
ところで、mew-pop-ssl, mew-imap-ssl, mew-nntp-ssl, mew-smtp-sslは
従来通りbooleanにしておいて、設定値tのまま移行できるように、
native対応には別の変数を新設してはどうでしょうか。
現時点でnativeを試す際にも、将来的にnativeの方をデフォルトにする際
にも、別変数の方が都合がよさそうに思います。
--
木下達也
Yasuhiro KIMURA
Jan 24, 2020, 5:13:22 AM1/24/20
to mew...@googlegroups.com
木村です。
From: Tatsuya Kinoshita <ta...@vega.ocn.ne.jp>
Subject: Re: [mew-ja] Re: GnuTLS 対応
Date: Thu, 23 Jan 2020 21:49:52 +0900 (JST)
> ところで、mew-pop-ssl, mew-imap-ssl, mew-nntp-ssl, mew-smtp-sslは
> 従来通りbooleanにしておいて、設定値tのまま移行できるように、
> native対応には別の変数を新設してはどうでしょうか。
>
> 現時点でnativeを試す際にも、将来的にnativeの方をデフォルトにする際
> にも、別変数の方が都合がよさそうに思います。
賛成に一票です。
ところで、Stunnel/GnuTLSどちらを使うかの指定って、プロトコル毎に指定で
きたり、ケースで切り替えることができた方が、やっぱりうれしいのでしょう
か。ちょっと考えてみたのですが、IMAPはStunnelだけどSMTPはGnuTLSを使う
とか、接続先によってStunnelとGnuTLSを使い分ける、という状況が思い浮か
ばないので、これに関しては全体で一つの変数で指定、で良いように思えるの
ですが。
---
木村 康浩
From: Tatsuya Kinoshita <ta...@vega.ocn.ne.jp>
Subject: Re: [mew-ja] Re: GnuTLS 対応
Date: Thu, 23 Jan 2020 21:49:52 +0900 (JST)
> ところで、mew-pop-ssl, mew-imap-ssl, mew-nntp-ssl, mew-smtp-sslは
> 従来通りbooleanにしておいて、設定値tのまま移行できるように、
> native対応には別の変数を新設してはどうでしょうか。
>
> 現時点でnativeを試す際にも、将来的にnativeの方をデフォルトにする際
> にも、別変数の方が都合がよさそうに思います。
ところで、Stunnel/GnuTLSどちらを使うかの指定って、プロトコル毎に指定で
きたり、ケースで切り替えることができた方が、やっぱりうれしいのでしょう
か。ちょっと考えてみたのですが、IMAPはStunnelだけどSMTPはGnuTLSを使う
とか、接続先によってStunnelとGnuTLSを使い分ける、という状況が思い浮か
ばないので、これに関しては全体で一つの変数で指定、で良いように思えるの
ですが。
---
木村 康浩
Yasuhiro KIMURA
Jan 24, 2020, 5:13:23 AM1/24/20
to mew...@googlegroups.com
https://github.com/yasuhirokimura/Mew/commit/fdc6fc4e96e385c3d59885d31473217ea22a4cc8
このコードでs + RETを連打すると、問題が発生した場合*Messages*には以下
のような出力が残ります。
----------------------------------------------------------------------
Connecting to the IMAP server...
mew-imap-open: mew-open-network-stream start
mew-open-network-stream: start
Opening a TLS connection (GnuTLS, STARTTLS)...
mew-open-network-stream: open-network-stream start
mew-open-network-stream: error: wrong-type-argument ((processp nil))
mew-open-network-stream: open-network-stream end
mew-open-network-stream: start
mew-imap-open: error: error ((Buffer %inbox has no process))
----------------------------------------------------------------------
この結果からは、open-network-streamの実行中にエラーが発生しているよう
に見えます。なのでひょっとすると、原因はWindows環境でのみ発生する、
Emacs本体のバグだったりしないでしょうか。
ちなみに、Emacsのリポジトリでは問題が修正されているかも思い、gitの
masterをビルドして試してみましたが、残念ながら問題が発生してしまいまし
た。
---
木村 康浩
Hiroki Sato
Jan 25, 2020, 3:16:17 PM1/25/20
to mew...@googlegroups.com
Tatsuya Kinoshita <ta...@vega.ocn.ne.jp> wrote
in <20200123.214952.1053192034668096235.tats%nob...@tats.iris.ne.jp>:
ta> 英語の方だけ誤ってmew-smtp-sslでなくmew-smtp-ssl-portについて変更
ta> してしまっているようです。
...
ta> mew-imap-sslでなくmew-nntp-ssl?
どうもありがとうございます。修正しました。
ta> ところで、mew-pop-ssl, mew-imap-ssl, mew-nntp-ssl, mew-smtp-sslは
ta> 従来通りbooleanにしておいて、設定値tのまま移行できるように、
ta> native対応には別の変数を新設してはどうでしょうか。
ta>
ta> 現時点でnativeを試す際にも、将来的にnativeの方をデフォルトにする際
ta> にも、別変数の方が都合がよさそうに思います。
あまり名前は良くないかも知れませんが、mew-ssl-default を追加しました。
-- Hiroki
in <20200123.214952.1053192034668096235.tats%nob...@tats.iris.ne.jp>:
ta> 英語の方だけ誤ってmew-smtp-sslでなくmew-smtp-ssl-portについて変更
ta> してしまっているようです。
...
ta> mew-imap-sslでなくmew-nntp-ssl?
どうもありがとうございます。修正しました。
ta> ところで、mew-pop-ssl, mew-imap-ssl, mew-nntp-ssl, mew-smtp-sslは
ta> 従来通りbooleanにしておいて、設定値tのまま移行できるように、
ta> native対応には別の変数を新設してはどうでしょうか。
ta>
ta> 現時点でnativeを試す際にも、将来的にnativeの方をデフォルトにする際
ta> にも、別変数の方が都合がよさそうに思います。
あまり名前は良くないかも知れませんが、mew-ssl-default を追加しました。
-- Hiroki
Hiroki Sato
Jan 26, 2020, 4:25:31 AM1/26/20
to mew...@googlegroups.com
佐藤です。
スレッドが長くなったので、現状をまとめました。
- mew-{imap,nntp,pop,smtp}-ssl は、
'native であれば GnuTLS を、
'tunnel であれば stunnel を、
t であれば mew-ssl-default に設定されている値を使います。
mew-{imap,nntp,pop,smtp}-ssl は、case で設定することも可能です。
- mew-{imap,nntp,pop,smtp}-port と mew-{imap,nntp,pop,smtp}-ssl-port が
同一の場合、STARTTLS を試みます。
- mew-ssl-verify-level は、>0 であれば
証明書の trust chain とホスト名の両方を検証します。
検証自体は、常に level 3 相当です。
<2 でかつ STARTTLS を使っている場合、検証が失敗した時には
通常の TCP 接続にフォールバックします。
それ以外は、検証が失敗すると接続を切断してエラーにします。
また、STARTTLS を使う場合は NSM による検証が行なわれます。
検証できなかった場合に接続するかどうかの選択ダイアログは
無効にしてありますが、あらかじめ NSM を設定しておくことで、
自己署名証明書等を信頼させることは可能です。
- mew-ssl-trustfiles にパス名のリストを設定することで、
信頼する root CA の証明書を指定することができます。
ただし、GnuTLS は OS が提供する root CA の証明書リストを
ライブラリ内に持っており、それが必ず追加されるようになっています。
たとえば /dev/null を指定しても、デフォルトの証明書リストを無効に
することができません。
実用上はそれほど深刻な問題ではありませんが、信頼する証明書が完全に
制御できないのはどうかと思いますので、Emacs 本体へのパッチを作りました。
添付の 2 個目、gnutls.c へのパッチでこの挙動を修正できます。
- mew-ssl-algorithm-priority に string を指定すると、TLS プロトコルバージョンや
cipher 等を制限することができます。nil ならデフォルト値を使います。
文字列の意味は、GnuTLS の Priority Strings を参照してください。
- mew-ssl-client-keycert-list は、鍵・証明書のパス名ペアのリストです。
クライアント認証を行ないたい場合に指定してください。
どちらも PEM フォーマットである必要があります。
- GnuTLS 自体は OCSP に対応していますが、Emacs 上での
revocation の検証には、CRL しか使えません。
CRL は使用頻度が低そうなので、そのための設定変数は
追加していません。
- 添付してあるのは master からのパッチです。
最新版は次の URL から取得できます。
細かなバグは見つけ次第修正しています。奇妙な動作に気づいた方は
連絡いただけると助かります。
[*] https://github.com/kazu-yamamoto/Mew/compare/master...hrs-allbsd:gnutls.diff
-- Hiroki
スレッドが長くなったので、現状をまとめました。
- mew-{imap,nntp,pop,smtp}-ssl は、
'native であれば GnuTLS を、
'tunnel であれば stunnel を、
t であれば mew-ssl-default に設定されている値を使います。
mew-{imap,nntp,pop,smtp}-ssl は、case で設定することも可能です。
- mew-{imap,nntp,pop,smtp}-port と mew-{imap,nntp,pop,smtp}-ssl-port が
同一の場合、STARTTLS を試みます。
- mew-ssl-verify-level は、>0 であれば
証明書の trust chain とホスト名の両方を検証します。
検証自体は、常に level 3 相当です。
<2 でかつ STARTTLS を使っている場合、検証が失敗した時には
通常の TCP 接続にフォールバックします。
それ以外は、検証が失敗すると接続を切断してエラーにします。
また、STARTTLS を使う場合は NSM による検証が行なわれます。
検証できなかった場合に接続するかどうかの選択ダイアログは
無効にしてありますが、あらかじめ NSM を設定しておくことで、
自己署名証明書等を信頼させることは可能です。
- mew-ssl-trustfiles にパス名のリストを設定することで、
信頼する root CA の証明書を指定することができます。
ただし、GnuTLS は OS が提供する root CA の証明書リストを
ライブラリ内に持っており、それが必ず追加されるようになっています。
たとえば /dev/null を指定しても、デフォルトの証明書リストを無効に
することができません。
実用上はそれほど深刻な問題ではありませんが、信頼する証明書が完全に
制御できないのはどうかと思いますので、Emacs 本体へのパッチを作りました。
添付の 2 個目、gnutls.c へのパッチでこの挙動を修正できます。
- mew-ssl-algorithm-priority に string を指定すると、TLS プロトコルバージョンや
cipher 等を制限することができます。nil ならデフォルト値を使います。
文字列の意味は、GnuTLS の Priority Strings を参照してください。
- mew-ssl-client-keycert-list は、鍵・証明書のパス名ペアのリストです。
クライアント認証を行ないたい場合に指定してください。
どちらも PEM フォーマットである必要があります。
- GnuTLS 自体は OCSP に対応していますが、Emacs 上での
revocation の検証には、CRL しか使えません。
CRL は使用頻度が低そうなので、そのための設定変数は
追加していません。
- 添付してあるのは master からのパッチです。
最新版は次の URL から取得できます。
細かなバグは見つけ次第修正しています。奇妙な動作に気づいた方は
連絡いただけると助かります。
[*] https://github.com/kazu-yamamoto/Mew/compare/master...hrs-allbsd:gnutls.diff
-- Hiroki
Yasuhiro KIMURA
Jan 27, 2020, 9:32:34 AM1/27/20
to mew...@googlegroups.com
木村です。
「processp, nil」が表示されて接続に失敗する件ですが、佐藤さんのリポジ
トリが更新されていたので試してみたところ、s + RETを連打しても問題が発
生しなくなったようです。もうしばらく使い続けて様子を見るつもりですが、
取りあえずご報告まで。
---
木村 康浩
「processp, nil」が表示されて接続に失敗する件ですが、佐藤さんのリポジ
トリが更新されていたので試してみたところ、s + RETを連打しても問題が発
生しなくなったようです。もうしばらく使い続けて様子を見るつもりですが、
取りあえずご報告まで。
---
木村 康浩
Tatsuya Kinoshita
Jan 29, 2020, 4:48:50 AM1/29/20
to mew...@googlegroups.com
On January 26, 2020 at 5:13AM +0900, hrs (at allbsd.org) wrote:
> mew-ssl-default を追加しました。
>
> +++ b/mew-ssl.el
> +(defvar mew-ssl-default 'tunnel
> + "Default SSL/TLS type when mew-{imap,nntp,pop,smtp}-ssl is 't'.")
> +(defun mew-ssl-native-p (type)
> + "Return if the type is native or not"
> + (or (eq type 'native)
> + (and type (eq mew-ssl-default 'native))))
デフォルトを'nativeにしたときに個別の'tunnel設定を生かすなら、
次のような感じでしょうか。
```
(defun mew-ssl-native-p (type)
"Return if the type is native or not"
(or (eq type 'native)
(and type (not (eq type 'tunnel)) (eq mew-ssl-default 'native))))
```
> +++ b/mew-vars.el
> +(defcustom mew-ssl-default 'tunnel
mew-ssl-defaultの定義がmew-ssl.elとmew-vars.elの両方にありますが、
片方は消し忘れでしょうか。
--
木下達也
> mew-ssl-default を追加しました。
>
> +++ b/mew-ssl.el
> +(defvar mew-ssl-default 'tunnel
> + "Default SSL/TLS type when mew-{imap,nntp,pop,smtp}-ssl is 't'.")
> +(defun mew-ssl-native-p (type)
> + "Return if the type is native or not"
> + (or (eq type 'native)
> + (and type (eq mew-ssl-default 'native))))
デフォルトを'nativeにしたときに個別の'tunnel設定を生かすなら、
次のような感じでしょうか。
```
(defun mew-ssl-native-p (type)
"Return if the type is native or not"
(or (eq type 'native)
(and type (not (eq type 'tunnel)) (eq mew-ssl-default 'native))))
```
> +++ b/mew-vars.el
> +(defcustom mew-ssl-default 'tunnel
mew-ssl-defaultの定義がmew-ssl.elとmew-vars.elの両方にありますが、
片方は消し忘れでしょうか。
--
木下達也
Hiroki Sato
Feb 4, 2020, 11:48:13 PM2/4/20
to mew...@googlegroups.com
佐藤です。
Hiroki Sato <h...@allbsd.org> wrote
in <20200126.182313.100...@allbsd.org>:
hr> - mew-ssl-verify-level は、>0 であれば
hr> 証明書の trust chain とホスト名の両方を検証します。
hr> 検証自体は、常に level 3 相当です。
hr>
hr> <2 でかつ STARTTLS を使っている場合、検証が失敗した時には
hr> 通常の TCP 接続にフォールバックします。
hr> それ以外は、検証が失敗すると接続を切断してエラーにします。
hr>
hr> また、STARTTLS を使う場合は NSM による検証が行なわれます。
hr> 検証できなかった場合に接続するかどうかの選択ダイアログは
hr> 無効にしてありますが、あらかじめ NSM を設定しておくことで、
hr> 自己署名証明書等を信頼させることは可能です。
今まで確認できた不具合は可能な限り修正し、
implicit TLS, STARTTLS の両方で NSM による
検証を行なうように変更しました。
implicit TLS の接続についても (open-network-stream) を使うように
変更しましたので、このパッチで正常に動作するか、
今一度レポートをいただけますでしょうか? > 試していただいたみなさま
これで動作に問題がないようでしたら、整理して pull request にします。
また、info の SSL と TLS の解説の部分を拡充しました。
旧版は implicit TLS を SSL, STARTTLS を TLS と呼んでいますが、
現在は SSLv3 も deprecated になったため TLS に用語を統一し、
冒頭で SSL という用語について簡単に触れるのみとしました。
Stunnel の解説はほぼそのまま、GnuTLS の解説を少し加えてあります。
もうちょっと書き足すべきだと思いますが、もし現段階で
技術的な誤り等、気づく点がありましたら指摘ください。
> 添付してあるのは master からのパッチです。
> 最新版は次の URL から取得できます。
>
Hiroki Sato <h...@allbsd.org> wrote
in <20200126.182313.100...@allbsd.org>:
hr> - mew-ssl-verify-level は、>0 であれば
hr> 証明書の trust chain とホスト名の両方を検証します。
hr> 検証自体は、常に level 3 相当です。
hr>
hr> <2 でかつ STARTTLS を使っている場合、検証が失敗した時には
hr> 通常の TCP 接続にフォールバックします。
hr> それ以外は、検証が失敗すると接続を切断してエラーにします。
hr>
hr> また、STARTTLS を使う場合は NSM による検証が行なわれます。
hr> 検証できなかった場合に接続するかどうかの選択ダイアログは
hr> 無効にしてありますが、あらかじめ NSM を設定しておくことで、
hr> 自己署名証明書等を信頼させることは可能です。
今まで確認できた不具合は可能な限り修正し、
implicit TLS, STARTTLS の両方で NSM による
検証を行なうように変更しました。
implicit TLS の接続についても (open-network-stream) を使うように
変更しましたので、このパッチで正常に動作するか、
今一度レポートをいただけますでしょうか? > 試していただいたみなさま
これで動作に問題がないようでしたら、整理して pull request にします。
また、info の SSL と TLS の解説の部分を拡充しました。
旧版は implicit TLS を SSL, STARTTLS を TLS と呼んでいますが、
現在は SSLv3 も deprecated になったため TLS に用語を統一し、
冒頭で SSL という用語について簡単に触れるのみとしました。
Stunnel の解説はほぼそのまま、GnuTLS の解説を少し加えてあります。
もうちょっと書き足すべきだと思いますが、もし現段階で
技術的な誤り等、気づく点がありましたら指摘ください。
> 添付してあるのは master からのパッチです。
> 最新版は次の URL から取得できます。
>
Hiroki Sato
Feb 4, 2020, 11:48:51 PM2/4/20
to mew...@googlegroups.com
Tatsuya Kinoshita <ta...@vega.ocn.ne.jp> wrote
in <20200129.184521.946417613298549141.tats%nob...@tats.iris.ne.jp>:
ta> On January 26, 2020 at 5:13AM +0900, hrs (at allbsd.org) wrote:
ta> > mew-ssl-default を追加しました。
ta> >
ta> > +++ b/mew-ssl.el
ta> > +(defvar mew-ssl-default 'tunnel
ta> > + "Default SSL/TLS type when mew-{imap,nntp,pop,smtp}-ssl is 't'.")
ta> > +(defun mew-ssl-native-p (type)
ta> > + "Return if the type is native or not"
ta> > + (or (eq type 'native)
ta> > + (and type (eq mew-ssl-default 'native))))
ta>
ta> デフォルトを'nativeにしたときに個別の'tunnel設定を生かすなら、
ta> 次のような感じでしょうか。
ta>
ta> ```
ta> (defun mew-ssl-native-p (type)
ta> "Return if the type is native or not"
ta> (or (eq type 'native)
ta> (and type (not (eq type 'tunnel)) (eq mew-ssl-default 'native))))
ta> ```
ta>
ta> > +++ b/mew-vars.el
ta> > +(defcustom mew-ssl-default 'tunnel
ta>
ta> mew-ssl-defaultの定義がmew-ssl.elとmew-vars.elの両方にありますが、
ta> 片方は消し忘れでしょうか。
ご指摘どうもです。修正しました。
-- Hiroki
in <20200129.184521.946417613298549141.tats%nob...@tats.iris.ne.jp>:
ta> On January 26, 2020 at 5:13AM +0900, hrs (at allbsd.org) wrote:
ta> > mew-ssl-default を追加しました。
ta> >
ta> > +++ b/mew-ssl.el
ta> > +(defvar mew-ssl-default 'tunnel
ta> > + "Default SSL/TLS type when mew-{imap,nntp,pop,smtp}-ssl is 't'.")
ta> > +(defun mew-ssl-native-p (type)
ta> > + "Return if the type is native or not"
ta> > + (or (eq type 'native)
ta> > + (and type (eq mew-ssl-default 'native))))
ta>
ta> デフォルトを'nativeにしたときに個別の'tunnel設定を生かすなら、
ta> 次のような感じでしょうか。
ta>
ta> ```
ta> (defun mew-ssl-native-p (type)
ta> "Return if the type is native or not"
ta> (or (eq type 'native)
ta> (and type (not (eq type 'tunnel)) (eq mew-ssl-default 'native))))
ta> ```
ta>
ta> > +++ b/mew-vars.el
ta> > +(defcustom mew-ssl-default 'tunnel
ta>
ta> mew-ssl-defaultの定義がmew-ssl.elとmew-vars.elの両方にありますが、
ta> 片方は消し忘れでしょうか。
ご指摘どうもです。修正しました。
-- Hiroki
Tatsuya Kinoshita
Feb 6, 2020, 5:30:06 AM2/6/20
to mew...@googlegroups.com
On February 5, 2020 at 1:46PM +0900, hrs (at allbsd.org) wrote:
> implicit TLS, STARTTLS の両方で NSM による
> 検証を行なうように変更しました。
gnutls-verify-errorをtにした状態だと、mew-ssl-verify-level 0が機能
> implicit TLS, STARTTLS の両方で NSM による
> 検証を行なうように変更しました。
しないことに気付きました。
gnutls-boot-parametersでverify-errorをnilにしておいて、NSMによる
検証結果のみを使う(mew-ssl-verify-level >0で検証失敗時にはNSMで選択
ダイアログを表示する)ことを意図しているように見えますが、この場合
gnutls-verify-error tの値が使われて、mew-ssl-verify-levelの値に
かかわらず、検証失敗時には選択ダイアログ無しで切断されてしまいます。
gnutls-verify-errorの値を生かす意図ならドキュメントで明示が必要だと
思います。値を上書きしたいのであれば、verify-errorにはnil以外を指定
してはどうでしょうか。
```
--- a/mew-smtp.el
+++ b/mew-smtp.el
@@ -434,7 +434,7 @@
;; the system-wide default path first even if
;; trustfiles is specified.
(trustfiles (mew-ssl-trustfiles case))
- (verify-error nil)
+ (verify-error '((".*")))
;; NSM level to 'low by default.
(nsm-noninteractive nil)
(network-security-level 'low))
```
--
木下達也
Hiroki Sato
Feb 8, 2020, 3:16:31 PM2/8/20
to mew...@googlegroups.com
佐藤です。
Tatsuya Kinoshita <ta...@vega.ocn.ne.jp> wrote
in <20200206.192635.1615324638299085238.tats%nob...@tats.iris.ne.jp>:
ta> On February 5, 2020 at 1:46PM +0900, hrs (at allbsd.org) wrote:
ta> > implicit TLS, STARTTLS の両方で NSM による
ta> > 検証を行なうように変更しました。
ta>
ta> gnutls-verify-errorをtにした状態だと、mew-ssl-verify-level 0が機能
ta> しないことに気付きました。
ta>
ta> gnutls-boot-parametersでverify-errorをnilにしておいて、NSMによる
ta> 検証結果のみを使う(mew-ssl-verify-level >0で検証失敗時にはNSMで選択
ta> ダイアログを表示する)ことを意図しているように見えますが、この場合
ta> gnutls-verify-error tの値が使われて、mew-ssl-verify-levelの値に
ta> かかわらず、検証失敗時には選択ダイアログ無しで切断されてしまいます。
ta>
ta> gnutls-verify-errorの値を生かす意図ならドキュメントで明示が必要だと
ta> 思います。値を上書きしたいのであれば、verify-errorにはnil以外を指定
ta> してはどうでしょうか。
gnutls-verify-error を non-nil にした場合の挙動については、
ご指摘のとおり、non-nil にすると実質的に NSM が機能しません。
そのあたりの記述を info に追記しました。
もうちょっと文章を推敲すべきですが、必要な情報は入ったと思います。
emacs-devel の議論を眺めている限りでは、「TLS を使う
Emacs Lisp プログラムは 原則として open-network-stream を使い、
検証は nsm-verify-connection に任せるべき」という話なのだと
理解しています。したがって、gnutls-verify-error を non-nil にすると
NSM が動かないというのは、仕様と考えるか、ケアするなら
open-network-stream 側で行なうべきなのだと思います。
Emacs 側のコードの端々に雑なところが見られるので、
これを仕様と考えるのは微妙なような気もしますが、
Mew だけが独自にそれを回避してしまうと動作に一貫性がなくなるため、
「gnutls-verify-error を設定すると mew-ssl-verify-level や
network-securiy-level が無視される」という文章を入れました。
-- Hiroki
Tatsuya Kinoshita <ta...@vega.ocn.ne.jp> wrote
in <20200206.192635.1615324638299085238.tats%nob...@tats.iris.ne.jp>:
ta> On February 5, 2020 at 1:46PM +0900, hrs (at allbsd.org) wrote:
ta> > implicit TLS, STARTTLS の両方で NSM による
ta> > 検証を行なうように変更しました。
ta>
ta> gnutls-verify-errorをtにした状態だと、mew-ssl-verify-level 0が機能
ta> しないことに気付きました。
ta>
ta> gnutls-boot-parametersでverify-errorをnilにしておいて、NSMによる
ta> 検証結果のみを使う(mew-ssl-verify-level >0で検証失敗時にはNSMで選択
ta> ダイアログを表示する)ことを意図しているように見えますが、この場合
ta> gnutls-verify-error tの値が使われて、mew-ssl-verify-levelの値に
ta> かかわらず、検証失敗時には選択ダイアログ無しで切断されてしまいます。
ta>
ta> gnutls-verify-errorの値を生かす意図ならドキュメントで明示が必要だと
ta> 思います。値を上書きしたいのであれば、verify-errorにはnil以外を指定
ta> してはどうでしょうか。
gnutls-verify-error を non-nil にした場合の挙動については、
ご指摘のとおり、non-nil にすると実質的に NSM が機能しません。
そのあたりの記述を info に追記しました。
もうちょっと文章を推敲すべきですが、必要な情報は入ったと思います。
emacs-devel の議論を眺めている限りでは、「TLS を使う
Emacs Lisp プログラムは 原則として open-network-stream を使い、
検証は nsm-verify-connection に任せるべき」という話なのだと
理解しています。したがって、gnutls-verify-error を non-nil にすると
NSM が動かないというのは、仕様と考えるか、ケアするなら
open-network-stream 側で行なうべきなのだと思います。
Emacs 側のコードの端々に雑なところが見られるので、
これを仕様と考えるのは微妙なような気もしますが、
Mew だけが独自にそれを回避してしまうと動作に一貫性がなくなるため、
「gnutls-verify-error を設定すると mew-ssl-verify-level や
network-securiy-level が無視される」という文章を入れました。
-- Hiroki
Tatsuya Kinoshita
Feb 9, 2020, 9:35:23 AM2/9/20
to mew...@googlegroups.com
On February 9, 2020 at 5:14AM +0900, hrs (at allbsd.org) wrote:
> これを仕様と考えるのは微妙なような気もしますが、
> Mew だけが独自にそれを回避してしまうと動作に一貫性がなくなるため、
mew-ssl-native-min-prime-bitsやmew-ssl-algorithm-priorityのように、
verify-errorの値nilも変数にしておくだけではどうでしょうか。
ところで、mew-ssl-algorithm-priorityが機能していないことにも気付き
ました。引数誤りで値を渡せていないようです。
(gnutls-boot-parametersとgnutls-negotiateの引数は、gnutls-bootと
違ってpriorityではなくpriority-stringです)
--
木下達也
> これを仕様と考えるのは微妙なような気もしますが、
> Mew だけが独自にそれを回避してしまうと動作に一貫性がなくなるため、
mew-ssl-native-min-prime-bitsやmew-ssl-algorithm-priorityのように、
verify-errorの値nilも変数にしておくだけではどうでしょうか。
ところで、mew-ssl-algorithm-priorityが機能していないことにも気付き
ました。引数誤りで値を渡せていないようです。
(gnutls-boot-parametersとgnutls-negotiateの引数は、gnutls-bootと
違ってpriorityではなくpriority-stringです)
--
木下達也
Hiroki Sato
Feb 9, 2020, 11:11:09 AM2/9/20
to mew...@googlegroups.com
Tatsuya Kinoshita <ta...@vega.ocn.ne.jp> wrote
in <20200209.233005.1806911736007404143.tats%nob...@tats.iris.ne.jp>:
ta> On February 9, 2020 at 5:14AM +0900, hrs (at allbsd.org) wrote:
ta> > これを仕様と考えるのは微妙なような気もしますが、
ta> > Mew だけが独自にそれを回避してしまうと動作に一貫性がなくなるため、
ta>
ta> mew-ssl-native-min-prime-bitsやmew-ssl-algorithm-priorityのように、
ta> verify-errorの値nilも変数にしておくだけではどうでしょうか。
mew-ssl-verify-error を追加しました。また、prime-bits は
mew-ssl-min-prime-bits に名前を短縮しました。
ただ、priority strings と trustfiles 以外の TLS パラメータは、
ユーザから直接設定されることを想定していませんので、
今後ばっさり消すかも知れません。
ta> ところで、mew-ssl-algorithm-priorityが機能していないことにも気付き
ta> ました。引数誤りで値を渡せていないようです。
ta> (gnutls-boot-parametersとgnutls-negotiateの引数は、gnutls-bootと
ta> 違ってpriorityではなくpriority-stringです)
おっと、こちらは書き間違えですね。修正しました。
どうもありがとうございます。
-- Hiroki
in <20200209.233005.1806911736007404143.tats%nob...@tats.iris.ne.jp>:
ta> On February 9, 2020 at 5:14AM +0900, hrs (at allbsd.org) wrote:
ta> > これを仕様と考えるのは微妙なような気もしますが、
ta> > Mew だけが独自にそれを回避してしまうと動作に一貫性がなくなるため、
ta>
ta> mew-ssl-native-min-prime-bitsやmew-ssl-algorithm-priorityのように、
ta> verify-errorの値nilも変数にしておくだけではどうでしょうか。
mew-ssl-verify-error を追加しました。また、prime-bits は
mew-ssl-min-prime-bits に名前を短縮しました。
ただ、priority strings と trustfiles 以外の TLS パラメータは、
ユーザから直接設定されることを想定していませんので、
今後ばっさり消すかも知れません。
ta> ところで、mew-ssl-algorithm-priorityが機能していないことにも気付き
ta> ました。引数誤りで値を渡せていないようです。
ta> (gnutls-boot-parametersとgnutls-negotiateの引数は、gnutls-bootと
ta> 違ってpriorityではなくpriority-stringです)
おっと、こちらは書き間違えですね。修正しました。
どうもありがとうございます。
-- Hiroki
Tatsuya Kinoshita
Feb 10, 2020, 6:47:17 AM2/10/20
to mew...@googlegroups.com
On February 10, 2020 at 1:10AM +0900, hrs (at allbsd.org) wrote:
> ta> (gnutls-boot-parametersとgnutls-negotiateの引数は、gnutls-bootと
> ta> 違ってpriorityではなくpriority-stringです)
>
> おっと、こちらは書き間違えですね。修正しました。
まだgnutls-negotiateには効いていないようです。
> ta> (gnutls-boot-parametersとgnutls-negotiateの引数は、gnutls-bootと
> ta> 違ってpriorityではなくpriority-stringです)
>
> おっと、こちらは書き間違えですね。修正しました。
make-network-processやopen-network-streamのための値を流用したようで
すが、gnutls-boot-parametersを通すとpriority-stringがpriorityに変わっ
たりtypeが失われたりするので、gnutls-negotiateには向きません。
gnutls-boot-parametersに渡す前のリストをそのまま使うと、とりあえず
動作するようになります。
```
--- a/mew-smtp.el
+++ b/mew-smtp.el
@@ -447,7 +447,7 @@
(setq network-security-level 'low))
(setq tlsparams
(cons 'gnutls-x509pki
- (gnutls-boot-parameters
+ (list
:type 'gnutls-x509pki
:keylist (mew-ssl-client-keycert-list case)
:trustfiles (mew-ssl-trustfiles case)
```
ところで、対応バージョンはEmacs 26以降でしょうか。どこかで機能か
バージョンで弾く必要がありそうです。
--
木下達也
Hiroki Sato
Feb 10, 2020, 8:21:34 AM2/10/20
to mew...@googlegroups.com
Tatsuya Kinoshita <ta...@vega.ocn.ne.jp> wrote
in <20200210.204521.291298442451640554.tats%nob...@tats.iris.ne.jp>:
ta> On February 10, 2020 at 1:10AM +0900, hrs (at allbsd.org) wrote:
ta> > ta> (gnutls-boot-parametersとgnutls-negotiateの引数は、gnutls-bootと
ta> > ta> 違ってpriorityではなくpriority-stringです)
ta> >
ta> > おっと、こちらは書き間違えですね。修正しました。
ta>
ta> まだgnutls-negotiateには効いていないようです。
ta>
ta> make-network-processやopen-network-streamのための値を流用したようで
ta> すが、gnutls-boot-parametersを通すとpriority-stringがpriorityに変わっ
ta> たりtypeが失われたりするので、gnutls-negotiateには向きません。
ta>
ta> gnutls-boot-parametersに渡す前のリストをそのまま使うと、とりあえず
ta> 動作するようになります。
ta>
ta> ```
ta> --- a/mew-smtp.el
ta> +++ b/mew-smtp.el
ta> @@ -447,7 +447,7 @@
ta> (setq network-security-level 'low))
ta> (setq tlsparams
ta> (cons 'gnutls-x509pki
ta> - (gnutls-boot-parameters
ta> + (list
ta> :type 'gnutls-x509pki
ta> :keylist (mew-ssl-client-keycert-list case)
ta> :trustfiles (mew-ssl-trustfiles case)
ta> ```
ご指摘どうもです。返されるキーが違うことに気づいていませんでした。
場あたり的ですが、修正を入れました。関連する関数すべてで
gnutls-boot-parameters の結果が共通して使えるように
なっていないとおかしいので、これは Emacs 側のバグですね...
ta> ところで、対応バージョンはEmacs 26以降でしょうか。どこかで機能か
ta> バージョンで弾く必要がありそうです。
バージョンで区別するなら、GnuTLS をリンクしている
25.1 以降の Emacs でのみ使用できます。
現在のコードでは、mew-*-ssl を 'native にして、かつ
* gnutls-available-p が未定義 or nil
* nsm-level が未定義
のいずれかだった場合、接続時にエラーを出すようにしてあります。
25.1 より前のバージョンは、これで自動的に排除されます。
GnuTLS が使えるようになったのは 24.1 以降、NSM が入ったのは
25.1 以降です。
-- Hiroki
in <20200210.204521.291298442451640554.tats%nob...@tats.iris.ne.jp>:
ta> On February 10, 2020 at 1:10AM +0900, hrs (at allbsd.org) wrote:
ta> > ta> (gnutls-boot-parametersとgnutls-negotiateの引数は、gnutls-bootと
ta> > ta> 違ってpriorityではなくpriority-stringです)
ta> >
ta> > おっと、こちらは書き間違えですね。修正しました。
ta>
ta> まだgnutls-negotiateには効いていないようです。
ta>
ta> make-network-processやopen-network-streamのための値を流用したようで
ta> すが、gnutls-boot-parametersを通すとpriority-stringがpriorityに変わっ
ta> たりtypeが失われたりするので、gnutls-negotiateには向きません。
ta>
ta> gnutls-boot-parametersに渡す前のリストをそのまま使うと、とりあえず
ta> 動作するようになります。
ta>
ta> ```
ta> --- a/mew-smtp.el
ta> +++ b/mew-smtp.el
ta> @@ -447,7 +447,7 @@
ta> (setq network-security-level 'low))
ta> (setq tlsparams
ta> (cons 'gnutls-x509pki
ta> - (gnutls-boot-parameters
ta> + (list
ta> :type 'gnutls-x509pki
ta> :keylist (mew-ssl-client-keycert-list case)
ta> :trustfiles (mew-ssl-trustfiles case)
ta> ```
ご指摘どうもです。返されるキーが違うことに気づいていませんでした。
場あたり的ですが、修正を入れました。関連する関数すべてで
gnutls-boot-parameters の結果が共通して使えるように
なっていないとおかしいので、これは Emacs 側のバグですね...
ta> ところで、対応バージョンはEmacs 26以降でしょうか。どこかで機能か
ta> バージョンで弾く必要がありそうです。
バージョンで区別するなら、GnuTLS をリンクしている
25.1 以降の Emacs でのみ使用できます。
現在のコードでは、mew-*-ssl を 'native にして、かつ
* gnutls-available-p が未定義 or nil
* nsm-level が未定義
のいずれかだった場合、接続時にエラーを出すようにしてあります。
25.1 より前のバージョンは、これで自動的に排除されます。
GnuTLS が使えるようになったのは 24.1 以降、NSM が入ったのは
25.1 以降です。
-- Hiroki
Tatsuya Kinoshita
Feb 10, 2020, 8:48:59 AM2/10/20
to mew...@googlegroups.com
On February 10, 2020 at 10:19PM +0900, hrs (at allbsd.org) wrote:
> 場あたり的ですが、修正を入れました。関連する関数すべてで
> gnutls-boot-parameters の結果が共通して使えるように
> なっていないとおかしいので、これは Emacs 側のバグですね...
gnutls-boot-parametersの内容は、かつてはgnutls-negotiate内にあった
> 場あたり的ですが、修正を入れました。関連する関数すべてで
> gnutls-boot-parameters の結果が共通して使えるように
> なっていないとおかしいので、これは Emacs 側のバグですね...
もののようで、今ではgnutls-negotiate内から使っていますので、扱いづ
らさはともかく、意図したものだとは思います。
> * gnutls-available-p が未定義 or nil
> * nsm-level が未定義
>
> のいずれかだった場合、接続時にエラーを出すようにしてあります。
> 25.1 より前のバージョンは、これで自動的に排除されます。
はnilです。
--
木下達也
Hiroki Sato
Feb 10, 2020, 9:06:34 AM2/10/20
to mew...@googlegroups.com
Tatsuya Kinoshita <ta...@vega.ocn.ne.jp> wrote
in <20200210.224643.1300477537754142988.tats%nob...@tats.iris.ne.jp>:
ta> On February 10, 2020 at 10:19PM +0900, hrs (at allbsd.org) wrote:
ta> > 場あたり的ですが、修正を入れました。関連する関数すべてで
ta> > gnutls-boot-parameters の結果が共通して使えるように
ta> > なっていないとおかしいので、これは Emacs 側のバグですね...
ta>
ta> gnutls-boot-parametersの内容は、かつてはgnutls-negotiate内にあった
ta> もののようで、今ではgnutls-negotiate内から使っていますので、扱いづ
ta> らさはともかく、意図したものだとは思います。
ta>
ta> > * gnutls-available-p が未定義 or nil
ta> > * nsm-level が未定義
ta> >
ta> > のいずれかだった場合、接続時にエラーを出すようにしてあります。
ta> > 25.1 より前のバージョンは、これで自動的に排除されます。
ta>
ta> とりあえず、Emacs 25.1-25.3では(fboundp 'gnutls-boot-parameters)
ta> はnilです。
ありゃ、確認すると確かにそうですね。関数のチェックを追加しました。
26.1 以降の対応ということになります。
-- Hiroki
in <20200210.224643.1300477537754142988.tats%nob...@tats.iris.ne.jp>:
ta> On February 10, 2020 at 10:19PM +0900, hrs (at allbsd.org) wrote:
ta> > 場あたり的ですが、修正を入れました。関連する関数すべてで
ta> > gnutls-boot-parameters の結果が共通して使えるように
ta> > なっていないとおかしいので、これは Emacs 側のバグですね...
ta>
ta> gnutls-boot-parametersの内容は、かつてはgnutls-negotiate内にあった
ta> もののようで、今ではgnutls-negotiate内から使っていますので、扱いづ
ta> らさはともかく、意図したものだとは思います。
ta>
ta> > * gnutls-available-p が未定義 or nil
ta> > * nsm-level が未定義
ta> >
ta> > のいずれかだった場合、接続時にエラーを出すようにしてあります。
ta> > 25.1 より前のバージョンは、これで自動的に排除されます。
ta>
ta> とりあえず、Emacs 25.1-25.3では(fboundp 'gnutls-boot-parameters)
ta> はnilです。
ありゃ、確認すると確かにそうですね。関数のチェックを追加しました。
26.1 以降の対応ということになります。
-- Hiroki
Tatsuya Kinoshita
Jan 31, 2021, 8:25:36 AM1/31/21
to mew...@googlegroups.com, h...@allbsd.org
直近のSmtplog関連の修正によって、GnuTLS対応で少しコンフリクトが発生
していましたので、最新のmasterでrebaseして解消しておきました。
- https://github.com/tats/Mew/tree/feature/gnutls
(注: 都度最新版へrebase, force pushしています)
ところで、GnuTLS対応、XOAUTH2対応について、Debianのmew-betaパッケージ
ではexperimental supportとして先行適用しています。
- https://tracker.debian.org/news/1210004/accepted-mew-beta-705068020201202-2-source-into-unstable/
- https://tracker.debian.org/pkg/mew-beta
GnuTLS対応は、手元ではEmacs 27.1だとEmacs 28.0.50と比べて遅くなる
ことがあってやや不安定な感じです。
--
木下達也
していましたので、最新のmasterでrebaseして解消しておきました。
- https://github.com/tats/Mew/tree/feature/gnutls
(注: 都度最新版へrebase, force pushしています)
ところで、GnuTLS対応、XOAUTH2対応について、Debianのmew-betaパッケージ
ではexperimental supportとして先行適用しています。
- https://tracker.debian.org/news/1210004/accepted-mew-beta-705068020201202-2-source-into-unstable/
- https://tracker.debian.org/pkg/mew-beta
GnuTLS対応は、手元ではEmacs 27.1だとEmacs 28.0.50と比べて遅くなる
ことがあってやや不安定な感じです。
--
木下達也
Tatsuya Kinoshita
Feb 14, 2023, 6:57:56 AM2/14/23
to mew...@googlegroups.com, h...@allbsd.org, n...@quickhack.net
On 2021-01-31 at 22:24, Tatsuya Kinoshita wrote:
> - https://github.com/tats/Mew/tree/feature/gnutls
> (注: 都度最新版へrebase, force pushしています)
>
> ところで、GnuTLS対応、XOAUTH2対応について、Debianのmew-betaパッケージ
> ではexperimental supportとして先行適用しています。
>
> - https://tracker.debian.org/news/1210004/accepted-mew-beta-705068020201202-2-source-into-unstable/
> - https://tracker.debian.org/pkg/mew-beta
GnuTLS対応、XOAUTH2対応を最新版でrebaseして適用し直しました。
> - https://github.com/tats/Mew/tree/feature/gnutls
> (注: 都度最新版へrebase, force pushしています)
>
> ところで、GnuTLS対応、XOAUTH2対応について、Debianのmew-betaパッケージ
> ではexperimental supportとして先行適用しています。
>
> - https://tracker.debian.org/news/1210004/accepted-mew-beta-705068020201202-2-source-into-unstable/
> - https://tracker.debian.org/pkg/mew-beta
* https://github.com/tats/Mew/tree/feature/gnutls-xoauth2
- GnuTLS関連、auth-source関連のコミットをそれぞれまとめてfixup
- 00diffの更新を除外 (内容はコミットログへ反映)
- copyright yearの更新を除外 (Mew 6.9で更新済)
- XOAUTH2を未設定で使わないようデフォルト値から除外
--
木下達也
Kazu Yamamoto
Feb 14, 2023, 8:59:23 AM2/14/23
to ta...@vega.ocn.ne.jp, mew...@googlegroups.com, h...@allbsd.org, n...@quickhack.net
山本です。
>> ところで、GnuTLS対応、XOAUTH2対応について、Debianのmew-betaパッケージ
>> ではexperimental supportとして先行適用しています。
XOAUTH2に関しては、nomさんに会ったときに「早くマージして」と何回か言っ
たような気がするんですが、なぜ止まっているのかまったく覚えていませ
ん。。。
問題ないなら、PRを出してください。
--かず
>> ところで、GnuTLS対応、XOAUTH2対応について、Debianのmew-betaパッケージ
>> ではexperimental supportとして先行適用しています。
たような気がするんですが、なぜ止まっているのかまったく覚えていませ
ん。。。
問題ないなら、PRを出してください。
--かず
Yoshinari Nomura
Feb 14, 2023, 6:31:23 PM2/14/23
to ka...@iij.ad.jp, ta...@vega.ocn.ne.jp, mew...@googlegroups.com, h...@allbsd.org
乃村です．
ごめんなさい．今週中にもう一度確認して XOAUTH2 PR 出します．
こいつを rebase して出す予定です．
https://github.com/yoshinari-nomura/Mew/tree/mew-support-xoauth2
自身では毎日 Mew + XOAUTH2 使ってるので，コード自体はそこそこ
実用的だと思いますが，確か，使ってる JSON 周りの関数が Emacs 27
after だったのを26 対応に置き換えるのともう 1個設定ファイルの書
き方周りで木下さんに指摘いただいた件があった気がするので，確認し
ときます．
その他，おかしなところがあれば指摘いただければ幸いです．
# 今日は，この後 1日缶詰なイベントです．
ごめんなさい．今週中にもう一度確認して XOAUTH2 PR 出します．
こいつを rebase して出す予定です．
https://github.com/yoshinari-nomura/Mew/tree/mew-support-xoauth2
自身では毎日 Mew + XOAUTH2 使ってるので，コード自体はそこそこ
実用的だと思いますが，確か，使ってる JSON 周りの関数が Emacs 27
after だったのを26 対応に置き換えるのともう 1個設定ファイルの書
き方周りで木下さんに指摘いただいた件があった気がするので，確認し
ときます．
その他，おかしなところがあれば指摘いただければ幸いです．
# 今日は，この後 1日缶詰なイベントです．
Tatsuya Kinoshita
Feb 22, 2023, 7:20:24 AM2/22/23
to mew...@googlegroups.com, h...@allbsd.org
On 2023-02-14 at 20:56, Tatsuya Kinoshita wrote:
> GnuTLS対応、XOAUTH2対応を最新版でrebaseして適用し直しました。
> * https://github.com/tats/Mew/tree/feature/gnutls-xoauth2
XOAUTH2対応はmasterにマージされました。
> GnuTLS対応、XOAUTH2対応を最新版でrebaseして適用し直しました。
> * https://github.com/tats/Mew/tree/feature/gnutls-xoauth2
GnuTLS対応としては現時点で下記のブランチを残してあります。
- https://github.com/tats/Mew/tree/feature/gnutls (都度masterでrebase)
- https://github.com/tats/Mew/tree/feature/v6.9-gnutls (Mew 6.9でrebase)
--
木下達也
Kazu Yamamoto
Feb 24, 2023, 11:49:40 PM2/24/23
to ta...@vega.ocn.ne.jp, mew...@googlegroups.com, h...@allbsd.org
木下さん、
> GnuTLS対応としては現時点で下記のブランチを残してあります。
>
> - https://github.com/tats/Mew/tree/feature/gnutls (都度masterでrebase)
これ、マージ希望なら、PR を出してください。
--かず
> GnuTLS対応としては現時点で下記のブランチを残してあります。
>
> - https://github.com/tats/Mew/tree/feature/gnutls (都度masterでrebase)
--かず
Tatsuya Kinoshita
Feb 26, 2023, 7:51:59 AM2/26/23
to mew...@googlegroups.com, h...@allbsd.org, ka...@iij.ad.jp
On 2023-02-25 at 13:49, kazu (at iij.ad.jp) wrote:
> > - https://github.com/tats/Mew/tree/feature/gnutls (都度masterでrebase)
> これ、マージ希望なら、PR を出してください。
Pull requestにしておきました。
> > - https://github.com/tats/Mew/tree/feature/gnutls (都度masterでrebase)
> これ、マージ希望なら、PR を出してください。
- https://github.com/kazu-yamamoto/Mew/pull/175
コミットをまとめたりコンフリクト解消のため手を加えたりはしていますが、
基本的に佐藤さんの元のブランチをそのまま最新のmasterに移植した内容に
なっています。
- https://github.com/hrs-allbsd/Mew
`(setq mew-ssl-default 'native)`とすればstunnelからGnuTLSに切り替え
できます。デフォルト値は従来どおりstunnelを使うようになっています。
--
木下達也
Reply all
Reply to author
Forward
0 new messages