KeePassXC の Debian 管理者、すべてのネットワーク機能を削除

(fosstodon.org/@keepassxc)

1 ポイント投稿者 GN⁺ 2024-05-12 | 1件のコメント | WhatsAppで共有

Debian の keepassxc パッケージが最小機能パッケージに変更されると、従来の機能を維持したいユーザーは keepassxc-full へ移行する必要がある
削除範囲はネットワーク機能にとどまらず、YubiKey、auto-type、ブラウザ統合、SSH agent、FDO secrets、favicon ダウンロード、HIBP まで含まれる
Debian パッケージの説明では、基本の keepassxc は “bare minimal functionality” のみを提供し、ネットワーク機能・SSH agent・ブラウザプラグイン・FDO secret storage をセキュリティ上の複雑性に分類している
変更の告知は NEWS.Debian.gz と apt-listchanges を通じて行われ、stable ユーザーはリリースノートを確認する必要がある
パッケージ名と移行方法はまだ調整の余地があり、Trixie 以降は apt install keepassxc が2つの選択肢を表示する案が言及されている

Debian `keepassxc` パッケージの変更

Team KeePassXC は Debian ユーザーに対し、keepassxc パッケージ管理者が機能を大幅に削除しようとしていると告知
変更が testing/sid の外へ反映されると、従来の機能が必要なユーザーは keepassxc-full へ移行する必要がある
Debian のバグレポートではネットワーク機能の無効化のように見えるが、Team KeePassXC は実際の変更はネットワーク機能を超えた全面的な機能削除に近いと反論している

削除される機能の範囲

Team KeePassXC が明らかにした削除対象は次のとおり
- YubiKey
- auto-type
- ブラウザ統合
- SSH agent
- FDO secrets
- ネットワーク機能
- favicon ダウンロード
- HIBP

Debian パッケージの説明と根拠

Debian sid の keepassxc パッケージ説明では、基本パッケージは最小限の機能だけを含むと案内している
同説明では、ネットワーク機能、SSH agent、ブラウザプラグイン、FDO secret storage をセキュリティ上の複雑性と見なし、必要であれば keepassxc-full を使うよう案内している
関連する Debian バグレポートとして #953529 - keepassxc: Compiling with disable networking support が共有されている

Debian 管理者の立場

Debian 管理者は、予期しない変更を確認する最初の場所として /usr/share/doc/<package>/NEWS.Debian.gz を挙げている
testing/unstable ユーザーは apt-listchanges がインストールされていれば変更点を自動的に確認でき、stable ユーザーはリリースノートを読む必要がある
この決定は1年間議論されており、xz-utils 事件以降、デフォルトで含めるコードをできるだけ減らす方向に傾いたと説明している
管理者は Debian、KeePassXC、多機能なパスワードマネージャーを同時に求めるユーザー層が大きく重なるとは見ていない
ローカル専用のパスワードマネージャーに「穴」を開けるのは筋が通らないと表現している

upstream と downstream のコミュニケーション問題

あるユーザーは、議論に長い時間がかかっていたにもかかわらず、upstream 開発者が完全に驚いているように見える点を問題視した
Debian 管理者は、これは Debian プロジェクト内部の問題であり、IRC で他の Debian 開発者に意見を求めたと答えた
upstream の立場はすでに把握しており、upstream は数年前に IRC を離れていて、新バージョンのパッケージングだけでも余力が不足していると説明した
Team KeePassXC と一部ユーザーは、downstream の決定によって upstream にバグレポートと混乱が集中する可能性を懸念している

パッケージ名と移行の方向性

複数のユーザーは、基本の keepassxc を最小機能パッケージに変えるより、keepassxc-minimal や keepassxc-light のような名前を使い、従来の keepassxc は全機能を維持するほうが混乱が少ないと提案した
ある提案は次の構成だった
- keepassxc-light
- keepassxc-full
- keepassxc は keepassxc-full に依存する移行パッケージ
- NEWS.Debian で変更を説明
Debian 管理者は、名称変更は ftpteam の承認にかかっており、Trixie の移行パッケージの方向性としてはその提案が最善かもしれないと答えた
Trixie 以降は移行パッケージをなくし、apt install keepassxc が2つの選択肢を表示するようにする案も言及されている

