pinentry patches

[Marcus Brinkmann]

Hi Peter,

At Fri, 25 May 2007 10:24:15 -0500,
"Peter O'Gorman" <gnupg-devel at mlists.thewrittenword.com> wrote:
> We built pinentry-0.7.2, it required getopt (which required gettext
> and iconv), so we added gnulib getopt.

Let's walk through all the changes individually.  I need your support
for all but one of them to make sane decisions.

You certainly mean getopt_long (which is a GNU extension), not getopt
(which is POSIX).  Is it correct that your platform doesn't have a
GNU'ish getopt_long (BSD for example has a compatible replacement).

> The IRIX compiler, for some reason, did not like this:
> { "version", no_argument, &opt_version, 1 }
> so, we changed it.

What's the reason?  getopt_long is a GNU extension, so if IRIX'es
getopt_long does not comply with GNU's getopt_long, there is a bug in
it.  struct option is specified as taking an int * and an int as third
and fourth member, and opt_version is an int.  What's the compiler
complaining about?  How is struct option defined on IRIX?
 
> Most compilers don't understand '\e', so replaced with its hex
> equivalent.

Ok.

> Now for the big problem though.
> In the normal situation when running pinentry it does not have a
> terminal, so it does fopen(tty_name,"r") etc to get a terminal to ask
> for the passphrase on. On hpux and tru64 ncurses is unable to properly
> initialize this device,

Why?

> it remains in line buffered mode and echoes
> the passphrase as it is typed, changing it to *** after the user
> presses return. It also does not change the keymappings, so I had to
> case '\r':
> case '\n':
> so the user could get out of the dialog. We "fixed" the echo to the
> screen issue using tcsetattr, but I hope that there is some more
> knowledgeable person here who knows a proper fix. With this "fix" the
> device stays in line buffered mode, but does not echo the chars as
> they are typed. It does still change them to '***' after the user
> presses <ENTER>.

The ncurses' library initscr() does just call newterm() on stdin and
stdout.  It's hard to imagine a reason why calling newterm() manually
on appropriate file descriptors would fail to do the proper job.

This requires more debugging.  Maybe you could try to disable colors,
or move start_colors() before noecho(), in case this trips things up.
That's just a wild guess of course.  There may be other things that
are subtly different.  Maybe the tty_type is given wrongly?

Thanks,
Marcus