Re: Build failed in Jenkins: java-identity-provider-multi-jdk » JDK-1.8 #322

[Cantor, Scott]

On 4/16/14, 1:34 PM, "Brent Putman" <putmanb at georgetown.edu> wrote:
>
>Scott tried to fix, so maybe he has more info.

Partial, but yes. The root cause is that setting FEATURE_SECURE_PROCESSING
with Java 8 also sets the ACCESS_EXTERNAL_SCHEMA property to disallow all
schemes. But I believe the root root cause is that there's an anomaly in
their code here.

Normally if you get the schema order correct, it will cache the loaded
schemas and not try and fetch them, which would in theory pass this check.
But it turns out there are cases where they don't do that, such as an
include or redefine, rather than an import. In these cases, our default
behavior causes the schema builder to try and load a classpath URI, and
that gets passed to the access checker.

That code in turn tries to construct a java.net.URL around the URI to
extract the protocol so it can check it. Guess what happens when you pass
classpath:/foo to java.net.URL? Yeah, you guessed it.

So their code inadvertently prevents all use of classpath URIs even if you
permit that explicitly. I don't think they mean for that to happen, but
that's the net effect.

I'm not sure this is fixable except by not using include/redefine, or by
cirumventing those checks. Since by default I don't install a
ResourceResolver, that's supposed to eventually block all remote schema
access anyway. I'm testing that theory now, but if that's correct, one fix
is by overriding the ACCESS_EXTERNAL_SCHEMA to "all", which would allow
any scheme. That's insecure on the surface, but may be usable in practice.

TL;DR: JAXP is broken for safe and sane schema lookup, nothing new.

-- Scott