slachiewicz opened a new pull request, #3857:
URL: https://github.com/apache/thrift/pull/3857

   JIRA: [THRIFT-6275](https://issues.apache.org/jira/browse/THRIFT-6275)
   Client: go,test
   
   The 18 `py-go_*-ip-ssl` cross-test rows have been listed as known failures 
since 2015. Two defects on the Go client side stack, and fixing either alone 
changes nothing.
   
   The Go test client sent no client certificate, while the Python test server 
requires one, so every socket transport over SSL failed the handshake with 
`tls: certificate required`. The client now takes the same `--certPath` flag as 
the server and loads `client_v3.crt` and `client_v3.key` into the TLS 
configuration it uses for sockets and HTTPS; `tests.json` passes the flag.
   
   Go also refuses to load `client_v3.crt` as shipped: its alternative names 
include `::ffff:127.0.0.1`, and Go's x509 parser rejects an IPv4-mapped IPv6 
SAN, so the TLS client has nothing to send. THRIFT-3660 added that entry in 
2016 for the Python peer-address check, which since THRIFT-6201 reduces a 
mapped address to its IPv4 form itself. The certificate is regenerated 
self-signed with the same key, the same distinguished name and extensions, and 
the alternative names `127.0.0.1`, `::1` and `localhost`. The Java client 
keystore is regenerated from it with the command in the keys README. The README 
recipe itself now produces what is shipped; it described a CA-signed 
certificate that the Python server rejects with `unable to get local issuer 
certificate`, which is not how the shipped certificate was made.
   
   The 18 entries leave `test/known_failures_Linux.json`, so the cross-test 
jobs here are the check that the rows pass.
   
   What is not touched: the other 59 Go entries in the file, which fail for 
other reasons recorded on THRIFT-5809.
   
   Verified: all twelve py-go SSL combinations (binary, compact, json, header 
over buffered, framed, zlib) pass locally with a Python server built from 
master and the Go client from this branch; `go test ./src/common/` in `test/go` 
passes with the regenerated certificate, and fails against the old one once the 
client loads it; the keystore's certificate fingerprint matches the regenerated 
`client_v3.crt`. Not run locally: the other clients against the regenerated 
certificate, which the cross-test matrix covers.
   
   *This change was created with AI assistance.*
   


-- 
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]

Reply via email to