Forum Discussion

tamird's avatar
tamird
New Contributor
5 months ago
Solved

op-ssh-sign fails when passed non-UTF-8 payloads

Hi 1Password team, I’ve run into an issue when using op-ssh-sign as a signing backend for tools other than Git, specifically patatt, which signs patch emails using GPG/SSH keys. patatt looks up gpg...
CLI
feature request
integrations
macos
security
  • floris_1P's avatar
    floris_1P
    4 months ago

    tamird​ Good catch! That's a bug on our side. We fixed it and it'll become available in the next release. If you need it sooner, it's already available on the nightly channel. Thanks for reporting!

Jack_P_1P's avatar
Jack_P_1P
Icon for 1Password Team rank1Password Team
4 months ago

Hi tamird​: 

I'm not entirely sure if this is an intentional choice or an oversight, but what I can tell you is that `op-ssh-sign` primarily exists to make commit signing a one click setup process.

 

Since the 1Password app has no good way of modifying your environment variables in a persistent manner, setting the `[gpg "ssh"].program` config option is the easiest way to ensure that git will use the ssh agent for signing operations, since git will use either the config value, or `SSH_AUTH_SOCK` in that order.

 

However, if `SSH_AUTH_SOCK` is set to point at the agent, like you've done in your example, there's no need to set the SSH program, and `ssh-keygen` should be able to use the agent normally.

 

Personally, I leave the SSH program unset in my gitconfig, and instead ensure that I have `SSH_AUTH_SOCK` set globally, which allows for everything to work as expected.

  • tamird's avatar
    tamird
    New Contributor
    4 months ago

    Hi Jack_P_1P​, thanks for the detailed reply.

    The problem with setting `SSH_AUTH_SOCK` globally is that it prevents you from using multiple agents which is common in corporate environments. In my case this is a show stopper.