Interactive Rsync Authentication Problem

[Andrew Klein]

The getpassphrase() call is identical to getpass() except it returns 256 
chars maximum.  Of course you would have to mess with autoconf but I 
don't think that should be too hard.  Based on the autoconf stuff in the 
latest rsync release, the compile check would be something along these 
lines:

AC_CACHE_CHECK([for getpassphrase],rsync_cv_HAVE_GETPASSPHRASE,[
AC_TRY_COMPILE([#include <unistd.h>],
[char *pass;  pass = getpassphrase("Password: ");],
rsync_cv_HAVE_GETPASSPHRASE=yes,rsync_cv_HAVE_GETPASSPHRASE=no)])
if test x"$rsync_cv_HAVE_GETPASSPHRASE" = x"yes"; then
    AC_DEFINE(HAVE_GETPASSPHRASE)
fi

jw schultz wrote:

>On Wed, May 28, 2003 at 04:14:54PM -0400, Carson Gaspar wrote:
>  
>
>>--On Wednesday, May 28, 2003 13:26:17 -0400 Andrew Klein 
>><andy at progress.com> wrote:
>>
>>    
>>
>>>I believe J.W. Schultz replied to this but I lost it since I was not yet
>>>fully subscribed to the list. He rightly suggested that the a portable
>>>getpass() would be non-trivial.  An alternate suggestion though:  Solaris
>>>has a getpassphrase() call that returns up to 256 chars.  The configure
>>>script could check if the function exists and do an appropriate #define.
>>>Then authenticate.c can be made a bit be smarter in a generally portable
>>>way.
>>>      
>>>
>>getpassphrase() is definitely worth using. OpenSSH also has a portable 
>>readpassphrase() that you could steal.
>>    
>>
>
>But how portable is readpassphrase really?  And how much
>would we have to change in autoconf to use it?  If
>getpassphrase is much like getpass then i'd say we could use
>it.  But i don't want to see any "#ifdef SOLARIS", autoconf
>would have to set HAVE_GETPASSPHRASE or something like that.
>
>  
>
>>I love the fact that the man page for getpass() under Linux says "don't use 
>>this", but does not provide any alternative. Mmmm... Linux - it's so 
>>secure! ;-)
>>    
>>
>
>Try SUSv2:
>	APPLICATION USAGE
>
>	 The return value points to static data whose content may be
>	 overwritten by each call. 
>
>	 This function was marked LEGACY since it provides no
>	 functionality which a user could not easily implement, and
>	 its name is misleading. 
>
>
>	FUTURE DIRECTIONS
>
>	  None. 
>
>SUSv3 doesn't even define getpass.
>
>Somewhere along the way the committees decided that since
>getpass was so "simple" it wasn't needed in the libs.
>Strncpy is even easier to implement and a bad design (no
>terminate on truncate) should it be dropped too?  I'll agree
>that getpass's design is poor but that means it should get a
>better replacement, not be dropped.
>
>In reality i don't expect getpass to be dropped for some
>time.  There are too many utilities using it that would
>suddenly be broken were it dropped.  It is easier for the
>vendors to add it back in than to field the support calls
>when software won't build.
>
>  
>