Bug#708419: openssh-client: ssh-copy-id leads to rm -f * (local vs. dash)

[Colin Watson <cjwatson@debian.org>]

Control: forwarded -1 https://bugzilla.mindrot.org/show_bug.cgi?id=2105

On Wed, May 15, 2013 at 06:57:58PM +0200, Cyril Brulebois wrote:
> ssh-copy-id uses "local" while pretending to be POSIX compliant (/bin/sh
> as a shebang). Unfortunately, lack of error handling meands that this
> isn't caught:
>   local L_TMP_ID_FILE=$(mktemp ~/.ssh/ssh-copy-id_id.XXXXXXXXXX)
>   trap "rm -f $L_TMP_ID_FILE*" EXIT TERM INT QUIT
> 
> mktemp succeeds but dash doesn't like local:
> | $ dash
> | $ local foo=bar
> | dash: 1: local: not in a function
> | $ echo $foo
> | 
> | $ 
> 
> Which leads to:
>   rm -f *
> 
> => Nasty!
> 
> Traced back to 1:6.2p1-1 due to:
>      - Update ssh-copy-id to Phil Hands' greatly revised version
>        (closes: #99785, #322228, #620428; LP: #518883, #835901, #1074798).
> 
> (Tagging "upstream" as it's also mention in upstream's ChangeLog.)
> 
> debdiffing both 6.1p1-4 and 1:6.2p1-1 confirms that the regression
> was introduced in the latter (there was no "local" before).

Forwarded upstream, thanks.  However, I think you may have misdiagnosed
this due to the way you tested it; 'local' works just fine in dash if
it's inside a function, as it is in ssh-copy-id:

  $ dash
  $ populate_new_ids() {
  >   local foo=bar
  >   echo $foo
  > }
  $ populate_new_ids
  bar
  $ 

Maybe mktemp failed in some other way.  Did ~/.ssh exist before running
this command?  mktemp won't create leading directories.

-- 
Colin Watson                                       [cjwatson@debian.org]