1件のコメント

GN⁺ 2024-05-12

Hacker News のコメント

アップストリームがソフトウェアに入れている機能を大幅に削除したうえで同じ名前で配布するのは、よく見ても疑わしい
その方向でやりたいなら別名のフォークとして配布すべきで、そうすればアップストリームがユーザーからの問題報告に悩まされ続けることもない
以前 Debian の Chromium メンテナーが拡張機能のインストール機能を一方的に無効化し、結局そのパッチが差し戻された件を思い出す
さらにずっと前、Debian がネットワークカードにバイナリファームウェアをロードするカーネルインターフェースを削除して、自分のネットワークが壊れたことも思い出す
- 実際にやったことは XC_ALL ビルドパラメータを OFF に変更しただけで [0]、この値はアップストリームの CMakeLists.txt のデフォルト値でもある 1
  アップストリームがこの機能をそれほど重要だと考えているなら、まずデフォルト値を直すべき
  アップグレード後に機能が止まってユーザーが混乱する可能性はあるが、サフィックスのないパッケージがアップストリームのデフォルト値と一致していること自体は、かなり合理的
  
  [0] https://salsa.debian.org/debian/keepassxc/-/commit/7d6d16e3f...
  1 https://github.com/keepassxreboot/keepassxc/blob/develop/CMa...
- メンテナーの役割は、アップストリームをコピーして貼り付ける以上のもの
  ディストリビューションのエンドユーザーにとって何が適切かを判断する権限がある
  この場合は妥当なセキュリティ上の根拠があるように見えるし、代替パッケージも提供されている
- Debian はアップストリームを無視する奇妙な態度を持つ唯一のディストリビューションのように思える
  自分が管理しているアップストリームプロジェクト2つでも、Debian が一方的にパッケージ名を変更した
  1つはかなり後になって知ったし、もう1つは自分が明確に反対したにもかかわらず、まったく筋の通らない形で進められた
  結局ユーザーに説明しなければならないのは自分
  
  追記: ここで Debian 側の Julian の傲慢さを見ればいい: https://github.com/keepassxreboot/keepassxc/issues/10725#iss... — 自分が言っているのはこういうこと
- アップストリームが作ったものを「えぐり取った」わけではない
  プラグインなしのバージョンを配布し、プラグイン入りの -full 版を作ったということ
  プラグインがデフォルトで挿さっているなら、それはプラグインではなく組み込み機能であり、このやり方が正しい
- Apple が「セキュリティ上より良いと思うのであなたのアプリを修正した」と言ったら、人々は松明と熊手を持って出てきただろう
  ところが deb メンテナーがやると論争の対象になる
  セキュリティ問題があるなら、安全でないバージョンはそもそも提供されるべきではないが、今回の場合はそれでもない
  App Store のような世界では、メンテナーの役割は変わるべき
  やるべきことはソフトウェアをディストリビューション上で動くようにすることであって、名前は維持したまま自分の好みで擬似フォークを作ることではない
かなり合理的な判断に見える
ネットワーク機能とブラウザ統合は、大きな潜在的な穴であり攻撃の入口でもある
ネットワーク関連機能なしに信頼しているデータベースだけを実行するなら、脆弱性が見つかってもそのツールを悪用するのはほぼ不可能であるべきで、パスワードマネージャーのような重要なツールには非常に望ましい特性
元のメンテナーも同意している 1
ネットワークが有効なフルパッケージも Debian にあるので、望むユーザーは apt install keepassxc-full するだけで全ネットワーク機能を使える
ただし、アップストリームを “crappy”[0] と呼ぶのはパッケージメンテナーとして建設的な態度ではないし、パッケージ名も keepassxc と keepassxc-full よりは keepassxc-lite と keepassxc-full のほうが Debian ユーザーには分かりやすかっただろう

[0] https://github.com/keepassxreboot/keepassxc/issues/10725#iss...

