[coverage] Conformance findings: AUTH-015,AUTH-016

[peco-engineer-bot]

Summary

Surfaced by the multi-language coverage fan-out while conformance-testing these SPEC-IDs against databricks/databricks-sql-python. Each finding is committed as an expected-failure (xfail) test in the coverage PR — the test asserts the CORRECT (post-fix) behavior and stays red until THIS driver (databricks/databricks-sql-python) is fixed, then flips green as a tripwire.

Findings

• AUTH-015 [thrift, sea]: a lone _tls_client_cert_key_file (private key without client cert) is silently dropped and the connection proceeds over one-way TLS with no client identity instead of failing fast; both SSLOptions.create_ssl_context() and _kernel_tls_kwargs gate solely on if cert_file:, so the kernel's own cert/key pairing check is never reached
  • failing test: test_mutual_tls_requires_client_certificate_alongside_private_key (see the coverage PR diff under tests/)
• AUTH-016 [thrift]: an unreadable or empty mTLS client-identity file fails with a raw stdlib error that does not identify which input failed (bare FileNotFoundError for a missing path, SSLError: [SSL] PEM lib for an empty file) because UnifiedHttpClient._setup_pool_managers calls ssl_context.load_cert_chain with no try/except
  • failing test: test_mutual_tls_rejects_unreadable_or_empty_client_identity_file (see the coverage PR diff under tests/)
• AUTH-016 [sea]: an unreadable or empty mTLS client-identity file fails with a raw stdlib error that does not identify which input failed; the kernel path's own diagnostics in _read_pem_bytes (which name tls_client_cert_file / tls_client_cert_key_file and the path) never surface because the unconditional UnifiedHttpClient build throws load_cert_chain's raw error first
  • failing test: test_mutual_tls_rejects_unreadable_or_empty_client_identity_file (see the coverage PR diff under tests/)
• AUTH-015: a lone _tls_client_cert_key_file (private key without client cert) is silently dropped and the connection proceeds over one-way TLS with no client identity instead of failing fast; both SSLOptions.create_ssl_context() and backend/kernel/client.py::_kernel_tls_kwargs gate solely on if cert_file:, so the kernel's own "client_key_pem is set without client_cert_pem" pairing check is never reached
• AUTH-016: an unreadable or empty mTLS client-identity file fails with a raw stdlib error that does not identify which input failed (FileNotFoundError: [Errno 2] No such file or directory for a missing path, SSLError: [SSL] PEM lib for an empty file) because UnifiedHttpClient._setup_pool_managers calls ssl_context.load_cert_chain(cert, key, password) with no try/except; the kernel path's own diagnostics in _read_pem_bytes (which do name tls_client_cert_file / tls_client_cert_key_file and the path) never surface since the unconditional UnifiedHttpClient build throws first

Reproduce & Expected

AUTH-015 — Verifies that enabling mutual TLS with an incomplete or contradictory configuration is rejected at connect time, before any connection is established — the driver fails fast rather than silently fall…

Expected (per the shared spec):

• full assertion contract:

result:
- label: missing_both
  error:
    contains:
    - clientcert
    - client cert
    - certificate
    - clientprivatekey
    - private key
    - required
    - missing
- label: missing_both
  connection_not_established: true
- label: missing_key
  error:
    contains:
    - clientprivatekey
    - private key
    - required
    - missing
- label: missing_key
  connection_not_established: true
- label: missing_cert
  error:
    contains:
    - clientcert
    - client cert
    - certificate
    - required
    - missing
- label: missing_cert
  connection_not_established: true
- label: plaintext
  error:
    contains:
    - ssl
    - tls
    - https
    - requires
- label: plaintext
  connection_not_established: true
- label: http_scheme
  error:
    contains:
    - https
    - ssl
    - tls
    - scheme
    - requires
- label: http_scheme
  connection_not_established: true

AUTH-016 — Verifies that with mutual TLS enabled and both client-identity inputs supplied, a client certificate or private key that cannot be loaded is rejected at connect time: the driver reports which input f…

Expected (per the shared spec):

• full assertion contract:

result:
- label: cert_path_missing
  error:
    contains:
    - clientcert
    - client cert
    - certificate
- label: cert_path_missing
  connection_not_established: true
- label: key_path_missing
  error:
    contains:
    - clientprivatekey
    - private key
- label: key_path_missing
  connection_not_established: true
- label: cert_file_empty
  error:
    contains:
    - clientcert
    - client cert
    - certificate
- label: cert_file_empty
  connection_not_established: true
- label: key_file_empty
  error:
    contains:
    - clientprivatekey
    - private key
- label: key_file_empty
  connection_not_established: true

Context

• The behavior was first fixed in a DIFFERENT driver — reference PR: https://github.com/databricks/databricks-odbc/pull/337 — which seeded the shared language-neutral spec. This issue tracks the same conformance gap in databricks/databricks-sql-python; the reference PR is for cross-referencing the intended behavior, NOT a change to this repo.
• Coverage PR carrying the reproducing xfail test(s): https://github.com/databricks/databricks-driver-test/pull/1541