Yukang-Lian opened a new pull request, #67614:
URL: https://github.com/apache/doris/pull/67614

   ### What problem does this PR solve?
   
   Issue Number: N/A
   
   Related PR: https://github.com/apache/brpc/pull/3173
   
   Problem Summary:
   
   Doris has unified TLS configuration, but several internal communication 
paths still selected plaintext URLs/transports directly or had no open-source 
provider boundary for TLS credentials. As a result, enabling TLS could leave 
individual FE, BE, Cloud, CDC, Thrift, Arrow Flight, BDBJE, or BRPC paths 
unable to communicate securely.
   
   This PR aligns the complete public/common TLS behavior with the 
corresponding SelectDB 4.1 implementation while adapting it to current Doris 
master APIs. Proprietary provider implementations are intentionally not 
included.
   
   Main changes:
   
   - Add public FE, BE, and Cloud connection-provider hooks and route internal 
HTTP/curl call sites through them.
   - Make unified HTTP TLS scheme selection consistent and fail closed: 
TLS-enabled paths do not silently downgrade or use an untrusted fallback. 
Legacy FE HTTPS behavior remains available when unified TLS is disabled.
   - Propagate CDC backend HTTPS, CA certificate, and protocol-level 
hostname-verification policy; keep the local CDC child control endpoint 
loopback-only over HTTP.
   - Cover threaded-selector Thrift TLS, Arrow Flight TLS result endpoints, 
BDBJE group administration, group-commit/cache-hotspot forwarding, diagnostics, 
tablet/proc URLs, and external JDBC URL preservation.
   - Add BRPC certificate hot reload and custom verification callback support, 
plus the upstream `SSLKEYLOGFILE` implementation from apache/brpc#3173.
   - Restore Cloud FDB/MetaService outbound TLS hooks and reject Cloud TLS 
startup when no provider is available.
   
   TDE scope:
   
   The public TDE contracts and implementations in Doris master are already 
equivalent to or newer than SelectDB 4.1. The remaining 4.1-only TDE 
differences call proprietary providers or lifecycle glue, so this PR correctly 
contains no TDE code changes.
   
   ### Release note
   
   Support unified TLS across the remaining public internal communication paths.
   
   ### Check List (For Author)
   
   - Test
       - [x] Regression test
       - [x] Unit Test
       - [x] Manual test
       - [ ] No need to test or manual test.
   
   Validation performed:
   
   - BE ASAN unit-test binary built with Clang 20.1.8; 34 focused 
TLS/CDC/URL/HTTP tests passed.
   - Cloud ASAN build/install passed; `ClientConnectionProviderTest.*` passed 
2/2.
   - FE TLS-affected suite passed 54 tests; the final JUnit 5 Thrift/provider 
tests passed 9/9 and the 60-module Maven reactor/checkstyle run succeeded.
   - CDC client focused Maven tests passed 6/6.
   - Regression framework connection test passed 1/1.
   - The complete 22-patch BRPC stack applied without rejects; static/shared 
BRPC and `brpc_ssl_unittest` built, three focused SSL tests passed, and 
`SSLKEYLOGFILE` produced valid TLS secret records.
   - Clang Format 16 dry-run and non-patch `git diff --check` passed.
   
   - Behavior changed:
       - [ ] No.
       - [x] Yes. Internal clients now honor unified TLS consistently and fail 
closed instead of silently using plaintext/untrusted fallback when TLS is 
required.
   
   - Does this need documentation?
       - [x] No. This PR completes internal wiring for the existing unified TLS 
model; it does not add a separate deployment mode.
       - [ ] Yes.
   
   ### Check List (For Reviewer who merge this PR)
   
   - [ ] Confirm the release note
   - [ ] Confirm test cases
   - [ ] Confirm document
   - [ ] Add branch pick label
   


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]


---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to