Nate created KARAF-6985:
---------------------------
Summary: FeatureServiceImpl.doProvision() prints a stack trace to
stderr on Throwable, bypassing any logging patterns that may be setup
Key: KARAF-6985
URL: https://issues.apache.org/jira/browse/KARAF-6985
Project: Karaf
Issue Type: Bug
Components: karaf
Affects Versions: 4.2.8
Reporter: Nate
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.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
