Sergei Golubchik via developers <developers@lists.mariadb.org> writes:
> But I definitely don't want any *new* application, written after 2023, > to use ENCODE/DECODE. This is what the warning is for. This is of course agreed. https://lists.mariadb.org/hyperkitty/list/comm...@lists.mariadb.org/thread/UAKPM7C3NQHCXT7ILI2YHZPYJHRYGNE2/ https://github.com/MariaDB/server/commit/83a1b921812c98b03f7af40a61722c508001f683 This is what I'm asking for. A way for me to disable the gazillions of SHOW WARNINGS that appear in my logs after I upgraded to 11.3. I have a legacy application with columns inserted using ENCODE(...), and I don't have the resources to do a full data migration to SHA2 or plaintext. (Not "me" personally but the future user I'm trying to help). And a note in the code to help prevent that I someday upgrade to 13.7 or whatever and find that ENCODE() is gone and I now need to reverse-engineer old MariaDB sources to re-implement DECODE() to rescue my data, as MariaDB downgrades between major versions is not supported. Agreed? >> There are legitimate uses for ENCODE(), though cryptographically safe >> protection of data against access without the password/key is >> obviously not one of them. > > What would be a legitimate use for a weak cryptographic function? I'll explain, but please don't get side-tracked by it. This is not relevant to the issue at hand, which is to help prevent regression during upgrades. I'm in no way trying to suggest using ENCODE() for anything where it can possibly be avoided. The only legitimate use for ENCODE()/DECODE() *now* is to access existing data in legacy MariaDB databases. This is however a very legitimate use, since IIUC it is the only way to do so (other than reverse-engineering the MariaDB implementation). An obvious use for a non-cryptographically strong encryption/scrambling/encoding or whatever you want to call it, is to protect user data from casual glances from developers when they are debugging the application. As an application developer in real life, I'll often find myself looking at binlogs or table data or whatever to debug problems. It's important to be able to do so without accidentally viewing user private messages etc. "rot13" is perhaps a bit too weak for this, but mostly anything that's not immediately recognisable by human eyes should work. It is easy to over-estimate the value of "strong" encryption/decryption of database columns inside an application. Where to keep the key is a serious problem. Unless the encryption is end-to-end (in which case no SQL functions are involved), the key will need to be stored somewhere. Usually hard-coded somewhere in the application code or configuration files. And SHA2() is little better than rot13 if the key is sitting next to the ciphertext. (Here, "rot13" is the Caecar cipher using "13" as the key). That's why passwords are best stored using a one-way hash function, not encrypted. - Kristian. _______________________________________________ developers mailing list -- developers@lists.mariadb.org To unsubscribe send an email to developers-le...@lists.mariadb.org
