summaryrefslogtreecommitdiff
path: root/sql/encryption.cc
Commit message (Collapse)AuthorAgeFilesLines
* MDEV-12863 No table can be created after second encryption plugin attempted ↵Sergei Golubchik2017-08-081-6/+14
| | | | | | | to load when deinitializing encryption plugins, disable server-wide encryption only if this plugin is the one that is used for encryption.
* MDEV-11288 Server crashes in Binlog_crypt_data::init trying to feed ↵Sergei Golubchik2016-12-061-0/+5
| | | | encrypted log without decryption capabilities
* MDEV-9618 solaris sparc build fails on 10.1.Alexey Botchkov2016-05-041-3/+13
| | | | | | | Compiler there is strict about the C/C++ call model mixing in function variable assumptions. Fixed by adding some 'extern "C"' and changing '?' operator with 'if'.
* make encrypt-binlog and encrypt-tmp-files to fail if no encryptionSergei Golubchik2015-09-091-5/+0
| | | | | | --encrypt-binlog and --encrypt-tmp-files used to mean "encrypt XXX if encryption is available, otherwise don't encrypt", now they mean "encrypt or fail with an error".
* New encryption API. Piece-wise encryption.Sergei Golubchik2015-09-041-34/+31
| | | | | | | | | | | | | Instead of encrypt(src, dst, key, iv) that encrypts all data in one go, now we have encrypt_init(key,iv), encrypt_update(src,dst), and encrypt_finish(dst). This also causes collateral changes in the internal my_crypt.cc encryption functions and in the encryption service. There are wrappers to provide the old all-at-once encryption functionality. But binlog events are often written piecewise, they'll need the new api.
* MDEV-8126 encryption for temp filesSergei Golubchik2015-06-021-0/+5
| | | | IO_CACHE tempfiles encryption
* MDEV-8173: InnoDB; Failing assertion: crypt_data->type == 1Jan Lindström2015-05-201-1/+7
| | | | | | | | | | | | | | | | | | | | | | | Make sure that when we publish the crypt_data we access the memory cache of the tablespace crypt_data. Make sure that crypt_data is stored whenever it is really needed. All this is not yet enough in my opinion because: sql/encryption.cc has DBUG_ASSERT(scheme->type == 1) i.e. crypt_data->type == CRYPT_SCHEME_1 However, for InnoDB point of view we have global crypt_data for every tablespace. When we change variables on crypt_data we take mutex. However, when we use crypt_data for encryption/decryption we use pointer to this global structure and no mutex to protect against changes on crypt_data. Tablespace encryption starts in fil_crypt_start_encrypting_space from crypt_data that has crypt_data->type = CRYPT_SCHEME_UNENCRYPTED and later we write page 0 CRYPT_SCHEME_1 and finally whe publish that to memory cache.
* Identical key derivation code in XtraDB/InnoDB/AriaSergei Golubchik2015-05-151-0/+107
| | | | | | | | * Extract it into the "encryption_scheme" service. * Make these engines to use the service, remove duplicate code. * Change MY_AES_xxx error codes, to return them safely from encryption_scheme_encrypt/decrypt without conflicting with ENCRYPTION_SCHEME_KEY_INVALID error
* Add encryption key id to the API as a distinct conceptSergei Golubchik2015-04-091-6/+12
| | | | which is separate from the encryption key version
* renames to follow single consistent naming styleSergei Golubchik2015-04-091-0/+99
with namespace prefixes