Introduce a per-user certificate inventory and migrate legacy PFX storage

オープン
  • 何か問題がありますか？
#9,474 コメント 0 件 リアクション 0 件 担当者 0 名 GitHub で見る

メンテナーはふだん 1 日以内に返信

まだ誰も着手していません。

評価

難易度
5/5
見積もり時間
1週間以上
初心者へのやさしさ
12/100
issue の種類
機能追加
明瞭さ
おおむね明確
活発さ
活発
技術スタック
php
領域
backend, security

調査の方向性

Start from SignEngineHandler, where the single signature.pfx filename is used, and trace how certificate creation, lookup and deletion assume one certificate per account. The work is a schema and storage design plus an idempotent migration, so read the existing storage code before proposing a data contract. Done means the acceptance criteria hold: existing PFX files are discoverable without reissuance, repeated migration is a no-op, accounts cannot read each other's material, and legacy signing still works.

索引モデルが issue の本文から書いたものです。

説明

backend enhancement php

Goal

Introduce a persistent inventory capable of representing multiple signing certificates per Nextcloud account, while preserving all existing reusable PFX certificates.

Current state

SignEngineHandler uses a single signature.pfx filename. Certificate creation, lookup and deletion assume one reusable certificate per account.

Scope

  • Introduce individual certificate records with stable identifiers and strict account ownership.
  • Store certificate metadata separately from protected PKCS#12 material.
  • Include issuer reference, subject, serial number, SHA-256 fingerprint, validity period, source, status and optional organizational context where applicable.
  • Support multiple inventory records for the same user without requiring multiple CAs.
  • Define a storage reference that does not expose private certificate material.
  • Migrate existing signature.pfx files idempotently, preserving their contents and password protection.
  • Retain compatibility with existing certificate lookup and signing paths during migration.
  • Establish backend contracts for later certificate-specific operations and UI development.
  • Avoid assuming that every certificate is LibreSign-issued or belongs to a Nextcloud group.

Acceptance criteria

  • Existing certificates are discoverable through the inventory without reissuance.
  • Two certificates belonging to one account have distinct records and protected storage references.
  • An account cannot retrieve another account's certificate material.
  • Repeated migration does not create duplicate records, overwrite PFX files or revoke certificates.
  • Listing certificate metadata does not require reading every PFX.
  • Missing files and inconsistent legacy records produce safe, recoverable behavior.
  • Tests cover ownership, migration, duplicate detection, storage failures and legacy signing compatibility.
  • The backend data contract and migration behavior are documented.

Out of scope

The complete CRUD UI, policy-based CA selection, certificate delegation, cloud certificates and interactive signing selection.

主要言語
PHP
スター
844
フォーク
176
平均マージ
13時間 46分
マージ済み PR（30日）
299

環境構築

Codespaces で開く

このプロジェクトの開発コンテナを、あなたの GitHub アカウントでブラウザ上に起動します。

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

LibreSign/libresign のほかの issue

LibreSign/libresign の issue をすべて見る

似ている issue

PHP の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。