Re: [xml-dev] The <any/> element: bane of security or savior of versioni

["bryan rasmussen" <rasmussen.bryan@gmail.com>]

hmm, no idea why any came out Any all over the place.

cheers,
Bryan Rasmussen

On 10/19/07, bryan rasmussen <rasmussen.bryan@gmail.com> wrote:
> Of course note that some of these examples are overdrawn worst case
> scenarios, but I have certainly seen lesser variations of them in some
> companies and large organizations that had to deal with Any and could
> not. And that were any's that were reasonably walled off from the rest
> of the markup (in an element defined as extensible. )
>
> Cheers,
> Bryan Rasmussen
>
> On 10/19/07, bryan rasmussen <rasmussen.bryan@gmail.com> wrote:
> > Possible problems with Any:
> >
> > well many problems with things are problems because we cannot count on
> > people to either use them correctly, or use the things that depend on
> > them correctly.
> >
> > Let us suppose we have an any allowed in the the following xml fragment
> >
> > <a>
> >  <b></b>
> >  <c></c>
> >  <d></d>
> > {any allowed here}
> > </a>
> >
> > This fragment is in a format of business critical data, not in
> > presentational markup.
> > This data is handled via a system with some millions of lines of code
> > programmed over several years by dozens of people.
> >
> > The following bugs have been determined to be in the system:
> >
> > -----------------------------------------------------------------------------------------------
> > If condition X occurs somewhere in the passing of the XML message
> > process X is run which recursively goes over the data entering all
> > data from elements into a ridiculously bad database structure where
> > field names match element names.
> >
> > When Any occurs in xml documents that are ran through process X the
> > system crashes.
> >
> > Somebody is working on this bug though and they will probably find it soon.
> >
> > -----------------------------------------------------------------------------------------------
> >
> > There are a number of stylesheets for various output media. These
> > stylesheets have all been written in the push style to increase
> > maintainability and with reference to the definition of elements in
> > the namespace.
> >
> > These stylesheets produce incorrect presentations when ran with
> > elements that extend the known namespace - i.e. when any is used.
> > Nobody has found out about this yet but somebody has noticed that
> > there are validation errors coming out in some instances when the
> > instances are ran through the format 2 xsl-fo stylesheets because the
> > xsl-fo renderer used is rendereX with validation of the XSL-FO.
> > Somebody is trying to debug this but it is somewhat difficult because
> > the guy who wrote the stylesheets is no longer there, but nobody at
> > the company knows XSL-FO.
> >
> > Also format 2 legacy html stylesheet produces output that crashes
> > Netscape 4 when some infrequent user of that browser shows up. That is
> > also set to debug, nobody knows what causes it though. The best guess
> > is it is somewhere on the server side not in the transformation, and
> > nobody is looking at it because hey, its Netscape 4.
> >
> > -----------------------------------------------------------------------------------------------
> >
> > There are any number of bits of code throughout this big big system
> > where someone gets a and has to read the children of a into an array
> > and blah blah blah. In some cases depending on how it was done the
> > system fails, in other cases the data gets added into the last item in
> > the array blah blah blah. In some bits of legacy data from a long time
> > ago before they found out they had these problems somebody made
> > extension y that had an integer datatype. d was a decimal datatype. In
> > some arrays that were really important for calculating some sort of
> > tax d and extension y ended up getting concatenated. Nobody has
> > actually realized that there are small decimal inconsistencies in the
> > data. This will be figured out in the next accounting cycle.
> >
> > Finally the IT support and consultants and programmers for this large
> > organization do not necessarily talk to each other about the bugs they
> > find in different non-connected parts. For example that the XSL-FO
> > stylesheets have a bug will not necessarily be communicated to the
> > programmers trying to figure out where the bug is on the format 2 html
> > presentation server.
> >
> > The upshot is that: given that people do not build large systems
> > invariably after best practices one cannot say well just make sure you
> > don't do any of those mistakes then.
> >
> > One must realize that decisions in the extensibility of the format can
> > cause those mistakes.
> >
> > Any in those contexts can lead to higher chances of things being
> > fucked up. Therefore, while I do not agree that Any is too dangerous
> > to ever use, Any is definitely to dangerous to just assume there is no
> > problem with it.
> >
> > Cheers,
> > Bryan Rasmussen
> >
> >
> >
> >
> >
> >
> >
> >
> > On 10/19/07, David Carlisle <davidc@nag.co.uk> wrote:
> > >
> > >
> > >
> > > < From a security perspective the <any/> element represents a high risk
> > > > and should be avoided if possible.  In environments where schema
> > > > validation is used in a guarding capacity, a schema that uses the
> > > > <any/> element is likely to be marked as high risk or even forbidden
> > > > from use.
> > >
> > > That seems a rather bizare characterisation, and compared to otehr
> > > features of XSD (for example lax or skip validation) what is teh problem
> > > that you see with <any/> ?
> > >
> > > David
> > >
> > > ________________________________________________________________________
> > > The Numerical Algorithms Group Ltd is a company registered in England
> > > and Wales with company number 1249803. The registered office is:
> > > Wilkinson House, Jordan Hill Road, Oxford OX2 8DR, United Kingdom.
> > >
> > > This e-mail has been scanned for all viruses by Star. The service is
> > > powered by MessageLabs.
> > > ________________________________________________________________________
> > >
> > > _______________________________________________________________________
> > >
> > > XML-DEV is a publicly archived, unmoderated list hosted by OASIS
> > > to support XML implementation and development. To minimize
> > > spam in the archives, you must subscribe before posting.
> > >
> > > [Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/
> > > Or unsubscribe: xml-dev-unsubscribe@lists.xml.org
> > > subscribe: xml-dev-subscribe@lists.xml.org
> > > List archive: http://lists.xml.org/archives/xml-dev/
> > > List Guidelines: http://www.oasis-open.org/maillists/guidelines.php
> > >
> > >
> >
>