Archive for the ‘protocol’ Category

CLIENT_LONG_PASSWORD

Февраль 23rd, 2012

Today a little history lesson.

I was on a quest to find the origin of this line in include/mysql_com.h:

#define CLIENT_LONG_PASSWORD    1       /* new more secure passwords */

"new" ? "more secure" ?

These CLIENT_* flags are used between client and server to negotiate what capabilities they support. It allows the server to add new features to the protocol and let's the client add support for it along the way. MySQL 5.5.x has 21 of these flags.

But back to CLIENT_LONG_PASSWORD and its wonderful comment. What would one expect if someone reads "new" and "more secure"?

new

Well, let's check the file history:

$ bzr blame include/mysql_com.h
2            bk@work | #define CLIENT_LONG_PASSWORD 1   /* new more secure passwords */
$ bzr log -c 2
revno: 2
committer: bk@work.mysql.com
timestamp: Mon 2000-07-31 21:29:14 +0200

Hmm, 2000? MySQL is older than that. To the archives!

mysql-4.1.1-alpha/include/mysql_com.h:#define CLIENT_LONG_PASSWORD  1   /* new more secure passwords */
mysql-4.1.0-alpha/include/mysql_com.h:#define CLIENT_LONG_PASSWORD  1   /* new more secure passwords */
mysql-3.23.49/include/mysql_com.h:#define CLIENT_LONG_PASSWORD  1   /* new more secure passwords */
mysql-3.22.32/include/mysql_com.h:#define CLIENT_LONG_PASSWORD  1   /* new more secure passwords */
mysql-3.21.33b/include/mysql_com.h:#define CLIENT_LONG_PASSWORD 1   /* new more secure passwords */

First non-match: 3.20.x. The whole feature of capabilities was added in 3.21.x and CLIENT_LONG_PASSWORD was its first use-case.

$ ls -ls mysql-3.21.33b/include/mysql_com.h
16 -rw-r--r--  1 jan  staff  5173 Jul  8  1998 mysql-3.21.33b/include/mysql_com.h

Since 14 years this is new.

more secure

More secure it says. Well, this flag is used by the function check_scramble() to flip some more bits (if set, old_ver == FALSE):

my_bool check_scramble(const char *scramble, const char *message,
                   ulong *hash_pass, my_bool old_ver)
{
  struct rand_struct rand;
  ulong hash_message[2];
  char buff[16],*to,extra;                  /* Big enough for check */
  const char *pos;

  hash_password(hash_message,message);
  if (old_ver)
    old_randominit(&rand,hash_pass[0] ^ hash_message[0]);
  else
    randominit(&rand,hash_pass[0] ^ hash_message[0],
           hash_pass[1] ^ hash_message[1]);
  to=buff;
  for (pos=scramble ; *pos ; pos++)
    *to++=(char) (floor(rnd(&rand)*31)+64);
  if (old_ver)
    extra=0;
  else
    extra=(char) (floor(rnd(&rand)*31));
  to=buff;
  while (*scramble)
  {
    if (*scramble++ != (char) (*to++ ^ extra))
      return 1;                                     /* Wrong password */
  }
  return 0;
}

That is the OLD_PASSWORD() which had a VERY_OLD_PASSWORD() variant it seems. Both of them are broken and shouldn't be used anymore.

essence

Luckily this flag lost its meaning a long time ago. Since 4.1.x it is assumed that it is always set and since the same release there is a SHA1-based hashing for your passwords. No one gets harmed.

Perhaps someone should update the comment of that flag though.


PlanetMySQL Voting: Vote UP / Vote DOWN

Protocol, the GPL, and how Bazaar can help

Март 17th, 2010
Bazaar
Mark Callaghan asks Can a protocol be GPL?, after finding a disturbing comment in a source file:
Any re-implementations of this protocol must also be under GPL, unless one has got an license from MySQL AB stating otherwise.

I recall talking with one of the company lawyers about this matter, and he assured me that the GPL can't be used for a protocol, and that's why this notice was dropped from MySQL.com site a few years ago, even before the Sun acquisition.
This is thus an embarrassing piece of ancient history (which will hopefully be removed soon) that has been in our files for long time. For how long?
If we get the source trees from the public bazaar repository, we don't get a good answer.

$ bzr annotate --long --all sql/net_serv.cc | head -n 24 |tail -n 9
2476.648.3 cmiller@xxxxx 20071011 | /**
2476.648.3 cmiller@xxxxx 20071011 | @file
2476.648.3 cmiller@xxxxx 20071011 |
1616.1722.3 joerg@xxxxx 20050307 | This file is the net layer API for the MySQL client/server protocol,
1616.1722.3 joerg@xxxxx 20050307 | which is a tightly coupled, proprietary protocol owned by MySQL AB.
2476.648.3 cmiller@xxxxx 20071011 | @note
1616.1722.3 joerg@xxxxx 20050307 | Any re-implementations of this protocol must also be under GPL
1616.1722.3 joerg@xxxxx 20050307 | unless one has got an license from MySQL AB stating otherwise.
1616.1722.3 joerg@xxxxx 20050307 |

Inspecting revision 1616.1722.3, we learn that it was just a merge. This thing was much older. A comment in Mark's blog from Venu Anuganti put me on the right track. He was a MySQL employee in 2003, and thus I needed to find older annotations.
A few years ago I showed how you could get back in time using Bazaar .
Using this technique, I resuscitated MySQL 4.1.2

$ bzr branch -r tag:mysql-4.1.2 lp:mysql-server/5.1 branch4.1.2
$ cd branch4.1.2
$ bzr annotate --long --all sql/net_serv.cc | head -n 24 |tail -n 9
2 bk@xxxxxxx 20000731 |
1098.3.1 monty@xxxx 20020723 | /*
1538.19.1 monty@xxxx 20030604 | This file is the net layer API for the MySQL client/server protocol,
1538.19.1 monty@xxxx 20030604 | which is a tightly coupled, proprietary protocol owned by MySQL AB.
1538.19.1 monty@xxxx 20030604 | Any re-implementations of this protocol must also be under GPL
1538.19.1 monty@xxxx 20030604 | unless one has got an license from MySQL AB stating otherwise.
1538.19.1 monty@xxxx 20030604 | */
1538.19.1 monty@xxxx 20030604 |
1538.19.1 monty@xxxx 20030604 | /*

$bzr log -r 1538.19.1
------------------------------------------------------------
revno: 1538.19.1
committer: monty@xxxx
timestamp: Wed 2003-06-04 18:28:51 +0300

So, this looks like a commit, not a merge, and thus we have found the origin of the offending message.
However, there is a problem.
In a comment on a recent Brian's blog post, Monty said
"I have never said or claimed that the GPL affects you over the protocol."
I am sure there is a reason for this quote, but unfortunately Bazaar doesn't have an answer.

PlanetMySQL Voting: Vote UP / Vote DOWN