Don’t trust software, verify it

Summary

Software and digital security should rely on verification, rather than trust. I want to strongly encourage more users and consumers of software to verify curl. And ideally require that you could do at least this level of verification of other software components in your dependency chains. Attacks are omnipresent With every source code commit and every release of software, there are risks. Also entirely independent of those. Some of the things a widely used project can become the victim of, include… Jia Tan is a skilled and friendly member of the project team but is deliberately merging malicious content disguised as something else. An established committer might have been breached unknowingly and now their commits or releases contain tainted bits. A rando convinced us to merge what looks like a bugfix but is a small step in a long chain of tiny pieces building up a planted vulnerability or even backdoor Someone blackmails or extorts an existing curl team member into performing changes not otherwise accepted in the project A change by an established and well-meaning project member that adds a feature or fixes a bug mistakenly creates a security vulnerability. The website on which tarballs are normally distributed gets hacked and now evil alternative versions of the latest release are provided, spreading malware. Credentials of a known curl project member is breached and misinformation gets distributed appearing to be from a known and trusted source. Via email, social media or websites. Could even be this blog! Something in this list is backed up by an online deep-fake video where a known project member seemingly repeats something incorrect to aid a malicious actor. A tool used in CI, hosted by a cloud provider, is hacked and runs something malicious While the primary curl git repository has a downtime, someone online (impersonating a curl team member?) offers a temporary “curl mirror” that contains tainted code. In the event any of these would happen, they could of c...