- 
                Notifications
    
You must be signed in to change notification settings  - Fork 96
 
[fix] Preserve OkHostnameVerifier from okhttp 3.9 #843
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
| 
           @iamdanfox what's latest here? Do we still want to merge this?  | 
    
| 
           Yep, if nobody has any concerns about the name then I just need to make a PR to add this extra field to the conjure-java-runtime-api!  | 
    
| 
           lgtm  | 
    
| 
           Is there more context somewhere? This seems dangerous and counterproductive. Can we not fix the service with bad certs?  | 
    
| 
           We are not intending to merge this as is - we're going to put it behind a feature flag, which is only expected to be enabled on the (3?) internal services which talk to the relevant internal server.  | 
    
| 
           @iamdanfox do you have timeline for adding the feature flag or should I submit the pr for that?  | 
    
| 
           @iamdanfox @robert3005 is this waiting on something?  | 
    
| 
           @j-baker any updates on the feature flag? This issue became a problem for gemini after we upgraded conjure-java-runtime because certain axiom hosts only include hostname in the CN, so gemini was running into a bunch of   | 
    
| 
           This is superseded by #907  | 
    
Before this PR
An earlier PR (#794) upgraded okhttp from 3.9.0 -> 3.11.0. This change from okhttp 3.10.0 meant conjure-java-runtime clients were unable to talk to a particular type of internal server (as it is currently only given certs with a CN and not a proper SAN):
After this PR
Jersey and Retrofit clients can be configured to use the old deprecated CN verification fallback behaviour.
TODO: