https://issues.apache.org/bugzilla/show_bug.cgi?id=54357
Alex Bligh <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #32036|0 |1 is obsolete| | --- Comment #21 from Alex Bligh <[email protected]> --- Created attachment 32037 --> https://issues.apache.org/bugzilla/attachment.cgi?id=32037&action=edit v4 Proof of concept patch to address the issue v4 Proof of concept patch to address the issue: (v4) Remove OCSP stapling info from X509 ex_data Remove OSCP stapling info from X509 ex_data, and manage it within normal APR pools with SSLModConfigRec lifecyle. This is to address BZ 54357 and BZ 56919. Introduce a hash of stapling info indexed by the SHA1 hash of the certificate content. Note this code as been compile tested only at this stage and is submitted as a proof of concept. Changes since v3: * move stapling_cert_info to SSLModConfigRec Changes since v2: * change stapling_info to stapling_cert_info * move init of stapling_cert_info hash to modssl_ctx_init_server * Drop unnecessary memory allocation failure checks * Simply extraction of uri string into apr memory management * Free aia structure * In stapling_get_cert_info check for X509_digest failure * Use SHA_DIGEST_LENGTH not hardcoded 20 * Fix up second call to ssl_stapling_init_cert * Remove ssl_stapling_ex_init() declaration from ssl_private.h Changes NOT done since v3 that were suggested by Kaspar Brand * Drop use of idx member from cert_info structure. Reason: the index to the apr hash structure has to be held somewhere for all the recorded certificates. Whilst we do calculate the SHA1 hash on the fly, the apr hash algorithm needs something to compare it to (i.e. the SHA1s of all the recorded certificates) so it can index the correct URI. As the SHA1 value needs to be stored somewhere for each certificate, it might as well be stored in the struct. It's possible I've misunderstood what Kaspar was suggesting here. -- You are receiving this mail because: You are the assignee for the bug. --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
