ff3cf4d38fe90aeb15c322a5cded7de4839a5b22 — Ivan Vilata-i-Balaguer 5 months ago 72441b7
Mention possibility of keeping a cache of already verified commits.

For sites where a single page may consist of several files (HTML, CSS, JS,
images), this may avoid peaks of CPU used on repeated signature verifications
of the same commit.
1 files changed, 2 insertions(+), 0 deletions(-)

M README.md => README.md +2 -0
@@ 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: