Log message:
Pullup ticket #6029 - requested by taca
databases/mysql57-client, databases/mysql57-server: security fix

Revisions pulled up:
- databases/mysql57-client/Makefile                             1.24
- databases/mysql57-client/Makefile.common                      1.20
- databases/mysql57-client/PLIST                                1.14
- databases/mysql57-client/distinfo                             1.30-1.31
- databases/mysql57-client/patches/patch-cmake_boost.cmake      1.11
- databases/mysql57-server/Makefile                             1.24
- databases/mysql57-server/PLIST                                1.13

---
   Module Name:    pkgsrc
   Committed By:   ryoon
   Date:           Mon Jul  1 04:08:55 UTC 2019

   Modified Files:
           pkgsrc/databases/mysql57-client: Makefile
           pkgsrc/databases/mysql57-server: Makefile

   Log message:
   Recursive revbump from boost-1.70.0

---
   Module Name:    pkgsrc
   Committed By:   adam
   Date:           Mon Jul  1 10:25:49 UTC 2019

   Modified Files:
           pkgsrc/databases/mysql57-client: distinfo
           pkgsrc/databases/mysql57-client/patches: patch-cmake_boost.cmake

   Log message:
   mysql57-client: allow newer Boost; fixes building with boost-1.70.0

---
   Module Name:    pkgsrc
   Committed By:   adam
   Date:           Tue Aug  6 06:56:43 UTC 2019

   Modified Files:
           pkgsrc/databases/mysql57-client: Makefile Makefile.common PLIST
               distinfo
           pkgsrc/databases/mysql57-server: Makefile PLIST

   Log message:
   mysql57: updated to 5.7.27

   Changes in MySQL 5.7.27:

   Keyring Notes

   The keyring_aws plugin has been updated to use the latest AWS SDK and so that \ 
it works with OpenSSL 1.1.

   Packaging Notes

   Binary packages that include curl rather than linking to the system curl \ 
library now use curl 7.64.0.

   X Plugin Notes

   On Windows, X Plugin logged some messages that were unnecessary or \ 
insufficiently informative. The messages have been removed or improved as \ 
appropriate.

   Functionality Added or Changed

   Microsoft Windows: A new warning message now reminds DBAs that connections \ 
made using the MySQL named pipe on Windows has limited the permissions a \ 
connector can request on the named pipe.

   Previously, the named_pipe_full_access_group system variable was set to a \ 
value that maps to the built-in Windows Everyone group (SID S-1-1-0) by default. \ 
However, this group is not ideal and should be replaced with a group that \ 
restricts its membership for connectors that are unable to request fewer \ 
permissions on the MySQL named pipe.

   The new warning is written to the error log at startup if the string value \ 
assigned to named_pipe_full_access_group is '*everyone*' (or the Windows System \ 
Language equivalent) and named pipes are enabled. In addition, the warning is \ 
written to the error log and raised to the client if the system variable is \ 
reset to the Everyone group at runtime.

   Bugs Fixed

   InnoDB: Insufficient memory barriers in the rw-lock implementation caused \ 
deadlocks on ARM.

   Thanks to Yibo Cai from Arm Technology for the contribution.

   InnoDB: Manually changing the system time while the MySQL server was running \ 
caused page cleaner thread delays.

   InnoDB: During log application, after an OPTIMIZE TABLE operation, InnoDB did \ 
not populate virtual columns before checking for virtual column index updates.

   InnoDB: An INSERT operation involving a generated virtual BLOB column \ 
resulted a secondary index being updated with an incorrect value.

   InnoDB: A full-text cache lock taken when data is synchronized was not \ 
released if the full-text cache size exceeded the full-text cache size limit.

   InnoDB: Client sessions using different auto_increment_increment values while \ 
performing concurrent insert operations could cause a duplicate key error.

   Partitioning: ALTER TABLE ... EXCHANGE PARTITION failed with the error Non \ 
