On Fri, 3 Dec 2004 20:31:56 +0000, Joe Orton <[EMAIL PROTECTED]> 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 <[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,
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
