1. 21 Mar, 2016 15 commits
  2. 19 Mar, 2016 3 commits
  3. 18 Mar, 2016 12 commits
    • Sergei Golubchik's avatar
      main.mysqld--help failure with cracklib plugin · d70697b6
      Sergei Golubchik authored
      don't fail if cracklib_password_check is statically compiled in
      d70697b6
    • Sergei Golubchik's avatar
      update plugins' maturity levels · 3fdc6140
      Sergei Golubchik authored
      3fdc6140
    • Jan Lindström's avatar
      MDEV-9422: Checksum errors on restart when killing busy instance that uses encrypted XtraDB tables · 7cb16dc2
      Jan Lindström authored
      Fix incorrectly merged files on innodb_plugin.
      7cb16dc2
    • Oleksandr Byelkin's avatar
      MDEV-9701: CREATE VIEW with GROUP BY or ORDER BY and constant produces invalid definition · 4fdac6c0
      Oleksandr Byelkin authored
      Fixed printing integer constant in the ORDER clause (MySQL solution)
      Removed workaround for double resolving counter in the ORDER.
      4fdac6c0
    • Sergei Golubchik's avatar
      MDEV-9527 build FAILs with GCC 5.1 with release supported "-std=c+11" · 11b77e9b
      Sergei Golubchik authored
      5.5 part of the fix
      11b77e9b
    • Alexander Barkov's avatar
      MDEV-9653 Assertion `length || !scale' failed in uint... · b25373be
      Alexander Barkov authored
      MDEV-9653 Assertion `length || !scale' failed in uint my_decimal_length_to_precision(uint, uint, bool)
      MDEV-9752 Wrong data type for COALEASCE(?,1) in prepared statements
      b25373be
    • Sergey Vojtovich's avatar
      Fixed plugins.cracklib_password_check failure · 546e9139
      Sergey Vojtovich authored
      In RHEL7/RHEL7.1 libcrack behavior seem to have been modified so that
      "foobar" password is considered bad (due to descending "ba") earlier than
      expected. For details google for cracklib-2.9.0-simplistic.patch.
      
      Adjusted affected passwords not to have descending and ascending sequences.
      546e9139
    • Akira Higuchi's avatar
    • Akira Higuchi's avatar
      fix a memory leak in handlersocket · 4f0fc0f9
      Akira Higuchi authored
      4f0fc0f9
    • Jan Lindström's avatar
    • Sergey Vojtovich's avatar
      4aac51db
    • Jan Lindström's avatar
      MDEV-9422: Checksum errors on restart when killing busy instance that uses encrypted XtraDB tables · f448a800
      Jan Lindström authored
      Analysis:
      
      -- InnoDB has n (>0) redo-log files.
      -- In the first page of redo-log there is 2 checkpoint records on fixed location (checkpoint is not encrypted)
      -- On every checkpoint record there is up to 5 crypt_keys containing the keys used for encryption/decryption
      -- On crash recovery we read all checkpoints on every file
      -- Recovery starts by reading from the latest checkpoint forward
      -- Problem is that latest checkpoint might not always contain the key we need to decrypt all the
         redo-log blocks (see MDEV-9422 for one example)
      -- Furthermore, there is no way to identify is the log block corrupted or encrypted
      
      For example checkpoint can contain following keys :
      
      write chk: 4 [ chk key ]: [ 5 1 ] [ 4 1 ] [ 3 1 ] [ 2 1 ] [ 1 1 ]
      
      so over time we could have a checkpoint
      
      write chk: 13 [ chk key ]: [ 14 1 ] [ 13 1 ] [ 12 1 ] [ 11 1 ] [ 10 1 ]
      
      killall -9 mysqld causes crash recovery and on crash recovery we read as
      many checkpoints as there is log files, e.g.
      
      read [ chk key ]: [ 13 1 ] [ 12 1 ] [ 11 1 ] [ 10 1 ] [ 9 1 ]
      read [ chk key ]: [ 14 1 ] [ 13 1 ] [ 12 1 ] [ 11 1 ] [ 10 1 ] [ 9 1 ]
      
      This is problematic, as we could still scan log blocks e.g. from checkpoint 4 and we do
      not know anymore the correct key.
      
      CRYPT INFO: for checkpoint 14 search 4
      CRYPT INFO: for checkpoint 13 search 4
      CRYPT INFO: for checkpoint 12 search 4
      CRYPT INFO: for checkpoint 11 search 4
      CRYPT INFO: for checkpoint 10 search 4
      CRYPT INFO: for checkpoint 9 search 4 (NOTE: NOT FOUND)
      
      For every checkpoint, code generated a new encrypted key based on key
      from encryption plugin and random numbers. Only random numbers are
      stored on checkpoint.
      
      Fix: Generate only one key for every log file. If checkpoint contains only
      one key, use that key to encrypt/decrypt all log blocks. If checkpoint
      contains more than one key (this is case for databases created
      using MariaDB server version 10.1.0 - 10.1.12 if log encryption was
      used). If looked checkpoint_no is found from keys on checkpoint we use
      that key to decrypt the log block. For encryption we use always the
      first key. If the looked checkpoint_no is not found from keys on checkpoint
      we use the first key.
      
      Modified code also so that if log is not encrypted, we do not generate
      any empty keys. If we have a log block and no keys is found from
      checkpoint we assume that log block is unencrypted. Log corruption or
      missing keys is found by comparing log block checksums. If we have
      a keys but current log block checksum is correct we again assume
      log block to be unencrypted. This is because current implementation
      stores checksum only before encryption and new checksum after
      encryption but before disk write is not stored anywhere.
      f448a800
  4. 17 Mar, 2016 4 commits
  5. 16 Mar, 2016 2 commits
  6. 15 Mar, 2016 2 commits
  7. 13 Mar, 2016 2 commits