matching attribute 'ROW_FORMAT' between partition and table when the partitioned \ 
table had partitions using different row formats, even when the partition to be \ 
exchanged used the same row format as the non-partitioned table.

   Replication: The error message that is issued for a discrepancy between the \ 
number of group members and the auto-increment interval incorrectly referred to \ 
the group_replication_auto_increment_increment system variable, instead of the \ 
auto_increment_increment system variable. The value of auto_increment_increment \ 
is changed to the value specified by group_replication_auto_increment_increment \ 
when Group Replication starts, but only if auto_increment_increment and \ 
auto_increment_offset have their default values, and from MySQL 8.0, only in \ 
multi-primary mode. The value of auto_increment_increment was always the value \ 
that was checked for the error message, and it has now been corrected to give \ 
the accurate system variable name.

   Replication: When events generated by one MySQL server instance were written \ 
to the binary log of another instance, the second server implicitly assumed that \ 
the first server supported the same number of binary log event types as itself. \ 
Where this was not the case, the event header was handled incorrectly. The issue \ 
has now been fixed. Thanks to Facebook for the contribution.

   Replication: In Group Replication, joining members could wrongly identify \ 
themselves as incompatible with an existing replication group even if there were \ 
members at the same version already in the group, because they checked against \ 
all other members, including the member at the highest version. Joining members \ 
also included their own version in the compatibility check. Now, joining members \ 
only compare themselves with the existing group member at the lowest version, \ 
and do not count their own version.

   Replication: If a FLUSH LOGS statement was issued before the binary log file \ 
was initialized, the statement attempted to write a binary log rotation event to \ 
the uninitialized file. The server now checks first that a binary log file is \ 
available.

   Replication: When a MEMORY table is implicitly deleted on a master following \ 
a server restart, the master writes a DELETE statement to the binary log so that \ 
slaves also empty the table. This generated event now includes a comment in the \ 
binary log so that the reason for the DELETE statement is easy to identify. \ 
Thanks to Daniël van Eeden for the contribution.

   Replication: With statement-based replication in use, if super_read_only was \ 
set to ON for a server at the point when a no-op transaction was between its \ 
UPDATE and COMMIT operations, the transaction was written to the binary log and \ 
assigned a GTID. The transaction is now blocked in this situation. From MySQL \ 
8.0, the value of super_read_only cannot be changed while a transaction is in \ 
progress.

   Replication: The group communication engine for Group Replication (XCom, a \ 
Paxos variant) did not handle out of memory errors in an appropriate way. If \ 
memory could not be allocated to make a copy of the payload for a message, an \ 
error was logged but the message was still sent, with a null payload. The Group \ 
Communication System (GCS) on the receiving member discarded the message as \ 
empty, and the XCom instance on the receiving member accepted this action and \ 
did not retry, resulting in the message effectively being skipped. This caused \ 
the GTID set on the receiving member to diverge from the group, leading to \ 
replication errors. XCom now terminates gracefully if it experiences an out of \ 
memory error, so that this situation cannot occur.

   Replication: In query log events in the binary log, the thread ID used for \ 
the execution of DROP TABLE and DELETE statements was identified incorrectly or \ 
not at all. On a multi-threaded replication slave, where temporary tables were \ 
involved (which require the correct thread ID as they are session specific), \ 
this omission resulted in errors when using mysqlbinlog to replay the binary log \ 
for point-in-time recovery. The thread ID is now set correctly.

   Replication: When a slave server logs master status and connection \ 
information to a table (master_info_repository=TABLE), which is the default in \ 
MySQL 8.0, the mysql.slave_master_info table was not being updated on shutdown \ 
if the server was in super read only mode (super_read_only=ON). No error was \ 
written to the error log at this time, but replication failed after server \ 
startup because the master log file and master log position information was out \ 
of date. The thread that updates the master info log at shutdown is now excluded \ 
from read-only checks like other replication threads are, so it can update the \ 
table even if the server is in super read only mode. Error handling for a slave \ 
that is shutting down has also been improved so that any failure to write to the \ 
slave status logs results in an error in the error log.

   An overly strict assertion could be raised during sorting of stored program \ 
