Protect what matters – even after you're gone. Make a plan for your digital legacy today.
Forum Discussion
XIII
4 years agoSuper Contributor
GPG support? (like SSH)
Would it be possible to add similar support for GPG keys?
86 Replies
- froazinNew Contributor
Big +1
SSH commit signing is fine until you need to rotate keys. Revoking a GPG key will continue to show commits in GitHub (unsure about GitLab) as "verified (expired)". The only way I've found to do the same with SSH keys is to remove the old key completely, but then commits show as "unverified" which defeats the point of supply chain integrity since it's not possible to distinguish a commit that was signed with an old key, or a commit that was not signed, or signed with another key that's not allowed.
The alternative is to not rotate signing keys, but then you compromise supply chain integrity further by not ensuring keys are rotated in a timely fashion.
- ragectlOccasional Contributor
The issue with SSH keys is they have no idea of a trust history, so they are not related in a way that GPG keys might be.
Having said that, if you keep your previous SSH keys in your allowed_signes file and don't delete them from your preferred git forge then those old SSH keys should remain listed as verified also.
Whether people trust signed commits or not is an exercise entirely for end user, they might not have your GPG keys trusted either.
- xavp75New Contributor
+1
- FatalMerlinNew Contributor
Please add GPG support! It would be amazing.
- rosstimsonNew Contributor
+1. I'd like to be able to store GPG subkeys in 1Password and instead of entering a PIN like I currently do with subkeys stored on a Yubikey I'd just use fingerprint. Subkeys would sync with other machines in the same way SSH keys (and everything else) do. I've already switched to using SSH with 1Password for signing Git commits, mostly for the convenience. If there was GPG support though I'd probably use GPG for Git signing again. However, I also use GPG for encryption of files, it's especially useful for encrypting and authing to things like email services etc when using Emacs which is my editor of choice.
- shishi1pNew Contributor
I can't wait to see this feature. GPG keys are not only for Git as you know and hard to store it securely. This will be very useful for business users also.
- srmNew Contributor
+1
- joshmockNew Contributor
I think they're hoping everyone storing PGP keys is using them for signing commits and as people discover it can be done with SSH, they'll give up asking for the feature.
I use GPG for more than just commit signing. Many CLI-based tools use GPG keys to encrypt secrets at rest, so that you can be prompted for your GPG passphrase at decrypt time rather than implementing some other standalone encryption scheme.
For example, https://www.passwordstore.org/ is used by my terminal email client to store my email account's password, which it encrypts using my GPG key.
- LucentNew Contributor
I think they're hoping everyone storing PGP keys is using them for signing commits and as people discover it can be done with SSH, they'll give up asking for the feature. There are indeed those of us from the '90s still using S/MIME and encrypting blocks to others who want 1Password to be the one stop secret shop.
- festus777New Contributor
What would be really beneficial after almost 2 years of this discussion is whether 1Password would comment on this feasibility. There have been plenty of comments on its usefulness. Either we’re considering, working on it, or it a’int happening.
- dannysauerNew Contributor
I'm still super interested in this because I'd like to be able to more natively use 1password as the central hub to store keys used to sign published artifacts generated in CI. It'd be super-handy if I could easily generate a new signing subkey and revoke one which was compromised when a CI system's cloud provider gets hacked again, all without having to change a thing about the ci logic. Bonus points for also auto-publishing to one or more keyservers on-change. For one example.
Right now I have to locally export a key, import that into 1password as a text field, then have automation fetch the armored key before importing it into a local agent, etc. It's kind of a convoluted process compared to something like telling a package signing process to just use a local key agent which can just speak to 1password connect -- for another example. :)
Git commit signing is technically on the list, but more of a side effect to me personally.