cryptpad

CryptPad

使用しないケース

• ローカルでオフィスファイルを作成または変換する場合は、documents または anydoc を使用してください。
• 一般的な API 契約の設計には、api-design-and-evolution を使用してください。
• コンテナー操作には、docker-compose を使用してください。CryptPad 固有の設定はこちらに記載します。
• EncryptPad は、別の OpenPGP デスクトップアプリケーションです。

ワークフロー

1. インスタンスのオリジン、デプロイされているバージョン、ドキュメントアプリケーション、およびタスクを確認します。 既存の CryptDrive コンテンツ、外部ストレージに保存されたドキュメントの埋め込み、またはインスタンス操作のいずれかです。 タイトル、HTTP リクエストの成功、またはエディター UI だけから権限を推測してはいけません。
2. 実現可能性について、アーキテクチャとインターフェースの境界を読みます。 外部ストレージには、文書化されたブラウザー統合 API を優先して使用してください。既存の CryptDrive ドキュメントには、認証済みのブラウザーセッションを使用します。存在しないベアラートークン CRUD ルートを作り上げてはいけません。
3. 公開インスタンスの検出には、以下の CLI を実行します。埋め込みには、統合契約を読んでから、アダプターと計画テンプレートを使用します。 セルフホストの問題については、運用を読んでください。
4. このスキルでは、外部状態を変更する操作をガイドできます。編集、インポート、共有、鍵のローテーション、デプロイ、保持設定の変更が含まれます。 操作の前に、対象、範囲、およびロールバック手順を確認してください。読み取り専用の調査は確認なしで進められます。 既存の明示的な承認でこれらの詳細が網羅されている場合は、それを使用してください。破壊的な操作には、引き続きユーザーの明示的な指示が必要です。不足事項を確認する前に、元に戻せる作業を準備してください。
5. 通常のブラウザーパスで結果を検証します。ドキュメントが読み込まれること、編集内容が同期されること、保存内容が永続ストレージに届くこと、新しいセッションで保存済みコンテンツを再度開けることを確認してください。 実際の閲覧キーを使用して、閲覧のみのアクセスを確認します。HTTP による検出は、この検証の代わりにはなりません。
6. バージョンとソースの根拠、実際に実行したテスト、残る制限事項とともに、成果物または診断結果を提示します。診断を3回行っても収束しない場合は中止し、失敗した境界と次に必要な証拠を正確に報告します。エクスポートしたドキュメントの内容の代わりに生の暗号文を提示したり、スキーマに適合する eval が実行時の動作を証明すると主張したりしてはいけません。

ツール

このスキルのルートから実行してください。ツールは Python の標準ライブラリのみを使用し、JSON を出力します。

python3 scripts/cryptpad.py probe --origin https://cryptpad.example.org
python3 scripts/cryptpad.py inspect-link < /secure/path/document-link.txt
python3 -m unittest discover -s scripts -p 'test_*.py'

CLI：probe は /api/config と /cryptpad-api.js に GET リクエストを送信し、リダイレクトを拒否し、応答サイズとタイムアウトに上限を設定し、JavaScript を実行せずに既知の AMD ラッパー内の JSON のみを解析します。終了コード 0 は両方のリソースが認識されたこと、1 は検出が不完全であること、2 は入力が無効であることを示します。enableEmbedding: false は設定上の所見であり、ネットワーク障害ではありません。バージョンやエンドツーエンドの健全性は推測しません。

inspect-link はオフラインで動作し、ケイパビリティリンクが argv に含まれないよう stdin から読み取ります。報告するのはオリジン、既知のアプリケーション、およびクエリ／フラグメントの有無のみで、その値や任意のパスは報告しません。鍵の検証や実効権限の判定は行いません。入力ファイルを保護してください。実際の鍵をログやシェル履歴に貼り付けてはいけません。

テストでは、不正な入力、秘密情報の秘匿、応答の認識、障害処理、保存／鍵コールバックをテストします。Node.js がある場合はアダプターテストを実行します。Node.js がない場合、そのテストは明示的にスキップされます。

統合の要点

• インスタンスの /cryptpad-api.js を読み込み、window.CryptPadAPI(containerId, config) を呼び出します。 これはブラウザー API であり、サーバー側の REST ドキュメントサービスではありません。
• 永続ストレージ、ユーザー認証、セッションキーの共有は、埋め込み側のサービスが担います。 統合セッションは一時的なものであり、通常の CryptDrive への永続化は別のワークフローです。
• デフォルトでは、onNewKey を使って CryptPad が生成するセッションキーを使用します。保存済みの古いキーと新しいキーをアトミックに比較し、編集キーと閲覧キーのうち勝ち残った組み合わせを保存します。同時更新で別の更新が勝った場合も、勝ち残った編集キーをコールバックに返します。各クライアントの候補をそのまま返さないでください。
• onSave には Blob が渡されます。永続保存が完了してからのみ保存完了を通知してください。失敗時は、画面上の未保存状態を維持してください。再試行に備えて、冪等性またはリビジョンを考慮したストレージが必要です。
• 編集キーを使った mode: 'view' は、UI をロックするだけです。実際の閲覧キーを使用し、閲覧ユーザーのストレージ API を通じて編集キーが公開されないようにしてください。デプロイ済みバージョンで機能がサポートされていることを確認してください。
• アプリケーションの ACL エントリーを削除しても、キーを持つ実行中のセッションは終了しません。キーのローテーションと新しいセッションへの移行を計画し、遡及的な機密性が保たれると主張しないでください。
• CryptPad 側の E2EE では、アプリケーションに保存したエクスポートデータは暗号化されません。E2EE が必要な場合は、信頼されたクライアントで暗号化と復号を行い、それに応じて鍵の配布方法を設計してください。

テンプレートと根拠資料

• 実装前に、統合計画を使って、ストレージ、キーの所有権、許可された変更、受け入れテストを定義します。
• アプリケーション側での永続化とアトミックなキー更新には、コールバックアダプターを調整して使用します。バックエンド、認証情報、暗号化方式は含まれていません。
• ブラウザー設定例を使って、ドキュメントに記載された API にアダプターを接続します。実際のアプリケーションサービスが必要なひな形です。
• 調査資料を使って、ソースのリビジョンと互換性を記録します。
• 出力品質のテストケースでは、統合と診断の動作を確認します。 トリガープローブは、別個のハーネス入力です。