Hi, Kristian, On Sep 11, Kristian Nielsen wrote:
Sergei Golubchik via developers <developers@lists.mariadb.org> writes:
And yes, we expect her to rewrite the application before we read on
I think this is the core of the problem:
"we expect her to rewrite the application"
No, "we" have no such expectation. And if you do, then you have become too far removed from the users.
No-no, I have no such expectations either, at least not when I'm replying to such a partial quote taken completely out of context :)
The purpose of MariaDB is to provide an Open Source tool to users to run their applications that need database storage. This means that _not_ breaking their applications in upgrades should be our primary concern. We cannot always avoid it, mostly due to human error and in some cases due to technical reasons. But we can avoid doing it *deliberately*.
What I have seen talking to different users is that regressions caused by upgrades has become a critical concern for them. We need to do everything we can to improve on this. That's the reason I bother to assist with this issue, not because I think ENCODE is something that will benefit new users obviously.
Of course, one can see any bug fix as something that breaks applications. And one can argue that providing a weak encryption function is a bug on itself. But we don't do sudden feature removal at random. ENCODE will not go away anytime soon, not before 2028. And then we can add an old mode for it, giving it five more years, if needed. And then again. It is of course possible that someone will use an application in 2033 that was written before 2023 and never updated afterwards. This might be a reason for us to keep ENCODE longer. But I definitely don't want any *new* application, written after 2023, to use ENCODE/DECODE. This is what the warning is for.
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.
This is a strawman's argument. I doubt you have a documented case where a security breach would have been prevented by removing ENCODE from the server.
No, I don't :) And I don't have a documented use case where MariaDB SSL-ed connection was intercepted and data was modified, but despite this all guidelines everywhere on the internel, both on MariaDB and on MySQL, tell that for a connection to be secure the client has to validate server certificate.
Do you agree that not breaking user's old applications is an important goal, and that holding users hostage by preventing them from upgrading if they don't rewrite their application according to specific guidelines is not the correct way to develop MariaDB?
Yes, of course, I agree. That's why we provide a long deprecation period and don't remove features at random. This is a security issue, much like deprecating DES in favor of AES.
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.
I'm not confused by anything, I don't know why you think so.
Because you keep saying that ENCODE function "encodes" something and compare it with base64 and rot13. While it is an encryption function, that encrypts given plain-text data with given encryption key. It is unfortunate that it was called "ENCODE", but it happened 25 years ago.
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? Regards, Sergei VP of MariaDB Server Engineering and security@mariadb.org