[KARAF-6985] FeatureServiceImpl.doProvision() prints a stack trace to stderr on Throwable, bypassing any logging patterns that may be setup

• Type: Bug
• Status: Open
• Priority: Major
• Resolution: Unresolved
• Affects Version/s: 4.2.8
• Component/s: karaf
• Assignee: Unassigned
• Reporter: Nate
• Created: 06/Jan/21 08:42
• Updated: 06/Jan/21 15:09

Description

In org.apache.karaf.features.internal.service.FeaturesServiceImpl, in the doProvision(Map, Map, State, Map, EnumSet, String), any Throwables that get caught have their stack trace printed to stderr, ignoring any logging framework patterns that are setup for message formatting or replacing sensitive information. This means that if this exception were to contain any sensitive information in the message of the exception or any suppressed exceptions, this information won't get replaced by log4j2 patterns designed to replace such information.

Background information about our situation: we have a dual karaf server/client configuration where the client sometimes needs to download and install a new Karaf feature jar from the server machine. We support SSH and FTP for this, and in order to do this we register custom Pax Url HandlerActivators that work based on a url that contains FTP or SSH credentials. These urls are only used internally within Karaf to communicate required information between the code that asks to download the feature and the HandlerActivator that downloads the feature. We can't pass the data directly because the Karaf FeaturesService is in between: we tell Karaf to download and install a feature jar, which then delegates the downloading of this feature to our custom HandlerActivator, which takes this URL, parses it to determine the username and password, then configures and launches an FTP or SSH client to download the feature and return it to the FeaturesService..

if there's a problem with the FTP or SSH connection, then the HandlerActivator fails to download the file and throws an exception. This exception is caught by the SimpleDownloadTask.download(), which is then recaught and rethrown by the AbstractRetryableDownloadTask, which is then recaught by the MavenDownloadManager. Eventually, this exception is then caught by the above mentioned FeatureServiceImple.doProvision(), and then printed to stderr. Along the way, the SimpleDownloadTask and AbstractRetryableDownloadTask both put the full URL in the message of their rethrown exception, which in our case contains plaintext credentials of the FTP or SSH server on our Karaf server that is being contacted. Then the doProvision catch clause prints this full stacktrace to stderr, including the URL, and bypassing the log4j2 pattern that replaces the password in the URL.