[JIRA] (OSJ-379) "trustAnchors parameter must be non-empty" failure in httpClient

[Brent Putman (Jira)]

Brent Putman ( https://shibboleth.atlassian.net/secure/ViewProfile.jspa?accountId=557058%3A97de0981-adc3-4044-95ed-131622fad81e ) *commented* on OSJ-379 ( https://shibboleth.atlassian.net/browse/OSJ-379?atlOrigin=eyJpIjoiODJhMDE5NmQxNTMxNGM0NjhiMDRlYjJhMDJjOWYwZDAiLCJwIjoiaiJ9 )

Re: "trustAnchors parameter must be non-empty" failure in httpClient ( https://shibboleth.atlassian.net/browse/OSJ-379?atlOrigin=eyJpIjoiODJhMDE5NmQxNTMxNGM0NjhiMDRlYjJhMDJjOWYwZDAiLCJwIjoiaiJ9 )

Yes, the “strict”mode is all standard Java, none of our special TLS socket factory code, etc.

Well, we don’t actually know yet if Java has a “bug” per se. If the problem is as speculated, then maybe one just isn’t supposed to change the trust store while a JVM referencing it is running.

I don’t think any of this is affected by the HC 5 work. Design-wise it’s pretty much still the same in this area.

So I think you’re saying possibly disallow the “strict” case in the high-level components such as produced by the Spring parsers, and only allow the disregardTLSCertificate case or config which effectively has a TrustEngine.

The main potential issue I see with that is that in the Spring parser, the effective trust engine can be supplied either directly via a <TrustEngine> element or indirectly via a bean ref httpClientSecurityParametersRef (just looking at the dynamic HTTP provider for the moment). Is it even possible to de-reference the latter within a Spring parser and get at the actual bean’s properties?

( https://shibboleth.atlassian.net/browse/OSJ-379#add-comment?atlOrigin=eyJpIjoiODJhMDE5NmQxNTMxNGM0NjhiMDRlYjJhMDJjOWYwZDAiLCJwIjoiaiJ9 ) Add Comment ( https://shibboleth.atlassian.net/browse/OSJ-379#add-comment?atlOrigin=eyJpIjoiODJhMDE5NmQxNTMxNGM0NjhiMDRlYjJhMDJjOWYwZDAiLCJwIjoiaiJ9 )

Get Jira notifications on your phone! Download the Jira Cloud app for Android ( https://play.google.com/store/apps/details?id=com.atlassian.android.jira.core&referrer=utm_source%3DNotificationLink%26utm_medium%3DEmail ) or iOS ( https://itunes.apple.com/app/apple-store/id1006972087?pt=696495&ct=EmailNotificationLink&mt=8 ) This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100225- sha1:9dd72a2 )
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/commits/attachments/20230519/34600899/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: jira-generated-image-static-comment-icon-dea1f8fa-3a1b-47bc-b031-1d7cfce710e7
Type: image/png
Size: 1084 bytes
Desc: not available
URL: <http://shibboleth.net/pipermail/commits/attachments/20230519/34600899/attachment-0003.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: jira-generated-image-avatar-461055e4-4720-4746-841d-adb399f5e75a
Type: image/png
Size: 345 bytes
Desc: not available
URL: <http://shibboleth.net/pipermail/commits/attachments/20230519/34600899/attachment-0004.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: jira-generated-image-static-footer-desktop-logo-a0cdaf95-e1eb-4afe-8f7d-6515e41ec82d
Type: image/png
Size: 10805 bytes
Desc: not available
URL: <http://shibboleth.net/pipermail/commits/attachments/20230519/34600899/attachment-0005.png>