Changes in snmp++ 3.6.4 according to "memory leak in the AuthPriv destructor"

SNMP++/AGENT++
1

Hello Frank

I just had a look on the changes between snmp++ 3.6.3 and snmp++ 3.6.4 and I’m not sure, whether this is the best solution for the issue of the “memory leak in the AuthPriv destructor” since the “legacy provider” must only be loaded once to use “DES” multiple times if I understand the documentation correctly.

Consequently, an easy and lazy solution in the constructor of AuthPriv could be to make “OSSL_PROVIDER *legacy_provider” static:

static OSSL_PROVIDER *legacy_provider = nullptr;
if (!legacy_provider)
{
legacy_provider = OSSL_PROVIDER_load(NULL, “legacy”);
if( !legacy_provider )
{
LOG_BEGIN(loggerModuleName, ERROR_LOG | 1);
LOG(“AuthPriv: Error loading ‘legacy’ provider for OpenSSL. No DES encryption available”);
LOG_END;
}
}

This avoids possibly unnecessary calls to “OSSL_PROVIDER_load” and “OSSL_PROVIDER_unload” during runtime.

This “only” does not release the memory allocated with the one and only successful call to “OSSL_PROVIDER_load” on termination of the hosting application.

If this is not acceptable, I personally would prefer a documentary solution that states that the hosting process has to assure that the “legacy provider” of OpenSSL is loaded before “DES” is needed.

This includes the requirement that the hosting process must assure that the loaded provider is unloaded accordingly on termination of the hosting process if this of importance. Ths includes allocated memory by “OSSL_PROVIDER_load”

regards, Thorsten

2

Th AuthPriv object is only created once per USM instance. The overhead of having the legacy_provider as instance member instead of a static variable is thus nearly zero and better than leaving it unused in memory after AuthPriv is no longer used by an application.

3

I have discussed this topic with Jochen and it seems that you have a valid point here, because the OpenSSL legacy provider itself is a static object. I will change the fix once again to correctly handle this use case as well.

4

SNMP++ 3.6.5 is now available which implements the suggested fix.