Last November, I submitted a bug report with patches for nmh - it didn't work
as a POP client properly on Linux systems. But unfortunately, the patches
didn't get into the 1.0.4 release, so here goes again:
The Symptom: Unless .netrc is used, on systems using glibc 2.1.1, 'inc' fails
to work when nmh is configured as a POP client.
The Reason: The glibc version of ruserpass() won't prompt the user for a
password (the glibc maintainers believe that this is the right and proper
behavior, and won't change ruserpass() - see note attached).
Possible Solutions:
1. At minimum, the documentation should be changed to note the current
restriction that ~/.netrc be used to supply a login/password for POP.
2. For Linux systems, avoid using the glibc version of ruserpass(), and use
the version supplied with nmh. There's an additional problem here -
ruserpass() calls getpass(), and in glibc, the getpass() flushes standard input
before prompting the user for a password. When a program like exmh uses 'inc',
it feeds in the password as standard input with code like:
exec inc +inbox -truncate -nochangecur -width 100 password
which fails with the glibc version of getpass(). So a replacement for
getpass() needs to be provided as well.
What to Do?
I'm willing to put together changes to the nmh configure script that will
use the nmh version of ruserpass(). I have a patch for ruserpass() that works
with my system (see attached). Would you like me to work on the configure
portion?
But it is also the case that 'ruserpass()' is not a "well defined" function -
it's not a Posix function, and can't be guaranteed to exist with any particular
attributes on any particular system. It's an internal routine to rexec(), and
by rights shouldn't really be used by nmh at all. So a better overall fix
would be to always use the nmh version of ruserpass(), including its own
'getpass()' routine, to make sure it always works.
So, what would you like to do? Please at least include a note in the MACHINES
file about the restriction that on Linux systems, ~/.netrc must be used for
POP login/password info. Thanks!
glenn writes:
Number: 1474
Category: libc
Synopsis: rexec() function won't prompt for password if not found in .netrc
file
Confidential: no
Severity: serious
Priority: medium
Responsible:libc-gnats
State: open
Class: sw-bug
Submitter-Id: unknown
Arrival-Date: Mon Nov 29 12:00:01 EST 1999
Last-Modified:
Originator: [EMAIL PROTECTED]
Organization:
net
Release:2.1.1
Environment:
Mandrake Linux 6.1, i386 architecture
Description:
Unfortunately, none of this family of functions (rexec, rcmd) is documented in the
manual.
Previous editions of ruserpass() in the BSD distribution would prompt for a
password if it wasn't found in a variety of places. The glibc version will
only return a username/password if there are appropriate entries in the .netrc file.
This has caused the current edition of nmh (1.0.2) not to work correctly, because
it counts on the user being prompted for a password.
Since there is no documentation of rexec() in the glibc manual, I include for
reference excerpts from man pages on
This has been discussed several times on the glibc mailing lists. I'm
citing some comments from the discussion:
Mark Kettenis writes on 26th October 1999:
Do you have any evidence that the statement about rexec asking for the
username/password is true? Although the BSD man pages do indeed
mention that rexec() would do this, none of the BSD's derived from
BSD 4.2 (which according to the man page is the first version that has
rexec()) do implement this. Since the code in glibc is derived
directly from BSD, it is no surprise that glibc doesn't do this
either. So the whole issue appears to be a documentation bug on the
side of BSD. There may be some reimplementations of rexec() around
that do ask for a password based on the BSD documentation, but that's
not very relevant. I think that there are a lot of cases where it is
unwanted. As a principle, no library call should print anything
(except when that's the explicit purpose of the call of course), let
alone ask for input.
And later, Mark again:
Anyway, the issue has been discussed before [1]. Ulrich thinks
we should stay with the BSD 4.4 implementation, and I agree with him.
It's more or less the reference standard for rexec().
Also note that rexec() is considered to be pretty dangerous. FreeBSD
and NetBSD only offer it for compatibility with BSD 4.4, and
reccommend using another mechanism.
Mark
[1] http://sourceware.cygnus.com/ml/bug-glibc/1999-07/msg00085.html
In a nutshell: glibc follows the BSD 4.4 implementation and we're not
going to change it.
Andreas
--
Andreas Jaeger
SuSE Labs [EMAIL PROTECTED]
private [EMAIL PROTECTED]
*** ruserpass.c.orig Fri Apr 30 14:08:34 1999
--- ruserpass.c Mon Nov
