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

[Jeff Huffman]

On Tue, Jun 15, 2021 at 04:39:42PM -0700, Sean Whitton wrote:
> 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

Hi Sean,

I was primarily thinking of:

1. Using array variables rather than space-separated strings for information that is,
   logically, a list of strings.
2. Expanding array variables in double quotes. i.e. use "$@", not $@

I'm hardly an accomplished shell programmer, but in my limited experience, these 2
rules seem like they solve a whole lot of whitespace problems for me before they begin.
Sorry if a came off a bit preachy :-)

Jeff
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://www.chiark.greenend.org.uk/pipermail/sgo-software-discuss/attachments/20210615/53f12a68/attachment.sig>