path: root/_tils/2021-07-23-gpg-verification-of-git-repositories-without-tls.md

---

title: GPG verification of Git repositories without TLS

date: 2021-07-23

layout: post

lang: en

ref: gpg-verification-of-git-repositories-without-tls

---

For online Git repositories that use the [Git Protocol] for serving code, you
can can use GPG to handle authentication, if you have the committer's public
key.

Here's how I'd verify that I've cloned an authentic version of [remembering]:

```shell
$ wget -qO- https://euandre.org/public.asc | gpg --import -
gpg: clef 81F90EC3CD356060 : « EuAndreh <eu@euandre.org> » n'est pas modifiée
gpg:       Quantité totale traitée : 1
gpg:                 non modifiées : 1
$ pushd `mktemp -d`
$ git clone git://euandreh.xyz/remembering .
$ git verify-commit HEAD
gpg: Signature faite le dim. 27 juin 2021 16:50:21 -03
gpg:                avec la clef RSA 5BDAE9B8B2F6C6BCBB0D6CE581F90EC3CD356060
gpg: Bonne signature de « EuAndreh <eu@euandre.org> » [ultime]
```

On the first line we import the public key (funnily enough, available via
HTTPS), and after cloning the code via the insecure `git://` protocol, we use
`git verify-commit` to check the signature.

The verification is successful, and we can see that the public key from the
signature matches the fingerprint of the imported one.  However
`git verify-commit` doesn't have an option to check which public key you want
to verify the commit against.  Which means that if a MITM attack happens, the
attacker could very easily serve a malicious repository with signed commits,
and you'd have to verify the public key by yourself.  That would need to happen
for subsequent fetches, too.

Even though this is possible, it is not very convenient, and certainly very
brittle.  Despite the fact that the Git Protocol is much faster, it being harder
to make secure is a big downside.



[Git Protocol]: https://git-scm.com/book/en/v2/Git-on-the-Server-The-Protocols#_the_git_protocol
[remembering]: https://euandreh.xyz/remembering/