[
https://issues.apache.org/jira/browse/KARAF-6985?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17259784#comment-17259784
]
Nate commented on KARAF-6985:
-----------------------------
I realize from the comment that this is probably intended because there might
not be a logger object, but it's still something that should be considered.
Maybe only do a printStackTrace() if there's no Log defined?
> 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
> Priority: Major
>
> 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)
