...
Propose we release updated 17 parent and re-lock everything to that to stablize javadoc mess
Unless we’ve decided to start leaving everything unlocked and letting dependency updates bleed into all the CI jobs?
If there are additional release profile changes we want to make, might be a good time.
Overall backlog of new work / release planning
Board update
Attendees:
Brent
Jira Legacy server System JIRA serverId f52c7d31-6eab-3f0e-93c3-231b5754d506 key OSJ-388 tested their changes and our update is ready to go. xmlsec 3.0.3 was released Thurs (yesterday).
need to update xmlsec dep to 3.0.3 - wrt to the agenda topic: do in java-parent or override in opensaml-parent, etc?
Jira Legacy server System JIRA serverId f52c7d31-6eab-3f0e-93c3-231b5754d506 key OSJ-391 Can default these in TLSSocketFactory impl itself, and can be overridden either at factory-level or per-request if necessary (the latter most likely)
Minor risk is if we have any gaps where we don’t have an HttpClientSecurityParameters that can be supplied to override
Should extrapolate to cipher suites also? Maybe hardening the protocols would already limit the “bad ones” inherently.
Jira Legacy server System JIRA serverId f52c7d31-6eab-3f0e-93c3-231b5754d506 key OSJ-392 I have observations not expressed in the issue yet. No resolution yet. Summary:
I think the issue isn’t use of xsi:type per se, it’s any case where you don’t have XMLObject support for an element/type in your runtime environment, and you get an XSAny.
If I remember XML Schema esoterica correctly (maybe not), any element’s content model can be subtyped - it’s just not common. I.e. RoleDescriptor isn’t special.
<KeyDescriptor xsi:type="brent:MyAwesomeKeyDescriptorType">- where that type is a subtype ofKeyDescriptorType.Is a theoretical concern, maybe we just ignore and focus on the “expected” extension points.
Daniel
Henri
Ian
John
Marvin
Phil
...