On Tuesday, 13 February 2018 at 22:13:36 UTC, H. S. Teoh wrote:
Ironically, the general advice I found online w.r.t XML
vulnerabilities is "don't allow DTDs", "don't expand entities",
"don't resolve externals", etc.. There also aren't many XML
parsers out there that fully support all the features called
for in the spec. IOW, this basically amounts to "just use dxml
and forget about everything else". :-D
Now of course, there *are* valid use cases for DTDs... but a
naïve implementation of the spec is only going to end in tears.
My current inclination is, just merge dxml into Phobos, then
whoever dares implement DTD support can do so on top of dxml,
and shoulder their own responsibility for vulnerabilities or
whatever. (I mean, seriously, just for the sake of being able
to say "my XML is validated" we have to implement network
access, local filesystem access, a security framework, and what
amounts to a sandbox to control pathological behaviour like
exponentially recursive entities? And all of this, just to
handle rare corner cases? That's completely ridiculous. It's
an obvious design smell to me. The only thing missing from
this poisonous mix is Turing completeness, which would have
made XML hackers' heaven. Oh wait, on further googling, I see
that XSLT *is* Turing complete. Great, just great. Now I
know why I've always had this gut feeling that *something* is
off about the whole XML mania.)
T
Thanks for the analysis. I'd say you're right. It makes no sense
to keep dxml from becoming std.xml's successor only because it
doesn't support DTDs. Also, as I said before, if we had DTD
support in std.xml, people would complain about the lack of
efficiency, and the discussion about interpreting the specs
correctly, implementing them 100%, complaints about the lack of
security would just never end.
