[
https://issues.apache.org/jira/browse/DELTASPIKE-382?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13684609#comment-13684609
]
Gerhard Petracek commented on DELTASPIKE-382:
---------------------------------------------
@mark:
in config-sources like jndi you don't only have values configured via/for
deltaspike.
exposing info from jndi is way more "common", because it doesn't even have to
be the goal to expose sensitive info.
like you said - if e.g. an operations guy is interested in all config-values
(not just configured via/for ds) and just logs everything, any masking done in
ds is useless.
-> i don't agree because (again):
checking logs before exposing them is imo by no way optional esp. if you store
passwords as plain text in a common config-source which might be logged for
many other reasons.
that would be just highly careless, since there might be even other logged
confidential info which isn't stored in a config.
> mask out passwords and other credentials
> ----------------------------------------
>
> Key: DELTASPIKE-382
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-382
> Project: DeltaSpike
> Issue Type: New Feature
> Components: Configuration
> Affects Versions: 0.4
> Reporter: Mark Struberg
> Assignee: Mark Struberg
> Fix For: 0.5
>
>
> Our configuration mechanism currently logs all the configured values.
> This makes it hard to use it for passwords and stuff.
> I suggest we introduce some specific prefix property to configure configs
> which contain sensitive information.
> For the key 'some.random.password' this could look like:
> deltaspike_config.mask.some.random.password=true
> In the log we would in this case just output the information whether and
> where we did find some value, but not print the details for all configs which
> start with all of the configured masks.
> I'm not yet sure though how to configure this best. Suggestions appreciated!
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
