Loading howto/gitlab.md +26 −0 Original line number Diff line number Diff line Loading @@ -1146,6 +1146,32 @@ Update, 2021-06-04: there was [another iteration](https://people.kernel.org/mons this time based on DKIM-like headers, with support for OpenPGP signatures but also "native" ed25519. One key takeaway from this approach, which we could reuse, is the way public keys are stored. In [patatt](https://pypi.org/project/patatt/), the git repository itself holds the public keys: > On the other hand, within the context of git repositories, we > already have a suitable mechanism for distributing developer public > keys, which is the repository itself. Consider this: > > * git is already decentralized and can be mirrored to multiple > locations, avoiding any single points of failure > * all contents are already versioned and key additions/removals can > be audited and “git blame’d” > * git commits themselves can be cryptographically signed, which > allows a small subset of developers to act as “trusted > introducers” to many other contributors (mimicking the > “keysigning” process) > > The idea of using git itself for keyring management was originally > suggested by the did:git project, though we do not currently > implement the proposed standard itself. > > <https://github.com/dhuseby/did-git-spec/blob/master/did-git-spec.md> It's unclear, however, why the latter spec wasn't reused. To be investigated. ### Ryabitsev: Secure Scuttlebutt A more exotic proposal is to [use the Secure Scuttlebutt (SSB) Loading Loading
howto/gitlab.md +26 −0 Original line number Diff line number Diff line Loading @@ -1146,6 +1146,32 @@ Update, 2021-06-04: there was [another iteration](https://people.kernel.org/mons this time based on DKIM-like headers, with support for OpenPGP signatures but also "native" ed25519. One key takeaway from this approach, which we could reuse, is the way public keys are stored. In [patatt](https://pypi.org/project/patatt/), the git repository itself holds the public keys: > On the other hand, within the context of git repositories, we > already have a suitable mechanism for distributing developer public > keys, which is the repository itself. Consider this: > > * git is already decentralized and can be mirrored to multiple > locations, avoiding any single points of failure > * all contents are already versioned and key additions/removals can > be audited and “git blame’d” > * git commits themselves can be cryptographically signed, which > allows a small subset of developers to act as “trusted > introducers” to many other contributors (mimicking the > “keysigning” process) > > The idea of using git itself for keyring management was originally > suggested by the did:git project, though we do not currently > implement the proposed standard itself. > > <https://github.com/dhuseby/did-git-spec/blob/master/did-git-spec.md> It's unclear, however, why the latter spec wasn't reused. To be investigated. ### Ryabitsev: Secure Scuttlebutt A more exotic proposal is to [use the Secure Scuttlebutt (SSB) Loading
