Kicksecure Digital Signature Policy

Kicksecure ™

Download

On Computer USB Installation Intel / AMD64 ARM64 Raspberry Pi PPC64 Windows (VM) Mac Linux (VM) VirtualBox (VM) Qubes (VM) KVM (VM) Debian morph to Kicksecure More options Source Code

About

Overview Features Why Open Source? Project Activities Contributors Mission & Vision

Docs

Documentation FAQ Troubleshooting

Community

Forums Forum Best Practices Contribute

Support

Self Support First Policy Search Engines, Docs and AI Support (Limited) Reporting Bugs Contact (Restricted)

Tools Upload file Special pages Recent changes Print Version Page meta What links here Related changes Page information

Page Read Edit History Move Protection Unwatch Watch Delete Purge

User Preferences Watchlist Contributions Logout Create account Login

Donate

Dev/image formats Design Vulnerability Disclosure Policy Previous page: Dev/image formats Index page: Design Next page: Vulnerability Disclosure Policy Kicksecure Digital Signature Policy

• Verifying Software Signatures
• OpenPGP
• Air Gapped OpenPGP Key
• Signify
• Codecrypt
• Authenticode
• Kicksecure Digital Signature Policy

This page outlines the digital signature policy of Kicksecure, describing how signed git commits, tags, and images are required; how unsigned code is strictly prohibited in builds and deployments; and how documentation must encourage digital signature verification.

Kicksecure Signing Key Policy - Digital Signature Policy

• Local signing keys only: The "primary" project Signing Key must always be kept local.
• No remote signing keys: Uploading "primary" signing keys to remote (cloud) servers is strictly prohibited.
  • Exception for remote signing keys: If a separate signing key is "secondary" and only required to comply with external requirements such as Microsoft Windows code signing, keys managed by remote servers are acceptable.

Kicksecure Source Code - Digital Signature Policy

• Signed git head: The git head should always be signed by a core developer.
• Signed git tags: All git tags should always be signed.
• Source code digital signatures policy: All source code used to build Kicksecure has security level System Security Level Always use software signatures verification.
  • Source code by Kicksecure developers: Must be signed at least after merge.
  • Signed git tag policy: Git tags in all source code repositories must always be signed and point to signed commits.
  • Signed commits policy: The head of git commits in all source code repositories must always be signed.

Kicksecure Build System - Digital Signature Policy

• Build source code signature verification: All source code used to build Kicksecure using Derivative-Maker must always verify all digital software signatures.
• Unsigned code execution prohibition: Executing unsigned code is prohibited.
• Unsigned code deployment prohibition: Deployment of unsigned code is prohibited.
• Software build digital signatures policy: All source code used to build Kicksecure must always use software digital signature verification.
  • Download signature verification during build: When Derivative-Maker downloads software (such as dependency packages, default installed packages) for the creation of binary images, all software must always come with digital signatures that are verified before executing the code and/or before adding the software to the image.
• Failure reaction: If software signature verification fails, the build must be aborted.
• Exception policy: Hardcoding strong hashsums might be appropriate in exceptional cases where digital software signatures are unavailable.

Kicksecure Downloads - Digital Signature Policy

• Image signing: All images must always be signed.
• Repository signing: The package repository must always be signed.

Kicksecure Documentation - Digital Signature Policy

• Documentation digital signatures policy: All documentation on the topic of software installation and updating should always contain recommendations (and if feasible, detailed instructions) to verify digital signatures. Wiki templates such as Template:Always_verify_signatures and Template:unsigned_software should be used.
  • Automatic verification notice exemption: If digital software verification is automatic, such as in the case of installing packages from packages.debian.org using APT default repositories, then a superfluous special notice is not required.
• Prohibition examples:
  • curl bash pipe: For example, Derivative-Maker using a curl bash pipe curl some-domain.com | bash (i.e. downloading an executable from a remote server and executing it without prior digital software signature verification) is prohibited.
  • Unverified software installation: As a hypothetical example: "wget virtualbox.org/virtualbox.deb && dpkg --install virtualbox.deb" (in this example, downloading a VirtualBox Debian package from the VirtualBox website and installing it without digital software verification) is prohibited.
