Remove query parameters from logs

[seladb]

This PR ports the changes from the approved but stale PR #1997 (by @bddap)

fixes #1996

FYI @henadzit

Description

This PR fixes a security vulnerability where sensitive data (passwords, tokens, API keys, personal information) was being exposed in debug logs through SQL query parameters. The fix removes parameter values from debug logging while preserving the SQL query structure for debugging purposes.

Changes made:

• Updated logging statements in 7 backend database client files (21 total logging calls)
• Changed from self.log.debug("%s: %s", query, values) to self.log.debug("%s", query)
• Affects: MySQL, SQLite, PostgreSQL/psycopg, ODBC, Oracle, MSSQL, and AsyncPG backends

Before:

DEBUG:tortoise.db_client:INSERT INTO "users" ("username","password_hash","email") VALUES (?,?,?): ['admin', 'super_secret_hash_123', 'admin@example.com']

After:

DEBUG:tortoise.db_client:INSERT INTO "users" ("username","password_hash","email") VALUES (?,?,?)

Motivation and Context

Fixes #1996

SQL query parameters often contain sensitive information that should never be logged:

• User passwords and password hashes-
• Authentication tokens and API keys
• Personal identifiable information (emails, names, addresses)
• Business-critical data that could be exposed in log files

This creates a significant security risk, especially in:

• Development environments where debug logging is commonly enabled
• Production systems where logs might be accidentally enabled or collected
• Shared development environments where logs could be accessed by unauthorized users

The current implementation logs both the SQL structure AND the parameter values, which unnecessarily exposes this sensitive data.

How Has This Been Tested?

1. Added comprehensive test suite (tests/test_logging_security.py):

• Validates that sensitive data (usernames, emails, bio information) is NOT exposed in debug logs
• Confirms SQL query structure is still logged for debugging purposes
• Tests INSERT, UPDATE, and SELECT operations
• Uses proper log capture mechanism to verify actual log output

2. Manual verification:

• Tested with debug logging enabled across different database backends
• Confirmed that SQL queries are still logged (maintaining debugging capability)
• Verified that parameter values are completely absent from log output

3. Existing test compatibility:

• All existing tests continue to pass (no breaking changes)
• The fix is purely additive to security without affecting functionality

Checklist:

• My code follows the code style of this project.
• My change requires a change to the documentation.
• I have updated the documentation accordingly.
• I have added the changelog accordingly.
• I have read the CONTRIBUTING document.
• I have added tests to cover my changes.
• All new and existing tests passed.

[abondar]

Do I understand correctly that this solution is basically just "not log any params for any queries ever"?

[seladb]

Do I understand correctly that this solution is basically just "not log any params for any queries ever"?

@abondar to be honest, I'm new to this project, but my understanding is yes, as this might be a security vulnerability as mentioned here.