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

[Sean Whitton]

Hello,

On Thu 10 Jun 2021 at 10:42AM GMT, Jeff Huffman wrote:

> 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.

Thanks for the analysis.  I'd be happy to apply a patch stripping spaces
for this particular git option.  I'm not sure what more general better
whitespace handling would look like; perhaps you'd care to expand.

-- 
Sean Whitton