• Manual verification reminder requirement: If digital signature verification is not automated (such as by using APT when using Debian default repositories), then Template:Always verify signatures reminder must always be used.

• Digital signatures are a tool enhancing download security. They are commonly used across the internet and nothing special to worry about.
• Optional, not required: Digital signatures are optional and not mandatory for using Kicksecure, but an extra security measure for advanced users. If you've never used them before, it might be overwhelming to look into them at this stage. Just ignore them for now.
• Learn more: Curious? If you are interested in becoming more familiar with advanced computer security concepts, you can learn more about digital signatures here: Verifying Software Signatures

Template:Always verify signatures reminder used on the following wiki pages: Special:WhatLinksHere/Template:Always verify signatures reminder

• Unsigned software documentation policy: If documented software does not provide digital signatures, then Template:Unsigned_software must always be used.

This software installation might be a security risk. Installation is discouraged, following the recommended best practices for software installation:

Unsigned software: You cannot follow the usual security advice to always verify software signatures, because - as far as the author of this page knows - at the time of writing, the original developer (upstream) does not provide digital signatures for their software. Users may wish to check if that has changed or consider requesting this feature from the developer.

Template:Unsigned_software used on the following wiki pages: Special:WhatLinksHere/Template:Unsigned_software

Kicksecure Website

Having an OpenPGP Signed Website would be desirable, but that would require signing tools to sign the website and browsers which verify digital software signatures, which does not yet exist. See also Dev/OpenPGP Signed Website.

Effective Date

• Date of enforcement: This policy has always been enforced for Kicksecure. However, this elaborate technical description was added in April 2025. It was moved to its own dedicated wiki page at the end of July 2025.

Appendix

Other Projects - Digital Signature Policy

The following examples show that requiring digital signatures for source code, package uploads, packages, repositories, images, git tags, release artifacts, and build inputs is common in major free software projects. These examples are not identical to the Kicksecure policy, but they show that strict digital signature requirements are neither unreasonable nor uncommon.

• Debian package uploads: Debian FTP Master documents that unsigned .dsc files and files not signed with a key in the Debian keyring are rejected. Debian documents this as a requirement for both .changes and .dsc files.
• Debian developer keys: Debian's Developer Reference states that every developer needs an OpenPGP key in order to sign and verify package uploads.
• Qubes OS source code signing: Qubes OS requires all contributions to Qubes OS source code to be cryptographically signed by the author's PGP key.
• Qubes OS signed release artifacts: Qubes OS documents that important project assets, including ISOs, RPMs, TGZs, and Git objects, are digitally signed by an official team member key or release signing key. These keys are signed by the Qubes Master Signing Key.
• Qubes OS build source verification: QubesBuilder verifies signed tags on every downloaded code by default.
• Fedora package signing: Fedora release engineering documentation states that Fedora creates release signing keys to prove the authenticity of packages built and distributed by Fedora, and that the key is used to sign all packages for public test and final releases.
• Arch Linux package signing trust model: Arch Linux uses master signing keys for developer and package maintainer keys. Arch documents that official developers and package maintainers responsible for packaging software should have their key signed by at least three master keys.
• Arch Linux package verification: The pacman.conf manual documents SigLevel, LocalFileSigLevel, and RemoteFileSigLevel settings for package and database signature verification.
• Gentoo signed repository metadata: Gentoo documents that thick Manifests add checksums for all files in the repository and an OpenPGP signature, providing integrity and authenticity checking when the repository is transmitted over insecure channels.
• Gentoo upstream signature verification: Gentoo's verify-sig.eclass provides a standardized method to verify upstream signatures on distfiles, and its verification functions fail when signature verification fails.
• Linux kernel signed git tags and tarballs: Linux kernel documentation states that git repositories provide PGP signatures on all tags and tarballs provide detached PGP signatures with all downloads. It also explicitly emphasizes trusting developers rather than infrastructure after the 2011 kernel.org compromise.
• Yocto Project signed git tags: The Yocto Project signs release notes and git tags with a dedicated build and release GPG key. Its documentation also states that the key was generated on an air-gapped machine and that signing subkeys were transferred to Yubikey hardware tokens.
• Tails image signing key policy: Tails documents that its signing key is used to sign released images and certify other public keys needed for development. Tails also documents that the secret key material will never be stored on an online server or on systems managed by anyone other than Tails core developers.
• Tails download verification: Tails documents that software verification is critical, that HTTPS alone is insufficient when relying on mirrors, and that Tails provides OpenPGP signatures of downloads.
• Tor Browser release signing: The Tor Browser team signs Tor Browser releases, and Tor Project documentation instructs users to verify the corresponding OpenPGP .asc signature file.
• Tor source code release signing: Tor Project documentation states that digital signatures ensure that downloaded Tor source code was created by Tor developers and has not been tampered with.
• Nix binary cache signature enforcement: The Nix manual documents require-sigs, which is enabled by default and requires store paths copied or substituted from a binary cache to have a signature by a trusted key.
• openSUSE repository verification: openSUSE's Zypper documentation states that repository metadata authenticity is verified by checking GPG signatures. If repository metadata are not signed, the GPG signature of each downloaded RPM package is checked before accepting it for installation.
• OpenBSD signed releases and packages: OpenBSD documents that releases and packages are cryptographically signed with signify, that the installer verifies all sets before installing, and that pkg_add trusts only signed packages by default.
• FreeBSD signed release checksums: FreeBSD release announcements and release pages provide PGP-signed checksums for release images.

