Are there cases where gpg --verify will exit 0, even if verification failed?

[Sandeep Murthy]

I know that all processes have an exit code, what I meant was
if you invoke gpg interactively like gpg —edit-key <key ID /email>
and then execute a wrong subcommand or specify something incorrectly
then the gpg exit code will not reflect this unless the subcommand
launches another process.

Sandeep Murthy
s.murthy at mykolab.com

> On 14 Jan 2015, at 13:40, Daniel Kahn Gillmor <dkg at fifthhorseman.net> wrote:
> 
> On Wed 2015-01-14 08:22:45 -0500, Sandeep Murthy wrote:
>> Exit codes in shells indicate problems relating to completion or disruption
>> of the child process invoked by a parent process.
>> 
>> They will not record unsuccessful events inside the child process
>> related to program functions, i.e. if you inside gpg editing a key
>> and enter an incorrect subcommand or use it incorrectly then this will
>> not affect the exit code, I don’t think.
> 
> This is not the case.  all processes have a return code, whether they
> are invoked by a shell or by other processes.  The return code is a
> critical part of the output of a program.
> 
> gpg does use the return code to indicate failure of signature
> verification.
> 
> consider the results of:
> 
>   echo test1 > test1.txt
>   echo test2 > test2.txt
>   gpg --detach-sign --armor test1.txt
>   gpg --verify test1.txt.asc test1.txt
>   gpg --verify test1.txt.asc test2.txt
> 
> the return value of the first --verify should be 0, but the second
> --verify invocation should return 1, indicating that the signature
> cannot be verified over the (different) contents of test2.txt
> 
>      --dkg