>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
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
