https://issues.apache.org/bugzilla/show_bug.cgi?id=54357
--- Comment #19 from Kaspar Brand <[email protected]> --- (In reply to Alex Bligh from comment #16) > 1. Does the OCSP somehow requires a state per vhost - for instance what > happens if 2 sites have a different stapling_force_url for the same > certificate? As SSLStaplingForceURL is a vhost ctx directive, wouldn't this > introduce a back compatibility problem? No, it doesn't. stapling_renew_response() favors stapling_force_url over all certs for a given vhost, i.e. any OCSP URI from stapling_cert_info (i.e. the cert itself) is ignored in this case. > 2. Does this work with apache's threading model without further mutexes? Do > I then need to worry about concurrent accesses to the stapling info in a way > I didn't before? stapling_cert_info is basically an "init-once" thing - i.e., it's only populated at startup (in ssl_init_server_certs()) and therefore different from the stapling_cache. > 3. If I make this change, presumably the check for ""ssl_stapling_init_cert: > certificate already initialized!"" should go. Yes, exactly, I was expecting you to figure this out. (In reply to Alex Bligh from comment #17) > * 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. Previously the SHA-1 hash was used as a key for the OCSP response cache (mc->stapling_cache), and as there was ex_info attached to each certificate, it was convenient to have it only calculated once. But now that we always have to calculate the hash in stapling_cb()/stapling_get_cert_info() anyway, we could just pass it directly to stapling_cache_response() and stapling_get_cached_response() (these are the only places where cinf->idx is still used) and avoid the reduntant storage. I.e., you could merge the code from staping_get_cert_info() right into stapling_cb() and use a local "idx" which you would pass as an argument to stapling_get_cached_response() and stapling_renew_response() (which in turn would supply it to stapling_cache_response()). -- 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]
