Open ealott opened 1 month ago
@ealott thanks for posting this bug report.
It looks like this change (disabling md5 hashing) might have been rolled back?
and I can confirm that the change was rolled back now for newly created Postgres Flexible Servers (at least for our cloud rooms).
Can you confirm that this is still an issue? This community forum post indicates it still is but I don't have an easy way to stand up a testbed in Azure to confirm.
Internal: from reading the database schema files, it looks like we use md5 to generate random UUIDs.
We didn't start with 1.53, though. Maybe we should consider another hashing algo like sha256 instead?
@mooreds Thanks for taking a look, and for the reply!
I can confirm Microsoft has re-enabled the Postgres MD5 function on our existing and new Azure Postgres Flexible Server 15.8 instances, and presumably all other versions as well. My issue is resolved.
I agree that another hashing algorithm would be ideal for those UUIDs, as Postgres disables MD5 when enabling FIPS mode, and it seems likely Microsoft will eventually disable MD5 again in the future (though hopefully with some forewarning, next time).
Thanks @ealott . I'll raise this with our product/engineering team.
We could also document that MD5 function support is required for any database FusionAuth is installed into (though that seems like a pretty common baseline).
Historically, PostgresSQL required the uuid-ossp
module to generate a UUID using uuid_generate_v4()
and pgcrypto
module to use gen_random_uuid()
. We have intentionally not required these modules to be installed at runtime.
I think Postgres version 13 added gen_random_uuid()
natively w/out requiring the pgcrypto
module. But our min. version is still Postgres version 10
. We could consider increasing our min. requirement, but 10
to 13
is a big jump all at once.
Perhaps that is another way to generate a UUID w/out MD5
, but I tend to think it is simpler to just re-enable MD5
unless this is being turned off en-masse.
Here is a useful thread in SO, all of these examples show MD5 but perhaps we need to investigate further.
Or maybe we can create a stored procedure that uses gen_random_uuid()
if available, and falls back to our current method which could allow us to work when MD5
is disabled as long as we are on version >= 13
?
it is simpler to just re-enable MD5 unless this is being turned off en-masse.
It was turned off by Azure disabling support. They later re-enabled it.
I'm not sure what 'en-masse' means, but a hyperscaler disabling it in a new minor release of a supported database platform is going to affect a significant number of folks who want to run FusionAuth there.
Not as many as if PG turned off this function in their default settings, though.
Installation on postgres fails when MD5 function disabled
Description
New deployments of the latest FusionAuth (1.53.2) are failing on Azure Database for PostgreSQL Flexible Server version 15.8 with the error below.
Note that Azure does not allow specifying minor versions of Postgres, and auto-upgrades all PostgreSQL Flexible Servers to the latest minor release, potentially breaking existing installations.
Calling the postgres md5 function produces the same error:
This error appears to be caused by Microsoft disabling MD5 support in Azure Postgres 15.8.
Note that MS re-enabled the MD5 function per this comment, but it is unclear how long it will be enabled.
Searched briefly and didn't find any long term plans to remove the md5 function from postgresql, but it still might be nice to move towards FIPS compliance.
Community guidelines
All issues filed in this repository must abide by the FusionAuth community guidelines.