Under low memory conditions, we're catching the OutOfMemory exception in the AbstractReloadingMetadataProvider class to log it, but it's only logged on DEBUG.
We catch the exception it rethrows in the refresh thread, but that doesn't get logged, so all the log shows on INFO is a stream of Next refresh time is... messages that make it appear to be checking for changes but not finding any.
We should also review the service reload code for any similar issue.
trscavo@ncsa.illinois.eduSeptember 18, 2015 at 7:51 PM
Edited
To work around this issue add the following logger to /opt/shibboleth-idp/conf/logging.xml:
Brent PutmanSeptember 17, 2015 at 8:40 PM
I don't personally see it as a security vulnerability either. At least doesn't seem to fit the historical categories.
Yes, I'm sure we'll have another v2 release with this fix in it. We also have the JSSE bug to fix, so I imagine we'll get at least one release out soon-ish, and then a final rollup one of all existing bugs to be fixed at year's end before we go to security-only maintenance (if there are any new ones at that point).
Scott CantorSeptember 16, 2015 at 9:18 PM
I don't think this is a security vulnerability, but I can't imagine we won't do one final bug-fix patch release at year end before we go into security-only maintenance. Brent's call though.
trscavo@ncsa.illinois.eduSeptember 16, 2015 at 4:15 PM
Edited
Will this issue be treated as a security vulnerability? Put another way, will this issue warrant a new release of V2?
Under low memory conditions, we're catching the OutOfMemory exception in the AbstractReloadingMetadataProvider class to log it, but it's only logged on DEBUG.
We catch the exception it rethrows in the refresh thread, but that doesn't get logged, so all the log shows on INFO is a stream of Next refresh time is... messages that make it appear to be checking for changes but not finding any.
We should also review the service reload code for any similar issue.