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
underlying problem.
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
>
> https://bazaar.launchpad.net/~apport-hackers/apport/trunk/view/head:/apport/hookutils.py#L517
>
> 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
> levels.
Agreed.
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:
https://salsa.debian.org/mariadb-team/mysql/blob/mysql-5.7/debian/master/debian/additions/source_mysql-5.7.py#L24
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.
Robie
