Problem
Signing is referenced as a future intention in three places with no plan behind any of them, and no roadmap document exists (verified: ROADMAP.md and docs/ROADMAP.md absent). SECURITY.md:139-140 "expected until a code-signing certificate is available"; SECURITY.md:118-124 "A machine-scope installed build under Program Files (not user-writable) is planned alongside code signing once a certificate is available" - meaning a second, separately valuable improvement (removing the user-writable-executable property the doc itself flags) is blocked behind the same undecided item; README.md:1087 solicits sponsorship for it. Nothing records which route is being pursued, what it costs, how long it takes, or what it requires of the maintainer. Critically, the requirement that actually blocks the decision is nowhere acknowledged: every certificate route puts a validated legal identity in the certificate subject, and that subject is visible to every user in the file's Properties -> Digital Signatures. This project is published under the pseudonym laurentiu021 (Directory.Build.props:8-9 sets Authors/Company to laurentiu021; the repo's identity rules treat the work identity as strictly off-limits), so signing is not merely a purchase - it is a decision to attach a real legal name to every shipped binary.
Proposed solution
Write a short signing-decision section (SECURITY.md, or a new docs/TRUST.md linked from it) that records the four routes side by side with the requirement that gates each, so the decision can be made once and revisited on evidence rather than re-litigated: (1) Azure Trusted Signing - Microsoft-operated, short-lived certificates, cheapest recurring cost, individual/OSS-friendly tiers, requires identity validation and an Azure subscription; best SmartScreen behaviour of the paid options. (2) Certum open-source code-signing - the long-standing budget route for individual OSS authors, low annual cost, requires submitting identity documents and (per current CA/B key-storage rules) hardware-token or cloud-HSM key storage, so signing must run through that token - which constrains automating it inside GitHub Actions. (3) SignPath OSS programme - free and CI-native, but gated on the project being an established/well-known OSS project; it was already rejected once for insufficient reach, so record the concrete proxy metrics to re-apply on (GitHub stars, Releases download counts, winget presence - all observable without telemetry) and treat re-application as an outcome of the visibility work rather than a separate task. (4) Ship unsigned and lean on certificate-free trust signals - build attestations plus SBOM (see the related findings) - which is the only route that requires no identity disclosure and no money. For each, state expected SmartScreen behaviour honestly (see the sponsor-wording finding). Explicitly record the pseudonymity trade-off as the blocking question, and note which downstream item (machine-scope Program Files install, SECURITY.md:118-124) unblocks once a route is chosen.
Rationale
Three public documents promise signing and one asks for money toward it, while the actual blocker has never been written down - and it is not cost or effort, it is whether the maintainer is willing to publish under a legal name. That is a decision only the maintainer can make, and leaving it implicit means the item is silently deferred forever while the docs keep promising it. Writing the routes down converts an open-ended aspiration into a single yes/no question, lets the free certificate-free options (attestations, SBOM) ship immediately instead of waiting behind it, and prevents a rushed purchase of the wrong product - e.g. buying a hardware-token certificate that cannot be automated in the existing GitHub Actions release pipeline (.github/workflows/release.yml), which would break the fully-automated release flow the project depends on.
Evidence
Verified no roadmap exists: ls ROADMAP.md docs/ROADMAP.md -> both "No such file or directory". Read all three forward-looking signing references with numbered output: SECURITY.md:138-141 and SECURITY.md:118-124 (machine-scope install "planned alongside code signing once a certificate is available"), README.md:1087-1089 (sponsor pitch). Confirmed the pseudonymous publishing identity from source: SysManager/Directory.Build.props:8-10 <Authors>laurentiu021</Authors>, <Company>laurentiu021</Company>, <Copyright>Copyright (c) 2026 laurentiu021</Copyright>; SysManager.csproj:18 Description credits "by laurentiu021". Confirmed the pipeline is fully automated with zero signing hooks to extend: grep -ci "signtool|sign" .github/workflows/release.yml -> 0; release.yml:107 invokes ./publish.ps1 and :167 uploads, with no signing step between build and publish.
Risk / trade-off
This finding produces a decision document, not code - it can sit unread if the maintainer does not engage with it. Recorded cost and eligibility figures for external vendors drift, so the section should describe requirements and trade-offs (identity disclosure, key-storage constraints, CI automatability) rather than hard prices that go stale. It also surfaces an uncomfortable personal trade-off; the honest framing is that route (4) is a legitimate permanent choice, not a placeholder.
Affected area
Release
Effort: M | priority: value 3/5, fit 4/5
Identified during the trust, distribution and reach audit audit.
Problem
Signing is referenced as a future intention in three places with no plan behind any of them, and no roadmap document exists (verified: ROADMAP.md and docs/ROADMAP.md absent). SECURITY.md:139-140 "expected until a code-signing certificate is available"; SECURITY.md:118-124 "A machine-scope installed build under Program Files (not user-writable) is planned alongside code signing once a certificate is available" - meaning a second, separately valuable improvement (removing the user-writable-executable property the doc itself flags) is blocked behind the same undecided item; README.md:1087 solicits sponsorship for it. Nothing records which route is being pursued, what it costs, how long it takes, or what it requires of the maintainer. Critically, the requirement that actually blocks the decision is nowhere acknowledged: every certificate route puts a validated legal identity in the certificate subject, and that subject is visible to every user in the file's Properties -> Digital Signatures. This project is published under the pseudonym laurentiu021 (Directory.Build.props:8-9 sets Authors/Company to laurentiu021; the repo's identity rules treat the work identity as strictly off-limits), so signing is not merely a purchase - it is a decision to attach a real legal name to every shipped binary.
Proposed solution
Write a short signing-decision section (SECURITY.md, or a new docs/TRUST.md linked from it) that records the four routes side by side with the requirement that gates each, so the decision can be made once and revisited on evidence rather than re-litigated: (1) Azure Trusted Signing - Microsoft-operated, short-lived certificates, cheapest recurring cost, individual/OSS-friendly tiers, requires identity validation and an Azure subscription; best SmartScreen behaviour of the paid options. (2) Certum open-source code-signing - the long-standing budget route for individual OSS authors, low annual cost, requires submitting identity documents and (per current CA/B key-storage rules) hardware-token or cloud-HSM key storage, so signing must run through that token - which constrains automating it inside GitHub Actions. (3) SignPath OSS programme - free and CI-native, but gated on the project being an established/well-known OSS project; it was already rejected once for insufficient reach, so record the concrete proxy metrics to re-apply on (GitHub stars, Releases download counts, winget presence - all observable without telemetry) and treat re-application as an outcome of the visibility work rather than a separate task. (4) Ship unsigned and lean on certificate-free trust signals - build attestations plus SBOM (see the related findings) - which is the only route that requires no identity disclosure and no money. For each, state expected SmartScreen behaviour honestly (see the sponsor-wording finding). Explicitly record the pseudonymity trade-off as the blocking question, and note which downstream item (machine-scope Program Files install, SECURITY.md:118-124) unblocks once a route is chosen.
Rationale
Three public documents promise signing and one asks for money toward it, while the actual blocker has never been written down - and it is not cost or effort, it is whether the maintainer is willing to publish under a legal name. That is a decision only the maintainer can make, and leaving it implicit means the item is silently deferred forever while the docs keep promising it. Writing the routes down converts an open-ended aspiration into a single yes/no question, lets the free certificate-free options (attestations, SBOM) ship immediately instead of waiting behind it, and prevents a rushed purchase of the wrong product - e.g. buying a hardware-token certificate that cannot be automated in the existing GitHub Actions release pipeline (.github/workflows/release.yml), which would break the fully-automated release flow the project depends on.
Evidence
Verified no roadmap exists:
ls ROADMAP.md docs/ROADMAP.md-> both "No such file or directory". Read all three forward-looking signing references with numbered output: SECURITY.md:138-141 and SECURITY.md:118-124 (machine-scope install "planned alongside code signing once a certificate is available"), README.md:1087-1089 (sponsor pitch). Confirmed the pseudonymous publishing identity from source: SysManager/Directory.Build.props:8-10<Authors>laurentiu021</Authors>,<Company>laurentiu021</Company>,<Copyright>Copyright (c) 2026 laurentiu021</Copyright>; SysManager.csproj:18 Description credits "by laurentiu021". Confirmed the pipeline is fully automated with zero signing hooks to extend:grep -ci "signtool|sign" .github/workflows/release.yml-> 0; release.yml:107 invokes ./publish.ps1 and :167 uploads, with no signing step between build and publish.Risk / trade-off
This finding produces a decision document, not code - it can sit unread if the maintainer does not engage with it. Recorded cost and eligibility figures for external vendors drift, so the section should describe requirements and trade-offs (identity disclosure, key-storage constraints, CI automatability) rather than hard prices that go stale. It also surfaces an uncomfortable personal trade-off; the honest framing is that route (4) is a legitimate permanent choice, not a placeholder.
Affected area
Release
Effort: M | priority: value 3/5, fit 4/5
Identified during the trust, distribution and reach audit audit.