Page MenuHomePhabricator

Standard process for dealing with public OAuth consumer secrets
Open, LowPublic

Description

Public OAuth credentials on Toolforge tools are an unfortunately common issue. Whilst the envvars service will hopefully make those less of an issue on the long term, I don't see the number of misconfigured tools decreasing on the short term. I wonder if there should be a standard process to follow especially in cases where the maintainer does not respond. Ssomething like this would be reasonable in my mind:

  • Add tool maintainers to the Phabricator task, and send an email to them
  • If the grant has any sensitive rights (which I believe is a MW defined term these days), revoke the consumer token immediately
  • If the maintainers do not respond within a reasonable timeframe (say, two weeks), revoke the consumer
  • If the issue goes unfixed within a slightly longer timeframe (say a month or two) revoke the consumer

Event Timeline

+1 to this as a general process to follow. The first two procedures are what have organically developed over the years for cloud/toolforge secret exposures like this, though this process has been missing eventual enforcement, which the last two procedures would provide. I believe adding generalized secret-scanning tools to cloud/toolforge to continually monitor for secret exposure has also been discussed at times, which would be a good idea IMO, if such tools could be properly-tuned and were not too noisy.

Sounds good to me. The document / guideline in question could also suggest some standard Phabricator tags to add – I believe the usual are Tools (if there’s no more specific tag – I was advised against Toolforge IIRC) and Vuln-Infoleak?