[git-remote-gcrypt] BUG involving handling of spaces in user.signingkey value

[Jeff Huffman]

Upon first trying git-remote-gcrypt, when I attempted my first git push, I got
the following output:

$ git push testcrypt master
gcrypt: Repository not found: file:///home/tejing/data/testcrypt.git/
gcrypt: Setting up new repository
gcrypt: Remote ID is :id:XuhaDtXFwQpt5h6CRfbw
gcrypt: Due to a longstanding bug, this push implicitly has --force.
gcrypt: Consider explicitly passing --force, and setting
gcrypt: gcrypt's require-explicit-force-push git config key.
Enumerating objects: 7, done.
Counting objects: 100% (7/7), done.
Compressing objects: 100% (5/5), done.
Total 7 (delta 0), reused 0 (delta 0), pack-reused 0
gcrypt: Encrypting to:  -r 46E96F6FF44F3D74
gcrypt: Requesting manifest signature
usage: gpg [options] --sign --encrypt [filename]
error: failed to push some refs to 'gcrypt::file:///home/tejing/data/testcrypt.git/'

That 'usage' line stuck out at me, and I attempted to find the problem myself.
After a few red herrings focusing on handling of the Recipients variable, I
tried adding this line to PRIVENCRYPT just before the gpg call:

echo Running rungpg with: --compress-algo none --trust-model=always -se "$@" >&2

this produced:

Running rungpg with: --compress-algo none --trust-model=always -se -r 46E96F6FF44F3D74 -u 963D 3AFB 8AA4 D693 153C  1500 46E9 6F6F F44F 3D74

making the problem quite clear. My user.signingkey value is specified with spaces,
just like the format gpg outputs (god only knows why they print it that way...)
and git itself handles this just fine, so it has caused me no problems. The rungpg
function does not quote its arguments ($@ instead of "$@") which is, incidentally,
the only reason the Recipients variable being quoted in the call to PRIVENCRYPT
doesn't cause its own problems. But this caused the fingerprint to be passed to
gpg as 10 distinct arguments instead of 1, which it has no idea what to do with,
so it prints a usage message.

The quick and dirty solution to this bug would be to strip spaces from the option
when retrieved, but the more complete solution would be to introduce better space
handling throughout the call structure, so this type of issue is less likely in
the future.

For now, I can just take the spaces out of my user.signingKey, so there's no rush,
but it would be nice to fix this for the future.

Jeff Huffman
-------------- next part --------------
A non-text attachment was scrubbed...
Name: publickey - tejing at tejing.com - 0x963D3AFB.asc
Type: application/pgp-keys
Size: 5647 bytes
Desc: not available
URL: <http://www.chiark.greenend.org.uk/pipermail/sgo-software-discuss/attachments/20210610/33e6aed7/attachment.key>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 509 bytes
Desc: OpenPGP digital signature
URL: <http://www.chiark.greenend.org.uk/pipermail/sgo-software-discuss/attachments/20210610/33e6aed7/attachment.sig>