On 09/11/2014 08:49 PM, Jamie Lennox wrote:
> ----- Original Message -----
>> From: "Travis S Tripp" <travis.tr...@hp.com>
>> To: "OpenStack Development Mailing List (not for usage questions)" 
>> <openstack-dev@lists.openstack.org>
>> Sent: Friday, 12 September, 2014 10:30:53 AM
>> Subject: [openstack-dev] masking X-Auth-Token in debug output - proposed 
>> consistency
>> Hi All,
>> I’m just helping with bug triage in Glance and we’ve got a bug to update how
>> tokens are redacted in the glanceclient [1]. It says to update to whatever
>> cross-project approach is agreed upon and references this thread:
>> http://lists.openstack.org/pipermail/openstack-dev/2014-June/037345.html
>> I just went through the thread and as best as I can tell there wasn’t a
>> conclusion in the ML. However, if we are going to do anything, IMO the
>> thread leans toward {SHA1}, with Morgan Fainberg dissenting.
>> However, he references a patch that was ultimately abandoned.
>> If there was a conclusion to this, please let me know so I can update and
>> work on closing this bug.
> 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. 

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.

> The best i can say for standardization is that when glanceclient adopts the 
> session it will be handled the same way as all the other clients and 
> improvements can happen there without you having to worry about it. 

Please don't let this be the perfect is the enemy of the good here.
Debugging OpenStack is hard. Not fixing this keeps it harder.


Sean Dague

OpenStack-dev mailing list

Reply via email to