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 Sat, 04 Dec 2004 13:43:26 GMT
On Fri, 3 Dec 2004 20:31:56 +0000, Joe Orton <jorton@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 <jorton@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

Mime
View raw message