Re: updated version of XML doc

[by way of "Chris M. Lonvick" <[EMAIL PROTECTED]>]

Kriss Andsten <[EMAIL PROTECTED]> replied to my reply:

"> applications.  If you invent your own encoding, you will have to do
 > your own parsers; because coding errors in such things are the most
 > vulnerable feature of existing protocol implementations (esp. syslogd)
 > reusing documented, well-exercised code is an important security
 > feature.
"Cant really see how that would be a -security- feature. Yes, some
standardization help, not arguing there, but making something XML doesnt
neccessarily make people less prone to stupidities. Ymmv, of course.."


The really stupid errors happen because the protocol was never designed,
was coded as a weekend project by an undergrad, and the first attempt,
since it worked, was never reexamined.   I strongly suspect this is the
story of UNIX syslog, which until fairly recently not only allowed a big
UDP packet to cause stack overflow, but allowed that stack overflow to
permit attacking code to take over the syslogd process!!

By reusing an encoding/decoding library with as broad and complex a
population of users as XML has, you draw on a much larger range of
requirements for implementations.  Many of them are likely to be student
projects with similar vulnerabilities, but some are likely to be fully
engineered products, either commercial or Open Source.  It's again a
judgement call, but this is an everyday thing in engineering -- we all make
build vs buy/reuse decisions constantly, and experience is the test.  (For
high security close examination should be added;  since that's only
possible with Open Source, I would say that an open implementation is also
a goal for a syslog replacement.)  Again, if there is an alternative to XML
for network encoding, that inspires similar confidence, let's hear about
it.


Alex Brown <[EMAIL PROTECTED]> +1 508 323 2283

NB:  I will be away from my desk much of this week;  I can be reached most
easily at:
Alex Brown <[EMAIL PROTECTED]> +1 617 504 8761