Re: RFC use APR's getpass() instead of native getpass() on HP-UX?
On Wed, 1 Dec 2004 19:30:43 +, Joe Orton [EMAIL PROTECTED] 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?
At 11:09 AM 12/3/2004, Jeff Trawick wrote: On Wed, 1 Dec 2004 19:30:43 +, Joe Orton [EMAIL PROTECTED] 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?
On Fri, Dec 03, 2004 at 12:09:23PM -0500, Jeff Trawick wrote: On Wed, 1 Dec 2004 19:30:43 +, Joe Orton [EMAIL PROTECTED] 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
