bug-gnulib
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: getpass alternative [Re: getpass documentation]


From: Simon Josefsson
Subject: Re: getpass alternative [Re: getpass documentation]
Date: Mon, 19 May 2008 09:53:13 +0200
User-agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.2 (gnu/linux)

Micah Cowan <address@hidden> writes:

> Simon Josefsson wrote:
>> I'm not sure it is a good idea to recommend use of getpass, possibly
>> gnulib could offer a better interface.  It could have a parameter to ask
>> for confirmation of the password internally.  However, I will use
>> getpass for now since I don't want to introduce a lot of changes in the
>> particular code I'm working on.
>
> Wget just added code to the dev repo that uses gnu_getpass to support
> password prompting. This was mainly because it was quick-and-easy, and
> because gnu_getpass doesn't suffer from many of the serious flaws
> plaguing alternative implementations.

That's the reason I used it as well.

> However, it's not quite ideal. One thing that I consider a problem is
> that one can't distinguish between an empty line and EOF. I'd have liked
> to treat EOF as an exit condition, but an empty line as an empty password.
>
> However, more of a problem is that if one enters EOF, it'd be nice if
> getpass issued an extra newline so that any further output begins on a
> new line. Otherwise, a program that exits in response to EOF (such as
> Wget) will wind up with the user's prompt following the program's
> password prompt. The program of course could issue the extra newline
> itself, but
>   (a) doesn't know whether it needs to (since it could have been an
> empty line, rather than EOF), and
>   (b) doesn't know where the newline should go (/dev/tty? stderr?).
>
> So, I think we'd be in favor of a better, general solution, for those
> who do not have need of a portable version of the obsolete interface.
>
> (Also, the Windows implementation might be improved by the removal of a
> hard buffer limit.)

Another problem that I discovered is that gnulib's getpass.c inhibits
signals, so the user cannot press ^C/^Z.  This is even more of a problem
when the user needs to type the same password twice: the process may be
stuck in a loop that can't be canceled waiting for the user to type two
identical strings.

What would a better replacement function look like?

enum getpassword_flags {
  DISABLE_SIGNALS
};

char *
getpassword (const char *prompt,
             enum getpassword_flags flags);

char *
getpassword_confirmed (const char *prompt,
                       const char *confirmprompt,
                       const char *confirmfailmessage,
                       enum getpassword_flags flags);

Ideally, the function could have features to talk with external password
prompting programs like gpg-agent: then you can get an out-of-band gtk
prompt even to tty programs.  GnuPG supports this, and I think the
passsword prompting mechanism is generic and can support other
applications too.

/Simon




reply via email to

[Prev in Thread] Current Thread [Next in Thread]