Forum Discussion
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.ssh.program in the Git config to determine what binary to invoke when performing OpenSSH signing (it uses ssh-keygen -Y sign under the hood). If you’ve followed the 1Password docs for Git signing and added this config:
[gpg "ssh"]
program = /Applications/1Password.app/Contents/MacOS/op-ssh-sign
…then any tool that reads gpg.ssh.program—like patatt—will end up calling op-ssh-sign, even if it’s not signing Git commits.
Unfortunately, op-ssh-sign seems to require that its input be valid UTF-8. This is fine for Git commit signing (since commit headers are UTF-8), but it breaks when tools like patatt try to sign arbitrary binary data (e.g. hashed headers).
Reproducible test case:
# Export the 1Password agent socket
export SSH_AUTH_SOCK="$HOME/Library/Group Containers/2BUA8C4S2C.com.1password/t/agent.sock"
# Export your public key from the agent to ~/.ssh/id_ed25519.pub
# (Replace this with your actual public key string if needed)
ssh-add -L | grep ed25519 > ~/.ssh/id_ed25519.pub
# This works
head -c 32 /dev/urandom | ssh-keygen -Y sign -n patatt -f ~/.ssh/id_ed25519.pub
# This doesnt'
head -c 32 /dev/urandom | /Applications/1Password.app/Contents/MacOS/op-ssh-sign -Y sign -n patatt -f ~/.ssh/id_ed25519.pub
op-ssh-sign appears to require the payload being signed to be valid UTF-8. This breaks legitimate OpenSSH workflows where the input is an arbitrary byte stream (like a SHA256 hash), which ssh-keygen -Y sign supports just fine.
- Clarification: Is the UTF-8 requirement in op-ssh-sign intentional or a limitation?
- If it is intentional, could the documentation note that this is not a drop-in replacement for ssh-keygen?
- Ideally, op-ssh-sign would support arbitrary input, which would make it more broadly compatible with tools that build on OpenSSH signing primitives (like patatt and git-sign).
- Alternatively, can we sidestep this so tools like patatt can work properly? I could override the SSH program for patatt specifically, but that seems like playing whack-a-mole.
Thanks for the otherwise excellent SSH key integration!
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!
3 Replies
- Jack_P_1P
1Password Team
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.
- tamirdNew Contributor
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.