Accordling to SNYK, on March 24, 2026, two versions of the LiteLLM Python package on PyPI were found containing malicious code. This attack used a three stages payload.
In the first stage, it collected among other things, system credentials as SSH private keys were stolen.
The credentials often don't expire, they are easily copied and they are an active target for malware. We are going to solve this problem storing the credentials out of a potential compromised machine.
Five aspects to improve commit traceability in FOSS projects:
1 DCO (Signed-off-by), creating a chain of custody for patches.
Each handler in the contribution pipeline adds their attestation via a Signed-off-by line,documenting everyone who touched the patch from author to final merge.
Main references:
- Linux Kernel Documentation - Submitting Patches https://docs.kernel.org/process/submitting-patches.html
- Kyle Mitchell, "The Developer Certificate of Origin is Not a Contributor License Agreement" (2021) https://writing.kemitchell.com/2021/07/02/DCO-Not-CLA
- Better Software, "The Developer Certificate of Origin" https://bssw.io/items/the-developer-certificate-of-origin
2 Issue-Commit linking
It links commits to issues connects code changes to their motivation and requirements. Despite its importance, research shows this practice is frequently missing or broken in open source projects.
Main references:
- Parveen et al., "Towards Effective Automation of Issue-Commit Link Recovery: An Empirical Investigation" (PROFES 2025) https://link.springer.com/chapter/10.1007/978-3-032-12089-2_15
- "Establishing Traceability between Release Notes & Software Artifacts" (2025) https://arxiv.org/html/2511.18187v1
- Hata et al., "18 Million Links in Commit Messages: Purpose, Evolution, and Decay" (Empirical Software Engineering, 2023) https://link.springer.com/article/10.1007/s10664-023-10325-8
3 GPG/SSH Commit Signing
Cryptographic signing provides authenticity and non-repudiation. Withoutit, Git identity is just free-form text that anyone can forge.
Main References:
- "Attributing Open-Source Contributions is Critical but Difficult" (NDSS 2025) https://www.ndss-symposium.org/wp-content/uploads/2025-613-paper.pdf
- Konstantin Ryabitsev, "What does a PGP signature on a git commit prove?" (kernel.org) https://people.kernel.org/monsieuricon/what-does-a-pgp-signature-on-a-git-commit-prove
- "Analysis of Commit Signing on GitHub" (arXiv, 2026) https://arxiv.org/html/2604.14014
- "On the Prevalence and Usage of Commit Signing on GitHub: A Longitudinal and Cross-Domain Study" (EASE 2025) https://dl.acm.org/doi/10.1145/3756681.3756959
4 Pull Requests with Code Review
Pull requests create a public record of why a change was accepted, not just what changed. Code review in open source works through mechanisms of accountability, transparency, and shared ownership.
Main references:
- Alami et al., "Why Does Code Review Work for Open Source Software Communities?" (ICSE 2019) https://dl.acm.org/doi/10.1145/2957792.2957801
- "A Large-Scale Study of Modern Code Review and Security in Open Source Projects" (UC Berkeley, 2017) https://people.eecs.berkeley.edu/~daw/papers/coderev-promise17.pdf
- Afzali et al., "Towards Verifiable Web-Based Code Review Systems" (NJIT) https://web.njit.edu/~crix/publications/ios-jcs22.pdf
5 Mailing Lists as Permanent Discussion Record (not just Slack or Discord)
Mailing lists serve as a persistently stored institutional memory,
preserving the rationale behind every change for future readers.
Even having the possibility to keep all the data,using Slack or Discord for this discussion makes hard for someone or an organization using your code to trace the origin of the need of your commits.
Main References:
- Linux Kernel Documentation - Submitting Patches https://docs.kernel.org/process/submitting-patches.html
- Ramsauer et al., "A Multi-Level Dataset of Linux Kernel Patchwork" (MSR 2018, ACM) https://dl.acm.org/doi/abs/10.1145/3196398.3196475
- "Differentiating Communication Styles of Leaders on the Linux Kernel Mailing List" (OpenSym 2016, ACM) https://dl.acm.org/doi/10.1145/2957792.2957801
- LWN.net discussion on LKML archiving and traceability https://lwn.net/Articles/950567/
This article focuses on storing, signing and protecting your credentials with a YubiKey 5 in your development workflow (the 3rh aspect).
Starting with the basics, we are going to setup a typical Fedora Workstation. For this, we need:
Fedora packages
sudo dnf install gnupg2 opensc pcsc-lite
To make PGP work, you need to configure scdaemon inside ~/.gnupg/scdaemon.conf:
disable-ccid
pcsc-shared
Without those changes, GPG doesn't find the Yubikey and you may get errors like "No such device" or "Card error".
gpg --batch --passphrase '' --yes --pinentry-mode loopback \
--generate-key <<EOF
%no-protection
Key-Type: RSA
Key-Length: 2048
Subkey-Type: RSA
Subkey-Length: 2048
Name-Real: Your Name
Name-Email: your.name@provider
Expire-Date: 2y
%commit
EOF
The above CLI creates a gpg key with "Your Name" and "your.name@provider" as your e-mail, within a 2 years expire date.
Moving it now to the Yubykey:
gpg --edit-key <KEY_ID>
gpg> keytocard (chave principal -> slot 1: Signature)
gpg> key 1
gpg> keytocard (subchave -> slot 2: Encryption)
gpg> save
Finally, export your pubkey to make people able to find it, and confirm your identity:
gpg --armor --export HASH
Following these steps, you are now able to use it to sign your commits and e-mails.
git
Now it is time to configure git to sign your commits and verify them when pushing to Github or Gitlab.
git config --global user.signingkey **hash**
git config --global commit.gpgsign true
Daily Usage
To use it in your daily workflow, it needs to be connected. GPG will ask for the OpenPGP PIN at the first use in the session.
In order to verify the signature,
git log --show-signature -1
To sign a tag:
git tag -s v1.0 -m "Release 1.0"
To export the SSH from GPG, export it using:
gpg --export-ssh-key <KEY_ID>
It creates the public and private key to use in the Github/Gitlab server.
Then, configure gpg-agent to be used as the SSH agent:
cat ~/.gnupg/gpg-agent.conf << EOF
enable-ssh-support
EOF
Configure your shell to use the gpg-agent instead of ssh-agent. For zshell,
cat ~/.zshrc << EOF
export GPG_TTY=$(tty)
export SSH_AUTH_SOCK=$(gpgconf --list-dirs agent-ssh-socket)
gpgconf --launch gpg-agent
EOF
Restart gpgconf:
gpgconf --kill gpg-agent
gpgconf --launch gpg-agent
Verify if ssh is seeing the key:
ssh-add -L
Known GPG bugs and workarounds
"No such device" / "Card error":
gpgconf --kill scdaemon
gpgconf --kill gpg-agent
Verify ~/.gnupg/scdaemon.conf, then disable-ccid, and pcsc-shared
Also, verify if pcscd is running:
systemctl status pcscd
Bad PIN:
Try to clean the cache
gpgconf --kill gpg-agent
Verify the number of remaining tries:
ykman openpgp info
"Segfault": --pinentry-mode loopback may cause a segfault with GPG 2.4.9, with card-edit generate. You need to create the key inside the computer and then move it to the yubikey.
Bonus: Configuring Thunderbird (flatpak)
Close it, and edit prefs.js (~/.var/app/org.mozilla.thunderbird/.thunderbird/n5yyk2sx.default-release/)
Add to prefs.js:
user_pref("mail.openpgp.allow_external_gnupg", true);
user_pref("mail.identity.id1.is_gnupg_key_id", true);
user_pref("mail.identity.id1.last_entered_external_gnupg_key_id", "HASH");
user_pref("mail.identity.id1.openpgp_key_id", "HASH");
Or using Thunderbird itself:
Enable the external GnuPG keys:
Settings > Config Editor > Find:
mail.openpgp.allow_external_gnupg > change to trueAccount Settings > End-To-End Encryption > Add Key
Select "Use your external key through GnuPG"
Paste the Key ID: HASHIf it asks for a public key:
Click "Select File to Import..."
Go to ~/.ssh/gpg_public_key.ascMark "Sign unencrypted messages" to sign by default.
I do recomend using ykman insted of the gpg directly. Yakman directly access the yubikey without passing through pinetry, wich is used by gpg. This can help to avoid some kinds of problems like having pinetry frozen when typing a PIN.
Now we have everything configured. But the last and most important step is verifying the key. Shittu et al. (2026), in their paper Analysis of Commit Signing on GitHub, state that, "For non-UI commits, verification failures are dominated by unknown key (73.73% of failures), meaning the signing key used for the commit is not registered with any GitHub account". So it is important to export your key and/or make sure that the users have access to a secure way to verify that the commit comes from a trusted source.
Doing that, we have secured one of the 5 main steps to prevent a supply chain attack.
