cygport improvements: upload, fish, src_prep_fini_hook

Andrew Schulman schulman.andrew@epa.gov
Tue Dec 9 01:40:00 GMT 2014


> > Here's what I have at the moment based on your branch as of a few weeks 
> > ago.  However, with password-protected SSH keys, the password prompt 
> > isn't handled properly.  Any ideas?
> 
> Re password prompts: I see the problem.  It's because I echo the lftp
> script to stdout, and pipe it into lftp -f /dev/stdin.  So stdin is
> unavailable for the password prompt.
> 
> I think using process substitution instead will be an easy fix for this.

OK, I looked into this.  Unfortunately lftp seems not to support using
encrypted SSH keys for sftp.

First I freed up stdin for lftp to use, by using process substitution 
instead of -f/dev/stdin, as I said before.  But it still doesn't work.

So I tried it with lftp from the command line.  With an unencrypted key it 
works, but with an encrypted key you get the following:

$ lftp sftp://cygwin:@cygwin.com
lftp cygwin@cygwin.com:~> set sftp:connect-program ssh -a -x -i /path/to/encrypted/key
lftp cygwin@cygwin.com:~> ls
`.' Enter passphrase for key '/home/andrex/.ssh/keys/home': XXXX

and the connection fails.  It seems that lftp intercepts the password 
prompt.  I'll ask about this on the lftp list, but meanwhile I think the
best we can do is to add a note in the documentation saying that users
will have to provide either an ssh-agent, or an unencrypted key in
SSH_KEY.  I went ahead and added that.

All the other issues have been addressed:

* Rebased against cygport/master.

* Moved !ready into $archdir/$NAME.

* Re-added doc for Uploading/SSH_KEY (accidentally removed in 8954ada).

* Misc. other small fixes to agree with your patch.

* In __pkg_upload(), I see you removed the default case in

    case ${ARCH} in
        i686)   archdir=(x86) ;;
        x86_64) archdir=(x86_64) ;;
        noarch) archdir=(x86 x86_64) ;;
        *)  error "Don't know where to upload packages with architecture ${ARCH}" ;;
    esac

The default is intended as future-proofing for other, future Cygwin
architectures.  I figure it's better to code an explicit error message now, 
than to leave a lurking error condition for later.  But your call.

Andrew



More information about the Cygwin-apps mailing list