[
https://issues.apache.org/jira/browse/COUCHDB-1606?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13881064#comment-13881064
]
Adam Kocoloski commented on COUCHDB-1606:
-----------------------------------------
Yes, this is a thing. The Erlang VM does have a robust fix for the issue; you
can have a process declare itself as sensitive:
{code}
process_flag(sensitive, true)
{code}
It does have some interesting ramifications:
{quote}
Set or clear the sensitive flag for the current process. When a process has
been marked as sensitive by calling process_flag(sensitive, true), features in
the run-time system that can be used for examining the data and/or inner
working of the process are silently disabled.
Features that are disabled include (but are not limited to) the following:
Tracing: Trace flags can still be set for the process, but no trace messages of
any kind will be generated. (If the sensitive flag is turned off, trace
messages will again be generated if there are any trace flags set.)
Sequential tracing: The sequential trace token will be propagated as usual, but
no sequential trace messages will be generated.
process_info/1,2 cannot be used to read out the message queue or the process
dictionary (both will be returned as empty lists).
Stack back-traces cannot be displayed for the process.
In crash dumps, the stack, messages, and the process dictionary will be omitted.
If \{save_calls,N\} has been set for the process, no function calls will be
saved to the call saving list. (The call saving list will not be cleared;
furthermore, send, receive, and timeout events will still be added to the list.)
{quote}
> Replicator leaves plaintext password in logs
> --------------------------------------------
>
> Key: COUCHDB-1606
> URL: https://issues.apache.org/jira/browse/COUCHDB-1606
> Project: CouchDB
> Issue Type: Bug
> Components: Logging, Replication
> Affects Versions: 1.2
> Reporter: Nathan Vander Wilt
> Assignee: Bob Dionne
> Attachments: pwd log.txt
>
>
> While reviewing logs, I noticed that a password had been recorded in the logs
> as part of a replicator error.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
