[
https://issues.apache.org/activemq/browse/CAMEL-3099?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=61602#action_61602
]
Hadrian Zbarcea commented on CAMEL-3099:
----------------------------------------
@Willem,
Encryption has nothing to do with this, the issue is not not display a password
in clear in logs, jmx consoles etc. The patch hardcodes password and passphrase
to be considered as secrets. Always. Which may or may not be the case.
If you saw my comment in the message Lorrin sent to the users@ list, I was
thinking about the same issue and a solution I am working on now is to annotate
with @Secret fields that are considered, well, secrets and must never be
displayed in clear. I think that is a more general solution. We will then need
to document how to best provide secrets to camel, like properties files with
400 permissions, not use them as arguments in command lines, etc.
Obviously the credit still goes to Lorrin for reporting this :).
> passwords and other private data contained in URIs should not be logged in
> plaintext
> ------------------------------------------------------------------------------------
>
> Key: CAMEL-3099
> URL: https://issues.apache.org/activemq/browse/CAMEL-3099
> Project: Apache Camel
> Issue Type: Improvement
> Components: camel-core
> Reporter: Lorrin Nelson
> Assignee: Hadrian Zbarcea
> Priority: Minor
> Attachments:
> 0001-Reduce-risk-of-showing-passwords-in-URIs-by-adding-c.patch
>
>
> URIs with sensitive data are common and that URIs are frequently logged. I
> bumped into this myself most recently with an FTP consumer. I ended up with
> log messages like this:
> RemoteFileProducer 2010-08-31 16:21:45,459 -- INFO -- Connected and logged in
> to:
> Endpoint[sftp://myusern...@my.host.name/var/my/path?fileName=myFile.txt&password=yikesMyPassword]
> I propose a sane-defaults patch of modifying DefaultEndoint.java's toString
> to sanitize the URI by looking for URI params containing the tokens
> "password" or "passphrase" and rendering their value as "*******" instead of
> the actual value. Obviously this isn't always the right thing to do in every
> situation, but it seems appropriate for many endpoints. Any for which it is
> not appropriate could override toString.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
