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:
> \1},"--redacted--"}'\n/'
>
> With a config option:
>
>   [log]
>   level = debug
>   log-sed-redaction=s/.ini', Config: (.*)},"\S*"}'\n/.ini', Config:
> \1},"--redacted--"}'\n/
>
> 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
>>

Reply via email to