For greater system security the installation of unsigned software should be avoided at all costs. Instead it is recommended to:
- Only install verifiable software that allows for confirmation of signing keys and signatures; and/or
- Use mechanisms that heavily simplify and automate this process, like apt upgrades.
Check the GPG signature timestamp makes sense. For example, if you previously saw a signature from 2020 and now see a signature from 2019, then this might be a targeted rollback (downgrade) or indefinite freeze attack. 
Note: OpenPGP signatures sign files, but not file names. 
Checking Digital Fingerprints of Signing Keys
A critical first step in verifying software is legitimate is confirmation that the signing key is authentic -- this requires inspection of the key fingerprint.  Always perform this operation before keys are imported or trust is placed in OpenPGP output when verifying files or repositories.
The standard Kicksecure ™ wiki advice is to carefully obtain copies of the OpenPGP fingerprint from multiple secure websites and to use other authentication systems to check they match.  In this instance, "other authentication systems" refers to: 
- Use the The OpenPGP Web of Trust.
- Check the key against different keyservers.
- Use different search engines to search for the fingerprint.
- Use various VPNs and proxy servers.
- Use different Wi-Fi networks (work, school, internet cafe, etc.).
- Ask people to post the fingerprint in various forums and chat rooms.
- Check against PDFs and photographs in which the fingerprint appears (e.g., slides from a talk or on a T-shirt).
- Repeat all of the above from different computers and devices.
- See also Bootstrapping OpenPGP keys from the web.
Checking Digital Fingerprints of Signed Software
Before file signatures can be safely verified with the signing key, several prerequisites must be met:
- The correct signing key pair was downloaded.
- The signing key's fingerprints were checked against multiple sources.
- The key pair was imported e.g:
user@host:~/Downloads$ gpg --import KEY gpg: key 61B7B526D98F0353: 24 signatures not checked due to missing keys gpg: key 61B7B526D98F0353: public key "Mozilla Software Releases <firstname.lastname@example.org>" imported gpg: Total number processed: 1 gpg: imported: 1 gpg: no ultimately trusted keys found
- The software package intended for installation was downloaded.
- The accompanying signature file for the software package (.asc files are GPG signatures) was downloaded.
The following example shows how the file signature is checked for Firefox v97.0.1, directly downloaded from The Mozilla Firefox website.
In a terminal run.
The OpenPGP output should show a "good signature", with the primary key fingerprint matching the one verified by the user earlier on. In this example.
gpg: Signature made Wed 16 Feb 2022 06:52:12 PM GMT gpg: using RSA key 4360FE2109C49763186F8E21EBE41E90F6F12F6D gpg: Good signature from "Mozilla Software Releases <email@example.com>" [unknown] gpg: WARNING: This key is not certified with a trusted signature! gpg: There is no indication that the signature belongs to the owner. Primary key fingerprint: 14F2 6682 D091 6CDD 81E3 7B6D 61B7 B526 D98F 0353 Subkey fingerprint: 4360 FE21 09C4 9763 186F 8E21 EBE4 1E90 F6F1 2F6D
The software can now be safely installed. If the output states "bad signature", then the files and digital signatures should be removed and downloaded again.
What Digital Signatures Prove
Bear in mind that using digital signatures to verify the trustworthiness of software is not an infallible process. Digital signatures increase the certainty that no backdoor was introduced by a third party during transit, but this does not mean the software is absolutely "backdoor-free". The following is a summary of what digital signatures prove and do not prove.
Table: Digital Signatures Properties
|Digital Signatures Prove||
|Digital Signatures do not Prove||
If all files downloaded from trusted vendors are verified, then this removes the threat of server compromises, dishonest staff at hosting companies or ISPs, Wi-Fi attacks and so on. The reason is files that have been tampered with will produce bad digital signatures, so long as the public keys used for signature verification are the authentic, original ones (see below).
System Security Level
System security level can be placed into one of three categories. From strongest to weakest these are:
Always use software signatures verification: software signatures are always verified with OpenPGP, codecrypt, APT or similar mechanisms.
Always use TLS: files are always securely downloaded over TLS.
If software was ever installed or started that did not previously successfully verify software signatures, then the system security level is reduced from the OpenPGP standard to either TLS or even the plaintext standard.
Unless a Disaster Recovery Procedure is utilized, it is impossible to increase the security level of a machine or VM (for example, from TLS to the OpenPGP standard).
If the reader shares the Kicksecure ™ opinion that Transport Layer Security (TLS) provides a weak safeguard, then software signatures must be consistently verified and without exception.
Conceptual Challenges in Digital Signatures Verification
Many educational shortcomings exist with respect to verification of software digital signatures. In the relevant literature, a number of implicit assumptions are made which are seldom spelled out. Unless users are properly educated beforehand, it is unrealistic to expect the majority can successfully verify software signatures and simultaneously notice attacks by advanced adversaries.
When digitally signed software is made available, most often the relevant website will simply state the signing key should be downloaded in order to verify software signature(s). This approach has limited usefulness and kicksecure.com is not alone in this regard -- the same is true for any software that provides software signatures.
Due diligence in verification of software signatures falls wholly upon users, and cannot be offered by vendors who make software and associated signatures available for download. The reason is the threat model of software signature verification is intimately linked with the system security level; this section attempts to make this explicit.
Threat Model Assumptions
In this threat model, signing keys and software signatures are considered to provide a higher security level. On the other hand, everything the user can see on a website (including instructions) is on a lower security level because (OpenPGP) signed websites do not exist yet. Further, TLS provides a lower security level than verification of digital software signatures.
Consider an example of signed software that is available on a random website that is secured by TLS (in this very example TLS vs non-TLS does not even matter). In this hypothetical case, due to the software's file size and economic shortcomings it is impossible to host the software downloads on the same server. Instead, downloads are offered on a mirror network operated by third parties. In such an example it could be argued that mirrors are less trusted than the main project website. In the event the main website offered a signing key, but a malicious file was shipped by a third party mirror, then it could be detected if software signature verification was utilized by the user.
In other cases the software downloads, signing key and software signatures are all provided by the same server over TLS; this is the situation for Kicksecure ™ and other projects.  While this may appear more secure than the first example, no project can guarantee that its server will never be compromised; see Distrusting Infrastructure for further details.
The preceding discussion makes it clear that is unwise to blindly trust whatever a project website says about software signature verification. Relevant threat model questions include:
- What if the website I am currently viewing is already compromised?
- What if a malicious third party has already modified instructions concerning how to verify signatures or which signing key should be used?
Also, after compromising a project web server, advanced adversaries are capable of showing fake website contents to specifically targeted users.
Potential Adversary Attacks
Competent adversaries are capable of various attacks, including malicious modifications of a project website. Consider the following vectors:
- Removal of any mention of software signature verification and replacement of software downloads with malicious counterparts.
- Users who have never heard about software verification would fail to notice this, leading to compromise.
- Users who already understood the threat model of digital software verification and wanted to enforce the security level "always use software signatures verification" would ask for software signatures and remain safe.
- Insertion of false information such as "From now on, software signatures are no longer required. This process is now automated, because ...".
- Gullible users would believe this statement and be compromised.
- Diligent users would search for a digitally signed message by the vendor confirming this change. If it was not found, they would report the issue and remain safe.
- Replacing the genuine signing key and software signatures with a signing key and software signatures created by the adversary.
- Users who did not previously receive the signing key and who did not do further research the plausibility of having received the correct signing key would fail to not notice this and be compromised.
- Diligent users would follow the recommendations in earlier chapters on this page and therefore stay safe.
To counter these threats, user intelligence and due diligence is necessary as a sanity check.
Due to the complexity of this issue and very low user awareness, it is unlikely the majority of users are enforcing the "always use software signatures verification" security level. To date, the author of this section has not seen the security level concept explicitly described elsewhere, probably because the relevant information is not widely known. Unfortunately, the existing tools used for manual verification of software signatures have poor usability and better technical solutions that are required do not exist.
Information Security Level
Information security level (similar to system security level) can be placed into one of three categories. From strongest to weakest these are:
signatures verification: signatures are verified with OpenPGP, codecrypt, or similar mechanisms.
TLS: information was received over TLS.
Other properties and categories are conceivable as well. Such as for example:
- Third party server not involved or cannot due to security by design tamper with information.
- Offline signing key.
Attacks in the Wild
Cryptocurrency Theft via Compromised Binaries
In late 2019, malware was in operation that led to the theft of funds from Monero users:
- Security Warning: CLI binaries available on getmonero.org may have been compromised at some point during the last 24h.
- Warning: The binaries of the CLI wallet were compromised for a short time
- Wrong hashes (from getmonero.org)
- Monero download site and binaries compromised
Fake Tor Browser
To illustrate the risk of installing unsigned software, consider the following attack which recently used a "trojanized" Tor Browser to spy on users and to steal Bitcoin. This attack had several elements:  
- Advertisements for the fake Tor Browser were used in Russian forums focused on privacy, censorship circumvention, darknet markets and cryptocurrencies.
- Messaging included promises to circumvent Russian censorship bodies and to bypass CAPTCHAs.
- Links were provided to fake domains for downloading Tor Browser (
torproect.org), instead of the genuine website:
- After visiting the fake websites, users received warnings their Tor Browser was outdated (regardless of the reality). Users who believed this message were redirected to another website with an installer.
- The malicious Tor Browser version downloaded was older (version 7.5) than the current release (9.0 at the time of writing), and had disabled the digital signature check for installed Tor Browser add-ons (
xpinstall.signatures.requiredwas set to false). It had also renamed the updater tool to prevent victims updating to a legitimate version of Tor Browser.
- The Tor proxy was used in the browser, anonymizing the user's IP address. However, users could be spied upon because a custom user-agent (text-based identifer) was set that allowed the software and operating system to be visible -- a unique browser fingerprint made tracking by network observers possible.
- Attackers had bundled HTTPS Everywhere with a modified
manifest.jsonfile. This permitted the web extension to have broader permissions and to add content scripts that were loaded into various web pages. As a consequence, a Command and Control server could load further scripts when users browsed on certain Darknet markets and a commonly used Russian money transfer service (QIWI) -- changing cryptocurrency wallet addresses to match an addressed controlled by criminals in order to steal money.
This highlights the possible dangers of installing unsigned software -- loss of anonymity and financial loss in this case. If the victims had instead only installed signed Tor Browser software from trusted and known sources after: verifying they had the correct key pair, confirming the key's fingerprints, and checking the signature file for the software package matched, then they could have bypassed this scam entirely.
- 1.) 2012 Unauthorized github repository write access: https://github.blog/2012-03-04-public-key-security-vulnerability-and-mitigation/ 
- 2. 2014 https://homakov.blogspot.com/2014/02/how-i-hacked-github-again.html 
- 3.) 2022 Hacked logins and private github repository data leak: Mike Hanley, Chief Security Officer at GitHub, wrote in a blog post:
We have high confidence that compromised OAuth user tokens from Heroku and Travis-CI-maintained OAuth applications were stolen and abused to download private repositories belonging to dozens of victim organizations that were using these apps. Our analysis of other behavior by the threat actor suggests that the actors may be mining the downloaded private repository contents, to which the stolen OAuth token had access, for secrets that could be used to pivot into other infrastructure.
- Placing Trust in Kicksecure ™
- Verify the virtual machine images
- Kicksecure ™ Signing Key
- Software Signature Verification Usability Issues and Proposed Solutions
Gratitude is expressed to Qubes OS (Permission). The What Digital Signatures Prove chapter contains content from the Qubes OS: What do the Digital Signatures Prove and What They DO NOT Prove page.
- As defined by TUF: Attacks and Weaknesses:
- For example, anybody could generate an OpenPGP key pair and pretend to be the "Kicksecure ™ Project", but only Patrick Schleizer's key pair is legitimate.
- Website checks are only as secure as the imperfect TLS system, which is itself based on certificate authorities that have been frequently compromised in recent years.
- Digital signatures are still useful in this case, because it is possible to limit trust to a few select people/organizations such as Kicksecure ™ developers.
- Kicksecure ™ also offers all three components over .onion; see also Download Security.