入力操作の統一、ARMのインストール対応、プラグインのセキュリティ修正

01キーボード配列と入力エンジンの操作を統一

dhhは10月10日、omacom/omarchy#14433をquattroにマージしました。この変更により、インストーラーでのキーボード選択が入力エンジンの設定と連動し、Typingメニューからキーボード配列と入力方式をその場で選べるようになりました。Super+Iで配列と文字入力エンジンをまとめて順に切り替え、Super+Shift+Iで逆順に切り替えられます。いずれも開発ブランチでの変更です。

greptile-apps[bot]のレビューでは、テキスト欄にフォーカスがないとショートカットでの選択が失われる問題と、フォントの書き込みに失敗すると保存済みの入力方式とメニューのチェック表示が食い違う問題が見つかりました。dhhは、フォーカスがなくても選択を保持し、フォントの書き込みに失敗した場合は以前の入力グループに戻す修正を報告しています。これらの修正はomacom/omarchy#14433:discussion_r4237897756とomacom/omarchy#14433:discussion_r4239436913に記録されています。

xdangerは、Shiftで中国語入力を解除し、日本語と韓国語の入力エンジンでも同様に動作させることを提案しました。dhhは、Caps LockとShiftの動作について後続の変更で対応することに同意しました。この提案は、マージ済みの入力操作の変更とは別のものです。提案と応答はomacom/omarchy#14433:issuecomment-6098200521とomacom/omarchy#14433:issuecomment-6098373295に記録されています。

02ランタイムの統合とインストール確認でARM対応が前進

ryanrhughesは10月10日、NVIDIA N1xのランタイム対応とaarch64のISOを提案しました。その後、両提案は本号の対象期間を過ぎた10月15日にquattroへマージされました。該当するのはomacom/omarchy#14820とomacom/omarchy-iso#251です。現在の説明には、N1x、Snapdragon、GB10へのより広範な対応が含まれていますが、後から更新された説明を、提案当初の範囲として読むべきではありません。

10月10日には、omarchybotによるMac対応の統合コミットもquattroに入り、プラットフォームに応じたセットアップと起動ライフサイクルの統合が導入されました。この統合はomacom/omarchy@e1b0e5e9bb72に記録されています。これとは別に、Emir Beganovic名義で、記録上の参加者にemirbも含まれるISOのコミットでは、汎用aarch64環境の無人インストールと起動のチェックが追加されました。また、汎用カーネルではzstd圧縮のsquashfsを読み込めなかったため、ライブ環境のルートファイルシステムの圧縮方式がlz4に変更されました。

ryanrhughesは、インストール先にArch Linux ARMのキーリングを配置し、それを使って署名を検証する変更もコミットしました。これは、インストール後に初めてオンラインでパッケージを操作する際、署名付きパッケージが拒否される問題への対処です。修正はomacom/omarchy-iso@2487d3b1cb7eに記録されています。これらのコミットと開発ブランチへのマージは、ARM向け安定版のリリースを意味するものではありません。

03Qt 6.12でのプラグイン不具合に、パッケージとシェルの両面で回避策

outfoxxedは、Qt 6.12の型名の競合でプラグインに問題が生じることへの暫定的なQuickshellパッチを提案し、ryanrhughesがパッケージリポジトリのmasterブランチにマージしました。その後、github-actions[bot]は、x86_64とaarch64の両方でquickshell 0.3.2-3がedgeに公開されたと報告しました。マージと公開はomacom/omarchy-pkgs#935とomacom/omarchy-pkgs#935:issuecomment-6096470146で確認できます。

outfoxxedは、対になるシェル側の変更もomacom/omarchy#14845を通じてquattroにマージしました。この変更ではQtQuickのインポートに回避策を適用し、バージョン6.11を指定してインポートすることでColor型の重複を避けています。edgeでのパッケージ公開と、開発ブランチでのシェル変更を組み合わせた対応です。

04周辺機器を承認できず操作不能になる報告と、承認機能を取り消す提案

gavrixは、KVMとして使用していたDell製モニター経由のキーボードとマウスがどちらもUSBGuardにブロックされ、承認に使える入力機器がなくなったと報告しました。復旧にはスナップショットから起動してUSBGuardを無効にする必要があったとのことです。利用者への影響はomacom/omarchy#11874:issuecomment-6102552400に記録されています。

omarchybotは10月10日遅く、USBとThunderboltの認可機能を取り消すため、omacom/omarchy#14938を作成しました。現在の説明には、導入済みの強制制御や起動制限を解除する移行処理も含まれています。ソースを削除するだけでは、承認の操作手段を失ったまま保護機能が有効であり続けるためです。omarchybotによる当日の検証報告では、使い捨てのワーカー環境でのチェックが説明される一方、実機のThunderboltファームウェアの復元は未検証だと明記されていました。

この取り消し提案は、対象期間外の10月12日にマージされずにクローズされました。したがって、現在の状態から、提案された機能削除がquattroに入ったとは確認できません。

05ロック状態が残り、次の画面ロックができなくなる問題

現在もオープンのomacom/omarchy#14816は、dsundtが10月10日に作成しました。当日の追加報告でdsundtは、検証したマシンではロックを解除するたびにシェルがロック中だと認識したままになり、次のロック要求が無反応になると述べています。回避策として報告されたのはシェルの再起動でした。omacom/omarchy#14816:issuecomment-6100203282には、後から編集されたIssue本文とは独立した形で、この観察結果が残っています。

