This bug was about sanitizing the secret tokens out of log messages. That code is working as intended. Bug #533769 shows that the log messages do have the secret tokens scrubbed. That bug also shows that an erlang crash dump still contains the secret tokens, and have not been scrubbed.
Regardless of the language, core dumps, backtraces, tracebacks, all may have sensitive information in them, and there are policies set up with the bugsquad triage guidelines to be sure that this info stays private. https://wiki.ubuntu.com/Bugs/HowToTriage/ Here is the logfile excerpt from the other bug: 2010-03-07 14:24:43,942 ERROR can't replicate 'rtg)test' 'http://localhost:47571/' <== {'source': 'rtg%29test', 'target': {'url': 'https://couchdb.one.ubuntu.com/u%2F630%2Fb96%2F52053%2Frtg%29test', 'auth': {'oauth': {'consumer_secret': 'HiddenHidd', 'token': 'Hidden', 'consumer_key': 'ubuntuone', 'token_secret': 'HiddenHiddenHiddenHiddenHiddenHiddenHiddenHiddenHiddenHiddenHiddenHiddenHiddenHi'}}}} Traceback (most recent call last): File "/usr/lib/python2.6/dist-packages/desktopcouch/pair/couchdb_pairing/couchdb_io.py", line 274, in replicate content=record) File "/usr/lib/pymodules/python2.6/couchdb/client.py", line 985, in post **params) File "/usr/lib/pymodules/python2.6/couchdb/client.py", line 1035, in _request raise ServerError((status_code, error)) ServerError: (500, ('case_clause', '{error,{{{case_clause,{error,illegal_database_name}}, [{couch_rep,open_db,2}, {couch_rep,do_init,1}, {couch_rep,init,1}, {gen_server,init_it,6}, {proc_lib,init_p_do_apply,3}]}, {child,undefined,"2d0327dd3a015c8572b199fb933effa1", {gen_server,start_link, [couch_rep, ["2d0327dd3a015c8572b199fb933effa1", {[{<<"source">>,<<"rtg%29test">>}, {<<"target">>, {[{<<"url">>, <<"https://couchdb.one.ubuntu.com/u%2F630%2Fb96%2F52053%2Frtg%29test";>>}, {<<"auth">>, {[{<<"oauth">>, {[{<<"consumer_secret">>, <<"hammertime">>}, {<<"token">>, <<"SRTj2PtxBblm3SCJXcZj">>}, {<<"consumer_key">>,<<"ubuntuone">>}, {<<"token_secret">>, <<"Secret!">>}]}}]}}]}}]}, {user_ctx,<<"Secret">>,[<<"_admin">>]}], []]},\n temporary,1,worker, [couch_rep]}}}')) In principle, I think it is a very bad idea to try and scrub data out of a python exception that goes into the log. This is a python exception wrapping an HTTP 500 errror from CouchDB, with an erlang crash report stuffed into the body of the 500 page. However, because the format of the erlang crash reports is so strict and regular, I wonder whether it would be reasonable to try and parse out the line " {<<"token_secret">>, <<"Secret!">>}". Even if we did this, it would not guarantee that couchdb crash info that went into the log file would be safe for the public to see. I think this bug should be put back to fix committed, and we should not try to sanitize python exceptions before they are written to the log. It's just my opinion though, if it's actually easy to do and there is some precedent for programs reaching in and stripping data out of exceptions before logging them, I'm willing to be convinced :) -- Replication log contains token and token secret so can't be pastebinned https://bugs.launchpad.net/bugs/460974 You received this bug notification because you are a member of Ubuntu Bugs, which is a direct subscriber. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
