Add support for uploaded PGP keys as claims on Git forges #19

Open
opened 3 months ago by caesar · 5 comments
caesar commented 3 months ago

This is a follow up to some comments I made on the Keyoxide Matrix room, because I thought this would be a better / more permanent place to discuss this.

Current method:

At present, DOIP / Keyoxide supports several Git forges on an ad-hoc basis using different mechanisms.
For example:

  • Github requires adding a Gist and using the Gist url as the claim
  • Gitlab and Gitea require creating a "magic" stub repo with a specific description and using the URL of that repo as the claim.
  • Sourcehut is a work in progress but seems to be a similar mechanism to the above.

When verifying the claim, doip.js uses each platform's API to retrieve the claimed fingerprint, and verifies that the fingerprint matches that of the key where the claim is attested.

Proposal

All of the above-mentioned forges already provide a dedicated mechanism for a user to upload their PGP key, and each forge makes the ASCII-armoured key available at a well-known URL.
Specifically:

  • Github, Gitlab, Gitea: https://{domain}/{username}.gpg
  • Sourcehut: https://meta.sr.ht/~{username}.pgp

To use one of the above as a claim, doip.js could retrieve the ASCII-armoured key from the above URLs, get the fingerprint of the key, and proceed to verify that claimed fingerprint as with any other claim.

The advantage of this from a UX point of view would be that it wouldn't be necessary to use specific workarounds on each site to upload a text fingerprint in a user-controlled location. Instead, dedicated platform-supported key upload features could be used. Many users who would want to verify these platforms will already have uploaded their keys to the relevant platforms anyway.

Potentially this could also result in an easier-to-maintain codebase by removing platform-specific workarounds in favour of dedicated locations provided by each plaform to upload user keys.

This is a follow up to some [comments I made on the Keyoxide Matrix room](https://matrix.to/#/!dEfJkFpQpwvbzcegRX:matrix.org/$veVRcp19htSBpmSgTuc7v-kl0Vzw61NapKbKmY__czE), because I thought this would be a better / more permanent place to discuss this. #### Current method: At present, DOIP / Keyoxide supports several Git forges on an ad-hoc basis using different mechanisms. For example: * **Github** requires adding a Gist and using the Gist url as the claim * **Gitlab** and **Gitea** require creating a "magic" stub repo with a specific *description* and using the URL of that repo as the claim. * **Sourcehut** is [a work in progress](https://codeberg.org/keyoxide/doipjs/pulls/17) but seems to be a similar mechanism to the above. When verifying the claim, doip.js uses each platform's API to retrieve the claimed fingerprint, and verifies that the fingerprint matches that of the key where the claim is attested. #### Proposal All of the above-mentioned forges already provide a dedicated mechanism for a user to upload their PGP key, and each forge makes the ASCII-armoured key available at a well-known URL. Specifically: * **Github**, **Gitlab**, **Gitea**: `https://{domain}/{username}.gpg` * **Sourcehut**: `https://meta.sr.ht/~{username}.pgp` To use one of the above as a claim, doip.js could retrieve the ASCII-armoured key from the above URLs, get the fingerprint of the key, and proceed to verify that claimed fingerprint as with any other claim. The advantage of this from a UX point of view would be that it wouldn't be necessary to use specific workarounds on each site to upload a text fingerprint in a user-controlled location. Instead, dedicated platform-supported key upload features could be used. Many users who would want to verify these platforms will already have uploaded their keys to the relevant platforms anyway. Potentially this could also result in an easier-to-maintain codebase by removing platform-specific workarounds in favour of dedicated locations provided by each plaform to upload user keys.
Poster

Potentially this could also result in an easier-to-maintain codebase by removing platform-specific workarounds in favour of dedicated locations provided by each plaform to upload user keys.

On the other hand, backwards compat dictates that it will be necessary to maintain support for the old locations too, at least in the short term, at least partially negating the above 'advantage'.

> Potentially this could also result in an easier-to-maintain codebase by removing platform-specific workarounds in favour of dedicated locations provided by each plaform to upload user keys. On the other hand, backwards compat dictates that it will be necessary to maintain support for the old locations too, at least in the short term, at least partially negating the above 'advantage'.
Poster

If this feature was implemented, the same implementation (using already-uploaded public keys to obtain a fingerprint, instead of posting claim text containing that fingerprint) could cover #1 (Facebook) I believe.

If this feature was implemented, the same implementation (using already-uploaded public keys to obtain a fingerprint, instead of posting claim text containing that fingerprint) could cover #1 (Facebook) I believe.
Poster

Now I find this has already been discussed over on the keyoxide-web repo. 😀

I'll leave this open though, as the implementation will have to be here rather than there.

Now I find this has [already been discussed over on the keyoxide-web repo](https://codeberg.org/keyoxide/keyoxide-web/issues/89). 😀 I'll leave this open though, as the implementation will have to be here rather than there.
Owner

Overall, yes, this is great and needed. A much simpler method would be great! Especially Gitlab's current implementation is "hacky" because it requires two separate API calls.

Since the current method must be kept both for backwards compatibility and the fact that sourcehut has a bug that doesn't allow some people to upload their keys, this proposal must also wait until we find a good way to do "multiple verification methods". (Thanks @caesar for linking to this issue in that forum topic)

the same implementation (using already-uploaded public keys to obtain a fingerprint, instead of posting claim text containing that fingerprint) could cover #1 (Facebook) I believe

That would be interesting. If someone with knowledge (and a FB account) could look into this.

I'll leave this open though, as the implementation will have to be here rather than there

Excellent! In fact, I'll link to this issue and close the other one.

Overall, yes, this is great and needed. A much simpler method would be great! Especially Gitlab's current implementation is "hacky" because it requires two separate API calls. Since the current method must be kept both for backwards compatibility and the fact that sourcehut has a bug that doesn't allow some people to upload their keys, this proposal must also wait until we find a good way to do "multiple verification methods". (Thanks @caesar for linking to this issue in that [forum topic](https://community.keyoxide.org/d/7-allow-multiple-proof-locations)) > the same implementation (using already-uploaded public keys to obtain a fingerprint, instead of posting claim text containing that fingerprint) could cover #1 (Facebook) I believe That would be interesting. If someone with knowledge (and a FB account) could look into this. > I'll leave this open though, as the implementation will have to be here rather than there Excellent! In fact, I'll link to this issue and close the other one.
Poster

If someone with knowledge (and a FB account) could look into this.

I do still have an FB account, though I rarely use it. It's one of those accounts I woudn't want to link to my public identity in the long term – but I don't mind doing so in the short term for testing purposes.

I just checked, and as @wiktor mentioned in #1, https://www.facebook.com/{username}/publickey/download/ works.

> If someone with knowledge (and a FB account) could look into this. I do still have an FB account, though I rarely use it. It's one of those accounts I woudn't want to link to my public identity in the long term – but I don't mind doing so in the short term for testing purposes. I just checked, and as @wiktor mentioned in #1, `https://www.facebook.com/{username}/publickey/download/` works.
Sign in to join this conversation.
No Milestone
No project
No Assignees
2 Participants
Notifications
Due Date

No due date set.

Dependencies

This issue currently doesn't have any dependencies.

Loading…
There is no content yet.