In bug 1151800, Heroku to papertrail logging was set up using the 'standalone account' method here: http://help.papertrailapp.com/kb/hosting-services/heroku/ See also: https://devcenter.heroku.com/articles/log-drains However as I understand it, the syslog:// protocol isn't encrypted, so we need to check that things like oauth keys are not outputted to the logs at any point.

IMO we should not be putting the oauth credentials in the query string. The oauth spec discourages against this behaviour: http://self-issued.info/docs/draft-ietf-oauth-v2-bearer.html#query-param This would avoid leaking them in the Heroku logs, as well as the recent instance where they were leaked in the autophone logs. IMO we should stop using the oauth2 package - it's inactive (no commits since December 2011) and does not support using anything other than the query string for the keys: https://github.com/simplegeo/python-oauth2/issues/114 The work in bug 1160111 will presumably move us away from oauth2, so should fix the problem here.

Opening this bug up, since the Heroku instance is only a prototype, so this doesn't need to be confidential. Marking comment 1 as private (not sure what security group it defaults to), since it contains oauth credentials for Heroku.

Once bug 1212936 is fixed, I'll double check no other secrets are present in the logs, then we can call this done :-)

We're all good here, no oauth use in the papertrail logs now (unsurprisingly): https://papertrailapp.com/systems/treeherder/events?q=oauth And the hawk MAC only appears for errors, eg: https://papertrailapp.com/systems/treeherder/events?q=hawk ...which is: (a) useful (b) not a problem, since even knowing them you can't derive the secret apart from a bruteforce attack, which given we use a UUID as the secret, should be unlikely