Am 19.03.2018 um 15:13 schrieb Christopher Schultz:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Mark,
On 3/19/18 9:54 AM, Mark Thomas wrote:
On 19/03/18 13:52, Christopher Schultz wrote:
All,
I'm guessing this is mostly directed towards Rainer: can someone
look at https://bz.apache.org/bugzilla/show_bug.cgi?id=53940?
It's got a proposed patch and IMO makes sense to implement.
I'm not familiar enough with OpenSSL and the way that the SSL
engine works to know if this is a valid technique.
Most people don't use CRLs so it won't affect their performance
or anything like that. But those who do rely on a CRL can't
afford to bounce their Tomcat instance or connector just to
pick-up an updated CRL .
Can't we just close that as WONTFIX on the grounds that you just
trigger the reload of the TLS config in Tomcat?
It seems reasonable, but I believe this patch looks at the CRL's
reload "schedule" (I didn't know CRLs had such as thing) and respects
it. So Tomcat could auto-reload appropriately without having to set up
e.g. cron to reload on a schedule.
Also, I didn't realize that the reload was working for native-based
connectors. Now that I think about it, I think you said at one point
that we are simply relying on a finalizer to clean-up after abandoned
native SSL engine resources rather than going through the trouble to
maintain our own reference-counting infrastructure. So I guess that's
a moot point.
I'm okay closing this as WONTFIX with a note saying "issue a reload
command yourself". The original poster can come back to request this
feature specifically if manual-reloading is not acceptable.
Having only looked very shortly, there could be an issue with c->crl
being freed and reinitialized. If that is shared between threads, we
might get crashes under load or other misbehavior and instead would need
a more atomic way of updating.
I hope I find some time and can look at httpd, whether it supports such
a feature and how it is done there.
Regards,
Rainer
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
