Mailing-List: contact dev-help@apr.apache.org; run by ezmlm
Precedence: bulk
Received-SPF: pass (hermes.apache.org: domain of jorton@redhat.com designates
 66.187.233.31 as permitted sender)
Date: Wed, 1 Dec 2004 19:30:43 +0000
From: Joe Orton <jorton@redhat.com>
To: dev@apr.apache.org
Subject: Re: RFC use APR's getpass() instead of native getpass() on HP-UX?
Message-ID: <20041201193042.GA9056@redhat.com>
Mail-Followup-To: dev@apr.apache.org
References: <cc67648e04120106363304ab03@mail.gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <cc67648e04120106363304ab03@mail.gmail.com>
User-Agent: Mutt/1.4.1i

On Wed, Dec 01, 2004 at 09:36:32AM -0500, Jeff Trawick wrote:
> HP-UX apparently has no other function than getpass(), and it silently
> truncates after 8 characters.  There are Apache httpd and Subversion
> users grappling with this limit.  (It caused a some puzzlement for me
> with cvs too, but APR won't help that ;) )
> 
> The hint from Joe is to set ac_cv_func_getpass=no before running
> configure.  A nicer way would be to add a configure option such as
> --enable-apr-getpass.  But why not avoid the system getpass() by
> default?  Is maintaining compatibility with limitations of other
> applications on the same system preferable to breaking compatibility
> with the same application used on different systems with different
> native capabilities?

Using the getpass replacement iff PASS_MAX is defined and "small" would
sound sensible?  The terminal handling of the APR getpass doesn't look
as good as my nearest libc w.r.t. handling control characters though if
that were fixed I guess it would be fine to use it on all platforms with
POSIX termios support.

But the trade-off is also against backwards-compatibility of APR, right? 
Use of long passwords could "break" when upgrading to a new version of
APR with this fixed, since they would stop being truncated, although the
workaround is obviously simple. 

I think I'd agree that compatibility of applications across platforms
would be of more value than any of the other compatibilities, in any
case!

joe