Open Stack

From Jamie Lennox:
>> We handle this in the keystoneclient Session object by just printing REDACTED or something similar. 
>> The problem with using a SHA1 is that for backwards compatability we often use the SHA1 of a PKI token
>> as if it were a UUID token and so this is still sensitive data. There is working in keystone by morganfainberg
>> (which i think was merged) to add a new audit_it which will be able to identify a token across calls without
>> exposing any sensitive information. We will support this in session when available. 

From Sean Dague
> So the problem is that means we are currently leaking secrets and making the logs unreadable.

> It seems like we should move forward with the {SHA1} ... and if that is still sensitive, address that later. 
> Not addressing it basically keeps the exposure and destroys usability of the code because there is so much garbage printed out.

I understand Sean's point about debugging.  Right now the glanceclient is just printing ***.  So it isn't printing a lot of excess and isn't leaking anything sensitive.  The other usability concern with the ***  that Sean previously mentioned was having a short usable string might be useful for debugging.

Morgan and Jamie, You think switching to SHA1 in actually adds a potential security vulnerability to glanceclient that doesn't exist now. If that is true, I think it would override the additional debugging concern of using SHA1 for now.  Can you please confirm?  

If only for consistency sake, I could switch to "TOKEN_REDACTED" like the code sample Morgan sent. [1]

[1] https://github.com/openstack/python-keystoneclient/blob/01cabf6bbbee8b5340295f3be5e1fa7111387e7d/keystoneclient/session.py#L126-L131