Hi, Kristian, On Sep 11, Kristian Nielsen wrote:
Kristian Nielsen <knielsen@knielsen-hq.org> writes:
From: Sergei Golubchik <serg@mariadb.org>
@@ -2724,6 +2725,10 @@ bool Item_func_encode::seed() hash_password(rand_nr, key->ptr(), key->length()); sql_crypt.init(rand_nr);
+ push_warning_printf(thd, Sql_condition::WARN_LEVEL_WARN, ER_WARN_DEPRECATED_SYNTAX, + ER_THD(thd, ER_WARN_DEPRECATED_SYNTAX_NO_REPLACEMENT), + func_name_cstring().str); // since 11.3 +
NAK. As I already explained in the MDEV-31872, deprecating these functions is not appropriate and will hurt users, not help them. Don't do this.
You need to see this from the user's point of view. She is a DBA, she has an application with columns encoded with ENCODE(). What do you expect her to do, rewrite the application because you or someone does not like these functions? That's very disrespectful.
Correct. We warn her that these "encryption" functions are crap, offer a minimal improvement over the Caesar cypher and her data is far less protected than we might've led her to think. And yes, we expect her to rewrite the application before we read on front pages that a site was hacked and credit card numbers were leaked. Or get the bad press (rightfully) when someone was using ENCODE to meet GDPR requirement of encrypting personally identifiable information.
If you want to give a warning for these functions, then you need to create an SQL mode or some other handle for the DBA to disable the warning and keep their application running. And the warning should explain why it's there, and what should be done to avoid it. And you need to carefully justify how burdening the DBA with this task of tracking down the source of the new warning and the way to remove it, is worth the benefit.
This is purely for the benefit of the user. Sometimes old features need to be removed to make the code easier to maintain or extend, but it's hardly the case here. And don't forget that exponential growth means we're getting more new users than we have old ones. And there are vastly more users who do not use ENCODE *yet* than those, who do. The main point here is to reach those who don't use ENCODE and help them not to start using it.
And deprecation suggests eventual removal, which is even worse, please don't do that.
it's not happening anytime soon
You haven't even updated the documentation https://mariadb.com/kb/en/encode/ to eg. say "encode" or "scramble" instead of encrypt. "base64_encode" also does not do encryption, nor is rot13 cryptographically safe, but that doesn't justify removing them either. Most columns in mariadb databases are not encrypted or encoded at all, how is ENCODE() any less secure that that?
You seem to be confused by ENCODE function name. It does *encryption* and the KB page says that. And also says one shouldn't use it, because the encryption is weak. If ENCODE managed to confuse even you, it certainly needs to go. base64_encode and rot13 don't do encryption. Most columns in mariadb databases are not encrypted, and it's fine - the user decides what needs encryption and what doesn't. But if a user decided that someone needs encryption, we shouldn't lie to her and do rot13 instead. Which is pretty much what ENCODE does. Regards, Sergei VP of MariaDB Server Engineering and security@mariadb.org