Upstream Feature Request - Signed Git

signed git tags / signed git commits

For better security, could you please sign all upcoming git commits and git tags?

It's useful in case github [gets hacked](http://www.extremetech.com/computing/120981-github-hacked-millions-of-projects-at-risk-of-being-modified-or-deleted) again in case [SSL CA's](https://en.wikipedia.org/wiki/DigiNotar) get [hacked](http://www.scmagazine.com/two-more-comodo-resellers-owned-in-ssl-hack/article/199620/) again.

> What about commits from other developers that submit pull requests?

In that case you just sign the merge commit. Therefore git master will always be some git commit signed by you, no matter if you merged commits by other developers.

References:

* https://github.com/blog/2144-gpg-signature-verification
* https://help.github.com/articles/signing-commits-with-gpg/
* http://mikegerwitz.com/papers/git-horror-story
* https://forums.whonix.org/t/security-git-general-verification-verifying-whonix-submodules/513/11

I think this makes sense. I've been signing my git commits by default lately, ever since I discovered I could my my ~/.gitconfig look like this:

~/.gitconfig

[user]
    name = Your Name
    email = example@example.com
    signingkey = signing-key-fingerprint

## Qubes
#[gpg]
    ## Qubes 'split-gpg-1'. Not for Qubes 'split-gpg-2'.
    #program = qubes-gpg-client-wrapper
    ## Sequoia-PGP sequoia-chameleon-gnupg
    ## (Compatible with 'split-gpg-2'.)
    #program = gpg-sq

[commit]
    gpgsign = true

List of Upstream Feature Requests - Signed Git

• https://github.com/onionshare/onionshare/issues/221
• https://github.com/annealmail/annealmail/issues/11

Footnotes

Dev/image formats Design Vulnerability Disclosure Policy Previous page: Dev/image formats Index page: Design Next page: Vulnerability Disclosure Policy

Kicksecure A secure by default operating system with the latest security research in place.

Dark mode

Follow us on social media

Supported by Power Up Privacy

Kicksecure is proudly supported until 2026 by Power Up Privacy, a privacy advocacy group that seeks to supercharge privacy projects with resources so they can complete their mission of making our world a better place. (Strictly subject to our sponsorship policy.)

At Kicksecure we value freedom and trust, supporting Open Source and Freedom Software

By using this website, you acknowledge you have read, understood, and agree to be bound by these agreements: Terms of Service, Privacy Policy, Cookie Policy, E-Sign Consent, DMCA, Imprint 2012- 2026 ENCRYPTED SUPPORT LLC

Your support makes
all the difference!

We believe security software like Kicksecure needs to remain Open Source and independent. Would you help sustain and grow the project? Learn more about our 14 year success story and maybe DONATE!