Huh. That's actually not a terrible idea to try and filter it at the
log level as well. For background there's a thing you can do that
allows you to not print the state of some processes which is where
we've always focused. But maybe keying on something a bit more
specific before logging it might also be a decent stop gap.
On Thu, Sep 15, 2016 at 7:24 PM, Paul Hammant <p...@hammant.org> wrote:
> So it is user-creation (debug log level) and crashes. I was thinking an
> exclusion regex might do it for the former
> sed 's/.ini', Config: (.*)},"\S*"}'\n/.ini', Config:
> With a config option:
> level = debug
> log-sed-redaction=s/.ini', Config: (.*)},"\S*"}'\n/.ini', Config:
> Just a thought.
> - Paul
> On Thu, Sep 15, 2016 at 8:41 AM, Robert Newson <rnew...@apache.org> wrote:
>> 100% agree that we shouldn't but it's hard to guarantee it never happens,
>> hence the warning. Passwords are held in process state so we can
>> authenticate to remote sources and targets while replicating. Crashes of
>> those processes write state dumps to the log.
>> We can do better but it will involve some re-engineering of internals.
>> We'll get it done but , for now, we can only warn you about the problem.
>> Sent from my iPhone
>> > On 15 Sep 2016, at 11:44, Paul Hammant <p...@hammant.org> wrote:
>> > In http://guide.couchdb.org/draft/security.html it is disclosed that
>> > passwords are written to the log if the debug level is 'debug' level. I'm
>> > not sure that's good practice. I do not think Couch should log passwords
>> > at any log level, and I think others might agree.
>> > At the very least it should be a specific setting in the config:
>> > [log]
>> > level = debug
>> > log-passwords = false // proposed :)
>> > Thoughts?
>> > - Paul