hardening: enforce DB TLS certificate validation and fail closed

[somethingwithproof]

Summary

Harden MySQL/MariaDB TLS behavior to avoid insecure fallback.

Work

• Enforce certificate/host validation when TLS is configured.
• Reject insecure downgrade/fallback paths in hardened mode.
• Emit actionable diagnostics for cert/host verification failures.

Acceptance Criteria

• TLS-enabled DB connections validate trust chain and host identity.
• Verification failure causes explicit connection failure (no silent insecure fallback).
• Operator-facing docs cover required TLS settings and failure modes.

[somethingwithproof]

Closing as not planned.

This was one of a batch of roadmap issues I filed over two days in March 2026. None of them were picked up, and collectively they were burying the reports that actually need attention. Reopening is cheap if it becomes relevant to a 2.0 discussion.

[somethingwithproof]

Recording where the implementation for this actually lives, since it is not obvious.

Working code exists on the branch of the now-closed #537 (feat/spine-2.0-behavioral, src/sql.c). It fixes a genuine width bug where MYSQL_OPT_SSL_VERIFY_SERVER_CERT was passed a bool into an API reading one byte, adds the missing mysql_ssl_set() (without which a MariaDB 5.x connector honours the verify flag but never sends CLIENT_SSL), and fails closed in two places: at configure time when the connector exposes neither MYSQL_OPT_SSL_MODE nor VERIFY_SERVER_CERT, and post-connect via mysql_get_ssl_cipher() == NULL, which catches a silent server-side downgrade.

The branch is retained; only the PR is closed. Those three are bug fixes and belong on 1.2.x independently of the 2.0 default flip that made #537 unmergeable. Left closed as not planned, but this should be re-raised as a small standalone PR.

[somethingwithproof]

Correcting my earlier comment on this issue. I said the TLS work on the #537 branch was written and worth extracting, and cited three specific defects. I have now tested all three against a live MariaDB 11 and none of them hold.

1. The bool vs my_bool width bug — not real. I claimed MYSQL_OPT_SSL_VERIFY_SERVER_CERT was being passed a 4-byte bool where the API reads one byte. sql.c gets bool from <stdbool.h> (common.h:95), so it is _Bool, and sizeof(bool) is 1 on every mainstream ABI — the same width as my_bool. The SPINE_SSL_VERIFY_T typedef on that branch is portability hygiene for code that references my_bool (which MySQL 8.0 removed), not a fix for a live defect.

2. The missing mysql_ssl_set() — not needed. The claim was that without it a connector honours the verify flag but never sends CLIENT_SSL. Tested with spine's exact approach, mysql_options() only and no mysql_ssl_set():

connected. ssl_cipher=TLS_AES_256_GCM_SHA384

TLS was negotiated. mysql_ssl_set() is a convenience wrapper around the same mysql_options() calls.

3. The silent downgrade — not reproducible. With a CA configured that does not exist, the connection does not fall back to plaintext, it fails closed:

connect failed: SSL connection error: SSL_CTX_set_default_verify_paths failed

A mysql_get_ssl_cipher() post-connect assertion is still reasonable defence in depth for a server too old to offer TLS at all, but that is a hardening idea rather than the vulnerability I described.

Leaving this closed. I should have tested before asserting it, and the earlier comment overstated what was there.