Am 19.03.21 um 01:47 schrieb Daniel Black:
md5:
extra/mariabackup/xbcloud.cc - old bit, however for old reasons used md5 as a checksum on a storage format. I'm think can be removed before RHEL9
In SQL there is a MD5 function, we can't just replace that as it will break user applications.
sha1:
also a SQL function.
plugin/file_key_management/parser.cc is a digest on the keys, however if this is a point of attack you've lost already. I suspect this can be fixed.
sha1 forms part of the mysql_native_password implementation, there's no known vulnerabilities in this due to its sha1 usage.
https://mariadb.com/kb/en/authentication-plugin-ed25519/ <https://mariadb.com/kb/en/authentication-plugin-ed25519/> is available, however not everything supports in on the client side. A mistake was also made (ref MDEV-19217), so a v2 might be needed.
As things like php have mysqlnd and are more strictly tied to MySQL rather than MariaDB compatibility so adding MariaDB authentication plugins hasn't been accepted yet.
On SQL functions, is this going to be a problem? or would a compile option that issues a user SQL warning if they are used be useful?
sql functions for sure not matter in that context besides it would break existing usecases it also would require to change applications workign with that data *and* replace the hases with some others in *existing* data which is a no-go -------------- md5/sha1 are not evil on it's own - it's a matter of what they are used for, i have usecases where even MD4 is enough and i use it because it's simply faster it's unlikely in my md4 usecase making sure in autotests that html output out of frameworks didn't change to hit a hash-collision at the same time a single html attribute in a source code changed