Easing adoption by generic Git repos

Summary: Recent changes to the gwit spec allow the verification of arbitrary commits merged into the site branch, even if they weren't signed by the site key. This allows a (possibly unrelated) actor to create a gwit site to certify the content from an existing Git repo, enabling links to it.

gwit was initially conceived to support the creation of Git repositories holding file-based sites. This relied on two main features: (i) gwit URIs allowing in-site and cross-site links, and (ii) a way of verifying site content based on per-commit signatures. In short, a URI would resolve to a path in a commit in a target site, and the commit should both be signed by that site's PGP key and belong to the chain of commits leading to the site's most recently known version, i.e. the head of the site branch.

This was ok but it meant that one may not verify an existing commit that belonged to another branch which was merged into the site branch unless that commit was also signed by the site key. For instance, take commit X that belongs in the "main" branch but isn't signed (or it is signed with the personal key of some contributor), and "main" was merged into the gwit site branch in commit Y (signed by the site key). A URI referring to "gwit://<X>@<SITE-ID>/…" would fail verification.

As a result, in general one could not refer to commits in a non-site branch using the gwit site, even if the site branch already "vouched" for their content transitively, by means of merging.

To avoid this limitation, the verification of site commits was recently relaxed so that they're only required to be ancestors of the current site branch head (which must still carry a valid signature by the site key).

This means that you can now create a gwit site for your favourite Git repo (even if you're not an allowed committer), and thus enable stable gwit links to it that don't depend on where the original repo is hosted, while having you "certificate" the repo's contents with each merge into the gwit site branch. For instance:

Linux repo at kernel.org: --X--Y--Z--> [master branch]
                           |
                           v fetch
                           |
Your repo elsewhere:      --X--Y--Z--> [master branch]
                             \     \
      (signed merge commits)  M1----M2--> [gwit site branch]

This would allow a link like "gwit://<Y>@<YOUR-SITE-ID>/lib/bcd.c" that addresses commit Y directly, while preserving its integrity.

This upgrade to the gwit specification should help use gwit URIs to create stable, host-neutral hyperlinks to files in Git repositories with little effort.

🍃

🗒 Back to log index