World: r3wp

according to above, it is not so difficult - algorithm is as above 
...

what I am not sure is if I can use checksum to get equivalent of 
above sha1("password") ?

Ah right:
checksum/secure checksum/secure "mypass"
== #{6C8989366EAF75BB670AD8EA7A7FC1176A95CEF4}

looks same as in 
http://dev.mysql.com/doc/refman/5.0/en/password-hashing.html

what is checksum/method "mypass" 'sha1 good for then?

does it mean mySQL new password method is even more rebol friendly 
as it was in the past? hmm, if so, should not be difficult to proceed 
from this point?

that checksum has only 20 digits?
'sha1, maybe more explicit?

above scheme, what client does, and what server does, should be sufficient 
to achieve the result?

I just wonder why Doc implemented scrambler in such complicated way 
then? Maybe older mysql did so too (some non standard mechanism). 
Do implemented 'floor, crypt-v9, crypt-v10, scramble, hash-v9, hash-v10 
in his scrambler object...

looks like a direct translation of the c-code to me.

i think it would be enough, if you figure out how Doc sends data 
to server. Have no experience with mysql unfortunally., always using 
files..

I figured it out ...

:-)

BTW, good recherche :)

there is read-packet and write-packet functions ...

in write-packet, there is part, where he simply sends passwd and 
calls 'scramble on it ... scramble decides upon protocol V9 or V10 
version, and calls crypt-v9 or crypt-v10 accordingly, those two call 
hash-v9 or hash-v10 ....

simply put - server sends you a "seed", that is stored in 'crypt-seed 
... you then use that seed for your hashing ...

I was not able to find-out, what just does v9 or V10 protocol mean? 
maybe mySQL protocol version ...

but dunno also, if it has anything in commone with password method 
used, as you can simply use old or new scheme with new server version 
...

Yes. "It supports server protocols v9 and v10, so it should work 
with all versions of mySQL." http://softinnov.org/rebol/mysql-usage.html

how do I automatically distinguish what version is mySQL communicating 
with me when sending me a seed is unknown to me yet ...

I mean - what password version ...

On server-side it is marked with a "*" as first char.

I just know that mySQL distinguishes it for itself simply by using 
asterisk as a first char in password ...

nice - checksum/secure "mypass" = checsum/method "mypass" 'sha1

Does this help? http://www.redferni.uklinux.net/mysql/MySQL-Protocol.html

so maybe we are closer to solution then it might seem :-) with older 
password schemes, maybe all those funcs were needed, as 'sha1standard 
 was not used?

could be.

thanks for the above link, informative ... clears some bits for me 
...

That article says password-length is given by a count-byte.

Doc already has 'long-password constant there, but it is not further 
used ...

what do you mean by "count-byte"?

ah, length? passwd?

but - server does not send password, only the 'seed ...

look for "preceeded with a single byte". yes, length.

ok, going for lunch .... I will look into it later ... thanks for 
the tips ...

its not the password, its this sha1-thing i guess.

it says "usually 20", like the cha1-length. Good lunch.

yes, hash is 20 bytes long, but server sends you a seed, which is 
shorter ... if I will not be able to distinguish by seed-lenght, 
then I will have to look elsewhere ... will check-on long-password 
constant ...

salt is sended before that, Salt="yF/WHCWj"

salt = seed ...

password is never sent ....

i think so. and a PROTOCOL_41 in a line nearby.

yes, it says scrambeled password. i guess the clients sends the length 
and then that sha1-wrangled thing.

so I have to find a way, how to distinguish, what passwd version 
is stored on the server ... it starts with asterisk, so the server 
easily knows, but seed does not start with asterisk ... which is 
a pity, would be trivial :-)

Caps=LONG_FLAG | CONNECT_WITH_DB | COMPRESS | TRANSACTIONS | PROTOCOL_41 
| SECURE_CONNECTION

is send by the server.

and?

protocol_41 means a long password?

i hope so. reminds on mysql 4.1