1 https://github.com/keepassxreboot/keepassxc/issues/10725#iss...
- 多くのものは大きな潜在的な穴であり攻撃の入口であると同時に、有用でもある
  「有用であること」はセキュリティを高めうる
  パスワードマネージャーが使いにくければ、人々は使うのをやめてしまうから
  もう少し見てみると、クリップボードの使用がブラウザ統合より必ず安全なのかも不明
  コピー＆ペーストのミスだけでも、ブラウザ統合のセキュリティ負担のかなりの部分を相殺しうる
  ずっと前に大企業で契約業務をしたことがあるが、アカウントマネージャーたちのノートPCにはディスク暗号化パスワード、Windows ログインパスワード、AD ログインパスワードがあり、すべて異なる必要があり、数か月ごとに変更しなければならず、複雑さの要件も厳しかった
  自分が見たすべてのノートPCには例外なく、3つのパスワードを書いた付箋が貼られていた
  要点は、架空のセキュリティオタク的セキュリティは現実世界のセキュリティと同じではないということ
  少なくとも常に同じではなく、ここには現実的なトレードオフが必要

本来そうすべきではなかったが、会社のITシステムを通すと官僚主義のせいで時間がかかりすぎ、こちらのほうがずっと速くて簡単だった。
そういうタイプの会社だった。
これ自体も当然「セキュリティリスク」だった。機密性の高い会社データが入ったノートPCを、コンピュータ店の任意の技術者が触るのは本来おかしいからだ。
ただ、守るべきものがそれほど多かったわけではないと思う。売上や顧客数程度で、ごく限られた人にしか役立たない情報だった。

ブラウザ統合には、手動のコピー＆ペーストよりセキュリティを高める面が1つある。
ブラウザ拡張は認証情報を入力する前にページのURLを確認するが、手動コピー＆ペーストはタイプミスしたドメインや同形文字によるフィッシングに弱い。
ネットワーク機能とブラウザ統合が大きな潜在的な穴であることには同意するが、GitHub Issue の参加者たちが言っていたように、完全ビルドに比べて縮小ビルドのテストがほとんどなく、任意のビルドフラグの組み合わせはまったくテストされていない点が重要だ。
他の場所でも出ていたように、無効化された「選択」フラグの1つが YubiKey サポートで、そのせいで新しく壊れたパッケージにアップグレードしたユーザーがパスワードマネージャーから締め出されている。
そのフラグ1つを戻すだけでも、実際には誰もテストしていない状態になる。
既存ユーザーを keepassxc-full に移したという前提なら、keepassxc-lite という名前なら問題を防げただろうという点には同意する。
だが、まさにそこが核心だ。
最も安全な解をデフォルトにするのは合理的だが、メンテナーはアップストリームやユーザーが望まない限り既存機能を壊すべきではないし、特にユーザーをパスワードマネージャーから締め出してはならない。
GitHub に「crappy」と投稿したのはあまりに無礼で、自分が Debian を使っていたなら利用を考え直しただろう。
パッケージがそんなにひどい機能でいっぱいなら、なぜわざわざメンテナンスしているのか分からない。
いっそ削除して、ユーザーが正しくインストールする方法を自分で探すようにしたほうがいい。
KeePassXC の開発者たちが気の毒だ。オープンソースプロジェクトの維持だけでも大変なのに、こんなことまで背負わされている。
crappyという表現を見た瞬間、julian-klode への敬意はすぐに消えた。
drawks が提案した解決策は、明らかに正しい選択に見える:

適切な解決策はおそらく、このソフトウェアの「-full」と「-minimal」の両バージョンをパッケージ化し、Debian パッケージのメタデータフィールドで2つのパッケージ間に Conflicts 関係を定義し、どちらも keepassxc を Provides するようタグ付けし、-full ビルドには Replaces: keepassxc タグも追加することだろう。そうすれば、パッケージのアップグレード中に既存ユーザーはアップグレード／置換されるパッケージの機能を引き続き提供するバージョンを受け取り、新規ユーザーはインストールするバージョンを自分で選べる。

https://github.com/keepassxreboot/keepassxc/issues/10725#iss...

