MySQL Router 8.0.11 GA has been released

Dear MySQL users,

MySQL Router 8.0.11 is the first GA release for MySQL Router 8.0 series.

The MySQL Router is a new building block for high availability solutions
based on MySQL InnoDB clusters.

By taking advantage of the new Group Replication technology, and
combined with the MySQL Shell, InnoDB clusters provide an integrated
solution for high availability and scalability for InnoDB based MySQL
databases, that does not require advanced MySQL expertise.

The deployment of applications with high availability requirements is
greatly simplified by MySQL Router. MySQL client connections are
transparently routed to online members of a InnoDB cluster, with MySQL
server outages and cluster reconfigurations being automatically handled
by the Router.

To download MySQL Router 8.0.11, see the “Generally Available (GA)
Releases” tab at http://dev.mysql.com/downloads/router. Package
binaries are available for several platforms and also as a source code
download.

Documentation for MySQL Router can be found at
http://dev.mysql.com/doc/mysql-router/en/

Enjoy!

Changes in MySQL Router 8.0.11 (2018-04-19,General Availability)

Bugs Fixed

* Some failed SQL queries executed during the bootstrap
process resulted in a generic "Unknown error" message instead of
reporting the original error message received from the MySQL
server. As a workaround, setting level=DEBUG during bootstrap
yielded these SQL errors. (Bug #27721898)

* Some unexpected errors from the MySQL server were not
shown during the Router bootstrap process. (Bug #27721834)

* Router failed to compile on Alpine Linux 3.6. (Bug
#27697883)

* Router's max_connect_errors option did not function in
v8.0.4. (Bug #27564958)

* Bootstrapping would only function if --bootstrap was the
first command-line argument. Now the argument order is
irrelevant. (Bug #25054974)

On behalf of Oracle MySQL Release Team
Nawaz Nazeer Ahamed

MySQL Connector/Java 5.1.46 GA has been released

Dear MySQL Users,

MySQL Connector/J 5.1.46, a maintenance release of the production 5.1
branch has been released. Connector/J is the Type-IV pure-Java JDBC
driver for MySQL.

MySQL Connector Java is available in source and binary form from the
Connector/J download pages at
http://dev.mysql.com/downloads/connector/j/5.1.html
and mirror sites as well as Maven-2 repositories.

MySQL Connector Java (Commercial) is already available for download on the
My Oracle Support (MOS) website. This release will shortly be available on
eDelivery (OSDC).

As always, we recommend that you check the “CHANGES” file in the
download archive to be aware of changes in behavior that might affect
your application.

MySQL Connector/J 5.1.46 includes the following general bug fixes and
improvements, also available in more detail on
http://dev.mysql.com/doc/relnotes/connector-j/en/news-5-1-46.html

Changes in MySQL Connector/J 5.1.46 (2018-03-12)

Version 5.1.46 is a maintenance release of the production 5.1
branch. It is suitable for use with MySQL Server versions
5.5, 5.6, 5.7, and 8.0. It supports the Java Database
Connectivity (JDBC) 4.2 API.

Functionality Added or Changed

* Because Connector/J restricted TLS versions to v1.1 and
below by default when connecting to MySQL Community
Server 8.0 (which used to be compiled with yaSSL by
default and thus supporting only TLS v1.1 and below), it
failed to connect to to a MySQL 8.0.4 Community Server
(which has been compiled with OpenSSL by default and thus
supports TLS v1.2) that was configured to only allow TLS
v1.2 connections. TLS v1.2 is now enabled for connections
with MySQL Community Server 8.0.4 and later. (Bug
#27374581)

* The bundle for Connector/J 5.1 delivered by Oracle now
contains an additional jar package with the name
mysql-connector-java-5.1.ver.jar
(mysql-connector-java-commercial-5.1.ver.jar for
commercial bundles). It is identical with the other jar
package with the original package named
mysql-connector-java-5.1.ver-bin.jar
(mysql-connector-java-commercial-5.1.ver-bin.jar for
commercial bundles), except for its more Maven-friendly
file name. (Bug #27231383)

* The lower bound for the connection property
packetDebugBufferSize has been changed to 1, to avoid the
connection errors that occur when the value is set to 0.
(Bug #26819691)

* For multi-host connections, when a MySQL Server was
configured with autocommit=0, Connection.getAutoCommit()
did not return the correct value. This was because
useLocalSessionState=true was assumed for multi-host
connections, which might not be the case, resulting thus
in inconsistent session states.
With this fix, by default, Connector/J executes some
extra queries in the connection synchronization process
to guarantee consistent session states between the client
and the server at any connection switch. This would mean,
however, that when none of the hosts are available during
an attempted server switch, an exception for closed
connection will be thrown immediately while, in earlier
Connector/J versions, there would be a connection error
thrown first before a closed connection error. Error
handling in some applications might need to be adjusted
accordingly.
Applications can skip the new session state
synchronization mechanism by having
useLocalSessionState=true. (Bug #26314325, Bug #86741)

* Connector/J now supports the new caching_sha2_password
authentication plugin for MySQL 8.0, which is the default
authentication plugin for MySQL 8.0.4 and later (see
Caching SHA-2 Pluggable Authentication
(http://dev.mysql.com/doc/refman/8.0/en/caching-sha2-plug
gable-authentication.html) for details).
Note
To authenticate accounts with the caching_sha2_password
plugin, either a secure connection to the server using
SSL
(http://dev.mysql.com/doc/connector-j/5.1/en/connector-j-
reference-using-ssl.html) or an unencrypted connection
that supports password exchange using an RSA key pair
(enabled by setting one or both of the connecting
properties allowPublicKeyRetrieval and
serverRSAPublicKeyFile) must be used.
Because earlier versions of Connector/J 5.1 do not
support the caching_sha2_password authentication plugin
and therefore will not be able to connect to accounts
that authenticate with the new plugin (which might
include the root account created by default during a new
installation of a MySQL 8.0 Server), it is highly
recommended that you upgrade now to Connector/J 5.1.46,
to help ensure that your applications continue to work
smoothly with the latest MySQL 8.0 Server.

Bugs Fixed

* When Connector/J 5.1.44 or earlier connected to MySQL
5.7.20 or later, warnings are issued because Connector/J
used the deprecated system variables tx_isolation and
tx_read_only. These SQL-level warnings, returned from a
SHOW WARNINGS statement, might cause some applications to
throw errors and stop working. With this fix, the
deprecated variables are no longer used for MySQL 5.7.20
and later; also, to avoid similar issues, a SHOW WARNINGS
statement is no longer issued for the use of deprecated
variables. (Bug #27029657, Bug #88227)

* When the default database was not specified for a
connection, the connection attributes did not get stored
in the session_connect_attrs table in the Performance
Schema of the MySQL Server. (Bug #22362474, Bug #79612)

On Behalf of Oracle/MySQL Release Engineering Team
Hery Ramilison

Preparing your Community Connector for MySQL 8 – part 2 – SHA256

In part 1 of this series we looked at implementing support for the caching_sha2_password authentication plugin using the libmyqlclient C library.  This is possible for C based connectors or connectors that can make use of an external C library.  For some, this is not possible.  For example, Java and C# both function better if they don’t have to thunk out to an external library.  For these, implementing the MySQL client/server protocol natively is required.  This part 2 is about implementing support for the caching_sha2_password plugin natively.  It is expected that you already have a working connector and understand the client/server protocol.  For reference please internal documentation here.  This post will not attempt to always give you precise byte positions or counts.  For that please see the above linked internal documentation.

This blog post will not attempt to explain every aspect of implementing the connection phase of the client server protocol.   For help in implementing it please refer to https://dev.mysql.com/doc/internals/en/connection-phase.html.

Initial Handshake

When initially connected, the server sends an initial handshake packet with lots of information.  Part of that information is the default authentication plugin that is set for the server.  Many connectors give the user the option of specifying an authentication plugin via a configuration or connection string option.  Doing this can eliminate a round trip during authentication.  However if you don’t do this or the user has not specified an authentication method, then attempting authentication using the default method is the way to go.

So a handshake response packet is now sent.  Part of this packet is the username, the “auth response”, and the plugin name.   Username is simple and the plugin name will be the name of the authentication plugin you received in the initial handshake packet.   By default starting with 8.0.4, that will be “caching_sha2_password” (assuming we are not switching to a different method).  The “auth response” part of the packet is the SHA256 scramble of the password.  This scramble uses the format

XOR(SHA256(PASSWORD), SHA256(SHA256(SHA256(PASSWORD)), seed_bytes))

Here the seed_bytes are the bytes originally passed to the plugin.

After sending the handshake response packet to the server, the server will respond with a packet.  There are four possible responses from the server:

  • Server sends a “More data” packet (first byte == 0x01) with the second byte = 0x03.  This will be followed by a normal OK packet.  This is the case when the user’s password is already in the server cache and authentication has succeeded.  We call this the “fast” authentication.
  • Server sends back an “error” packet.  This means the user’s password is in the cache but it doesn’t match what was given.
  • Server sends back an “auth switch” packet (first byte == 0xFE).  This means that the user who is trying to authenticate is using a different authentication plugin than the one specified and an auth switch cycle needs to happen.
  • Server sends back a “More data” packet (first byte == 0x01) with the second byte = 0x04.  This means that more data is needed to complete the authentication.  In the example of using “caching_sha2_password” this means that the users password is not in the server cache and the server is asking the client to send the user’s full password.  This is called the “full” authentication.

Full Authentication

When the server cache does not contain the password hash, the server asks for the full password so the cache can be populated.  This can be done in one of two ways:

  • Passing it in plain text if the connection is already secure using SSL/TLS.
  • Encrypting it with the servers public key if the connection is not secure.

Full Authentication via SSL/TLS

If the connection is already secure then all that is necessary is to pass the users password in clear text.  This is as simple as simply sending a single packet containing only the password as a zero terminated array of bytes.  The server will then respond with either an “Ok” packet if authentication was successful or an “Error” packet if not.

Full Authentication via RSA Key Exchange

If the connection is not already secure then passing the password in clear text is obviously not going to work.  This case is handled by the client encrypting the user’s password with the server’s public key and sending that back.  Here are the steps to accomplishing that.

  • In response to receiving the 0x01 0x04 packet from the server, the client has two choices.  The client could respond with a packet containing the single byte 0x02.  This requests the server send it’s public key.  This is considered somewhat insecure.  A better option if available would be for the client to have the server public key locally.  This would be stored in some implementation defined way.
  • If the client requested the server send the public key, the server will then respond with a “More data” packet containing the servers public key
  • The client then responds with the password encrypted with the servers public key. (see below for more details)
  • The server would then respond with either the Ok or Error packet.

Password Encryption (a closer look)

The password is “obfuscated” first by employing a rotating “xor” against the seed bytes that were given to the authentication plugin upon initial handshake.   Pseudocode for this might look like this:

Buffer would then be encrypted using the RSA public key the server passed to the client.  The resulting buffer would then be passed back to the server.

RSA Padding Change

It’s important to note that a incompatible change happened in server 8.0.5.  Prior to server 8.0.5 the encryption was done using RSA_PKCS1_PADDING.  With 8.0.5 it is done with RSA_PKCS1_OAEP_PADDING.  This means that if you have implemented support for this authentication scheme for servers prior to 8.0.5 you will need to update your connector to make this change.

Conclusion

I hope this blog has helped you understand a bit better how to implement this new security protocol into your product.  We continually strive to find new and better ways to help protect your data.  Please let us know if you have any questions or find any errors with this post!

MySQL Connector/C++ 8.0.7-rc has been released

Dear MySQL users,

MySQL Connector/C++ 8.0.7-rc is the release candidate (RC)
of the MySQL Connector/C++ 8.0 series.

Connector/C++ 8.0 can be used to access MySQL implementing Document
Store or in a traditional way, using SQL queries. It allows writing
both C++ applications using X DevAPI or plain C applications using
XAPI.

To learn more about how to write applications using X DevAPI, see
“X DevAPI User Guide”

https://dev.mysql.com/doc/x-devapi-userguide/en/

and “X DevAPI Reference” at

https://dev.mysql.com/doc/dev/connector-cpp/devapi_ref.html

For more information about using plain C XAPI see “XAPI Reference” at

https://dev.mysql.com/doc/dev/connector-cpp/xapi_ref.html

For generic information on using Connector/C++ 8.0, see

https://dev.mysql.com/doc/dev/connector-cpp/

Note

Connector/C++ 8.0 requires MySQL Server version 8.0 or higher with
X Plugin enabled. For general documentation about how to get started
using MySQL as a document store, see “Using MySQL as a Document Store”

https://dev.mysql.com/doc/refman/5.7/en/document-store.html

To download MySQL Connector/C++ 8.0.7-rc, see the “Development Releases”
tab at

https://dev.mysql.com/downloads/connector/cpp/



Changes in MySQL Connector/C++ 8.0.7 (2018-02-26, Release
Candidate)

In addition to the new APIs introduced in MySQL Connector/C++
8.0 (X DevAPI and XAPI), Connector/C++ now also supports the
legacy API based on JDBC4. Applications written against the
JDBC4-based API of Connector/C++ 1.1 can be also compiled
with Connector/C++ 8.0, which is backward compatible with the
earlier version. Such code does not require the X Plugin and
can communicate with older versions of the MySQL Server using
the legacy protocol. This contrasts with X DevAPI and XAPI
applications, which expect MySQL Server 8.0.

The legacy API is implemented as a separate library with base
name mysqlcppconn as opposed to mysqlcppconn8 library
implementing the new APIs. For information about using the
legacy API, refer to the documentation at
http://dev.mysql.com/doc/connector-cpp/en/connector-cpp-getting-started-examples.html.

* Deprecation and Removal Notes

* Security Notes

* X DevAPI and XAPI Notes

* Functionality Added or Changed

* Bugs Fixed

Deprecation and Removal Notes

* View and table DDL methods have been removed. It is
preferable that SQL statements be used for such
operations.
Removed X DevAPI methods:
Schema.createView()
Schema.alterView()
Schema.dropView()
Schema.dropTable()

Removed X DevAPI data types:
Algorithm
CheckOption
SQLSecurity

Removed XAPI functions:
mysqlx_view_create
mysqlx_view_create_new
mysqlx_view_modify
mysqlx_view_modify_new
mysqlx_view_replace
mysqlx_view_replace_new
mysqlx_view_drop
mysqlx_table_drop
mysqlx_set_view_algorithm
mysqlx_set_view_security
mysqlx_set_view_definer
mysqlx_set_view_check_option
mysqlx_set_view_columns

Removed XAPI enumerations:
mysqlx_view_algorithm_t
mysqlx_view_security_t
mysqlx_view_check_option_t

Removed XAPI macros:
VIEW_ALGORITHM()
VIEW_SECURITY()
VIEW_DEFINER()
VIEW_CHECK_OPTION()
VIEW_COLUMNS()
VIEW_OPTION_XXX

Security Notes

* MySQL Connector/C++ now supports the
caching_sha2_password authentication plugin introduced in
MySQL 8.0 (see Caching SHA-2 Pluggable Authentication
(http://dev.mysql.com/doc/refman/8.0/en/caching-sha2-pluggable-authentication.html)),
with these limitations:

+ For applications that use X DevAPI or XAPI, only
encrypted (SSL) connections can be used to connect
to cached_sha2_password accounts. For non-SSL
connections, it is not possible to use
cached_sha2_password accounts.

+ For applications that use the legacy protocol, it is
not possible to make connections to
cached_sha2_password accounts in the following
scenario:
o The connection is unencrypted (OPT_SSL_MODE is
set to SSL_MODE_DISABLED).
o The server public key is given using the
"rsaKey" option and no RSA key exchange is used
(OPT_GET_SERVER_PUBLIC_KEY is set to false).
If RSA key exchange is enabled, the connection
works.

X DevAPI and XAPI Notes

* It is now possible to use the Collection interface to
create and drop indexes on document collections.
X DevAPI example:
coll.createIndex("idx",
R"({
"fields": [
{ "field": "$.zip", "type": "TEXT(10)" },
{ "field": "$.count", "type": "INT UNSIGNED" }
]
})"
);

coll.createIndex("loc",
R"({
"type": "SPATIAL",
"fields": [ { "field": "$.coords", "type": "GEOJSON", "srid": 3128
7 } ]
})"
);

coll.dropIndex("idx");

XAPI example:
ret = mysqlx_collection_create_index(coll, "idx",
R"({
"fields": [
{ "field": "$.zip", "type": "TEXT(10)" },
{ "field": "$.count", "type": "INT UNSIGNED" }
]
})"
)

ret = mysqlx_collecton_create_index(coll, "loc",
R"({
"type": "SPATIAL",
"fields": [ { "field": "$.coords", "type": "GEOJSON", "srid": 3128
7 } ]
})"
);

mysqlx_collection_drop_index(coll, "idx");


* It is now possible to use the Session interface to create
savepoints inside transactions and roll back a
transaction to a given savepoint. This interface supports
the operations provided by the SAVEPOINT, ROLLBACK TO
SAVEPOINT, and RELEASE SAVEPOINT statements. For more
information about these statements, see SAVEPOINT,
ROLLBACK TO SAVEPOINT, and RELEASE SAVEPOINT Syntax
(http://dev.mysql.com/doc/refman/8.0/en/savepoint.html).
X DevAPI example:
sess.startTransaction();
string point1 = sess.setSavepoint();
sess.setSavepoint("point2");
sess.rollbackTo(point1);         // this also removes savepoint "point
2"
string point3 = sess.setSavepoint();
sess.releaseSavepoint(point3);  // explicitly remove savepoint
sess.commitTransaction();

XAPI example:
mysqlx_trasaction_begin(sess);
const char *point1 = mysqlx_savepoint_set(sess,NULL);
mysqlx_savepoint_set(sess,"point2");
mysqlx_rollback_to(sess,point1);
const char *point3 = mysqlx_savepoint_set(sess,NULL);
mysqlx_sevepoint_release(sess,point3);
mysqlx_transaction_commit(sess);

Functionality Added or Changed

* MySQL Connector/C++ now implements TLS connections using
the OpenSSL library. It is possible to build
Connector/C++ with OpenSSL or the bundled yaSSL
implementation of TLS. This is controlled by the WITH_SSL
CMake option, which takes these values: bundled (build
using bundled yaSSL code); system (build using system
OpenSSL library, with the location as detected by CMake);
path_name (build using OpenSSL library installed at the
named location). For more information, see
http://dev.mysql.com/doc/dev/connector-cpp/8.0/building.html

Bugs Fixed

* replaceOne() and similar methods did not correctly detect
document ID mismatches. (Bug #27246854)

* Calling bind() twice on the same parameter for complex
types resulted in empty values. (Bug #26962725)

On Behalf of the MySQL/Oracle Release Engineering Team,
Daniel Horecki

Welcome to Slack!

Open source is at the foundation of MySQL and the biggest and best part of open source is the legion of developers and users who use and contribute to our great product.  It has always been of incredible importance to us to interact with our friends in MySQL space and one of the great ways of doing that is via IRC (Internet Relay Chat) on #freenode.  While that still remains a great option many other systems have been developed that offer other advantages.  One of those is slack.

We wanted to create a slack space where our users could hang out, help each other, and interact with MySQL developers.  We’re in no way wanting to replace IRC but just wanting to make it even easier to solve your MySQL problems and learn about the many great things we are working on.

Head on over to http://mysqlcommunity.slack.com to join in on the fun!

MySQL Router 8.0.4-rc has been released

Dear MySQL users,

MySQL Router 8.0.4-rc is the first release candidate for MySQL Router
8.0 series.

The MySQL Router is a new building block for high availability solutions
based on MySQL InnoDB clusters.

By taking advantage of the new Group Replication technology, and
combined with the MySQL Shell, InnoDB clusters provide an integrated
solution for high availability and scalability for InnoDB based MySQL
databases, that does not require advanced MySQL expertise.

The deployment of applications with high availability requirements is
greatly simplified by MySQL Router. MySQL client connections are
transparently routed to online members of a InnoDB cluster, with MySQL
server outages and cluster reconfigurations being automatically handled
by the Router.

To download MySQL Router 8.0.4-rc, see the “Development Releases” tab at
http://dev.mysql.com/downloads/router. Package binaries are available
for several platforms and also as a source code download.

Documentation for MySQL Router can be found at
http://dev.mysql.com/doc/mysql-router/en/

Enjoy!

Changes in MySQL Router 8.0.4 (2018-02-07, Release Candidate)


   Functionality Added or Changed

     * Bootstrapping now accepts the --config option and reads
       the [logger] level option's definition. For example, to enable
       bootstrap's debugging mode:
      
       [logger]
       level = DEBUG

       (Bug #27158098)

     * The default ttl metadata option (Time To Live, in
       seconds) changed from 300 to 5. (Bug #26990955, Bug #88140)

     * The new connect_timeout and read_timeout options were
       added. These are defined under the [DEFAULT] namespace and affect
       internal operations, such as metadata server connections. (Bug
       #26877946)

     * Bootstrap now accepts any member of an InnoDB cluster and
       automatically finds and reconnects to a writable primary.  (Bug
       #25489509)

     * The optional routing_strategy configuration option was
       added. The available values are first-available, next-available,
       round-robin, and round-robin-with-fallback.  Previously, these
       strategies were described as scheduling modes by the mode
       configuration option where the read-write mode defaults to the
       first-available strategy, and the read-only mode defaults to the
       round-robin strategy. This preserves previous behavior for these
       modes. (Bug #86261, Bug #26045094, Bug #25852803)

   Bugs Fixed

     * With logging_folder undefined during bootstrap, all logs
       were written to STDERR. Now, normal bootstrap logs are written to
       STDOUT and debug bootstrap logs are written to STDERR. (Bug
       #27232410)

     * Errors were changed to warnings for the following
       conditions: when Router could not connect to a particular
       metadata server, and when Router could not update the default
       metadata cache replicaset. Under these conditions, Router does
       not stop running because there are multiple metadata servers and
       replicasets. (Bug #27226627)

     * Configuring MySQL Router with sockets would create a
       socket that was only accessible by the MySQL Router user.  (Bug
       #27179456, Bug #88667)

     * The commercial .deb packages were missing the
       mysqlrouter_plugin_info tool. (Bug #27122367)

     * The apt purge process did not remove the
       /var/{lib,log,run}/mysqlrouter directories. (Bug #26955232)

     * Bootstrapping would fail when connecting to a MySQL
       Server under high load if an associated bootstrap query took
       longer than 5 seconds. The 5 second read timeout was increased
       from 5 to 30. In addition, command line options were added to
       change the connect and read timeout values.  (Bug #26877946)

     * Improved error text when bootstrapping against a MySQL
       server 8.0 instance that was not part of InnoDB cluster.  (Bug
       #26846040)

     * Router assumed that a resulting socket from accept()ing a
       socket would be always blocking. On Solaris and Windows this
       assumption is not valid, and this resulted in broken connections
       with large result sets. (Bug #26834769)

     * It was difficult to distinguish the "Too many
       connections" between MySQL Server and MySQL Router, so the Router
       variant now reads as "Too many connections to MySQL Router". (Bug
       #26593909)

     * The bundled README.txt was missing Protobuf and Rapid
       JSON references. (Bug #25619654)

     * Some builds were missing the sample configuration file,
       including the Solaris and Oracle Linux binaries. (Bug #25530691)

     * Router would check IPv4 or IPv6 addresses, but not both.
       Now it goes through the list of addresses and first tries to bind
       to an IPv4 address and if it fails then it goes through the same
       address list and tries to bind to an IPv6 address. (Bug
       #25127667)

     * The generated error message from passing in an empty file
       to --master-key-file (or using an empty mysqlrouter.key) was
       improved. (Bug #25111926)

     * Defining multiple logger sections in the configuration
       file would emit an unclear error. Defining multiple logger
       sections is not allowed. (Bug #25095565)

     * Where destinations=metadata-cache, the role attribute was
       not used or validated; only the mode configuration option was
       used. (Bug #25061854)

     * Failed bootstrap commands would leave a generated
       mysqlrouter.conf.tmp file on the system. (Bug #24930442)

     * On Ubuntu Linux, documentation related files were
       installed under both /usr/share/mysql-router/docs and
       /usr/share/doc/mysql-router. Now they are only installed under
       /usr/share/doc/mysql-router for community builds and
       /usr/share/doc/mysql-router-commercial for commercial builds.
       (Bug #24765509)

     * The maximum number of concurrent client connections was
       increased from about 500 to over 5000, a limit now dependent on
       the operation system. To achieve this, select() based fd event
       calls were replaced by poll() (or WSAPoll() on Windows). (Bug
       #22661705, Bug #80260)

     * The --ssl-key and --ssl-cert optional bootstrap
       command-line options were added. They directly use their MySQL
       client's counterparts, and specify the client-side certificate
       and private key to facilitate client-side authentication. This is
       useful when the root account used during bootstrap was created
       with REQUIRE X509, which requires the client to authenticate
       itself when logging in.

On behalf of Oracle MySQL Release Team
Nawaz Nazeer Ahamed

Preparing your Community Connector for MySQL 8 – part 1 – SHA256

As some of you are by now aware we have shipped MySQL version 8.0.4 and with it delivered a change to the default authentication plugin that is used by the server when new users are created and is announced by the server to the client.  This was done to further tighten the security of MySQL.  Please refer to this article for a good explanation of this new authentication plugin and why it is important.

If you are an application user or application developer and you want to use MySQL 8.0.3 or 8.0.4 and make use of this new authentication plugin then you need to make sure that connector you use supports it.  As this is a new plugin, support for it in community connectors is still being developed.  I would encourage you to reach out to the communities that create the connector you use and let them  know you need this support.

This article (and the one coming after it) is for the connector developers.  There are two types of connectors out there.  The first type uses the libmysqlclient C library to implement the protocol.  The second type implements the MySQL client server protocol natively.  This article gives you important information for using libmysqclient in your connector.  A followup article will include relevant information for native implementations.

Which Version Should You Use?

Even though your application may currently link against the libmysqlclient library that comes with MySQL 5.7, this one will only work for authenticating users who are using other plugins such as mysql_native_password or sha256_password.  For all situations where new users would be created using the caching_sha2_password plugin, an updated connector that supports this plugin is required.  MySQL 8.0.4-rc contains libmysqlclient version 21 which fully understands this new plugin and can work with any user accounts.  We are exploring the possibility of backporting support for caching_sha2_password to previous versions of libmysqlclient.

It’s important to understand that the libmysqlclient library that comes with MySQL 8 is backward compatible and can connect to previous versions of the server so there is no significant need to support building against 5.7 and 8.0 versions at the same time.

How Do I Use It?

Exactly the way you have been using it.  The only change to the API related to this new authentication plugin is a new connection option to retrieve the server public key.  Here are the two scenarios and how they might be coded.

Using an SSL connection (same as for 5.7)
In this scenario the users credentials are passed to the server in plain text however they are passed via the SSL connection and are therefore passed securely.

Not using an SSL connection
In this scenario we are not using an SSL connection and so it is vital that the users credentials not get passed “in the clear”.  To facilitate this the servers public key is retrieved and is used for an RSA key exchange.

For for information on creating encrypted connections to the server, please see this page.

Conclusion

Connectors based on libmysqlclient can be updated very easily by simply updating the version of libmysqlclient they link against.

MySQL Connector/Python 8.0.6-rc has been released

Dear MySQL users,

MySQL Connector/Python 8.0.6-rc is the first release candidate version
of the MySQL Connector Python 8.0 series. This series adds support for
the new X DevAPI. The X DevAPI enables application developers to write
code that combines the strengths of the relational and document models
using a modern, NoSQL-like syntax that does not assume previous
experience writing traditional SQL.

To learn more about how to write applications using the X DevAPI, see
http://dev.mysql.com/doc/x-devapi-userguide/en/. For more information
about how the X DevAPI is implemented in MySQL Connector/Python, and its
usage, see http://dev.mysql.com/doc/dev/connector-python.

Please note that the X DevAPI requires MySQL Server version 5.7.12 or
higher with the X Plugin enabled. For general documentation about how to
get started using MySQL as a document store, see
http://dev.mysql.com/doc/refman/5.7/en/document-store.html.

To download MySQL Connector/Python 8.0.6-rc, see the “Development
Releases” tab at http://dev.mysql.com/downloads/connector/python/

Enjoy!

Changes in MySQL Connector/Python 8.0.6 (2018-02-01, Release
Candidate)

Functionality Added or Changed

* A new bdist_wheel distutils command was added to build a
Connector/Python wheel package.
A new –static option was added that enables static
linking for the C extension variant.

* X DevAPI: In the process of refining the definition of
the X DevAPI to cover the most relevant usage scenarios,
the following API components have been removed from the X
DevAPI implementation for Connector/Python:

+ API components that support session configurations.
The mysqlx.config namespace and all members of the
namespace.

+ The create_table, drop_table, create_view,
drop_view, and alter_view methods from the Schema
class.

* A Pylint test was added for the mysqlx module.

* A new Modify.patch() method was added to the X DevAPI as
a way to change several document attributes in one
operation; otherwise known as a JSON Merge Patch via RFC
7386.

* The create_index() method was added to the Collection
API.

* The transaction API was extended to allow setting
savepoints. The following methods have been added to the
Session object:

+ set_savepoint([name]): executes the SAVEPOINT name
SQL statement to generate a savepoint. If a name is
not provided (or None), one is generated.
The SAVEPOINT statement sets a named transaction
savepoint with a name of identifier. If the current
transaction has a savepoint with the same name, the
old savepoint is deleted and a new one is set.

+ release_savepoint(name): executes the RELEASE name
SQL statement to release a savepoint.
The RELEASE SAVEPOINT statement removes the named
savepoint from the set of savepoints of the current
transaction. No commit or rollback occurs. It
returns an error if the savepoint does not exist.

+ rollback_to(name): executes the ROLLBACK TO name SQL
statement to rollback a savepoint.
The ROLLBACK TO identifier command reverts the state
of the transaction back to what was when executed
the command SAVEPOINT identifier.
Names passed to these functions are checked to make sure
that the name is not null or an empty string. Names such
as ”, “”, , and so on, are not allowed even though
they are allowed by the server. For more information, see
SAVEPOINT, ROLLBACK TO SAVEPOINT, and RELEASE SAVEPOINT
Syntax
(http://dev.mysql.com/doc/refman/5.7/en/savepoint.html).

Bugs Fixed

* On Enterprise Linux 7, SSL connections could fail due to
the Python 2.7.9 or higher requirement. Since EL7
backported the SSL module from Python 3 (PEP466) into its
default Python 2.7.5, SSL connections are now enabled on
EL7. (Bug #27368032)

* MySQL Server 8.0 utf8mb4 collations were missing from
Connector/Python. (Bug #27277964)

* The LICENSE and README files were missing from the C
extension ( “cext”) builds. (Bug #26912787)

* Python 3.6 is now officially supported and tested.

On Behalf of Oracle/MySQL Release Engineering Team
Prashant Tekriwal

MySQL Connector/Java 8.0.9-rc has been released

Dear MySQL users,

MySQL Connector/Java 8.0.9-rc is the first Release Candidate
of the 8.0 branch of MySQL Connector/J, providing an insight into
upcoming features. It is suitable for use with MySQL Server versions
5.5, 5.6, 5.7, and 8.0. It supports the Java Database Connectivity
(JDBC) 4.2 API.

This release includes the following new features and changes, also
described in more detail on

https://dev.mysql.com/doc/relnotes/connector-j/8.0/en/news-8-0-9.html

MySQL Connectors and other MySQL client tools and applications now
synchronize the first digit of their version number with the (highest)
MySQL server version they support.
This change makes it easy and intuitive to decide which client version
to use for which server version.

As always, we recommend that you check the “CHANGES” file in the download
archive to be aware of changes in behavior that might affect your application.

To download MySQL Connector/Java 8.0.9-rc, see the “Development
Releases” tab at http://dev.mysql.com/downloads/connector/j/

Enjoy!

Changes in MySQL Connector/J 8.0.9 (2018-01-30, Release
Candidate)

Functionality Added or Changed

* X DevAPI: In the process of refining the definition of
the X DevAPI to cover the most relevant usage scenarios,
the following API components have been removed from the X
DevAPI implementation for Connector/J:

+ Components that support DDLs for views, including
the createView(), dropView(), and modifyView()
methods.

+ Components that support DDLS for tables, including
the createTable(), dropTable(), and modifyTable()
methods.

+ Components that support session configurations,
including the SessionConfig object, the
PersistenceHandler interface, the PasswordHandler
interface, and the SessionConfigManager class.

* X DevAPI: Added the setSavepoint(), rollbackTo(), and
releaseSavepoint() methods to the Session interface to
support the SAVEPOINT
(http://dev.mysql.com/doc/refman/8.0/en/savepoint.html),
ROLLBACK TO SAVEPOINT
(http://dev.mysql.com/doc/refman/8.0/en/savepoint.html),
and RELEASE SAVEPOINT
(http://dev.mysql.com/doc/refman/8.0/en/savepoint.html)
statements. See MySQL Connector/J X DevAPI Reference
(http://dev.mysql.com/doc/dev/connector-j) for more
details.

* X DevAPI: A new patch() function has been added to the
ModifyStatement interface. The function accepts an
JSON-like object describing document changes and applies
them to documents matched by the modify() filter. See
MySQL Connector/J X DevAPI Reference
(http://dev.mysql.com/doc/dev/connector-j) for more
details.

* X DevAPI: The createIndex() method for the Collection
interface now has a new syntax. See MySQL Connector/J X
DevAPI Reference
(http://dev.mysql.com/doc/dev/connector-j) for more
details.

* X DevAPI: Added the following methods for single-document
operations in the X DevAPI:

+ replaceOne()

+ addOrReplaceOne()

+ getOne()

+ removeOne()
See MySQL Connector/J X DevAPI Reference
(http://dev.mysql.com/doc/dev/connector-j) for more
details.

* X DevAPI: Setters and getters methods have been added for
the configuration properties with the MysqlDataSource,
MysqlXADataSource, and MysqlConnectionPoolDataSource
classes.

* X DevAPI: The connection property enabledTLSProtocols can
now be used to select the allowed TLS versions for an X
Protocol connection to the server.

* Connector/J now supports the new caching_sha2_password
authentication plugin, which is the default
authentication plugin for MySQL 8.0.4 and later (see
Caching SHA-2 Pluggable Authentication
(http://dev.mysql.com/doc/refman/8.0/en/caching-sha2-plug
gable-authentication.html) for details).
Note
To authenticate accounts with the caching_sha2_password
plugin, either a secure connection to the server using
SSL
(http://dev.mysql.com/doc/connector-j/8.0/en/connector-j-reference-using-ssl.html)
or an unencrypted connection that supports password exchange
using an RSA key pair (enabled by setting one or both of the
connecting properties allowPublicKeyRetrieval and
serverRSAPublicKeyFile) must be used.
Because earlier versions of Connector/J 8.0 do not
support the caching_sha2_password authentication plugin
and therefore will not be able to connect to accounts
that authenticate with the new plugin (which might
include the root account created by default during a new
installation of a MySQL 8.0 Server), it is highly
recommended that you upgrade now to Connector/J 8.0.9, to
help ensure that your applications continue to work
smoothly with the latest MySQL 8.0 Server.

* Connector/J now takes advantage of the MySQL Server 8.0
data dictionary by making the connection property
useInformationSchema true by default; this makes
Connector/J, by default, access the data dictionary more
efficiently by querying tables in the INFORMATION_SCHEME.
See INFORMATION_SCHEMA and Data Dictionary Integration
(http://dev.mysql.com/doc/refman/8.0/en/data-dictionary-information-schema.html)
for details. Users can still set useInformationSchema to false,
but for MySQL 8.0.3 and later, some data dictionary queries might
then fail, due to deprecations of older data dictionary features.

* In the past, query texts were always passed as strings to
QueryInterceptor methods, even if the texts were not
actually used by them. Now, only suppliers for the texts
are passed, and the texts are only extracted by get()
calls on the suppliers.

Bugs Fixed

* The connection property nullNamePatternMatchesAll, when
set to false (which was the default value), caused some
DatabaseMetaData methods to throw an error when a null
search string was used with them. The behavior was not
compliant with the JDBC specification, which requires
that a search criterion be ignored when a null search
string is used for it. The connection property has now
been removed from Connector/J 8.0. (Bug #26846249, Bug
#87826)

* Trying to print the query in a PreparedStatement using
the toString() method after it has been closed resulted
in an exception (No operations allowed after statement
closed) being thrown. (Bug #26748909)

* When working with MySQL Server 8.0, an update or delete
statement for a CONCUR_UPDATABLE ResultSet failed when
the ResultSet’s primary keys included a boolean column
and the character set used was not latin1. (Bug
#26266731)

* Connector/J failed to recognize a server greeting error
it received during a handshake with the server and parsed
the error message as a normal greeting packet, causing an
ArrayIndexOutOfBoundsException to be thrown. (Bug
#24924097)

On Behalf of the MySQL/Oracle Release Engineering Team,
Hery Ramilison

MySQL Connector/ODBC 5.3.10 has been released

MySQL Connector/ODBC 5.3.10, a new version of the ODBC driver for the MySQL database management system, has been released.

The available downloads include both a Unicode driver and an ANSI driver based on the same modern codebase. Please select the driver type you need based on the type of your application – Unicode or ANSI. Server-side prepared statements are enabled by default. It is suitable for use with any MySQL version from 5.5.

This is the fifth release of the MySQL ODBC driver conforming to the ODBC 3.8 specification. It contains implementations of key 3.8 features, including self-identification as a ODBC 3.8 driver, streaming of output parameters (supported for binary types only), and support of the SQL_ATTR_RESET_CONNECTION connection attribute (for the Unicode driver only).

Also, Connector/ODBC 5.3 introduces a GTK+-based setup library providing a GUI DSN setup dialog on some Unix-based systems, currently included in the Debian 7/8/9, EL6/OL6, EL7/OL7 (64-bit only), Fedora 24/25/26, FreeBSD 10/11, SLES 12, Ubuntu 14/16/17 packages. Other new features in the 5.3 driver are FileDSN and Bookmarks support.

The release is now available in source and binary form for a number of platforms from our download pages at

http://dev.mysql.com/downloads/connector/odbc/5.3.html

For information on installing, please see the documentation at

http://dev.mysql.com/doc/connector-odbc/en/connector-odbc-installation.html

Functionality Added or Changed

Bugs Fixed

  • Fixed an OpenRecordSet memory leak due to get_session_variable() not freeing a result for errors. (Bug #27155880, Bug #88143
  • Calling MySQLDriverConnect with the pcbConnStrOut argument set to NULL caused an unexpected failure. (Bug #27101767, Bug #88371)
  • Connector/ODBC now compiles on MySQL 5.5. Thanks to Vadim Zeitlin for the patch. (Bug #26633971, Bug #87413)

Enjoy and thanks for the support!