Christophe ColombierI like explaining things. I love the following proverb
Give a Man a Fish, and You Feed Him for a Day. Teach a Man To Fish, and You Feed Him for a Lifetime.
Let's talk about something that is often barely explained.
For anyone who started using git, you may have found the classic tutorial that starts with:
git config --global user.email you@domain.com
Then the fun begins in the tutorial.
There is an issue with these tutorials. They don't explain what is behind the hood.
So there is a email to set up. Why? Because an email is somehow a unique identifier. So user1@gmail.com is not user2@gmail.com
But there is big catch, it's a simple a label. Think about it now: Did you see anything in these tutorials about email verification process? No !
So it's a label, which means that at any time user2@gmail.com can send commits labeled as if they were written by user1@gmail.com by using git config user.email user1@gmail.com
Why is that possible? Because git is a tool. There is no authority behind it. git is not GitHub.
Which means that anytime an attacker could pretend to be one maintainer, just by changing the email, then send commits as a maintainer of a library, and another maintainer will approve the changes, thinking he knows who sent the commits. And here you create a security breach.
The situation is critical. That's why there is a way to secure your commits, in fact it doesn't secure the content of the commits (it does also, but that's another story) but it identifies the author as the legitimate ones.
This is what is called a signature.
There is only one way to do that. It's to refer to an authority.
Here are the main ways to get identified by these authorities
- GPG signing + gpg public severs
- SSH signing + git hosting provider
Both of them provide you a private and public key pair that will be used for identifying the committer is the owner of the key, and by extension the owner of the email, so his identity. The owner will sign the commits with his private key, and its public key will be public. The system is asymmetric. Only the owner has the private key, but everyone can check the commits were signed with it by using the public key.
GPG signing is supposed to be more secure, but it requires to understand things such as gpg, armor, private, expiration, revocational. GPG servers are public and interconnected, they replicate each other, it's part of the authority mechanismsm.
The second one is using SSH keys, plus a git hosting provider (GitHub, GitLab …). It's easy to generate SSH keys. Then these git hosting provider are using accounts. Each account is linked to an email, you use this email as an identifier plus a password (+2FA if you activated it). The website validated your email with a "verify email" mechanism once. So one email equals one identity.
These platforms allow you to link the public key with an account. So one account owns SSH or GPG public key. And because these platform already validated your email with a verification link, it becomes an authority, and why you get the "verified" badge by signing your commits.
The verified badge is not for ego, it's for security. But you can be proud of having a verified badge because security of these others matters to you.
Here is a tutorial I wrote about signing your commit with SSH:
This article was written by a Human. No AI were involved or hurt by writing this article.
