GPG support? (like SSH)

+1

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.

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.

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.

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.

+1
I require GPG for commit signing with eclipse/jgit, which as far as I can tell does not support SSH signing

I use GPG for git signing and for email sending. Yes, I could change to use SSH for git signing (six in one hand; half-dozen in the other), and S/MIME for email encryption (more difficult than GPG).

At present, I use https://gpgtools.org (macOS) for managing all of my GPG keys, and the GPG keys of contacts and services. I also use https://github.com/jorgelbg/pinentry-touchid for using Touch ID instead of having to lookup and type in a password. It's not a bad solution at all, and may be a good choice in the interim for people who are still waiting on this support in 1Password.

I have no idea if this feature will come to 1Password or not. All I know is that this thread was started 2 years ago, and we still do not have it in any shipping release. I have low expectations about this becoming a reality, so I've moved on. There are other tools that solve this just as well — it doesn't need to be baked into 1Password if the company doesn't want to do it.

¯_(ツ)_/¯

+1
git-crypt

As others have stated here already, I use GPG-based signing and encryption for the following activities:
* E-mail signing (majority use case) and encryption (not-insignificant minority)
* As the framework for securing on-site incremental system backups and the occasional full volume images
* To authenticate the end product of packaging efforts for various and sundry Linux distribution package archives (this one's the doozy of the bunch)
* Securing P2P file transfers and shares over otherwise less-secure services (e.g. Dropbox, OneDrive, LocalSend, et al.)

Also echoing several others in this thread, the primary functionality that I seek is really the gpg-agent service and less so the key pair generation and management, although ideally they would at some future time all be present in 1Password. Just to be able to import public and private keys exported as individual files (whether binary or ASCII-armored) and have 1P recognize them, display their identifying characteristics (algorithm, key size, fingerprint and comment) and serve them up in response to the standard gpg-agent calls would be more than enough to have me purring like a kitten for a good long while, though. It's the ability to have them available on all my devices in the same manner that 1P already does for other credentials that I'm so sorely lacking in my current workflows; it wouldn't be an onerous hardship to handle the tasks like key signing, subkey and identity addition/revocation and expiration changes with the tools I already have in place so long as in the end the updated key pairs could be returned to 1P and made use of from my other devices.

I hope that provides the clarification you were asking for, floris_1P, if not, I can get more granular.

+1 for having a clean gpg management solution