🤖 Proposal from Repo Assist.
Background
PR #1596 (merged in 6.6.0) added secure XML parsing defaults to XmlRuntime.fs:
DtdProcessing = DtdProcessing.Prohibit
XmlResolver = null
This was the right security posture, but it broke any XML that contains a (!DOCTYPE ...) declaration — including Nmap scan output, XHTML documents, and many other real-world XML formats (issue #1632).
PR #1633 (by @dsyme) reverts #1596 to unblock users. However, reverting means giving up the XXE protection entirely.
Proposed fix
Add a DtdProcessing static parameter to XmlProvider so users can choose the trade-off explicitly:
// Secure default — throws on any DTD (current 6.6.0 behavior)
type T = XmlProvider<"sample.xml"> // DtdProcessing defaults to "Prohibit"
// Silently ignore DTD declarations (safe for most cases)
type Nmap = XmlProvider<"nmap_scan.xml", DtdProcessing="Ignore">
// Fully parse DTD (needed for XHTML entity expansion, etc.) — use with caution
type Xhtml = XmlProvider<"page.xhtml", DtdProcessing="Parse">
The three string values map directly to System.Xml.DtdProcessing.Prohibit, Ignore, and Parse.
Implementation sketch
XmlRuntime.fs — change XmlElement.Create and XmlElement.CreateList to accept a DtdProcessing parameter (or a bool allowDtd flag) instead of always using Prohibit
XmlProvider.fs — add DtdProcessing : string static parameter (default "Prohibit") and thread it through to the runtime call site
XmlGenerator.fs / XmlProviderUtils.fs — pass the setting when constructing XmlElement values in generated code
TypeProviderInstantiation.fs (tests) — add the new parameter
The design-time sample parsing (in XmlInference.fs) should also respect the setting when loading the sample XML, so that DTD-bearing sample files don't fail at design time.
Notes
- Default should be
"Prohibit" to preserve the 6.6.0 security improvement (breaking change only for users who relied on the pre-6.6.0 behavior, which is fine since the revert would also change that)
"Ignore" is the right choice for most users who just want their DTD-bearing XML to work without actually using DTD features
"Parse" enables full DTD processing (entity expansion etc.) and should be marked as a potential security risk in the docs
Tracked from comment on #1632 and future-work note in the monthly activity issue.
Closes #1632 (as a proper fix once implemented — in the meantime, #1633 unblocks users).
Generated by Repo Assist
To install this workflow, run gh aw add githubnext/agentics/workflows/repo-assist.md@828ac109efb43990f59475cbfce90ede5546586c. View source at https://github.com/githubnext/agentics/tree/828ac109efb43990f59475cbfce90ede5546586c/workflows/repo-assist.md.
🤖 Proposal from Repo Assist.
Background
PR #1596 (merged in 6.6.0) added secure XML parsing defaults to
XmlRuntime.fs:DtdProcessing = DtdProcessing.ProhibitXmlResolver = nullThis was the right security posture, but it broke any XML that contains a
(!DOCTYPE ...)declaration — including Nmap scan output, XHTML documents, and many other real-world XML formats (issue #1632).PR #1633 (by @dsyme) reverts #1596 to unblock users. However, reverting means giving up the XXE protection entirely.
Proposed fix
Add a
DtdProcessingstatic parameter toXmlProviderso users can choose the trade-off explicitly:The three string values map directly to
System.Xml.DtdProcessing.Prohibit,Ignore, andParse.Implementation sketch
XmlRuntime.fs— changeXmlElement.CreateandXmlElement.CreateListto accept aDtdProcessingparameter (or abool allowDtdflag) instead of always usingProhibitXmlProvider.fs— addDtdProcessing : stringstatic parameter (default"Prohibit") and thread it through to the runtime call siteXmlGenerator.fs/XmlProviderUtils.fs— pass the setting when constructingXmlElementvalues in generated codeTypeProviderInstantiation.fs(tests) — add the new parameterThe design-time sample parsing (in
XmlInference.fs) should also respect the setting when loading the sample XML, so that DTD-bearing sample files don't fail at design time.Notes
"Prohibit"to preserve the 6.6.0 security improvement (breaking change only for users who relied on the pre-6.6.0 behavior, which is fine since the revert would also change that)"Ignore"is the right choice for most users who just want their DTD-bearing XML to work without actually using DTD features"Parse"enables full DTD processing (entity expansion etc.) and should be marked as a potential security risk in the docsTracked from comment on #1632 and future-work note in the monthly activity issue.
Closes #1632 (as a proper fix once implemented — in the meantime, #1633 unblocks users).