local objects.

   Installing from RPM packages could result in an error log with incorrect \ 
permissions.

   Enabling audit log encryption could cause a server exit.

   On Debian and Ubuntu, MySQL packages did not enable mysql.service after \ 
upgrades from native MySQL packages.

   The server did not properly close shared-memory connections when an error \ 
occurred, which could result in unexpected server behavior.

   MySQL Installer did not install OpenSSL DLL dependencies if the Development \ 
component was not selected.

   The parser could leak memory for certain multiple-statement queries.

   CREATE USER and ALTER USER did not check the validity of a hashed \ 
authentication string when used with IDENTIFIED WITH auth_plugin AS \ 
'hash_string' syntax.

   For InnoDB tables that contained an index on a VARCHAR column and were \ 
created prior to MySQL 5.7.23, some simple ALTER TABLE statements that should \ 
have been done in place were performed with a table rebuild after an upgrade to \ 
MySQL 5.7.23 or higher.

   HANDLER statements did not always work correctly with tables having generated \ 
columns.

   Session-tracking information in the client/server protocol could be mishandled.

   With the PAD_CHAR_TO_FULL_LENGTH SQL mode enabled, password changes failed, \ 
with no warning or error reported.

   The audit_log plugin did not log UNINSTALL PLUGIN audit_log statements.

   audit_log filtering operations could leak memory.

   An index defined on a virtual generated column could fail to be updated if \ 
the column had a base column in a foreign key relationship.

   Privileges for dropping some Performance Schema tables were checked incorrectly.

   A query that employed a derived table which included an ORDER BY was not \ 
always handled correctly.

   Base columns were not excluded from index-only access by a generated column.

   A thread pool group could be blocked when a thread process tick time exceeded \ 
the maximum permitted value. The tick time now uses a larger data type to permit \ 
larger values.

   MySQL does not support OpenSSL session tickets, but did not set the \ 
SSL_OP_NO_TICKET flag to inform OpenSSL of that. The flag is now set.

   The audit_null plugin did not properly check for a null event record.

   UpdateXML() did not always free memory properly in certain cases.

   Empty values in the name column of the mysql.plugin system table caused the \ 
server to exit during startup.

   With the thread_pool plugin enabled, the Performance Schema status_by_thread \ 
table contained no data.

   If an INSTALL PLUGIN statement contained invalid UTF-8 characters in the \ 
shared library name, it caused the server to hang (or to raise an assertion in \ 
debug builds).

   Inner tables of different semijoin nests were interleaved during \ 
materialization, which could lead to a different result for the same query when \ 
it used a different query plan. To keep this from occurring, a check is added to \ 
prevent such interleaving.

   A query involving GROUP BY on a TIMESTAMP column resulted in a duplicate \ 
entry for key (ER_DUP_ENTRY) error. This problem arose when TIMESTAMP values \ 
were inserted into a table using a given setting for the time zone and these \ 
values were later fetched after the time zone setting had been changed, such \ 
that at least some of the inserted TIMESTAMP values occurred during the hour \ 
that the time changed from standard to daylight time (DST) in the new time zone, \ 
during which time the same TIMESTAMP value can exist twice. Now, when the server \ 
would otherwise return the error DUPLICATE ENTRY FOR KEY 'group_key', if the \ 
grouping involves a TIMESTAMP column, it instead raises the error Grouping on \ 
temporal is non-deterministic for time zones having DST. Please consider \ 
switching to UTC for this query.

   In addition, it is suggested to set explicit_defaults_for_timestamp to ON as \ 
well as one or more of MODE_NO_ZERO_IN_DATE, MODE_NO_ZERO_DATE, or \ 
MODE_INVALID_DATES as part of the server SQL mode to help avoid this issue.