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 <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 >>
