For information. this will concerns new parsec authentication.

In this regards, most people will use some pools, configured with one user, and ext-salt doesn't change for a user.
This means having 'parsec' send in Initial Handshake Packet authentication plugin name + having the "server scramble" directly send in this packet, first connection will have to request ext-salt, but can cache it, then all others new connection can directly send the "random 32-byte scramble, and the concat(server scramble, client scramble) ed25519-signed by a secret key generated from the PBKDF2(password, ext-salt)" in Handshake Response Packet, without further exchanges.

It would be good to have a description here of what will be implemented, to be sure we are ok on what will be done

diego dupin thank you for the link! Now I know that an initial scramble is variable sized at the protocol level. Because it was hardcoded as 20-byte long on both client and server:

#define SCRAMBLE_LENGTH 20

My idea was to deal with the implementation gently, so I just sent first 20 bytes of parsec's scramble as "initial handshake scramble":

  my_random_bytes(scramble_pair.server, CHALLENGE_SCRAMBLE_LENGTH);

  memcpy(info->scramble, scramble_pair.server, SCRAMBLE_LENGTH);

  info->scramble[SCRAMBLE_LENGTH]= 0;

  if (vio->write_packet(vio, scramble_pair.server, sizeof(scramble_pair.server)))

    return CR_ERROR;

[github commit]

This of course means that first 20 bytes will duplicate, but I believe they'll be sent in the same packet, so it won't affect the handshake performance.

The next thing we want to make is to read ext-salt from the client config file. This is what you propose as well, I just don't see how can we cache it other than store it manually with the user's help (AFAIK we don't have any client cache).

The latter is not in the scope of this task though.

I came across a better solution.

The server always treats first 20 bytes of default plugin's payload as scramble, during the first write_packet. The client didn't set the scramble itself, though.

I had to fix the server logic to support payloads larger than 20 bytes. The plugins still can set the scramble manually, on both client and server side, if they [would] want so.

As a result, no duplicated scramble bytes sent, and the plugins require no changes to be able to be set as default. And also scramble is set (and used) seamlessly.

I expect the login process to be backward-compatible with 3.4 clients, of course unless default_auth_plugin (other that old or native) is used.

serg please review the following commits:

Libmariadb: 

12d78187 Auth: release the plugins from responsibility to fill scramble_buff.

Server:

982bf06d MDEV-12320 configurable default authentication plugin for the server

bd616a37 Auth: set thd->scramble in all cases during writing Initial Handshake Packet

bbbb429a Auth: release the plugins from responsibility to fill scramble_buff

diego dupin FYI

mysql already have some variable named `default-authentication-plugin` if i'm not wrong commit use a different naming 'default_auth_plugin'. It would be better to use the same naming

see https://dev.mysql.com/blog-archive/upgrading-to-mysql-8-0-default-authentication-plugin-considerations/