1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
|
= GPG verification of Git repositories without TLS
:empty:
:git-protocol: https://git-scm.com/book/en/v2/Git-on-the-Server-The-Protocols#_the_git_protocol
:remembering: https://euandreh.xyz/remembering/
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}[remembering]footnote:not-available[
Funnily enough, not available anymore via the Git Protocol, now only with
HTTPS.
]:
[source,sh]
----
$ 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.
|
