-
Notifications
You must be signed in to change notification settings - Fork 94
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Discuss and implement PGP support. #58
Comments
I think it makes sense to reuse existing key infrastructure like PGP yes. Though trusting a PGP identity should of course not be equal to trusting his code reviews ;) |
@stevenroose Yes. GPG's WoT is completely out of the picture for Crev. WoT-s between GPG and Crev serve different purposes: confirming that underlying identity is true vs trusting someones code reviews. |
But that doesn't take away the utility of using PGP identities for crev, though. |
I have created this ticket for a reason. I'm not disputing utility of supporting PGP. 😎 |
In terms of integration with I can think of the following models, in increasing level of complexity:
|
I guess a similar interface to git for signing commits may be used: https://help.github.com/en/github/authenticating-to-github/telling-git-about-your-signing-key |
https://sequoia-pgp.org/ , haven't checked if they have SC support already. |
there is a pure rust pgp implementation available under the pgp crate. this is currently used in rustup for signature validation, so already is in use by the wider rust community disclaimer: I maintain that crate |
this issue seems related: https://gitlab.com/sequoia-pgp/sequoia/-/issues/114 |
Another way is to only cross link identities, as you can not only use email in gpg identities. See e.g.: https://github.com/wiktor-k/openpgp-proofs |
I am a heavy GPG user, and I belive it's a PITA for a mass audience. But it's almost the only game in town for hardware keys support, so security-minded people will probably want to use that.
GPG support is not implemented, but can be added at later time.
The identity would look like this:
The exported public key will be embedded into git repo somewhere.The pgp WoT won't be involved at all here: just 1:1 match between the ID and gpg identity to use to check the signatures against.
Also, review timestamp should be checked to within time of life of a PGP identity.
When the PGP key goes out of life, the author will just create a new one, and set the trust to the old one as
high
.It should be fairly straightforward to add, but it is not high on my personal priority list.
The text was updated successfully, but these errors were encountered: