Code signing policy
Who can sign a release, and how
LibreDB Studio publishes Windows binaries from public CI. This page states who is trusted to change the source, who approves a release for signing, and what the software does on the network — the three questions a certificate authority asks before it lends its name to a binary, and the three a cautious user should ask before running one.
Current state — unsigned
Windows builds are not signed yet
The Windows portable zip and the winget and Chocolatey payloads ship unsigned, so SmartScreen will warn on first run. That warning is correct and you should treat it as correct: verify the checksum published with the release before running the binary. An application for free open-source code signing is open; this page is written so that when it is granted, nothing about who approves a release has to change.
Team roles
Who holds which trust
The definitions are the ones a signing foundation uses. The members are the repository’s actual permissions rather than a list assembled for this page — if the two ever disagree, the repository is right and this page is a bug.
-
Authors
People trusted to modify the source code in the version control system without an additional review.
Write access on the repository — two administrators and one maintainer. Everyone else, including the fourth organisation member, has read access and lands changes only through a pull request.
-
Reviewers
Each change proposed by someone who is not a committer is reviewed by a team member.
main is protected: no direct pushes, and lint, typecheck, build, the full test suite and a secret scan must pass before a merge. An outside pull request is additionally read by one of the people above before it lands.
-
Approvers
Each signing request is approved by a team member trusted by the entire team.
Three approvers, so a release is never gated on one person being available. Signing is never automatic: a release is a tag pushed by hand, and each signing request is approved individually.
How a release is approved
Nothing signs itself
-
Built from a tag, in public
Every artifact is produced by GitHub Actions from a pushed tag, using workflows anyone can read in the repository. Nothing is built on a maintainer’s machine and uploaded.
-
Multi-factor authentication, enforced
Two-factor authentication is required for every member of the GitHub organisation, enforced at the organisation level rather than requested. It was enabled on 2026-09-01 and applies to all four members.
-
Each signing request approved by hand
A release is never signed as a side effect of a merge. An Approver authorises each request individually, after the release assets are built and verified.
-
A release is never rewritten
Published releases and package versions are immutable here by policy: a bad release is replaced by the next patch version, never re-uploaded under the same one. A signature therefore always describes the bytes it was made for.
What the software sends
Where data goes, and on whose instruction
This program will not transfer any information to other networked systems unless specifically requested by the user or the person installing or operating it.
LibreDB Studio is self-hosted and ships no telemetry or analytics; the container disables the framework’s own telemetry as well. It connects to the databases you configure, and to a model provider only if you configure one — both are outbound connections you set up, and the second is documented as a limit rather than a feature, because it means query content leaves the machine.
The site's own cookie and analytics handling is a separate matter, covered in the privacy policy. Where those guarantees stop is set out in the security model.