Hi,
Theoretically this is not just a Xerces issue but any XML parser
implementing the JDK SAX APIs.
I do not actually know which versions of Xerces fail and which do not
to clearly state all versions less than V will fail :-) But i could
update the user guide to mention this area and provide some rational
for deployment failure which i have only observed for Xerces.
> Finally: leaving decision up to developers may be reasonable approach;
> but in my opinion it needs to be opt-out for secure processing, not
> opt-in.
IIUC i think we are in agreement and the developer has to explicitly
do something to disable secure processing?
Paul.
On Mar 2, 2010, at 2:54 AM, Tatu Saloranta wrote:
> On Mon, Mar 1, 2010 at 5:33 PM, Mike Baranczak
> <mbaranczak_at_gmail.com> wrote:
>>
>> Yeah, it was way old - 2.6.2 to be exact. I was able to replace it
>> with
>> 2.9.1, and everything works beautifully now.
>>
>> I'm not crazy about the idea of requiring some specific parser
>> library. I
>> think the default behavior of Jersey should be the same as it is
>> now - use
>> whatever parser the JRE gives you, and if that doesn't work, let the
>> developer deal with it. But I do like the idea of an optional
>> setting in
>> Jersey to force a specific parser implementation. Most people
>> wouldn't need
>> it, but it'd be very useful in some situations.
>
> I personally prefer having loose baseline limits too (that is, try to
> avoid forcing more recent version than necessary). But I think it is
> much preferred to define what that version is (whatever it is) than
> leave it to chance. So there already was a requirement of Xerces
> version (to some degree), you just did not know there was one. This is
> not a new requirement, just documenting existing one; implicitly
> established of course (via failure on older versions).
>
> But as to whether this is a reasonable baseline requirement (compared
> to earlier versions, which do core xml parsing just fine, even 2.4
> would do that), well, considering it is a security risk, companies
> generally consider it worth the hassle.
> I don't know many managers who would comfortable if asked to say it's
> ok to use an older version that causes allegedly non-secure
> processing, just to avoid inconvenience of library upgrade.
>
> Finally: leaving decision up to developers may be reasonable approach;
> but in my opinion it needs to be opt-out for secure processing, not
> opt-in.
>
> -+ Tatu +-
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
> For additional commands, e-mail: users-help_at_jersey.dev.java.net
>