Re: [PATCH 2/2] git-tag -s must fail if gpg is broken and cannot sign tags

From: Carlos Rica <jasampler@gmail.com>
Date: Sep 8, 2007, 05:41 UTC
Message-ID: <1b46aba20709072241v2a6b071tdeb0e9fc35ea217d@mail.gmail.com>
In-Reply-To: <20070907045833.GZ18160@spearce.org>

2007/9/7, Shawn O. Pearce <spearce@spearce.org>:

Show 16 quoted lines

> Junio C Hamano <gitster@pobox.com> wrote:
> > "Shawn O. Pearce" <spearce@spearce.org> writes:
> >
> > > "Shawn O. Pearce" <spearce@spearce.org> wrote:
> > >> If the user has misconfigured `user.signingkey` in their .git/config
> > >> or just doesn't have any secret keys on their keyring and they ask
> > >> for a signed tag with `git tag -s` we better make sure the resulting
> > >> tag was actually signed by gpg.
> >
> > This seems to fail the test depending on the order processes
> > happen to be scheduled.  I haven't looked at it closely yet.
>
> That's not good.  I noticed stepping through the code last night
> that if gpg is misconfigured (e.g. set a bad user.signingkey in
> .git/config) it will terminate and send SIGPIPE to git-tag, which
> makes it terminate.

I haven't tested it enough, but now I know that the program is terminated
in write_or_die(gpg.in, buffer, size), and it is passing the test or not
depending on the system, because I added some code before the test
and then it worked for me and if I remove that test, it is failing again.
These messages are printed:
   gpg: skipped "BobTheMouse": secret key not available
   gpg: signing failed: secret key not available
Just after start_command and before write_in_full.

Possibly the reason is that code in write_in_full() that makes exit(0) without a warning when EPIPE is returned, or possibly is write() in xwrite(), that dies directly when EPIPE is received like it was for builtin-verify-tag.c. Catching the signal EPIPE doesn't worked for me, so I will do some checks more to trace the code more exactly in my system.

> All my change did was implement proper error handling.  So if you
> are seeing failures now then we probably have a problem with the
> code without my patch too...

The test seems to fail also without your patch, as you say.