Bug#570651: ssh-vulnkey: uncommon behaviour in return values

[Colin Watson <cjwatson@debian.org>]

On Sat, Feb 20, 2010 at 03:14:35PM +0100, redshift wrote:
> In the man page it can be read:
> 
> "EXIT STATUS
>  ssh-vulnkey will exit zero if any of the given keys were in the
> compromised list, otherwise non-zero."
> 
>  While this describes correctly the behaviour of the utility, I don't
> agree it is a useful solution. While scripting (and checking for return
> values) I would expect a non-zero exit status when there is some action
> to be taken (in this case, a corrupted key), or a clean (zero) exit
> status when there's nothing to worry about.
> 
>  Is there any particular reason why ssh-vulnkey should be one of the few
> software (if not the only one) allowed to do right the opposite?

Maybe it's just a mindset thing, but I think of the linguistic expansion
as:

  if ssh-vulnkey; then
    ...
  fi

  =>

  if there is a vulnerable ssh key; then
    ...
  fi

... and that's why I did it this way round.  To me as a shell script
author, this seems perfectly natural.  ssh-vulnkey's job is to look for
vulnerable keys, and if it finds some then that's a success.  If it had
been the other way round, it would have to have been called ssh-okkey or
something like that.  I don't think of utility success as necessarily
meaning that the world is in a desirable state - one might reasonably do
something like this, by analogy:

  if grep -q 'regex indicating system compromise' /var/log/syslog; then
    alert sysadmin
  fi

In any case, I think it would be especially unhelpful to flip the exit
status now that it's been in place for some years?  Doing so would break
pretty much every deployed shell script using ssh-vulnkey.

-- 
Colin Watson                                       [cjwatson@debian.org]