Code signing policy — KalderaShield

1. What this policy determines

This page states which KalderaShield release artifacts are signed, by whom, under which key custody arrangement, and who is accountable for approving each signature. The source version of the same document in the repository: CODE_SIGNING_POLICY.md

2. Windows

Free code signing provided by SignPath.io, certificate by SignPath Foundation.

Status: not yet applied. KalderaShield intends to apply to the SignPath Foundation and has prepared this policy in advance, because their terms require it to exist before an application is made. The application has not yet been submitted and no decision is pending. Nothing in this section should be read as a claim that any Windows artifact is currently signed. It is not signed. Until the first signed release actually ships, the honest statement is the current status table below, and this section is updated before that release, not after.

The files to be signed are the NSIS installer (KalderaShield_<version>_x64-setup.exe), the MSI package for managed deployment (KalderaShield_<version>_x64.msi) and the portable executable that needs no installation (KalderaShield_<version>_x64-portable.exe). All three are built from this repository and published on the releases page. No artifact not built from this repository is signed with this project's certificate, and no third-party binary is re-signed under it.

Key custody: the private key is generated and stored on SignPath's HSM. This project never holds it, never exports it, and never transmits it to a build runner or a developer machine. Signing happens on SignPath's side, in response to a signature request that this repository's CI submits and a human approves.

Chain: a version tag is pushed → GitHub Actions builds the files (workflows are public, third-party actions are pinned by commit SHA, token permissions are read-only) → the build uploads them to SignPath and raises a signature request without signing → an Approver approves or rejects → SignPath signs with the Foundation certificate → the signed file is published together with SHA256SUMS.txt. Every release requires manual approval; there is no unattended signing path and none will be added.

A valid SignPath Foundation signature means the binary is a verifiable, automated build of the source code in this repository at the commit the release names. It does not mean the software has been audited, and it is not a security endorsement of the application. This project publishes a threat model and quality-gate documentation, but has no completed independent third-party security audit:

3. Team roles

KalderaShield is maintained by a single person. That is stated here rather than presented as a team, because the roles below are the ones SignPath requires and a single maintainer can only honestly fill them alone. All accounts with write access to this repository use multi-factor authentication.

Authors — people who may modify the source code without additional review:

hafgit99 — github.com/hafgit99

This is the only account with write access. The repository is owned by a personal account rather than an organisation, so the write path is a single identity with MFA on it.

Reviewers — people who review every change proposed by a non-committer before it is merged:

hafgit99

There are no non-committer contributors at present, so this role is currently vacant in practice rather than merely thin.

Approvers — people who approve each signature request before the artifact is signed:

hafgit99

Known gap: with one person holding all three roles, the person who writes the code also approves its signature. SignPath's model assumes an Approver is "trusted by the entire team", which presumes more than one team member. Adding a second Approver is planned and not yet done. A reviewer who considers this disqualifying should say so now rather than after approval.

4. Privacy policy

In the terms SignPath asks for: this program will not transfer any information to other networked systems unless specifically requested by the user or the person installing or operating it.

KalderaShield is an offline-first, zero-knowledge password manager. Vault contents are encrypted on the device with keys derived from the master password and are never transmitted. There is no account, no sync service, no telemetry and no analytics. The Windows binaries contain no network client of any kind beyond the operating system's own components. Full text: Privacy policy. The behaviour of third-party components that affects users is covered by LICENSE-3RD-PARTY.md.

5. Other platforms

macOS — artifacts are signed with an Apple Developer ID and notarized by Apple. The certificate has not been issued yet, so no macOS artifact has been signed and none is published. Linux — .deb, .rpm and .AppImage are published with detached GPG signatures (.sig); SBOMs and browser-extension packages with keyless Sigstore signatures (.sigstore.json). Android — release APKs are signed with a release keystore held in GitHub Actions secrets; Android signing is separate from Authenticode. No platform is described as signed until it is.

Current status: Linux, Android and the browser extension are published and signed. Windows is published only as an unsigned preview: a pre-release, not a stable release, and latest does not point at it. Unsigned files trigger the Windows SmartScreen "Windows protected your PC" warning, and you must click "More info" → "Run anyway" to run the installer; this is expected. Verify the SHA-256 digest against SHA256SUMS.txt before running it. The SignPath Foundation application has not yet been submitted. macOS is not published and unsigned (certificate not yet issued).

Windows artifacts are not published as a release: the release pipeline treats an unsigned desktop release as a failure, and no workflow in .github/workflows/ is able to publish one. The preview is assembled and uploaded by hand, from the maintainer's machine through GitHub's own release form, and marked as a pre-release — so it is visibly provisional, latest never points at it, and the next signed release replaces it. That route is deliberate rather than a workaround. The repository contains a security gate (npm run security:release-signing) that fails any workflow capable of turning an unsigned build into a published one, and its closing claim is that without the signing secrets a public desktop release is impossible by design. Adding an exception for a workflow would have made that claim false in exchange for a convenience. Keeping the upload in a browser keeps the guarantee intact. The gate is documented in the Code Signing & Artifact Signing Guide; the step-by-step procedure is in the Plan: site, then the unsigned Windows preview.

6. Reporting a problem

If you believe an artifact signed with a SignPath Foundation certificate violates this policy, report it to support@signpath.io with the artifact's hash and the reason. For anything else about these artifacts, use security@kalderashield.com; the disclosure process is in SECURITY.md.

In case of any discrepancy, the Turkish text of this policy governs.