Re: RFR (JAXP): 8028111 : XML readers share the same entity expansion counter
On 13/11/2013 22:08, huizhe wang wrote: : Each parser has its own copy of XMLSecurityManager that maintains the values of the limits. The parser is reset before it starts to parse a document. Resetting the values managed by XMLSecurityManager therefore makes sure that the limits are per document. Daniel sent me a private email to question if the reset in PropertyManager is safe. He was right. I traced that back to the previous patch in that the StAX parsers actually were sharing the same XMLSecurityManager, and also XMLSecurityPropertyManager. I've changed the code so that they are cloned. webrev: http://cr.openjdk.java.net/~joehw/jdk8/8028111/webrev/ Sorry about that, having it called XMLSecurityManager when it's not a SecurityManager is always confusing. In that case, it looks okay to me. -Alan.
Re: RFR (JAXP): 8028111 : XML readers share the same entity expansion counter
Hi Joe, The new webrev looks good... -- daniel On 11/13/13 11:08 PM, huizhe wang wrote: On 11/13/2013 1:33 PM, Alan Bateman wrote: On 13/11/2013 20:02, huizhe wang wrote: Hi, The issue is that the limits applied to each processing process rather than each file processing. This applies to not only StAX as reported, but also other parsers and validators. The fix is to add reset to XMLSecurityManager and call it upon each file processing. XSLT Transform is verified fixed as the underlying parsers are fixed. webrev: http://cr.openjdk.java.net/~joehw/jdk8/8028111/webrev/ This looks okay as a band-aid but won't this be replaced if fixed to have limits per document? Each parser has its own copy of XMLSecurityManager that maintains the values of the limits. The parser is reset before it starts to parse a document. Resetting the values managed by XMLSecurityManager therefore makes sure that the limits are per document. Daniel sent me a private email to question if the reset in PropertyManager is safe. He was right. I traced that back to the previous patch in that the StAX parsers actually were sharing the same XMLSecurityManager, and also XMLSecurityPropertyManager. I've changed the code so that they are cloned. webrev: http://cr.openjdk.java.net/~joehw/jdk8/8028111/webrev/ Thanks, Joe -Alan.
RFR (JAXP): 8028111 : XML readers share the same entity expansion counter
Hi, The issue is that the limits applied to each processing process rather than each file processing. This applies to not only StAX as reported, but also other parsers and validators. The fix is to add reset to XMLSecurityManager and call it upon each file processing. XSLT Transform is verified fixed as the underlying parsers are fixed. webrev: http://cr.openjdk.java.net/~joehw/jdk8/8028111/webrev/ Thanks, Joe
Re: RFR (JAXP): 8028111 : XML readers share the same entity expansion counter
On 13/11/2013 20:02, huizhe wang wrote: Hi, The issue is that the limits applied to each processing process rather than each file processing. This applies to not only StAX as reported, but also other parsers and validators. The fix is to add reset to XMLSecurityManager and call it upon each file processing. XSLT Transform is verified fixed as the underlying parsers are fixed. webrev: http://cr.openjdk.java.net/~joehw/jdk8/8028111/webrev/ This looks okay as a band-aid but won't this be replaced if fixed to have limits per document? -Alan.
Re: RFR (JAXP): 8028111 : XML readers share the same entity expansion counter
looks fine joe On Nov 13, 2013, at 3:02 PM, huizhe wang wrote: Hi, The issue is that the limits applied to each processing process rather than each file processing. This applies to not only StAX as reported, but also other parsers and validators. The fix is to add reset to XMLSecurityManager and call it upon each file processing. XSLT Transform is verified fixed as the underlying parsers are fixed. webrev: http://cr.openjdk.java.net/~joehw/jdk8/8028111/webrev/ Thanks, Joe Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 lance.ander...@oracle.com
Re: RFR (JAXP): 8028111 : XML readers share the same entity expansion counter
On 11/13/2013 1:33 PM, Alan Bateman wrote: On 13/11/2013 20:02, huizhe wang wrote: Hi, The issue is that the limits applied to each processing process rather than each file processing. This applies to not only StAX as reported, but also other parsers and validators. The fix is to add reset to XMLSecurityManager and call it upon each file processing. XSLT Transform is verified fixed as the underlying parsers are fixed. webrev: http://cr.openjdk.java.net/~joehw/jdk8/8028111/webrev/ This looks okay as a band-aid but won't this be replaced if fixed to have limits per document? Each parser has its own copy of XMLSecurityManager that maintains the values of the limits. The parser is reset before it starts to parse a document. Resetting the values managed by XMLSecurityManager therefore makes sure that the limits are per document. Daniel sent me a private email to question if the reset in PropertyManager is safe. He was right. I traced that back to the previous patch in that the StAX parsers actually were sharing the same XMLSecurityManager, and also XMLSecurityPropertyManager. I've changed the code so that they are cloned. webrev: http://cr.openjdk.java.net/~joehw/jdk8/8028111/webrev/ Thanks, Joe -Alan.
