法的情報

コード署名ポリシー

最終更新: 2026年10月 · 12言語で提供。

1. このポリシーが定めること

このページは、KalderaShield のどのリリース成果物が、誰によって、どの鍵の管理方式で署名され、各署名について誰が承認責任を負うかを示します。同じ文書のソース版はリポジトリにあります: CODE_SIGNING_POLICY.md

2. Windows

Free code signing provided by SignPath.io, certificate by SignPath Foundation.

状態: 未申請。 KalderaShield は SignPath Foundation への申請を予定しており THEIR の条件が申請前に本ポリシーの存在を求めるため、先に用意しました。申請は提出されておらず、保留中の決定もありません。この節から、現在の Windows 成果物が署名済みであるとは読み取ってはなりません。署名はされていません。最初の署名済みリリースが実際に公開されるまで、正しい記述は下のステータス表であり、この節はそのリリースの前に更新されます。

署名されるファイルは、NSIS インストーラー(KalderaShield_<バージョン>_x64-setup.exe)、一元管理パッケージ向け MSI パッケージ(KalderaShield_<バージョン>_x64.msi)、そしてインストール不要のポータブル実行ファイル(KalderaShield_<バージョン>_x64-portable.exe)です。三つともこのリポジトリからビルドされ、リリースページで公開されます。このリポジトリからビルドされていない成果物が本プロジェクトの証明書で署名されることはなく、第三者のバイナリをこの証明書で再署名することもありません。

鍵の管理:秘密鍵は SignPath の HSM 上で生成され、保管されます。本プロジェクトは鍵を一切保持せず、エクスポートもせず、ビルドランナーや開発者マシンに送信することもありません。署名は、本リポジトリの CI が送信し、責任者が承認した署名リクエストに応えて、SignPath 側で行われます。

連鎖: バージョンタグを push → GitHub Actions がファイルをビルド(ワークフローは公開、第三者アクションはコミット SHA で固定、トークン権限は読み取り専用)→ ビルドが SignPath へアップロードして署名リクエストを発行(署名はしない)→ 承認者が承認または却下 → SignPath が Foundation 証明書で署名 → 署名済みファイルを SHA256SUMS.txt と共に公開。すべてのリリースで人手による承認が必要です。無人の署名経路は存在せず、近い将来も追加されません。

有効な SignPath Foundation 署名は、そのバイナリが、リリースが示すコミットにおける本リポジトリのソースコードからの検証可能な自動ビルドであることを意味します。ソフトウェアが監査済みであることを意味せず、アプリケーションに対するセキュリティの推奨でもありません。本プロジェクトは脅威モデルと品質ゲート文書を公開していますが、完了した独立した第三者セキュリティ監査は持っていません:

3. チームの役割

KalderaShield は一人が保守しています。これはチームとして提示するのではなく、ここではっきり記載しています。以下は SignPath が求める役割であり、単独のメンテナが正直に埋められるのはそれらのみだからです。このリポジトリへの書き込み権限を持つすべてのアカウントは、多要素認証を使用しています。

著者 (Authors) — 追加のレビューなしにソースコードを変更できる人:

書き込み権限を持つアカウントはこれだけです。リポジトリは組織ではなく個人のアカウントが所有しているため、書き込み経路は MFA が有効な単一の身元です。

レビュアー (Reviewers) — コミッター以外が提案したすべての変更を、マージ前にレビューする人:

  • hafgit99

現在コミット権限のない貢献者はいないため、この役割は単に薄いというだけでなく、実質的に空いています。

承認者 (Approvers) — 成果物が署名される前に各署名リクエストを承認する人:

  • hafgit99

既知の不足: 三つの役割を同一人物が兼ねているため、コードを書く人が自分の署名も承認してしまいます。SignPath のモデルは承認者が「チーム全体の信頼される人」であることを前提としており、それは複数人のチームメンバーが存在することを前提としており、第二の承認者を追加する計画はありますが、まだ実現していません。これを不合格の理由と考える審査者は、承認の後にではなく今言うべきです。

4. プライバシーポリシー

SignPath が求める表現で: 本プログラムは、ユーザーまたはこれをインストール・運用する人が明示的に求める場合を除き、他のネットワーク接続システムに何らの情報もも転送しません。

KalderaShield はオフラインファーストでゼロ知識に基づくパスワードマネージャーです。保管庫の内容はデバイス上でマスターパスワードから導出された鍵により暗号化され、送信されることはありません。アカウントも、同期サービスも、テレメトリも、分析も存在しません。Windows のバイナリには、オペレーティングシステム自身のコンポーネント以外にネットワーククライアントは一切含まれていません。全文: プライバシーポリシー. 利用者に影響する第三者コンポーネントの挙動は LICENSE-3RD-PARTY.md に記載されています。

5. その他のプラットフォーム

macOS — 成果物は Apple Developer ID で署名され、Apple が notarize します。証明書はまだ発行されていないため、署名済みの macOS 成果物は存在せず、公開されているものもありません。Linux — .deb、.rpm、.AppImage は切り離された GPG 署名(.sig)付きで、SBOM とブラウザ拡張パッケージは鍵なし Sigstore 署名(.sigstore.json)付きで公開されます。Android — リリース APK は GitHub Actions のシークレットに保管されたリリース用 keystore で署名され、Android の署名は Authenticode とは別物です。実際に署名されるまで、どのプラットフォームも署名済みとは説明されません。

現在の状況: Linux、Android、ブラウザ拡張機能は公開済みで署名済みです。Windows は未署名プレビューとしてのみ公開されます。プレリリースであって安定したリリースではなく、latest もこれを指しません。未署名ファイルでは Windows SmartScreen の「PC を保護しています」が表示され、インストーラーを実行するには「詳細」→「実行する」をクリックする必要があります。これは想定された動作です。実行前に SHA256SUMS.txt と SHA-256 ダイジェストを照合してください。SignPath Foundation への署名はまだ提出されていません。macOS は未公開・未署名です(証明書未発行)。

Windows の成果物はリリースとして公開されません。リリースパイプラインは未署名のデスクトップリリースを失敗として扱い、.github/workflows/ 内のどのワークフローもそれを公開できません。プレビューは手作業で組み立てられ、保守者のマシンから GitHub のリリースフォームを通じてアップロードされ、プレリリースとして示されます。つまり一時的なものとしてはっきりわかり、latest がそれを指すことはなく、次の署名済みリリースが置き換えます。これは回避策ではなく意図的な選択です。このリポジトリには、npm run security:release-signing というセキュリティゲートがあり、未署名ビルドを公開物に変えられるあらゆるワークフローを拒否します。その最終的な主張は、署名シークレットがなければ公開デスクトップリリースは設計上不可能という点です。ワークフローに例外を追加すれば、利便と引き換えにその主張が偽のものになります。アップロードをブラウザに留めることで約束は保たれます。ゲートは コード署名と成果物署名ガイド に、手順は 計画:サイト、その後 Windows 未署名プレビュー に記載されています。

6. 問題の報告

SignPath Foundation の証明書で署名された成果物がこのポリシーに違反していると思う場合は、そのハッシュと理由を添えて support@signpath.io へ報告してください。これらの成果物に関するその他の事項は security@kalderashield.com へ連絡してください。開示の手順は SECURITY.md にあります。

相違がある場合は、本ポリシーのトルコ語正文が優先します。