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. 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. > 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. Much more realistic is the scenario that a site was hacked because they were stuck on an old version of MariaDB that is out of support and had known vulnerabilities. This is the real issue many users are facing now. 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? > old mode isn't quite for that. it's to revert the new behavior > *temporarily* to give users time to adjust their applications. ... if so, then please agree to rework this patch so that users will be able to configure the server to continue running their application without spewing warnings or errors. If you don't like my suggestions, then whatever other method you think is more appropriate for this. > Sometimes old features need > to be removed to make the code easier to maintain or extend, but it's > hardly the case here. Exactly! > 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. There are legitimate uses for ENCODE(), though cryptographically safe protection of data against access without the password/key is obviously not one of them. - Kristian. _______________________________________________ developers mailing list -- developers@lists.mariadb.org To unsubscribe send an email to developers-le...@lists.mariadb.org
