XMLSec 1.3.3 #750
Replies: 2 comments 2 replies
-
Hm, I hit a problem with commit 8fc21b2 while updating the bundled xmlsec on the libreoffice side, where we build against a debug nss in debug builds, i.e. asserts actually can fail (which is not something I tested with odfsig). Here is the backtrace of the failure I see:
Does this ring a bell for you? This is against nss-3.90, perhaps the code was only tested against some older nss or only against nss with asserts disabled? If it's useful, I can try to collect a bit more info, like what is the value of type when the called Edit: ah, the type is there already, 307, which is 0x133, which seems to be CKM_DES3_CBC. Edit 2: the below fixes the assertion failure for me:
Looks like debug nss asserts that the OID hashtable is already initialized, but if asserts are off, then it will just silently initialize the hashtable, so nothing bad happens. Should I send this in as a proper PR or you have a better idea how to avoid the problem? Thanks. Edit 3: probably the intention of the nss assert is that auto-init is bad, beause the init and shutdown should be called as a pair, i.e. SECOID_Init() before this new code and SECOID_Shutdown() at the end, so the above patch is just a PoC, would still leak memory. |
Beta Was this translation helpful? Give feedback.
-
Sorry for delay with reply -- I am traveling for the next few days. Looks like you already found the reason -- NSS was not initialized before xmlsec-nss init was called. I can add this change from above but the proper solution is to init NSS before xmlsec. |
Beta Was this translation helpful? Give feedback.
-
The XML Security Library 1.3.3 release includes the following changes:
Thanks for bug reports and PRs!
Aleksey
This discussion was created from the release XMLSec 1.3.3.
Beta Was this translation helpful? Give feedback.
All reactions