Tone down the comment around SSL_set_tlsext_status_ocsp_resp. (#764)
The ownership semantics of SSL_set_tlsext_status_ocsp_resp are not as
complex as the comment suggests. There's no leak or complex lifetime.
It's an ownership transfer of an OPENSSL_malloc'd buffer. The
documentation is lacking, and making the copy internally would have been
tidier (though less efficient if the OCSP response where generated by
i2d_OCSP_RESPONSE), but this sort of thing has precedent in OpenSSL's
API.
diff --git a/src/OpenSSL/SSL.py b/src/OpenSSL/SSL.py
index 0a2fe48..5cf39c0 100644
--- a/src/OpenSSL/SSL.py
+++ b/src/OpenSSL/SSL.py
@@ -523,13 +523,8 @@
if not ocsp_data:
return 3 # SSL_TLSEXT_ERR_NOACK
- # Pass the data to OpenSSL. Insanely, OpenSSL doesn't make a
- # private copy of this data, so we need to keep it alive, but
- # it *does* want to free it itself if it gets replaced. This
- # somewhat bonkers behaviour means we need to use
- # OPENSSL_malloc directly, which is a pain in the butt to work
- # with. It's ok for us to "leak" the memory here because
- # OpenSSL now owns it and will free it.
+ # OpenSSL takes ownership of this data and expects it to have
+ # been allocated by OPENSSL_malloc.
ocsp_data_length = len(ocsp_data)
data_ptr = _lib.OPENSSL_malloc(ocsp_data_length)
_ffi.buffer(data_ptr, ocsp_data_length)[:] = ocsp_data