Operation Normal ?

【 2019年7月6日 追記 】

filezilla-3.43.0-2 以降からソースコードからビルドしたものが提供されるようになったため、このエントリーで書いた問題は発生しなくなりました。

----- 追記ここまで -----

［現象］

filezilla をインストールしている環境では、gnutls を利用しているソフト（例: corebird, jdim）で TLS 証明書に関するエラーが発生する可能性があります。

下図は Twitter クライアントの corebird での例ですが、「受け付けられない TLS 証明書です」というエラーが発生して Twitter に全くアクセスできなくなっています。

［原因］

filezilla パッケージによってインストールされる /usr/lib/libgnutls.so.30 と、lib64gnutls30 パッケージによってインストールされている /usr/lib64/libgnutls.so.30 がコンフリクトするためです。

［対策］

以下のいずれかの方法で問題を回避できます。

• filezilla パッケージを削除する。
• filezilla パッケージによってインストールされた /usr/lib/libgnutls.so.30 を削除する。（これが無くても filezilla は正常に動作します。間違っても /usr/lib64/libgnutls.so.30 の方を削除しないこと！）
• 自前で filezilla をソースコードからビルドする。

［経緯＆考察＆愚痴］

冒頭で書いた corebird のエラーに、一昨日の夜に気が付きました。普段は wine 経由で Saezuri を使用しているので何時からこのエラーが発生していたのかは不明です。で、TLS 証明書絡みのエラーと言えば 先のエントリー で書いた JDim でも発生していたので、根本原因を突き止めるべく、仮想環境に新たに PCLinuxOS をインストールして調べてみました。

まず、インストール直後の環境では問題は発生しないことを確認。そこから私が日頃使っているアプリを一つ一つインストールしては問題が発生していないかを確認しながら環境を整えて行きました。結果、かなり時間がかかりましたが filezilla が原因であることを突き止めました。

ソースパッケージを調べるまで知らなかったのですが、PCLinuxOS の filezilla パッケージはソースコードからビルドしているのではなくて、開発元が 64bit Linux 用として配布している tar 玉を引っ張ってきてそのまま /usr 下に展開しています。それ故、tar 玉に同梱されている libgnutls.so.30 が /usr/lib 下に配置されることとなり、問題を引き起こす原因になりました。

さらに、filezilla パッケージでは後処理部分の %post が存在せず ldconfig コマンドが実行されない為、filezilla だけをインストールした直後には問題が発覚せず、その後に ldconfig を実行するパッケージをインストールした段階で初めて問題が表面化するという時限爆弾のオマケ付きです。

実際、上記の仮想環境での調査過程でも filezilla のインストール直後には気付かず、その後に幾つかのパッケージをインストールした段階で初めて問題が発覚したので、発覚直前にインストールした他のパッケージが原因ではないかと最初は疑ってしまいました。

なお、filezilla をインストールすると libgnutls.so.30 以外にも libgmp.so.10 , libhogweed.so.4 , libnettle.so.6 が /usr/lib 下に配置されますが、これらと同名のライブラリが lib64gmp10 と lib64nettle6 のパッケージがインストールされている環境では /usr/lib64 下に存在しており、libgnutls.so.30 と同様にコンフリクトする状態となります。これがどのような問題を引き起こすのか、あるいは起こさないのかは不明ですが、予防措置として私はこれらのファイルも削除しました。（削除しても filezilla は問題なく動作しています）

また、JDim で TLS 証明書のエラーが出た時には filezilla パッケージが原因だとは夢にも考えていなかったので、JDim 側の問題ではないのにもかかわらず、JDim の開発者のお一人の ma8ma さんには --with-default-trust-store-file オプションの追加 という労力を強いることになってしまったことを心より深くお詫び致します。

PCLinuxOS では filezilla の他にも Firefox や LibreOffice などのようにビルドに大きなリソースを要するパッケージではソースコードからのビルドは行なわずに、開発元が配布しているバイナリーな tar 玉を利用しています。開発にかかわる人的リソースが少ない零細ディストリビューションではそれも有りかなと個人的には思っています。

ただしそれは「他の部分に無用な影響を及ぼさにように配慮した上で」という前提条件付きなはずです。今回の filezilla に関して言えば、tar 玉の展開先を /usr ではなくて /usr/local にしておけば、あるいはライブラリのコンフリクトについてもう少しだけ配慮してもらえていたら問題は発生しなかったはずで非常に残念です。