[Top][All Lists]
[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
- getpass documentation, Simon Josefsson, 2008/05/16
- Re: getpass documentation, Bruno Haible, 2008/05/18
- Re: getpass documentation, Simon Josefsson, 2008/05/19
- Re: getpass documentation, Bruno Haible, 2008/05/19
- Re: getpass documentation, Jim Meyering, 2008/05/19
- Re: getpass documentation, Simon Josefsson, 2008/05/19