[p4] long passwords

[Matt Craighead]

I think I can expand on the p4api behavior based on my latest experiments.

On a non-Unicode P4 server, everything seems to work as expected.

On a Unicode P4 server, I make the following sequence of calls: (a little
bit of pseudocode here)

ClientApi::SetProtocol("tag", "");
ClientApi::SetTrans(CharSetApi::UTF_8, 0, 0, 0);
ClientApi::SetCharset("utf8");
ClientApi::SetPort(<port>);
ClientApi::Init();
ClientApi::SetUser(<username>);
ClientApi::SetPassword("abcdefghij1234567890");
ClientApi::SetArgv("-m", "1", "-s", "submitted");
ClientApi::Run("changes");

...and I get an error.  I do *not* get an error if I
SetPassword("abcdefghij123456") instead, even though I originally entered
the password at the "p4 passwd" prompt as "abcdefghij1234567890".

When I use the p4.exe command line client, on the other hand,
"abcdefghij1234567890" works just fine as the password, as does
"abcdefghij123456", or "abcdefghij123456_garbage", or whatever, as long as
the first 16 match.  So it's only with the API that this happens.  I'm not
sure how p4.exe is doing things differently such that it doesn't run into
the same issue.

I can't just truncate all passwords to 16 characters before calling the
P4API, because tickets need all 32.  I could guess whether it's a ticket or
not by looking at its length (must be exactly 32) and content (must be all
hex digits), but now we're getting into the realm of pretty egregious hacks
-- surely there must be a simpler, more obvious answer as to what's going
on?

I'm honestly a little confused as to whether I am using the
SetTrans()/SetCharset() APIs correctly.  The p4api docs online make no
mention of these APIs, so I'm going based on a few random tidbits I dug up
from the Web suggesting that SetCharset() by itself does nothing, and you
have to use SetTrans().  Of course I don't know whether a server is Unicode
or not before connecting to it (there doesn't seem to be any way to know
except to try and see if you get an error), so it's rather more involved
than the pseudocode above would indicate, but I tried simplifying everything
down to the above and it didn't help.

On Thu, Oct 9, 2008 at 4:50 PM, Matt Craighead <
matt.craighead at conifersystems.com> wrote:

>  Some experiments I've just run seem to suggest that Perforce truncates
> passwords longer than 16 characters back down to 16 characters before
> storing or comparing them.  Is this correct?  I don't see anything in either
> the user or administrator docs talking about a maximum password length.
>
>  I can put in whatever garbage I want after those first 16 characters in
> the password, and it doesn't seem to make a difference.
>
>  Note: this does *not* apply to tickets, where all 32 hex digits appear to
> be significant (and in fact even changing uppercase to lowercase hex digits
> will give you an error).
>
> I'm also seeing some particularly unusual behavior with >16 character
> passwords via the p4api, but I haven't entirely figured out what is going on
> yet, so I'll refrain from speculating as to what the issue is.
>
> --
> Matt Craighead
> Founder/CEO, Conifer Systems LLC
> http://www.conifersystems.com
> 512-772-1834
>



-- 
Matt Craighead
Founder/CEO, Conifer Systems LLC
http://www.conifersystems.com
512-772-1834