GitHub’s green “Verified” badge on signed commits isn’t decoration. It’s cryptographic proof your code came from you, not an impersonator with git config user.name "Linus Torvalds". Supply chain attacks jumped 742% in 2025, targeting developer workflows. Moreover, ByteIota covered WordPress plugin backdoors hitting 30+ plugins. Signed commits prevent this attack vector.
GPG seems intimidating. Comprehensive guides span 377 pages. Most developers skip it entirely. However, this tutorial delivers practical GPG setup in under 30 minutes: Ed25519 key generation, Git commit signing, SSH authentication, and file encryption. Copy-paste commands. 2026 defaults. No security theater.
Why GPG Matters for Developers
Anyone can set git config user.email to anything. Literally anything. GitHub doesn’t verify commit authorship unless you sign with GPG. That green “Verified” badge proves cryptographic ownership.
Beyond vanity, GPG solves real problems. First, Git commit signing verifies code provenance, which is critical for supply chain security. Second, SSH authentication with the same key provides unified key management with fewer files to secure. Third, file encryption protects credentials and .env files. Finally, signed releases prevent package tampering.
More projects now require signed commits in CONTRIBUTING.md. Enterprise teams mandate it. If you push code, you need GPG setup. Modern setup takes 20 minutes.
Ed25519: The 2026 Default
Old GPG tutorials push RSA. Ignore them. Ed25519 is the 2026 standard for GnuPG 2.5.x and every major cloud provider.
Ed25519 delivers equivalent security to 3072-bit RSA with just 256-bit keys. It generates instantly, whereas RSA takes seconds for 4096-bit keys. Additionally, signature verification is faster. The algorithm is immune to RNG-based attacks through deterministic signing. If you’re starting fresh in 2026, Ed25519 is the only choice.
RSA requires minimum 4096-bit keys for current security standards. Smaller RSA keys are deprecated. Use Ed25519 unless you’re stuck with legacy systems that don’t support it.
Generate Your Ed25519 GPG Key
Most Linux distros ship GnuPG 2.5.x. macOS users: brew install gnupg. Start the interactive key generation:
gpg --full-generate-key
Select these options when prompted:
- Key type: (9) ECC (sign and encrypt)
- Curve: (1) Curve 25519
- Expiration: 2y (keys should expire; you can extend later)
- Real name: Your actual name (GitHub displays this)
- Email: Verified GitHub email address
- Passphrase: Strong passphrase (or use YubiKey PIN later)
Next, list your keys to grab the KEY_ID (the hex string after sec):
gpg --list-secret-keys --keyid-format=long
Then, export the public key for GitHub:
gpg --armor --export YOUR_KEY_ID
Copy the entire output (including -----BEGIN PGP PUBLIC KEY BLOCK----- headers). Go to GitHub → Settings → SSH and GPG keys → New GPG key. Paste. Save.
Configure Git to Auto-Sign Commits
Tell Git which key to use:
git config --global user.signingkey YOUR_KEY_ID
git config --global commit.gpgsign true
Now every commit signs automatically. Test it:
git commit -m "First signed commit"
git log --show-signature
Push to GitHub. Check the commit page. Green “Verified” badge. Done.
If Git complains about gpg: signing failed: No secret key, your user.email in Git config must match the email in your GPG key. GitHub’s official documentation covers troubleshooting.
SSH Authentication with GPG
Why maintain separate SSH keypairs when your GPG key can handle both signing and authentication? Configure gpg-agent to replace ssh-agent:
echo "enable-ssh-support" >> ~/.gnupg/gpg-agent.conf
gpgconf --kill gpg-agent
Subsequently, export your SSH public key from the GPG key:
gpg --export-ssh-key YOUR_KEY_ID > ~/.ssh/gpg.pub
Add this to your shell profile (~/.bashrc or ~/.zshrc):
export SSH_AUTH_SOCK=$(gpgconf --list-dirs agent-ssh-socket)
Reload your shell (source ~/.bashrc). Then, copy the contents of ~/.ssh/gpg.pub and add it to GitHub → Settings → SSH and GPG keys → New SSH key. Same process for servers (authorized_keys).
Finally, test SSH authentication:
ssh -T git@github.com
If it works, you’re authenticating with your GPG key. One key for Git signing and SSH. Unified key management means fewer files to back up and secure.
File Encryption for Developers
GPG encrypts files. Practical use case: never commit plaintext .env files to Git. Encrypt them instead.
Symmetric encryption (password-based, quick):
gpg -c .env
This creates .env.gpg (password-protected). Consequently, add .env.gpg to Git. Add .env to .gitignore. Decrypt when needed:
gpg -d .env.gpg > .env
Asymmetric encryption (public key, for team sharing):
gpg --encrypt --recipient alice@example.com secrets.txt
Encrypt for multiple recipients:
gpg -e -r alice@example.com -r bob@example.com file.txt
Any recipient with their private key can decrypt. Great for sharing credentials across teams without Slack messages. Red Hat’s GPG encryption guide covers advanced use cases.
YubiKey Integration (Optional)
YubiKey stores your GPG private key on hardware. The key never touches disk. Signing and encryption happen on the YubiKey. Even if your computer is compromised, the private key can’t be extracted. Furthermore, you set PIN protection and physical touch policies.
Setup requires moving your key to the YubiKey with keytocard. This command is destructive—once the key moves, it’s gone from your computer. Make backups first.
YubiKey setup is beyond this tutorial’s scope. If you need hardware-level security (FOSS maintainers, enterprise compliance, paranoid devs), start with drduh’s YubiKey-Guide (12K+ stars, comprehensive). OneUptime’s 2026 YubiKey GPG guide covers Ubuntu setup.
You’re Done
You now have: Ed25519 GPG key following 2026 standards, Git commits that display “Verified” on GitHub, SSH authentication using the same GPG key, and file encryption for protecting credentials.
Sign your next commit. The green badge is one git commit away. For more GPG details, GnuPG’s official documentation is comprehensive (if overwhelming).
Supply chain security isn’t optional anymore. You just made your workflow harder to compromise.