なぜこれが明白な選択肢ではない可能性があるのか分からない。
- メンテナーには自分の見解があり、明示的にデフォルトを変えたいと思っていたからだ。
- それは明白な選択であるだけでなく、実際の Debian でまさにその通り起きた: https://salsa.debian.org/debian/keepassxc/-/commit/7d6d16e3f...
  
  元の記事は、単によくないクリックベイトだ。
  何も削除されておらず、keepassxc-full パッケージに移されただけだ。
一方 Arch 側では、おそらくユーザー層ではかなり一般的にインストールされているfwupd パッケージが、ひっそり passim に依存するよう設定され、passim は明示的なユーザー同意なしに 0.0.0.0:275001 で開いたWebサーバーを立ち上げる。
しかも passim は、穴の多さがスイスチーズ以上として有名な GnuTLS を使っている 2。
本当にあり得ないと思うし、チェーンのどこかに xz 型のエクスプロイトが潜んでいても驚かない気がする。
- わざわざ fwupd を探すまでもない。
  どこにでもある systemd-resolved は、要求時に5355番ポートで LLMNR サーバー、つまり mDNS とも呼ばれ、昔の Microsoft NetBIOS 系列にあたるものを開くことができる。
  IoT のせいで誰もが私の LAN にアクセスできる時代になり、今や Linux もその混乱に加わらせようとしている。
  
  fwupd の修正は、デフォルト設定ファイルの品質が低く、コメントアウトされたデフォルト値もないので、こうすればいい:
```
# /etc/fwupd/fwupd.conf  
[fwupd]  
P2pPolicy=none  
```
  resolved の修正は /etc/systemd/resolved.conf で LLMNR=no とコメントアウトされており、おそらく DNSStubListener=no も望むだろう。
  まともなデフォルト値はこうだ:
```
# /etc/systemd/resolved.conf  
[Resolve]  
DNS=9.9.9.9#dns.quad9.net 149.112.112.112#dns.quad9.net 2620:fe::fe#dns.quad9.net 2620:fe::9#dns.quad9.net  
FallbackDNS=127.0.0.1 ::1  
Domains=~.  
DNSOverTLS=yes  
LLMNR=no  
DNSStubListener=no  
```
- 知っておくとよい。
  これは別記事として投稿されてもよさそうだ。
パッケージ管理者は最小驚きの原則に従って動くべきで、文書化された、あるいは少なくとももっともらしいリスクがない限り、コア機能を無効化すべきではないと思う。
このコメント欄では「プラグイン」という言葉が現時点で25回出てくるが、ここで話しているのはプラグインではない。
KeePassXCには機能が多いが、明示的なユーザー操作なしにそれ自体が脆弱性の有力な発生源になりそうなものは見当たらない。
ブラウザ統合は設定する前にまず有効化する必要があり、このフラグで無効化された他の機能もおそらく同様なので、-minimal パッケージのほうが適切だったはずだ。
不確実な将来にこの変更で恩恵を受けるごく少数のユーザーより、ブラウザ統合を使っていた人たちに生じる深刻な不便のほうがはるかに大きい。
ブラウザ統合は一般に、クリップボードアクセスよりずっと安全な機能でもある。
プロジェクトのビジョンとも合っていないように見える:

誰でも使える一方で、必要とする人には高度な機能も提供するアプリケーションを作ることが目標である。
既存ユーザーを壊さずにこの区分を作ることはできたのだから、Debianパッケージ管理者の悪い判断以外には見えにくい。
ネットワーク機能なしの KeepassXC を使えるのは確かに良いことだが、ブラウザ統合をニッチな機能と見るのはひどく現実離れしている。
今 Debian で KeepassXC を使っているユーザーの半数以上、おそらくはるかに多くが、今回のやり方によって予告なく無効化される機能を望んでいる、というほうに賭けてもいい。
結局、決定権は彼らにあるが、それが良い判断だという意味ではなく、私はそうは思わない。
KeePassXC 管理者の発言:

このスレッドが始まるまでに、この新しいパッケージング方式が人々のワークフローを壊したという報告を3件受けていた。1件は yubikey 機能が削除されたため、もはやデータベースを開けなくなったユーザーだった。少し考えてみてほしい。最も重要な秘密にアクセスできなくなった人は、パニック状態で時に非合理的な行動を取ることがある。

