For feature requests, please see: Mattermost | Operational and AI Sovereignty for Critical Infrastructure and National Security .
For troubleshooting questions, please post in the following format:
Summary
Getting a database migration error:
“could not compute MD5 hash: unsupported”
Steps to reproduce
* Mattermost Enterprise 12.0.1
- RHEL 9.8 running in FIPS
- PostgreSQL 16.15 also in FIPS
Running Mattermost 11.x installation, perform upgrade to 12.x and it will be very unhappy about those MD5 hashes.
Expected behavior
- Successful update to Mattermost 12.x
Observed behavior
- The relevant error from PostgreSQL is “could not compute MD5 hash: unsupported”
- Then it follows with dozensof lines of SQL statements
On self-hosted upgrades the sticky parts are usually TLS and the reverse proxy in front of the app: keep the public URL on https, make sure the proxy forwards the right headers, and re-check that Let’s Encrypt / cert paths still match after the version bump. Also worth confirming the service units or containers for the app and any job workers came back cleanly—upgrade can look fine while websocket or file uploads break behind a stale proxy config.
FIPS-mode Postgres refuses md5 outright, so pin down which layer calls it: a role password re-hash (fix: password_encryption=scram-sha-256, reset the role) or migration SQL. Which step throws it?
Yup. After a bunch of digging, I found found some interesting logs.
Mattermost is doing a bunch of calls similar to this:
CASE
WHEN jsonb_typeof(o.opt->'id') = 'string'
AND o.opt->>'id' <> ''
AND o.idclaim = 1
THEN o.opt->>'id'
ELSE substr(
md5(random()::text ||
clock_timestamp()::text ||
o.fieldid ||
o.ord::text
),
1, 26
)
END
The “md5(random()” is what is failing.
gen_random_uuid()
Would be a much better replacement.
Since we have a support agreement with MM, I sent everything to them and they agreed with the assessment but do not have a fix yet. (Didn’t remember about the support agreement until later unfortunately.)
Thanks.