În configurația sa implicită, Git nu oferă nicio garanție criptografică a identității autorului unui commit. Oricine poate rula local comenzile git config user.name "Linus Torvalds" și git config user.email "torvalds@linux-foundation.org" și poate trimite un commit ce pare a fi scris de fondatorul Linux. Fără semnătură digitală, orice atacator care obține acces la un cont sau trimite un Pull Request poate impersona identitatea unui dezvoltator respectat din echipă.
1. Semnarea Modernă a Commit-urilor cu Chei SSH (Metoda Recomandată în Git 2.34+)
Până la apariția versiunii Git 2.34, dezvoltatorii erau obligați să utilizeze GPG (GNU Privacy Guard) — un sistem greoi și complex de gestionat. Astăzi, puteți folosi direct aceeași cheie privată SSH (de tip Ed25519) pe care o utilizați deja pentru autentificarea la GitHub sau serverele Linux!
# 1. Verificăm cheia SSH publică existentă (sau generăm una nouă cu ssh-keygen -t ed25519):
cat ~/.ssh/id_ed25519.pub
# 2. Setăm Git să folosească SSH ca format de semnare criptografică:
git config --global gpg.format ssh
# 3. Specificăm calea către cheia voastră publică (sau direct string-ul cheii):
git config --global user.signingkey ~/.ssh/id_ed25519.pub
# 4. (Opțional, recomandat): Activăm semnarea automată a fiecărui commit nou:
git config --global commit.gpgsign true
# 5. Activăm și semnarea automată a tag-urilor de lansare:
git config --global tag.gpgSign true
După configurare, orice comandă git commit -m "..." va include automat o semnătură criptografică validată prin cheia privată SSH corespunzătoare.
2. Adăugarea Cheii de Semnare în GitHub / GitLab
Pentru ca platformele de colaborare să afișeze insigna verde „Verified” în dreptul modificărilor voastre:
- Copiați conținutul cheii publice:
pbcopy < ~/.ssh/id_ed25519.pub(pe macOS) saucat ~/.ssh/id_ed25519.pub. - Accesați setările contului: Settings -> SSH and GPG keys.
- Apăsați pe New SSH Key, iar la meniul derulant Key type selectați obligatoriu Signing Key (nu doar Authentication Key).
- Salvați cheia. De acum, fiecare commit trimis va purta bifa verde de autenticitate garantată!
3. Verificarea Semnăturilor în Terminal
# 1. Vizualizarea istoricului complet cu detaliile semnăturilor:
git log --show-signature -n 3
# Exemplu de ieșire validă SSH:
# Good "git" signature for user@exemplu.ro with ED25519 key SHA256:xYz...
# 2. Verificarea unui commit specific:
git verify-commit <hash-commit>
# 3. Verificarea autenticității unui tag de lansare oficială:
git verify-tag v1.0.0
4. Alternativa Tradițională: Semnarea cu Chei GPG
Dacă politica companiei impune utilizarea unei infrastructuri PKI pe bază de chei PGP/GPG:
# 1. Generare pereche de chei GPG (alegeți RSA 4096 biți sau Ed25519):
gpg --full-generate-key
# 2. Listarea ID-ului cheii nou generate:
gpg --list-secret-keys --keyid-format=long
# Ieșire: sec rsa4096/3AA5C34371567BD2 2024-01-15 [SC]
# ID-ul este: 3AA5C34371567BD2
# 3. Configurarea cheii în Git:
git config --global user.signingkey 3AA5C34371567BD2
git config --global commit.gpgsign true
# 4. Exportarea cheii publice pentru GitHub/GitLab:
gpg --armor --export 3AA5C34371567BD2
5. Reguli de Protecție a Ramurilor (Branch Protection Rules)
Semnarea commit-urilor devine cu adevărat puternică atunci când este impusă prin politici la nivelul depozitului remote (GitHub, GitLab sau Bitbucket):
- Require signed commits: Serverul va respinge automat prin eroare (
rejected - commit not signed) orice încercare de push a unui commit neînsoțit de o semnătură criptografică validă. - Require pull request before merging: Blochează trimiterea directă (push) pe ramurile critice (
main,production). Orice modificare trebuie să treacă printr-un PR. - Require approvals: Impune recenzia obligatorie a cel puțin 1-2 colegi seniori înainte ca fuziunea să fie permisă.
- Require status checks to pass: Obligă rularea cu succes a tuturor testelor automate din pipeline-ul de CI (lintere de cod, teste de securitate SAST, suite de teste unitare).
- Include administrators: Asigură că nici măcar posesorii sau administratorii depozitului nu pot sări peste regulile de securitate stabilite.
6. Prevenirea Scurgerii de Secrete cu Pre-Commit Hooks
Pentru a împiedica un coleg să comită accidental fișiere .env cu parole de producție sau chei API Stripe în Git, configurați un hook local automat de tip gitleaks sau detect-secrets:
# Instalare gitleaks:
brew install gitleaks # pe macOS
# sau descărcare binar pe Linux
# Testare depozit pentru secrete comise în trecut:
gitleaks detect --verbose
# Protecție automată înainte de fiecare commit:
gitleaks protect --verbose --staged