On a restart of a service using auth_token middleware, the last modified time of the revocation list file is checked to decide whether to get the fresh list from keystone. In server timezones that are ahead of UTC, this compares a local time with UTC. This means whenever a service is restarted it doesn't update the revocation list for the length of the timezone offset from UTC. Where I live that's 10 hours. I'm beginning to rue my Australian heritage...
Note: this is only an issue for servers with timezones set ahead of UTC, and it only delays the first update. Updates after that obey token_revocation_list_cache_timeout.
https://github.com/openstack/python-keystoneclient/blob/fca985c09e11c581b61b9edcae19673e3112093a/keystoneclient/middleware/auth_token.py#L1061-L1092
>>> import os, datetime
>>> from keystone.openstack.common import timeutils
>>> os.path.getmtime('/var/lib/nova/keystone-signing/revoked.pem')
1374563990.4148088
>>> datetime.datetime.fromtimestamp(1374563990.4148088)
datetime.datetime(2013, 7, 23, 17, 19, 50, 414809)
>>> timeutils.utcnow() < datetime.datetime.fromtimestamp(mtime)
True
The modification time should be converted to UTC:
>>> timeutils.utcnow() < datetime.datetime.utcfromtimestamp(mtime)
False
While this is definitely a bug, i don't think it warrants an advisory, since the exploitation scenario is a bit unlikely (server not set to UTC time, then restarted) and the impact is limited (revoked tokens are valid for slightly more time).
My take would be to open this publicly and get it fixed (and backported if necessary). Thoughts ?