apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeff Trawick <traw...@gmail.com>
Subject Re: RFC use APR's getpass() instead of native getpass() on HP-UX?
Date Fri, 03 Dec 2004 17:09:23 GMT
On Wed, 1 Dec 2004 19:30:43 +0000, Joe Orton <jorton@redhat.com> wrote:
> 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.

is this an accurate understanding?

the migration problem comes with the subversion-type usage scenario;
user thinks password is 10 characters; actual stored password on
server (HP-UX) was truncated at 8 characters; user upgrades APR on
HP-UX client and now the passwords don't match when user continues to
enter 10 characters; if server wasn't HP-UX or client wasn't HP-UX, it
never would have worked to begin with; when both are HP-UX, client has
to now be aware that they only thought their password was 10
characters, and it was really 8

with the Apache httpd (htpasswd) testcase, the discrepancy would
already have been noted since the long password entered on the web
browser dialog would never have matched; so no migration concern

View raw message