WSDL parsing fetches schemas from schemas.dmtf.org at runtime — fails on offline / air-gapped hosts

[ivanmerkish]

Summary

WinRMService.createInstance(...) performs an outbound HTTP fetch to schemas.dmtf.org and www.w3.org every time it parses the bundled wsdl/WinRM.wsdl. On hosts that cannot reach those domains (offline labs, air-gapped on-prem deployments, networks behind egress firewalls or HTTP proxies), the call blocks for ~75 s (OS TCP timeout) and finally throws:

org.metricshub.winrm.exceptions.WinRMException: Failed to create service.
WSDLException: WSDLException (at /wsdl:definitions/wsdl:types/xs:schema[1]):
 faultCode=PARSER_ERROR: Problem parsing
 'http://schemas.dmtf.org/wbem/wsman/1/dsp8034_1.0.xsd'.:
java.net.ConnectException: Connection timed out: connect
    at org.metricshub.winrm.service.WinRMService.createInstance(WinRMService.java:312)
    ...
Caused by: javax.wsdl.WSDLException: ... PARSER_ERROR: Problem parsing
 'http://schemas.dmtf.org/wbem/wsman/1/dsp8034_1.0.xsd'.: ...
    at com.ibm.wsdl.xml.WSDLReaderImpl.getDocument(WSDLReaderImpl.java:2198)
    at com.ibm.wsdl.xml.WSDLReaderImpl.parseSchema(WSDLReaderImpl.java:830)
    ...
Caused by: java.net.ConnectException: Connection timed out: connect
    at java.base/sun.nio.ch.Net.connect0(Native Method)
    ...
    at org.apache.xerces.impl.XMLEntityManager.setupCurrentEntity(Unknown Source)
    at com.ibm.wsdl.xml.WSDLReaderImpl.getDocument(WSDLReaderImpl.java:2188)

Root cause

The shipped src/main/resources/wsdl/WinRM.wsdl declares three external schema imports via absolute URL:

<xs:import namespace="http://schemas.xmlsoap.org/ws/2004/09/enumeration"
           schemaLocation="http://schemas.dmtf.org/wbem/wsman/1/dsp8033_1.0.xsd"/>
<xs:import namespace="http://schemas.xmlsoap.org/ws/2004/08/addressing"
           schemaLocation="http://schemas.dmtf.org/wbem/wsman/1/dsp8034_1.0.xsd"/>
<xs:import namespace="http://www.w3.org/XML/1998/namespace"
           schemaLocation="http://www.w3.org/2001/xml.xsd"/>

Apache CXF's WSDL loader resolves those imports by calling URL.openStream() directly on each absolute URL — there is currently no META-INF/jax-ws-catalog.xml, no programmatic OASISCatalogManager configuration and no custom WSDLLocator / URIResolver to remap them to local copies.

The JAR does include xsd/dsp8033_1.0.xsd, xsd/transfer.xsd and xsd/wsman.xsd, but they are never consulted because nothing wires them to the absolute URLs the WSDL points at. In addition xsd/dsp8034_1.0.xsd is missing entirely — and even when dsp8033 happens to be served from a local resolver fallback, its content recursively imports dsp8034, so a network fetch is still required.

Net effect: every WinRMService.createInstance(...) call silently makes 2-3 outbound HTTPS-less requests to third-party servers at session start, even on hosts that have full internet access — and fails completely on hosts that do not.

Reproduction

1. Block outbound TCP to schemas.dmtf.org (firewall rule, /etc/hosts entry pointing it at 127.0.0.1, or any restricted-egress network).
2. Call WinRMService.createInstance(endpoint, 120_000L, null, List.of(AuthenticationEnum.NTLM)).
3. After ~75 s, the call throws the exception shown above.

Equivalent reproduction without a target: a minimal CXF client that loads the bundled WinRM.wsdl via JaxWsProxyFactoryBean.setWsdlLocation(...) exhibits the same failure on an offline host.

Impact

• Air-gapped / restricted-egress deployments: WinRM scans never succeed on these networks; users see a 75 s hang followed by an opaque WSDLException(PARSER_ERROR) whose immediate message references schemas.dmtf.org, not a problem with the WinRM target.
• All other deployments: a silent runtime dependency on schemas.dmtf.org and www.w3.org for every WinRM session — slower session startup, brittleness if DMTF / W3C have downtime, and a small information leak (every scan announces itself to schemas.dmtf.org).

Proposed fix

Ship a META-INF/jax-ws-catalog.xml (auto-discovered by CXF's OASISCatalogManager) mapping all four absolute URLs to local classpath copies under xsd/, and bundle the missing dsp8034_1.0.xsd, xml.xsd and ws-addr.xsd. This is the standard JAX-WS resolution mechanism and requires no code change — just resource files. After the change, the WSDL parses fully offline and no outbound HTTP is performed.

A PR with the catalog, the three missing schemas and a CatalogResolutionTest is opened against this issue: #82.

Environment

• org.metricshub:winrm-java:1.1.02
• Java 11+ / 17
• Apache CXF (the version transitively pulled by this library)
• Reproduced on Linux + Windows collectors, on-prem and lab.

[bertysentry]

Thank you for reporting this and for the PR! We're looking into it!