LibreSign/libresign

Part of #8939. Part of #8939. Context LibreSign supports two certificate engines: OpenSSL; CFSSL. The implementations differ internally, but LibreSign depends on them producing certificates with the same business-level certificate intent. CFSSL 1.7.0 includes certificate and key-usage changes upstream, including a fix preventing CSR extensions from overriding CA-managed key usage when copy_extensions is used. LibreSign does not currently enable copy_extensions. We should not enable it in this issue. The upgrade is a good point to add regression coverage for the final certificate properties LibreSign depends on, so future engine-specific changes do not silently create incompatible certificates. Goal Add behavior-level regression tests that protect the LibreSign leaf-certificate profile for both CFSSL and OpenSSL. The tests must inspect the certificate produced by the engine. Do not test private implementation details such as the internal JSON array passed to CFSSL or the internal Open

Part of #8939. Part of #8939. Context LibreSign currently manages CFSSL 1.6.5 in: lib/Service/Install/InstallService.php through: InstallService::CFSSL_VERSION The managed installer downloads the architecture-specific binary from the official CFSSL GitHub release and retrieves the expected SHA-256 value from the upstream checksum file. CFSSL 1.7.0 is available here: https://github.com/cloudflare/cfssl/releases/tag/v1.7.0 The release provides the two architectures already supported by LibreSign: cfssl_1.7.0_linux_amd64 cfssl_1.7.0_linux_arm64 and the checksum manifest: cfssl_1.7.0_checksums.txt Do not hard-code a copied checksum in LibreSign. Keep using the official checksum manifest through DependencyDownloader::fetchChecksum(). Goal Update the LibreSign-managed CFSSL dependency from 1.6.5 to 1.7.0 without changing how CFSSL is configured or used. This issue is only about the managed dependency lifecycle and version validation. What to change 1. Update the supported CFSSL version I

Part of #8931. Blocked by #8934. Before starting This issue is intentionally blocked until #8934 publishes the final administration API in LibreSign's generated OpenAPI contract. If you want to work on this issue while #8934 is still open, comment here first. A maintainer will confirm whether the backend contract is already stable enough and will update this issue if endpoint names or generated types changed. Once #8934 is complete, do not redesign the backend contract in this issue. Use the committed generated OpenAPI/TypeScript types as the source of truth. Goal Give Nextcloud administrators a clear and transparent interface for LibreSign usage statistics. Opt-in Show one global installation-level setting: Share anonymous usage statistics The setting is disabled by default. Do not expose: per-user configuration; per-group configuration; Policy Workbench integration; per-category toggles; per-metric toggles; a separate historical-data toggle. Categories are hardcoded organization i

Goal Make mutation-testing changes in ProgressService fail quickly when they break polling-loop progress instead of running until the Infection timeout. Context Investigation under #8053 identified mutation timeouts in: lib/Service/SignRequest/ProgressService.php tests/php/Unit/Service/SignRequest/ProgressServiceTest.php Some mutants can change the polling interval or elapsed-time update so the loop no longer makes progress. The current tests exercise these paths with a zero interval. When the relevant expression is mutated, the observable failure can become an effectively unbounded loop and Infection stops it only through its mutant timeout. The test already interacts with collaborators during polling. A bounded interaction expectation can make an unexpected extra iteration fail immediately. Required outcome Protect the polling behavior through observable collaborator interactions. Prefer a tests-only change if the current production behavior can be verified correctly without introdu

Goal Add the minimum StrykerJS configuration required to run frontend mutation testing locally using LibreSign's existing Vitest configuration. This issue is only about making mutation testing work reliably. Do not introduce a CI quality gate in this issue. Parent: #8810 Current frontend test stack LibreSign currently uses: Vue 3 TypeScript Vite Vitest happy-dom The existing Vitest configuration is: vitest.config.js The project already declares a Node version compatible with the current StrykerJS runtime requirements. Dependencies Use the official Stryker packages for Vitest: @stryker-mutator/core @stryker-mutator/vitest-runner Do not replace Vitest or add a second frontend unit-test framework. Required implementation Add an npm script such as: test:mutation that runs Stryker. Add a Stryker configuration file and reuse the existing: vitest.config.js Do not duplicate Vitest aliases, Vue setup, environment configuration, or shared mocks inside the Stryker configuration when the exis