using Velocity to externalize configuration properties ?

[Brent Putman]

>
> I suppose though that if the schemaLocations hint mapped the namespace to
> itself (something I used to do explicitly in my documents, but eventually
> changed), our existing spring.schemas mappings might work with their
> built-in EntityResolver.

Yeah, that might work.  In fact it probably would, unless they actually
detect whether the "location" is a URL (http, https, etc), and do
something different if it's not.

But there's something to be said for not confusing people by doing
something that violates the intent of xsi:schemaLocation and/or
spring.schemas.  So offhand my inclination is that we should probably
just "do it right" according to the docs.  Or, in the worst case,
completely replace it with a mechanism that's not based on
xsi:schemaLocation at all, if that is do-able.

>
>> (I also do not know what the Spring EntityResolver does, but I will go
>> look that up if I should)
> Presumably it does a lookup through spring.schemas files, and then it will
> fall back to just doing a remote fetch if it's a URL (which it shouldn't).

Yes, that's my understanding as well.  It checks to see whether there is
a mapping of a location (pulled from xsi:schemaLocation) to a classpath
resource.  If yes, then it uses the location resource.  If not, then it
falls back to doing the remote fetch of the resource URL.

>
> What I do is implement my own catalog files that map from namespaces to
> files, and then I use an entity resolver that is explicitly programmed to
> only allow loading of entities in that set of namespaces and files, and
> block anything else.

That sounds conceptually nicer than what Spring does with their
proprietary mechanism.  However, whatever we did would have to take into
account that Spring ships with their own spring.schemas files defined
according to their mechanism.  We'd have to somehow either make it work
with both styles and approaches side-by-side, or else take ownership of
all of the Spring namespace -> local XSD resource mappings, and maintain
that across upgrades, etc.  That doesn't sound attractive to me personally.

I don't know what the right answer is.  I guess the question for me is:
how much is the xsi:schemaLocation usage really a security problem for
the use cases and environment we have (parsers, entity resolvers, etc),
and does it justify building a whole new mechanism? Would just plugging
in an entity resolver that absolutely never does a remote lookup (if
possible) be a sufficient compromise?


> Further, there is in some cases (but perhaps not in Java) a problem with
> schemas importing schemas. When that happens there is a second parsing
> step. In Xerces-C, that parsing step is broken and will follow schema
> import locations even if the parser is originally told to ignore location
> hints. I had to work around that in some very ugly ways.


I don't know if Xerces-J does that or not.