I have pulled it down and tested it. It appears to fix the problem, and works correctly.
Regards, -Tom -----Original Message----- From: xmlsec <[email protected]> On Behalf Of Floodeenjr, Thomas Sent: Tuesday, March 31, 2020 10:27 AM To: Aleksey Sanin <[email protected]>; [email protected] Subject: Re: [xmlsec] xmlsec1-1.2.16 to xmlsec1-1.2.29 decrypt problems Thanks! -----Original Message----- From: Aleksey Sanin <[email protected]> Sent: Tuesday, March 31, 2020 10:26 AM To: Floodeenjr, Thomas <[email protected]>; [email protected] Subject: Re: [xmlsec] xmlsec1-1.2.16 to xmlsec1-1.2.29 decrypt problems Should be fixed on master now. Aleksey On 3/30/20 2:29 PM, Floodeenjr, Thomas wrote: > Sure, thanks for the suggestion. > > https://github.com/lsh123/xmlsec/issues/283 > > -Tom > > -----Original Message----- > From: Aleksey Sanin <[email protected]> > Sent: Monday, March 30, 2020 2:21 PM > To: Floodeenjr, Thomas <[email protected]>; > [email protected] > Subject: Re: [xmlsec] xmlsec1-1.2.16 to xmlsec1-1.2.29 decrypt > problems > > Could you please file a bug/feature request in github? I don't think it is > too difficult to do. > > Aleksey > > On 3/30/20 8:16 AM, Floodeenjr, Thomas wrote: >> Aleksey, >> >> Following the progression of our code, according to this call stack: >> >> Application.exe!xmlParseCDSect(_xmlParserCtxt * ctxt) Line 9748 C >> Application.exe!xmlParseContent(_xmlParserCtxt * ctxt) Line 9831 >> C >> Application.exe!xmlParseInNodeContext(_xmlNode * node, const char * >> data, int datalen, int options, _xmlNode * * lst) Line 13682 C >> Application.exe!xmlSecReplaceNodeBufferAndReturn(_xmlNode * node, const >> unsigned char * buffer, unsigned int size, _xmlNode * * replaced) Line 632 >> C >> Application.exe!xmlSecReplaceNodeBuffer(_xmlNode * node, const unsigned >> char * buffer, unsigned int size) Line 609 C >>> Application.exe!xmlSecEncCtxDecrypt(_xmlSecEncCtx * encCtx, _xmlNode * >>> node) Line 562 C >> >> Inside xmlSecReplaceNodeBufferAndReturn(), we call >> xmlParseInNodeContext(node->parent, (const char*)buffer, size, >> XML_PARSE_NODICT, &results); >> >> It looks like the call in xmlSecReplaceNodeBufferAndReturn() hard-codes the >> option to "XML_PARSE_NODICT", and gives us no option to pass in the >> XML_PARSE_HUGE parameter we need when we call xmlSecEncCtxDecrypt(). >> >> Any ideas how to get around this? >> >> Thanks, >> -Tom >> >> -----Original Message----- >> From: Aleksey Sanin <[email protected]> >> Sent: Friday, March 27, 2020 5:17 PM >> To: Floodeenjr, Thomas <[email protected]>; >> [email protected] >> Subject: Re: [xmlsec] xmlsec1-1.2.16 to xmlsec1-1.2.29 decrypt >> problems >> >> Great. I am not aware of any issues with this flag. Since you posted to >> libxml2 mailing list, I am sure you fill get the answer shortly. >> >> Aleksey >> >> On 3/27/20 2:55 PM, Floodeenjr, Thomas wrote: >>> Aleksey, >>> >>> It seems we found the problem. Before we decrypt, we call doc = >>> xmlReadFile( filePath, NULL, XML_PARSE_HUGE ); It seems the XML_PARSE_HUGE >>> flag is not honored in libxml2. I am not sure if this is a bug in libxml2, >>> or if it is a new "feature". We are looking for a way to work around this. >>> If we hard-code it in xmlCtxtUseOptionsInternal(), i.e., ctxt->options |= >>> XML_PARSE_HUGE;, then our code decrypts fine. >>> >>> Thanks for your replies. >>> >>> -Tom >>> >>> >>> >>> -----Original Message----- >>> From: Aleksey Sanin <[email protected]> >>> Sent: Friday, March 27, 2020 10:32 AM >>> To: Floodeenjr, Thomas <[email protected]>; >>> [email protected] >>> Subject: Re: [xmlsec] xmlsec1-1.2.16 to xmlsec1-1.2.29 decrypt >>> problems >>> >>> Hi Thomas, >>> >>> I am not aware of any limitations on file sizes. I would suggest to either >>> set a breakpoint or dump the decrypted data before the call to >>> xmlParseInNodeContext() to see what's wrong. There are a couple options I >>> can think of: >>> 1) Decryption is completely incorrect and you will see junk in the buffer. >>> 2) Decryption is correct but the data is truncated. >>> >>> Let me know what do you find. >>> >>> Aleksey >>> >>> On 3/27/20 6:07 AM, Floodeenjr, Thomas wrote: >>>> Aleksey, >>>> >>>> Is there a limitation with xmlsec1-1.2.29 on the size of the >>>> encrypted XML that is being decrypted? The file seems to encrypt >>>> OK, but will not decrypt. (290 MB). Smaller files work fine both ways. >>>> We are using >>>> libxml2-2.9.9 and openssl-1.1.1d. (Previously we used >>>> libxml2-2.7.8 and openssl-1.0.2g, and it worked fine.) >>>> >>>> Thanks, >>>> -Tom >>>> >>>> -----Original Message----- >>>> From: xmlsec <[email protected]> On Behalf Of Floodeenjr, >>>> Thomas >>>> Sent: Thursday, March 26, 2020 12:52 PM >>>> To: Aleksey Sanin <[email protected]>; [email protected] >>>> Subject: Re: [xmlsec] xmlsec1-1.2.16 to xmlsec1-1.2.29 decrypt >>>> problems >>>> >>>> It returns here with -1 >>>> >>>> if(ret != XML_ERR_OK) { >>>> xmlSecXmlError("xmlParseInNodeContext", NULL); >>>> return(-1); >>>> } >>>> >>>> -----Original Message----- >>>> From: Aleksey Sanin <[email protected]> >>>> Sent: Thursday, March 26, 2020 11:05 AM >>>> To: Floodeenjr, Thomas <[email protected]>; >>>> [email protected] >>>> Subject: Re: [xmlsec] xmlsec1-1.2.16 to xmlsec1-1.2.29 decrypt >>>> problems >>>> >>>> What error do you get? >>>> >>>> Aleksey >>>> >>>> On 3/26/20 8:26 AM, Floodeenjr, Thomas wrote: >>>>> Hello, >>>>> >>>>> We recently upgraded from xmlsec1-1.2.16 to xmlsec1-1.2.29. We >>>>> have some data created in 1.2.16 that we can decrypt, but it fails >>>>> to decrypt in 1.2.29. >>>>> >>>>> Application.exe!xmlSecCheckNodeName(_xmlNode * >>>>> const cur, const unsigned char * name, const unsigned char * ns) >>>>> Line 210 C >>>>> >>>>>> >>>>>> Application.exe!xmlSecEncCtxEncDataNodeRead(_xmlSecEncCtx * >>>>>> encCtx, _xmlNode * node) Line 696 C >>>>> >>>>> >>>>> Application.exe!xmlSecEncCtxDecryptToBuffer(_xmlSecEncCtx >>>>> * encCtx, _xmlNode * node) Line 597 C >>>>> >>>>> >>>>> Application.exe!xmlSecEncCtxDecrypt(_xmlSecEncCtx >>>>> * encCtx, _xmlNode * node) Line 524 C >>>>> >>>>> Other items do decrypt fine with both versions. Any ideas what we >>>>> can look into? >>>>> >>>>> Thanks, >>>>> >>>>> -Tom >>>>> >>>>> >>>>> _______________________________________________ >>>>> xmlsec mailing list >>>>> [email protected] >>>>> http://www.aleksey.com/mailman/listinfo/xmlsec >>>>> >>>> _______________________________________________ >>>> xmlsec mailing list >>>> [email protected] >>>> http://www.aleksey.com/mailman/listinfo/xmlsec >>>> >>> _______________________________________________ >>> xmlsec mailing list >>> [email protected] >>> http://www.aleksey.com/mailman/listinfo/xmlsec >>> _______________________________________________ xmlsec mailing list [email protected] http://www.aleksey.com/mailman/listinfo/xmlsec _______________________________________________ xmlsec mailing list [email protected] http://www.aleksey.com/mailman/listinfo/xmlsec
