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
signature.asc
Description: PGP signature
-- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel