Re: [openstack-dev] [oslo.utils] allow strutils.mask_password to mask keys dynamically
On 03/20/2015 11:43 AM, Doug Hellmann wrote: Excerpts from Matthew Van Dijk's message of 2015-03-20 15:06:08 +: I’ve come across a use case for allowing dynamic keys to be made secret. The hardcoded list is good for common keys, but there will be cases where masking a custom value is useful without having to add it to the hardcoded list. Can you be more specific about what that case is? My concern with making some keys optional is that we'll have different security behavior in different apps, because some will mask values that are not masked in other places. Part of the point of centralizing behaviors like this is to keep them consistent across all of the projects. I think I may have been the first to suggest this way back when, and at the time my thought was that it's weird for consumers of a library to have to push a change into the library itself for things that might be pretty specific to their application. That said, the oslo libs are not entirely normal in this respect. They're also an opinionated set of modules that make it easy to do things The OpenStack Way, so in that respect I agree that it's probably good to keep the list of masked keys the same across applications. So I think at this point I'm backing off my stance that this is something we _should_ do for sure, and will take the view that it's something we _could_ do if a compelling argument is made. /2 cents I propose we add an optional parameter that is a list of secret_keys whose values will be masked. There is concern that this will lead to differing levels of security. But I disagree as either the message will be masked before passing on or mask_password will be called. In this case the developer should be aware of the incoming data and manually mask it. Keeping with a hardcoded list discourages use of the function. __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [oslo.utils] allow strutils.mask_password to mask keys dynamically
I’ve come across a use case for allowing dynamic keys to be made secret. The hardcoded list is good for common keys, but there will be cases where masking a custom value is useful without having to add it to the hardcoded list. I propose we add an optional parameter that is a list of secret_keys whose values will be masked. There is concern that this will lead to differing levels of security. But I disagree as either the message will be masked before passing on or mask_password will be called. In this case the developer should be aware of the incoming data and manually mask it. Keeping with a hardcoded list discourages use of the function. __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [oslo.utils] allow strutils.mask_password to mask keys dynamically
Excerpts from Matthew Van Dijk's message of 2015-03-20 15:06:08 +: I’ve come across a use case for allowing dynamic keys to be made secret. The hardcoded list is good for common keys, but there will be cases where masking a custom value is useful without having to add it to the hardcoded list. Can you be more specific about what that case is? My concern with making some keys optional is that we'll have different security behavior in different apps, because some will mask values that are not masked in other places. Part of the point of centralizing behaviors like this is to keep them consistent across all of the projects. I propose we add an optional parameter that is a list of secret_keys whose values will be masked. There is concern that this will lead to differing levels of security. But I disagree as either the message will be masked before passing on or mask_password will be called. In this case the developer should be aware of the incoming data and manually mask it. Keeping with a hardcoded list discourages use of the function. __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
