Skip to main content

Browse the archive

Revision aba91192ae39cd1a2f79e7ed91e966df3cfe10b7 authored by Carlos Rica on 09 September 2007, 00:39:29 UTC, committed by Junio C Hamano on 10 September 2007, 04:30:54 UTC 
git-tag -s must fail if gpg cannot sign the tag.
 
Most of this patch code and message was written by Shawn O. Pearce.
I made some tests to know what the problem was, and then I changed
the code related with the SIGPIPE signal.

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.

Prior versions of builtin git-tag allowed this failure to slip
by without error as they were not checking the return value of
the finish_command() so they did not notice when gpg exited with
an error exit status.  They also did not fail if gpg produced an
empty output or if read_in_full received an error from the read
system call while trying to read the pipe back from gpg.

Finally, we did not actually honor any return value from the do_sign
function as it returns ssize_t but was being stored into an unsigned
long.  This caused the compiler to optimize out the die condition,
allowing git-tag to continue along and create the tag object.

However, when gpg gets a wrong username, it exits before any read was done
and then the writing process receives SIGPIPE and program is terminated.
By ignoring this signal, anyway, the function write_or_die gets EPIPE from
write_in_full and exits returning 0 to the system without a message.
Here we better call to write_in_full directly so we can fail
printing a message and return safely to the caller.

With these issues fixed `git-tag -s` will now fail to create the
tag and will report a non-zero exit status to its caller, thereby
allowing automated helper scripts to detect (and recover from)
failure if gpg is not working properly.

Proposed-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Carlos Rica <jasampler@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
1 parent 7b02b85
Raw File
RelNotes-1.5.0.2.txt 
GIT v1.5.0.2 Release Notes
==========================

Fixes since v1.5.0.1
--------------------

* Bugfixes

  - Automated merge conflict handling when changes to symbolic
    links conflicted were completely broken.  The merge-resolve
    strategy created a regular file with conflict markers in it
    in place of the symbolic link.  The default strategy,
    merge-recursive was even more broken.  It removed the path
    that was pointed at by the symbolic link.  Both of these
    problems have been fixed.

  - 'git diff maint master next' did not correctly give combined
    diff across three trees.

  - 'git fast-import' portability fix for Solaris.

  - 'git show-ref --verify' without arguments did not error out
    but segfaulted.

  - 'git diff :tracked-file `pwd`/an-untracked-file' gave an extra
    slashes after a/ and b/.

  - 'git format-patch' produced too long filenames if the commit
    message had too long line at the beginning.

  - Running 'make all' and then without changing anything
    running 'make install' still rebuilt some files.  This
    was inconvenient when building as yourself and then
    installing as root (especially problematic when the source
    directory is on NFS and root is mapped to nobody).

  - 'git-rerere' failed to deal with two unconflicted paths that
    sorted next to each other.

  - 'git-rerere' attempted to open(2) a symlink and failed if
    there was a conflict.  Since a conflicting change to a
    symlink would not benefit from rerere anyway, the command
    now ignores conflicting changes to symlinks.

  - 'git-repack' did not like to pass more than 64 arguments
    internally to underlying 'rev-list' logic, which made it
    impossible to repack after accumulating many (small) packs
    in the repository.

  - 'git-diff' to review the combined diff during a conflicted
    merge were not reading the working tree version correctly
    when changes to a symbolic link conflicted.  It should have
    read the data using readlink(2) but read from the regular
    file the symbolic link pointed at.

  - 'git-remote' did not like period in a remote's name.

* Documentation updates

  - added and clarified core.bare, core.legacyheaders configurations.

  - updated "git-clone --depth" documentation.


* Assorted git-gui fixes.
back to top