On Sat, Mar 17, 2018 at 06:09:25PM +0100, Sebastien Bacher wrote:
> The report pointed out that private info have been included in a report
> through JournalError.txt, and the solution applied was to change apport
> to include errors level messages only and not warning.
IMHO, not logging warning level messages is too blunt an instrument to
fix this bug. And it doesn't really fix it either - the next time it
might be that private data is leaked via an error rather than a warning.
IMHO, private information should never be leaked to logs by default, by
being obfuscated at source. An exception might be if a developer
explicitly and specifically turns on such an option having had the
opportunity to understand the consequences and take the necessary care.
I also think that while private information should of course be removed,
the log line should still be present (eg. "Sent: <private information
removed>" instead of nothing at all). Developers don't usually need to
know a specific secret, but the fact that the event happened is
sometimes very useful for debugging.
This isn't just for apport: people doing community support (such as IRC,
askubuntu.com, etc) quite reasonably encourage the pastebinning of
appropriate logs, and just doing something in apport will not fix this
In this case, I don't know enough about the stack in question and I
wasn't able to gather this from reading the logs. Is the problem that
one process is setting a secret in an environment variable and another
process is "innocently" reporting an environment variable that has been
set not knowing that it is a secret? Perhaps the way the stack operates
needs to be revisited if so.
> The xession logs are filtering on "safe" keywords, maybe one option
> would be to do something similar for the journal
> Another thing we could/should do is to review the logs and fix programs
> that are logging too much details to the journal as the warning/error
For example, in MySQL, we once had an edge case reported where it did
leak passwords (LP: #1574458). It was treated as an upstream bug which
got fixed. In the meantime, we SRU'd an apport workaround to amend the
known bad strings. This code is still present:
I think this is a reasonable pattern to follow: treat it as a privacy
leak bug, fix the software upstream to stop logging it by default, and
distro-patch or adjust apport hooks to work around the problem until the
upstream fix arrives.