RFC use APR's getpass() instead of native getpass() on HP-UX?

[Jeff Trawick <tr...@gmail.com>]

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?

Re: RFC use APR's getpass() instead of native getpass() on HP-UX?

["William A. Rowe, Jr." <wr...@rowe-clan.net>]

At 11:09 AM 12/3/2004, Jeff Trawick wrote:
>On Wed, 1 Dec 2004 19:30:43 +0000, Joe Orton <jo...@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?
>
>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

Yes.  Now the question becomes, do we fix?  Since it changes the
expectations, my thought is;

1. optionally disable in 0.9, 1.x APR.  Put this in README.
2. automatically disable in 2.0 APR. 

Re: RFC use APR's getpass() instead of native getpass() on HP-UX?

[Jeff Trawick <tr...@gmail.com>]

On Fri, 3 Dec 2004 20:31:56 +0000, Joe Orton <jo...@redhat.com> wrote:
> On Fri, Dec 03, 2004 at 12:09:23PM -0500, Jeff Trawick wrote:
> > On Wed, 1 Dec 2004 19:30:43 +0000, Joe Orton <jo...@redhat.com> wrote:
> ...
> 
> 
> > > 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
> 
> Yes, exactly.  But I agree with your original sentiment,

oh, agreed; just trying to state things more explicitly to ensure that
I didn't miss a more pervasive migration issue

I gather that some subversion users on HP-UX have already switched
manually to the APR implementation.  I'll try to play with it myself
soon.

As you say, the switch could be made for platforms that define a limit
constant and where the value is less than some magic number*.  I'm
leery of switching away from the OS implementation unless it has a
limitation which we expect will affect more than a handful of users.

*16?  google thinks that Tru64 and Ultrix have such a limit

Re: RFC use APR's getpass() instead of native getpass() on HP-UX?

[Joe Orton <jo...@redhat.com>]

On Fri, Dec 03, 2004 at 12:09:23PM -0500, Jeff Trawick wrote:
> On Wed, 1 Dec 2004 19:30:43 +0000, Joe Orton <jo...@redhat.com> wrote:
...
> > 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

Yes, exactly.  But I agree with your original sentiment, that fixing the
bug and making the APR behaviour consistent across platforms for both
0.9.x and 1.0.x is worth breaking this rather obscure "compatibility". 
Anyone who relied on passwords being truncated at 8 characters before
can just stop typing after the 8th character, that's simple enough.

The number of people this will burn is probably pretty small.

joe

Re: RFC use APR's getpass() instead of native getpass() on HP-UX?

[Jeff Trawick <tr...@gmail.com>]

On Wed, 1 Dec 2004 19:30:43 +0000, Joe Orton <jo...@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

Re: RFC use APR's getpass() instead of native getpass() on HP-UX?

["William A. Rowe, Jr." <wr...@rowe-clan.net>]

Joe makes a good point, +1 for this change when we roll over into 2.0.

Bill

At 01:30 PM 12/1/2004, Joe Orton 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. 
>
>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

Re: RFC use APR's getpass() instead of native getpass() on HP-UX?

[Joe Orton <jo...@redhat.com>]

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