I have found these related issues/pull requests
Relates to #4081
Description
Could PostgreSQL password authentication be placed behind an optional feature, following the pattern introduced for MySQL RSA in #4142?
sqlx-postgres currently always includes cleartext password, MD5, and SCRAM authentication support. This pulls in dependencies such as md-5, hmac, sha2, and stringprep, even for deployments that exclusively use PostgreSQL client-certificate authentication.
Making password authentication optional would reduce unused dependencies and audit surface. It would also help FIPS-oriented deployments ensure that unused cryptographic operations are excluded from the binary rather than implemented outside their selected validated cryptographic module.
Prefered solution
Add a default-enabled feature such as:
postgres-password-auth = [
"dep:md-5",
"dep:hmac",
"dep:sha2",
"dep:stringprep",
]
Is this a breaking change? Why or why not?
Potentially. Public APIs can remain compatible, but builds using
default-features = false may need to enable postgres-password-auth
to retain existing password-authentication behavior. This is similar
to the compatibility impact described in #4142.
I have found these related issues/pull requests
Relates to #4081
Description
Could PostgreSQL password authentication be placed behind an optional feature, following the pattern introduced for MySQL RSA in #4142?
sqlx-postgrescurrently always includes cleartext password, MD5, and SCRAM authentication support. This pulls in dependencies such asmd-5,hmac,sha2, andstringprep, even for deployments that exclusively use PostgreSQL client-certificate authentication.Making password authentication optional would reduce unused dependencies and audit surface. It would also help FIPS-oriented deployments ensure that unused cryptographic operations are excluded from the binary rather than implemented outside their selected validated cryptographic module.
Prefered solution
Add a default-enabled feature such as:
Is this a breaking change? Why or why not?
Potentially. Public APIs can remain compatible, but builds using
default-features = falsemay need to enablepostgres-password-authto retain existing password-authentication behavior. This is similar
to the compatibility impact described in #4142.