X509Extension has a memory leak in its private member function _subjectAltNameString() which is publicly exposed via the member function __str__()

[crc32a]

just calling the member method str() on an X509Extention instance object will trigger a memory leak when the extension is a SubjectAltName. IE when str() is called and the condition if _lib.NID_subject_alt_name == self._nid triggers return self._subjectAltNameString()

proposed solution. Not sure I suspect GENERAL_NAMES_free may need to be registered as a garbage collection function at some point. I also noticed the GENERAL_NAMES_free is has no bindings in cryptography hazmat. :( Investigating.

[crc32a]

proposed solution is to expose hazmat bindings from cryptography project for libcrypto function GENERAL_NAMES_free and call this method before exiting the _subjectAltNameString method of X509Extentions.

Example of using GENERAL_NAMES_free is https://github.com/rackerlabs/pyopenssl/commit/a479a74820619da13dfab8925cf49c4f766b6536

[exarkun]

Thanks. This sounds reasonable. pyOpenSSL has an informal memory leak test suite in leakcheck. It would be great if a fix for this issue could include a new leak check that demonstrates the problem has been fixed.

[crc32a]

yea I was gonna ask about how to go about testing this. I was thinking I could do this in leakcheck/crypto.py but I don't know how memory is being measured. I was testing this through valgrind which was painful. What are the leak check stradegies you'll use. I was pretty much just looking at lost blocks from valgrind as well as looking at the memory usage clime. If not I'm sure I'll figure it out.

[crc32a]

ok I think I got it. Writing the test.

[exarkun]

Why did you close this issue?

[crc32a]

cause it seemed to be duplicated in issue #140

[hynek]

Fixed via #252