{{Header}}
{{title|title=
{{project_name_short}} Digital Signature Policy
}}
{{#seo:
|description=todo
}}
{{verification_tools_mininav}}
{{intro|
todo
}}
= {{project_name_short}} 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 {{project_name_short}} has security level [[Verifying_Software_Signatures#System_Security_Level|System Security Level]] Always use software signatures verification
.
** Source code by {{project_name_short}} 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.
= {{project_name_short}} Build System - Digital Signature Policy =
* Build source code signature verification: All source code used to build {{project_name_short}} using [[Dev/Derivative-Maker|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 {{project_name_short}} must always use software digital signature verification.
** Download signature verification during build: When [[Dev/Derivative-Maker|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.
= {{project_name_short}} Downloads - Digital Signature Policy =
* Image signing: All images must always be signed.
* Repository signing: The package repository must always be signed.
= {{project_name_short}} 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 [[Dev/curl_bash_pipe|curl bash pipe]]
(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.
{{quotation
|quote=
{{Always verify signatures reminder}}
|context=[[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.
{{quotation
|quote=
{{Unsigned_software}}
|context=[[Template:Unsigned_software]] used on the following wiki pages: [[Special:WhatLinksHere/Template:Unsigned_software]]
}}
= Effective Date =
* Date of enforcement: This policy has always been enforced for {{project_name_long}}. 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 =
== 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] #program = qubes-gpg-client-wrapper [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 = {{reflist|close=1}} {{Footer}} [[Category:Documentation]] [[Category:Development]] [[Category:MultiWiki]]