@@ 177,6 177,8 @@ After the previous steps, the client MAY access the `gwit.ini` file in the `HEAD
**Note:** Example commands using `git verify-commit --raw <COMMIT>` report the fingerprint of the *primary key* of the key used to sign the commit. An alternative approach would be to get the signing key (e.g. `git show --no-patch --format=format:%GK <COMMIT>` as `<SIG-KEY>`), check that it is (a subkey of) the key that matches `<SITE-ID>` (e.g. `gpg --homedir <CLIENT-GPG-DIR> --list-keys --with-fingerprint --with-colons <SIG-KEY> | grep -A1 '^pub:' | grep -qiE '^fpr:+<SITE-ID>:$'`), then just run `git verify-commit <COMMIT>`.
**Note:** Since Git commits are immutable, a gwit client MAY keep a cache of commits for which it has already verified that they have a valid signature from the expected key, so as to avoid the potentially expensive operation of signature verification (e.g. the invocation of `git verify-commit` ).
### Site updates
If someone wants to retrieve updates to a gwit site identified by `<SITE-ID>` for which they already have a Git clone in persistent client storage, the gwit client MUST choose one of its remotes `<REMOTE>`, fetch new items from it (including site key updates), verify that the default branch's new head commit is signed by the key matching `<SITE-ID>` and a successor of the current `HEAD` commit, and then point the clone's `HEAD` to the new head commit. An implementation may follow the steps below, or some others with equivalent results: