On Fri, Sep 12, 2014 at 12:02 PM, Tripp, Travis S
wrote:
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
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]
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.
On Fri, Sep 12, 2014 at 12:02 PM, Tripp, Travis S travis.tr...@hp.com
wrote:
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
@lists.openstack.org
Subject: Re: [openstack-dev] masking X-Auth-Token in debug output - proposed
consistency
On Fri, Sep 12, 2014 at 12:02 PM, Tripp, Travis S
wrote:
From Jamie Lennox:
We handle this in the keystoneclient Session object by just printing
REDACTED or something similar
Hi Travis,
By and large we have addressed this in the Session code within Keystoneclient
via the function here (and other similar cases):
https://github.com/openstack/python-keystoneclient/blob/01cabf6bbbee8b5340295f3be5e1fa7111387e7d/keystoneclient/session.py#L126-L131
If/when Glanceclient is
- 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
If these tokens are variable length up to 4k, it will make the search space
much to large to construct any kind of useful table. They become infeasible
for A-z0-9 variable-length password sets above 10 chars if you include
every permutation. Assuming the tokens are generated in a very predictable
Morgan Fainberg wrote:
I’ve been looking over the code for this and it turns out plain old SHA1
is a bad idea. We recently had a patch land in keystone client and
keystone to let us configure the hashing algorithm used for token
revocation list and the short-token ids.
I’ve updated my
On Wed, Jun 11, 2014 at 9:47 PM, Sean Dague s...@dague.net wrote:
Actually swiftclient is one of the biggest offenders in the gate -
http://logs.openstack.org/96/99396/1/check/check-tempest-dsvm-full/4501fc8/logs/screen-g-api.txt.gz#_2014-06-11_15_20_11_078
I'd be happy to fix that but that
On Thu, Jun 12, 2014 at 12:58 PM, Chmouel Boudjnah chmo...@enovance.com
wrote:
On Wed, Jun 11, 2014 at 9:47 PM, Sean Dague s...@dague.net wrote:
Actually swiftclient is one of the biggest offenders in the gate -
On 06/12/2014 07:42 AM, Chmouel Boudjnah wrote:
On Thu, Jun 12, 2014 at 12:58 PM, Chmouel Boudjnah chmo...@enovance.com
mailto:chmo...@enovance.com wrote:
On Wed, Jun 11, 2014 at 9:47 PM, Sean Dague s...@dague.net
mailto:s...@dague.net wrote:
Actually swiftclient is one
On Thu, Jun 12, 2014 at 1:59 PM, Sean Dague s...@dague.net wrote:
The only thing it makes harder is you have to generate your own token to
run the curl command. The rest is there.
Well I would have imagine that the curl command debug are here so people
can easily copy and paste them and/or
I'm hoping we can just ACK this approach, and get folks to start moving
patches through the clients to clean this all up.
just an fyi, in pyCADF, we obfuscate tokens similar to how credit cards
are handled: by capturing a percentage of leading and trailing characters
and substituting the
Sorry to interrupt this discussion.
Sean,
Since I'm working the neutron client code change, by looking at your code
change to nova client, looks like only X-Auth-Token is taken care of in
http_log_req. There is also password in header and token id in response. Any
particular reason
This stems a bit further than just reduction in noise in the logs. Think of
this from a case of security (with centralized logging or lower privileged
users able to read log files). If we aren’t putting passwords into these log
files, we shouldn’t be putting tokens in. The major functional
For both the security and the log line length, Swift is by default just
displaying the first 16 bytes of the token.
--John
On Jun 11, 2014, at 12:39 PM, Morgan Fainberg morgan.fainb...@gmail.com wrote:
This stems a bit further than just reduction in noise in the logs. Think of
this from a
Actually swiftclient is one of the biggest offenders in the gate -
http://logs.openstack.org/96/99396/1/check/check-tempest-dsvm-full/4501fc8/logs/screen-g-api.txt.gz#_2014-06-11_15_20_11_078
On 06/11/2014 03:44 PM, John Dickinson wrote:
For both the security and the log line length, Swift is by
On 06/11/2014 03:01 PM, Sean Dague wrote:
We've had a few reviews recently going around to mask out X-Auth-Token
from the python clients in the debug output. Currently there are a mix
of ways this is done.
In glanceclient (straight stricken)
X-Auth-Token: ***
The neutronclient proposal -
Fainberg
From: Jay Pipes jaypi...@gmail.com
Reply: OpenStack Development Mailing List (not for usage questions)
openstack-dev@lists.openstack.org
Date: June 11, 2014 at 12:49:35
To: openstack-dev@lists.openstack.org openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] masking X-Auth-Token
20 matches
Mail list logo