https://github.com/keepassxreboot/keepassxc/issues/10725#iss...
- オフラインのパスワードマネージャーを使っていてバックアップがないなら、すべてを失ったものと見なしてよい。
  これは感情的な脅しのように聞こえる。
  ハードウェア故障、OSを壊すアップデート、間違ったドライブへの dd 使用などで、どれだけすべてを失ってきたか分からない。
ダウンストリームの管理者がアップストリームプロジェクトの意図と異なる形でパッケージを変更するなら、別の名前で配布し、その修正版によって生じるすべてのバグ報告を自分で処理すべきだと思う。
- デフォルトビルドではネットワーキングは OFF である。
  Yubikey、ブラウザ統合なども同様である。
  
  -DWITH_XC_NETWORKING=[ON|OFF] Enable/Disable Networking support (e.g., favicon downloading) (default: OFF)
  
  https://github.com/keepassxreboot/keepassxc/blob/develop/INS...
- WITH_XC_NETWORKING ビルドオプションはデフォルトでオフなので、開発者たちがこの構成を有効なビルド設定として意図しているのは明らかだ。
- 通常はあまり守られていないことは分かっているが、本来の基本的な流れはそうなっている。
  ディストリビューション提供のパッケージを使っていてバグに遭遇したら、そのディストリビューションのパッケージにバグを報告し、管理者が調べたうえでアップストリーム由来のバグであればアップストリームプロジェクトに上げる、という形であるべきだ。
  この方式が有用な理由は、1. パッケージ管理者はそのパッケージに慣れているため初期の分類と分析ができ、アップストリームに行く前にその場で直せる場合もあること、2. 述べたとおりディストリビューションのパッケージはしばしばパッチを含むため、管理者が問題がパッケージングにあるのかアップストリームのソースにあるのかを確認する必要があることだ。
  残念ながら、多くのユーザーはまずアップストリームに報告する。
  だから現実的には心配するに値するが、本来はそうであってはならない。
- あるいは、エンドユーザーにサポートされていないパッケージであることを示すべきだ。
  たとえば KeePassXC-Debian や KeePassXC-Unsupported のように見せ、About から開発者の連絡先やウェブサイトを外して Debian のサポート情報に置き換える、といった形だ。
  OSに合わせるためのダウンストリームの小さな変更は問題ない。
  しかしアプリを変更してコア機能を削除し、アップストリーム開発者に大量の苦情が行くようにするのは問題だ。
- リンク先の200字程度の記事すら読まずに、なぜコメントしているのか分からない。
  管理者は keepassxc-full パッケージでネットワーク関連を含むすべてのプラグインを有効にし、keepassxc パッケージにははるかに良いセキュリティ態勢を持つ基本機能だけを入れるようにした。
  これは明らかに完全に問題なく、管理者の権限の範囲内である。
  不満の全体は、これが変更であるという点にある。
関心のある人にとっては、GitHub のこの Issue に最新のコメントが含まれているようだ。

https://github.com/keepassxreboot/keepassxc/issues/10725
- Debian 管理者 Julian Klode の見解はかなり刺々しい:
  
  残念ながら、そうはなりません。デフォルトで全プラグインをビルドして配布したのは誤りでした。ユーザーが読むべき NEWS ファイルを腹立たしいほど読まないため、1年ほどは苦痛が続くでしょうが、できることはほとんどありません。
  
  ユーザーに可能な限り最も安全な選択肢をデフォルトで提供することが、私たちの責任です。これらの機能はすべて不要であり、ローカルのパスワードデータベース管理ツールには実際には属しません。このような開発の方向性はすべて完全に間違っています。
  
  このゴミが必要なユーザーはゴミ版をインストールできますが、当然ながら、それは通りすがりのコントリビューターによる攻撃のリスクを高めます。
タイトルが間違っている。
元の記事は、管理者がネットワーク機能だけでなくすべての機能を削除したと述べており、実際にすべてのオプション機能、完全にオフラインの機能までビルド時にオフにされたため、その表現は正しかった。