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

未关闭
#9,474 0 条评论 0 个 reaction 已指派 0 人 在 GitHub 查看

维护者通常 1 天内回复

还没有人认领这个 Issue。

评估

难度
5/5
预计耗时
一周以上
新手友好度
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 分钟
30 天内合并 PR
299

环境准备

在 Codespaces 中打开

在浏览器里用你自己的 GitHub 账号启动这个项目的开发容器。

从这里开始

  1. 先读完整个 Issue,再读项目的贡献指南。
  2. 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
  3. Fork 仓库,在一个分支上完成修改。
  4. 提交 Pull Request,并在描述里引用这个 Issue 编号。

LibreSign/libresign 的其他 Issue

查看 LibreSign/libresign 的全部 Issue

相似的 Issue

更多 PHP Issue

把新 issue 发到你的邮箱

精选适合新手参与的 GitHub issue 摘要。