Code signing policy

How code enters ArtDaddy, who approves a release, and how the binaries you download are produced. Last reviewed 15 September 2026.

Project

ArtDaddy is a local-first AI video editor for Windows, macOS and Linux. The desktop application is open source under GPL-3.0-or-later and developed in public at github.com/art-daddy/artdaddy. The hosted AI backend it talks to is a separate, closed-source service and is not part of this repository.

Who may commit

Write access to the repository is limited to the maintainers below. Everyone else contributes through pull requests from a fork.

Person	GitHub	Role
Akshay Dagar	`akshay-dagar-98`	Maintainer, reviewer, release approver
Kumar Anubhav	`anubhavka4`	Maintainer, reviewer

Only Akshay Dagar approves and publishes releases. Maintainer accounts are administered through the art-daddy GitHub organisation.

How changes are reviewed

Every external contribution arrives as a pull request and must be reviewed and approved by a maintainer before merging. A contributor cannot merge their own pull request.
Contributors must accept the Contributor License Agreement. Acceptance is recorded automatically by the cla.yml workflow, which blocks a pull request until the author has signed.
Continuous integration runs on every push and pull request and must pass: unit tests, real-browser UI and compositor pixel checks, and a full Tauri desktop build.
A local pre-push hook additionally runs the build, the JavaScript test suite and the Rust test suite, and refuses the push on failure.

How releases are built

Release builds are produced from a tagged commit on main in the public repository. Every published binary corresponds to source that is public at that tag.
Builds run in GitHub Actions on GitHub-hosted runners. The macOS and Linux release workflows (macos-release.yml and linux-release.yml) are triggered manually by a maintainer.
Third-party components bundled with the application — FFmpeg, whisper.cpp, yt-dlp — are fetched from their official upstream releases at pinned versions and are listed in THIRD-PARTY-NOTICES.md.

Signing and updates

Update packages are signed with a minisign key held by the release approver. The corresponding public key is committed to the repository in src-tauri/tauri.conf.json, and the application verifies every update against it before installing. An update that does not verify is rejected.
The update manifest is served from artdaddy.app/updates/latest.json and release binaries are published on GitHub Releases.
The macOS bundle is ad-hoc signed. That is a valid signature with no identity behind it: it satisfies the requirement that an Apple Silicon binary carry a signature to execute, but it is not an Apple Developer ID and it is not notarized. Gatekeeper will say the developer cannot be verified; open it once with right-click → Open.
Authenticode signing of the Windows installer is not yet in place, so SmartScreen will warn that the publisher is unrecognised. Apple notarization is not in place either. This page will be updated when either is enabled — not before.
Linux AppImage updates are signed with the same minisign updater key clients already trust. This verifies update bytes; it is separate from distribution-specific package signing.
Signing keys are never committed to the repository and are not shared with contributors.

Privacy

Editing, export and transcription run on your own machine; your media is not uploaded in order to be edited. The requests you explicitly make of an AI model, your account email, and usage records including prompt text are transferred to the services listed in the privacy policy, which describes exactly what is sent and when.

Reporting a problem

Please report a suspected malicious build, a signature that fails to verify, or a security vulnerability to support@artdaddy.app rather than opening a public issue.