Автор коміту в Git нічим не підтверджений. Поля user.name і user.email будь-хто може встановити довільно:
git -c user.name="Taylor Otwell" -c user.email="taylor@laravel.com" commit -m "Totally legit"
GitHub покаже цей коміт з аватаркою власника пошти. Підпис - криптографічне підтвердження, що коміт створив власник ключа, і що вміст не змінювали після підписання.
Налаштування з SSH-ключем (простіше, ніж GPG, з Git 2.34):
git config --global gpg.format ssh
git config --global user.signingkey ~/.ssh/id_ed25519.pub
git config --global commit.gpgsign true
git config --global tag.gpgsign true
Той самий публічний ключ додається на GitHub як Signing key (окремо від ключа автентифікації, навіть якщо файл той самий). Після цього коміти отримують позначку Verified.
Локальна перевірка підписів потребує файлу довірених ключів:
git config --global gpg.ssh.allowedSignersFile ~/.config/git/allowed_signers
git log --show-signature
git verify-commit HEAD
GPG чи SSH:
| GPG | SSH | |
|---|---|---|
| налаштування | складніше: окремі ключі, агент, термін дії | ключ, який уже є |
| відкликання й термін дії | вбудовані | немає (лише видалити ключ з GitHub) |
| підтримка | старі версії Git | Git 2.34+ |
Що підпис дає команді:
- branch protection «Require signed commits» - у захищену гілку не потрапить непідписаний коміт;
- захист ланцюга постачання: зловмисник з викраденим токеном push не підробить підпис без приватного ключа;
- аудит у регульованих галузях.
Пастки:
- коміти, створені на GitHub (злиття через інтерфейс, редагування в браузері), підписує ключ GitHub - вони теж Verified;
- після rebase чи squash коміти перестворюються - їх підписує той, хто виконує операцію, з власним ключем;
- режим vigilant на GitHub позначає непідписані коміти з вашою поштою як Unverified, щоб підробку було помітно;
- ключ на ноутбуці без пароля - слабке місце; краще апаратний ключ (YubiKey) чи ключ у менеджері паролів з агентом SSH.
Докладніше в документації: GitHub: перевірка підпису комітів
