Sorry about not responding to these earlier, I was no longer subscribed to this list and did not realize it. Thank you for spending the time to investigate these issues and provide this level of detail.
1. Memory leaks
PKCS#12 “ComputePkcs12MAC(…)” leak
<<<< I have performed memory leak testing on sign/verify and encrypt/decrypt and have found no such leaks. Hopefully they will not be present in your tests when you run R2.4. I will be re-checking the memory leak issue before release. I will re-build you test programs to search for memory leaks to be sure these are fixed as well. If I discover any specific fixes here I will e-mail.
2. Memory overrun
unsigned char const*, unsigned long)+160
<<<<<<FIXED to supply 8 bytes of memory. Odd that this was not found by our MS Windows BoundsChecker.
3. Mismatched library calls
I have encountered three of these. They are benign with GCC,
but might matter on some platforms.
a. SNACC::AsnFileSeg::AsnFileSeg(char const*) allocates member
m_filename using strdup() (and hence malloc()) but frees it
c. SNACC::ConsStringDeck::~ConsStringDeck() uses delete rather
than delete  to free memory allocated using new in
<<<< FIXED to properly reflect construction of memory.
4. Lack of thread safety
<<<< This issue was known at release time. All of our lists, including the SNACC lists, have internal pointers indicating the “Curr()” current value. Threads interfere with this value causing problems. Our solution in the SFL was to simply lock all references to such lists. You have probably discovered a location that was not protected. The upcoming R2.4 release no longer uses lists with internal pointers to “Curr()”, we now use the std::list::iterator concept, which provides full thread protection. Unfortunately it means that all referencing applications must convert as well, but it is not difficult.
5. Lack of handling of std::exception exceptions thrown by crypto++
<<<< I will add such exception checking to the sm_free3 CTIL to wrap the crypto++ exceptions. Previously this was caught by the upper level application with “catch(…)”, but there is no call stack nor any indication of what the failure was.
6. Less robust than SFL 2.1
<<< Without specifics this is hard to address. If your high-level application was not catching (…), then perhaps the crashes were due to the Crypto++ decryption failures? The fix for Number 5 in the next release (R4.2) should fix these. Any ASN.1 decode failures are reported directly, so they should not cause a crash/segmentation fault.
7. Memory usage processing large messages
<<<< This is a know issue, we have not made the SFL fully compatible with file-based processing; it is on our wish-list. Unfortunately the existing SNACC buffer handling requires memory resident data for processing. This has no easy solution. Our hope was to develop a simple stream-based input/output capability, but this changes the entire SNACC API as well as the SNACC compiler generated logic. This is no easy task and is not required by our customer at this time, so it has been difficult to implement thus far.
<<<< Added this feature as described, but untested (I will have to create a program to generate a PKCS12 file with no password).
<<<< Added this feature as described.