scottadairは別のノートPCでも同じ状態を報告し、ふたを閉じて2回サスペンドしても安全にロックされず、手動ロックも機能しなかったと述べています。rafalyovsonは、この報告を既存のQuickshellの調査や複数の修正案と関連付け、検証時点で最新のedgeビルドでも再現したと報告しました。これらは貢献者による報告と原因分析であり、修正がマージされたことを示すものではありません。経緯はomacom/omarchy#14816:issuecomment-6097484047とomacom/omarchy#14816:issuecomment-6099485761に記録されています。

06小容量USB向けネットワークインストール案、保守負担を理由にクローズ

Tsurgcomはomacom/omarchy-iso#256で、公称4 GBのUSBメモリーに収まるネットワークインストール用メディアを提案しました。作者によると、同梱のパッケージミラーを省くことで、イメージは約1.41 GiBになったとのことです。オフラインでのインストールができなくなる代わりに、利用可能なインターネット接続を必須とする方式です。

実動テストでは、キーリングの初期データ配置とWi-Fiスキャン結果の解析に不具合が見つかりました。Tsurgcomは、それらを修正した後、キーリングの初期データに誤って含まれていたエージェントのソケットも取り除いたと報告しました。omacom/omarchy-iso#256:issuecomment-6101577594にある作者のテスト報告によると、その後に再ビルドしたイメージでは、無人のネットワークインストールと再起動が完了し、失敗したユニットもなかったとのことです。

dhhは、既存ISOの保守負担を理由に新たなインストール方式の追加を見送りましたが、独立して保守する余地は残しました。この提案は10月10日、マージされずにクローズされました。判断はomacom/omarchy-iso#256:issuecomment-6103168854に記録されています。

07Piphone、端末へのアクセスと操作対象アプリの制限を修正して掲載

areu01or00が申請したPiphoneは、WebDriverAgentとPi拡張機能を使い、OmarchyのウィジェットとパネルからiPhoneを操作できるようにするものです。github-actions[bot]は、メンテナーのレビューを経て、検証済みスナップショットとしてマーケットプレイスに公開されたと報告しました。公開はomacom/omarchy-plugin-marketplace#10915:issuecomment-6098503193に記録されています。

HANCORE-linuxのレビューでは、端末操作用エンドポイントにローカルから認証なしでアクセスできる問題と、非公開のプロファイルが露出する問題が指摘されました。areu01or00は、直接アクセスするエンドポイントを所有者だけが利用できるUnixソケットに置き換え、プロファイルの扱いを厳格化し、基盤となるトンネルを専用のネットワーク名前空間に隔離しました。その後の修正では、操作前に実際に前面にあるアプリを確認し、承認を送信した後にも再確認するようにしました。また、対象アプリが許可範囲から外れた場合は監視処理を停止するようにしています。

HANCORE-linuxは、エンドポイント、プロファイル、トンネル、操作対象アプリの範囲に関する修正をレビューのうえ受け入れました。一方で、ローカルビルド、署名済みWebDriverAgent、Piとモデルの設定は手動で行うことを条件としました。この判断はomacom/omarchy-plugin-marketplace#10915:issuecomment-6098467632に記録されています。マーケットプレイスでの検証はレビュー対象のスナップショットに適用されるもので、セキュリティ監査ではありません。

08Omabumpの検証で、特権で動くVoxtype更新フックの欠陥が判明

Vladkarokによる新しいOmabumpスナップショットの検証依頼は、omacom/omarchy-plugin-marketplace#10910で引き続きオープンとなっています。レビュー中、HANCORE-linuxは、Voxtypeのパッケージフックが共有一時ディレクトリから引き継ぎ用ファイルを所有者確認なしで読み込み、攻撃者が制御する実行ファイルをシステムのランチャーとして受け入れることを指摘しました。

Vladkarokはこの仕組みを確認し、通常のパッケージ更新でも同じフックが動くため、修正すべき場所はプラグインではなくパッケージ側だと説明しました。作者は、rootだけがアクセスできる保存先を使い、復元する実行ファイルのパスを制限する変更案を示しました。その修正がマージされた後で、Omabumpが固定参照しているレシピを更新する予定としています。応答はomacom/omarchy-plugin-marketplace#10910:issuecomment-6098036843に記録されていますが、提示された議論からはパッケージ側の修正完了を確認できません。

09Wardのレビューで、読み取り専用ディレクトリの許可による情報露出を指摘

jacob-vincent-minkによるWardの提案は、omacom/omarchy#10974で引き続きオープンとなっています。現在の説明では、サードパーティーのQuickshellワーカーを隔離し、リビジョンごとの承認と選択したアクセス権限を与える方式を提案しています。一方、ネイティブパッケージ化、レジストリの振り分け、より広範な受け入れ確認の作業は未完了とされています。

10月10日、レビュアーのSorenHJohansenは、書き込み権限の付与が拒否される場所でも、読み取り専用の権限を与えると保護対象のホスト設定が露出し得ると報告しました。レビュアーは承認フローを一通り再現した手順を示し、読み取り・書き込みの両方で対象のルートディレクトリを拒否するか、何が開示されるのかを明確に定めるよう求めました。同じレビューでは、任意実行のテストにおけるコンパイラーのパスとグラフィックス環境の問題も指摘されました。omacom/omarchy#10974:issuecomment-6102074229は、現在もオープンの隔離機構の提案に、機密性についての具体的な論点を加えています。