>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]

OpenStack-dev mailing list

Reply via email to